Пять критических ошибок, которые могут привести к провалу в разработке стартапа

Старт разработки без сформированных требований к проекту

Мы много работаем со стартапами и часто видим одну комплексную проблему — бизнесмены не формируют требования к своему проекту, не очерчивают его границы. Они приходят с идеей, с набором гипотез. Но оценить сроки и бюджет невозможно — всё лежит у предпринимателя в голове, максимум — составлен список фич в Excel.

Если предприниматель приходит к опытным разработчикам, те предложат сначала разработать ТЗ, сделать макеты и юзер-стори, сформулировать бизнес-логику проекта.

Это хороший выход из ситуации — такое ТЗ можно предложить оценить другим разработчикам, получите срез рынка и сможете выбрать подходящую цену. Исследование занимает одну-две недели, в некоторых случаях дольше. Цена зависит от студии: кто-то предлагает делать за 50 000 рублей, кто-то может сделать за 300 000 рублей.

Но чаще у стартапера сильно ограниченный бюджет, и он попадает к неопытной команде с невысоким ценником. У них может не быть системного аналитика, не отработаны процессы уточнения требований. В результате они могут озвучить низкую цену, чтобы продать, но нюансы не проговорят, и будут разбираться в требованиях по ходу работы.

Велик риск, что в какой-то момент появится фича, с внедрением которой неопытный подрядчик вообще не сможет справиться.

Если требования к проекту не будут формализованы, подрядчик может предложить работать без оценки бюджета и сроков, на почасовке. Это нормальный вариант для фаундеров с техническим бэкграундом, которые умеют управлять разработкой и контролируют риски. 

Но если проект без отсутствия границ начинает основатель без технической экспертизы и неопытная команда, риски велики. Да, такой проет быстро стартует, но почасовка может привести к проблемам. Например, предприниматель в процессе озвучит фичу, которую неопытный подрядчик просто не сможет реализовать, или погрузится в нее на много часов — получится не развивающийся стартап, а долгострой с непонятными перспективами.

К нам часто приходят стартаперы после таких попыток сделать быстро, дешево и без оценки — или потрачены деньги, а результата нет вообще, или разработчики торопятся и совершают много ошибок, которые потом очень дорого править.

Чтобы избежать таких проблем, попробуйте сами формализовать требования:

• Опишите цель и суть бизнес-проекта. Лаконично, чтобы поняли другие люди, сильно не углубляясь — так, будто у вас короткий питч для инвестора.
• Перечислите роли пользователей в сервисе.
• Распишите функциональность — что можно сделать и у какой роли есть доступ к такой функции.
• Сделайте приоритизацию всех функций — что важно сделать сейчас, а что можно перенести на попозже.
• Пропишите список интеграций — с какими сервисами проект должен взаимодействовать, например, с банками, с картами.
• Создайте веб-фреймы, то есть предварительные макеты. Не думайте о дизайне, просто накидайте в любой программе окна с кнопками, расставьте их в последовательности, как их увидят пользователи.

Процесс формирования у стартапера может занять несколько часов. Но даже такой труд даст колоссальный результат — это очень сильно упростит разработку, подрядчики поймут суть проекта, смогут быстро уточнить нюансы и оценить задачу.

Если увлечетесь процессом, посоветую книгу Карла Вигерса и Джоя Битти «Разработка требований к программному обеспечению». Или закажите формализацию и оценивайте сроки и бюджет по ней.

Недооценка сложности задачи из-за недостатка опыта и компетенций

Недостаток опыта разработчика в предметной области всегда негативно влияет на сроки проекта.

Допустим, предприниматель делает финтех-сервис и пришел к неопытным подрядчикам, которые глубоко в эту сферу не погружались. Даже если все требования формализованы, разработчики могут неверно их оценить — например, они работали с парой банков и думают, что с остальными интеграция устроена примерно так же.

На деле же появляется платежная система, в которой всё организовано иначе — и всё, не факт, что разработчики быстро разберутся в нюансах и сделают хорошо. Пострадает или срок, или качество проекта. 

