Пару раз мы облажались с обратным инжинирингом. При всей прелести и красоте этого словосочетания по факту оно означает: «давайте возьмем чье-то известное изобретение и попробуем вскрыть, как они это сделали, и сделать аналог. Наверняка ведь получится дешевле, и можно будет зарабатывать». Так вот, я крайне не рекомендую браться за обратный инжиниринг. Не стоит питать больших иллюзий, что вы можете за 3-5 миллионов рублей решить задачу, на которую какая-нибудь крупная корпорация потратила лет 20 и несколько миллионов долларов. Это все иллюзии, что можно «хоп-хоп и вскрыть». Порой куда проще сделать свое, чем пытаться разгадать чужие секреты.

По нескольким контрактам мы сорвали сроки или не получили прибыль, сработав в ноль.

Если вы считаете, что вы все успеете за 6 месяцев, не постесняйтесь попросить на работу год. С одной стороны, вы досрочно завершите работу, будете молодцом и попросите премию. А с другой, чаще всего заказчик зреет для проекта год-полтора-два, поэтому он сможет еще подождать, ничего страшного не произойдет.

В паре проектов мы порушили отношения с партнерами, потому что допустили возможность широкого общения разработчиков с заказчиком. Оказалось, что при прямом общении ученых и бизнесменов, даже при полном кураторстве инжиниринга, могут происходить совершенно невообразимые вещи. Ученый может с легкостью сказать: "Ну я не знаю, по-моему, разработка не удастся". Он может сделать это из лукавства или потому что настроение плохое, а для заказчика это всё, катастрофа, "Боже мой, мы зря вложили деньги!" Понятно, что всегда есть сомнения, но их нужно держать при себе и максимально работать на результат. И тогда чаще всего все получается. Если рассказывать о внутренних проблемах и своих бедах, то можно вызвать у заказчика мгновенное отторжение. Вот мы и встряли с тем, что контракты закончились раньше ожидаемого без достижения результата просто потому, что мы допустили избыточное общение разработчиков и заказчиков. Так лучше не делать.

Еще на старте,когда мы были молодыми и даже скорее маленькими инжиниринговыми людьми, мы пару раз косячнули, выполнив работу идеально на наш взгляд, но, как потом оказалось, заказчику нужно было нечто иное. Поэтому нам приходилось все переворачивать с ног на голову, исправлять и тратить свои деньги. Всем рекомендую тщательно готовить техническое задание, а лучше не полениться и составить преамбулу на полстраницы, в которой вы простыми русскими словами напишете описание проблемы, как вы её поняли сами. Условно: мы понимаем, что у заказчика есть вот такая вот задача, ее решение мы будем делать так-то, получим такой-то результат. И после этого уже должно идти ТЗ, которое вытекает из вашего понимания задачи. Тогда заказчик на этапе согласования ТЗ, прочитав преамбулу, увидит, правильно ли вы поняли его задачу. И это предотвратит беды взаимонепонимания с заказчиком.

В общем, залажали мы где-то в четырех случаях из 120. Я думаю, что это вполне себе приемлемый процент. При этом, важно, что наши заказчики ни в одном из этих четырех случаев не потратили свои деньги зря. Так или иначе результат был получен, либо мы вообще не брали оплаты.

А какие бы вы дали рекомендации по работе в инжиниринговом бизнесе и разработке? С какими проблемами вы встречались в своем бизнесе и как их решали?

Если материал оказался для вас полезным - поддержите проект и поделитесь записью!