Если команда никогда не работала с аналогичным проектом, то вероятность провала очень высока. Лучший способ решить эту проблему — искать подрядчика, который уже работал в предметной области. Особенности если это нетривиальные сферы, например, блокчейн и криптовалюты, финтех, медтех.

Конечно, они дороже. Но это окупится, потому что они уже набили шишки на других проектах и знают, как их обойти. Они посоветуют способ решить задачу, порекомендуют подходящий язык программирования, сразу предупредят, где могут быть проблемы с технологиями и со сроками. Чем больше опыта — тем меньше вероятность проблем.

Неготовность выбирать между качеством или скоростью

В разработке стартапов обычно есть две крайности:

1. Делать быстро, но не уделять много внимания архитектуре. Срок разработки сокращается, но в проекте могут появиться ошибки, на проверку качества кода не хватит времени, с масштабируемостью тоже будут проблемы. В какой-то момент всё может вообще сломаться, и придется переписывать заново.
2. Делать долго, но заботиться о качестве кода. Потратить время на подготовку архитектуры, заложить ресурсы для развития. Гипотезы в таком случае тестируются дольше, фичи внедряются медленнее. Зато проект в будущем будет проще и быстрее масштабировать, сроки и бюджет на внедрение фич тоже будут понятны.

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

Бывает, что нужно собрать что-то на коленке, проверить идею, готовность пользователей платить за услугу — отлично, значит, нужна команда без упора на качество продукта. Они понимают, как быстро внедрять фичи, могут прямо сказать — сделаем за пару дней, но качество будет страдать.

Только предупредите инвесторов, что проект у вас «костыльный», его в будущем возможно придется переписывать, это займет столько-то месяцев.

Если общая идея уже проверена, и вам нужно качество — идите к подрядчику, который специализируется на таком подходе. Подобный ближе нам.

Ориентируйтесь на бизнес-задачу. Не идите на поводу у подрядчика. Если вам нужно быстро проверить идею — не слушайте советов делать медленно и основательно. Просто предусмотрите риски и расставьте приоритеты.

Ошибка в планировании — игнорирование времени на исправление ошибок и доработки

В любых ИТ-проектах в процессе разработки возникает так называемый «технический долг». Это ситуации, когда разработчик использует некое компромиссное решение, «костыль». Допустим, нужно срочно ввести фичу, и разработчик игнорирует архитектуру, пишет код, который в будущем усложняет работу, мешает развитию проекта и может привести к багам.

Чтобы поддерживать качество и надежность кода и избежать накапливания технического долга, разработчики используют несколько приемов.

Например, можно покрывать код автоматическими тестами — это отдельный маленькие программы, которые сканируют весь код и проверяют его надежность. Проблема в том, что написание таких тестов может занимать около 30% времени самой разработки. И именно ими жертвуют в первую очередь, если хотят побыстрее внедрить фичу.

Или есть понятие «историчность данных» — когда разработчики закладывают в базу данных возможность сохранять старые версии каких-либо данных.

Условный пример: если изменилась должность у сотрудника, ее можно просто поменять в базе, а можно указать новую должность, но сохранить упоминание о старой в нужном месте. Чтобы проработать эту историчность, нужно время. Если разработку надо ускорить, этой фиксацией жертвуют. 

Для небольшого проекта это не проблема. Но если проект масштабируется и в нем часто меняются данные, то их отслеживание с каждым изменением занимает у разработчика всё больше времени. Он не может просто прийти в нужную часть проекта и что-то сделать — сначала ему нужно разобраться в куче связей между данными.

Технический долг накапливается, и если не выделять время на его исправление, проект пострадает:

• Изменения в проект становится добавлять сложнее из-за постоянных ошибок;
• Скорость разработки существенно замедлится — люди будут не вводить новые фичи, а разбираться, как работают старые;
• Команда рискует выгореть — чем ниже качество кода, тем сложнее работать. Люди могут срываться друг на друга, начнут думать, что они плохие специалисты, ругаться с коллегами.

Если команда в найме, стоит выделить время не только на внедрение новых фич, но и на рефакторинг кода, на отработку технического долга.

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

Расчет на быстрое формирование команды

После проверки идеи от стартапа обычно ждут бурного роста, особенно если проект попал в акселератор. Потребуется быстро расширить команду, и об этом нужно думать заранее.

Как директор студии разработки могу сказать — найти хороших разработчиков на рынке труда сейчас очень тяжело. Вам придется конкурировать в зарплатах, условиях труда и интересных задачах с банками и зарубежными компаниями. Причем просто заваливать деньгами соискателей — не самый эффективный путь, нужно придумать, чем еще можно заинтересовать разработчиков.

• Решение интересного проекта, который влияет на жизнь. В определенный момент разработчику становится неинтересно работать просто за деньги, особенно когда базовые потребности закрыты. Хочется приносить пользу, чувствовать энтузиазм. Если стартап может предложить такой интересный проект, отлично.
• Сформированный HR-бренд. Нужно не просто предлагать хорошие условия разработчикам, а еще и активно рассказывать про это. Придется качать PR-направление, вести контент-маркетинг, не только для клиентов, но и для потенциальных сотрудников. Я рекомендую делегировать это отдельным людям на фултайм.
• Делегирование срочных задач. Стартап необязательно должен развиваться за счет собственного технического штата. На начальном этапе многим достаточно ресурса внешнего подрядчика, аутсорсинговой компании. Когда проект вырастет, подрядчиков можно использовать для решения срочных задач, пока вы формируете собственный штат.
• Потенциальные доли в компании. Это стандарт для зарубежных компаний, но у нас формат еще не распространен. Поэтому опционы могут стать конкурентным преимуществом.
• Разработка на непопулярном языке. Это очень спорная тема, но у нас сработала. Мы используем Haskell, а этот язык привлекает разработчиков, которые уже много где покодили и понимают, что хотят работать именно с этой технологией. Haskell сложный и мощный, плюс мы не конкурируем с крупными банками и богатыми стартапами, потому что они обычно используют популярные языки.

Проблема в том, что если масштабироваться придется очень быстро, то найти сразу нескольких разработчиков на непопулярном языке сложно. Значит, нужно готовить почву заранее. Например, начать обучать неопытных разработчиков. Или сразу найти несколько аутсорс-команд, которые работают на этом языке, чтобы закрыть срочные и тяжелые задачи.

Кратко. Как не допустить ошибок, начиная разработку стартапа

Приступая к разработке MVP, важно одновременно делать всё быстро, но не допускать критических ошибок:

1. Начинать разработку без формализации требований. Вместо этого сначала опишите цель и суть бизнес-проекта, сделайте предварительные макеты, составьте список всех функций и расставьте их по приоритету.
2. Недооценить задачи из-за недостатка опыта и компетенций. Лучше обратиться к опытным разработчикам, которые уже делали похожие проекты. Да, они будут дороже, но зато риски превращения MVP в долгострой будут ниже.
3. Желание получить и скорость, и качество. Это две крайности, два разных подхода к разработке. Если нужно сделать быстро — готовьтесь мириться с багами и затем тратить время и деньги на их исправление.
4. Игнорирование технического долга. В создании технического проекта нужно закладывать время не только на саму разработку, но и на рефакторинг, на код-ревью — то есть на работу, которая улучшает качество кода.
5. Рассчитывать быстро набрать команду. Если стартап масштабируется, основателю придется быстро формировать команду разработчиков. Но хороших специалистов сейчас найти трудно. Поэтому заранее подумайте, где вы будете их брать. Может быть, стоит сразу начать работать над HR-брендом. Или найти подрядчиков, которым можно отдать часть задач, пока формируете свой штат.

Фото на обложке: Shutterstock / Who is Danny