Почему стартапы на ранних стадиях часто не успевают с разработкой и как этого избежать

Зачастую почти все стартапы ранней стадии проходят через типичную проблему — неправильную оценку задач по разработке. Разрешить такую ситуацию можно с помощью разумной оценки сроков и бюджета. Процесс разработки любит детальные требования и расстановку приоритетов — для early stage стартапов такой подход приобретает критическое значение.  

Оценивать задачи не нравится никому. Но без понятно измеряемых задач и валидных требований начинать разработку бессмысленно. Зачастую основатели стремятся быстро запустить проект на одной фиче без формирования конкретных требований к нему. А ограниченные ресурсы могут сыграть со стартапом злую шутку — например, к разработке привлекается «‎дешевый» подрядчик, который выставляет счета исходя из почасовой ставки. 

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

Чтобы избежать впустую слитых денег без осязаемого результата, нужно, как минимум, на базовом уровне прописать требования к проекту. По сути, это то, как видят стартап его основатели: первые ключевые фичи и очередность их реализации, цели и структура нового бизнеса (монолитная или микросервисная архитектура, интеграции с другими сервисами и пр.). Так фаундерам станет легче объяснять, что они хотят от команды разработки. 

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

При выборе подрядчика важно смотреть на его опыт и достижения в конкретной области. Возможно, такая аутсорсинговая компания будет чуть дороже, чем студии широкого профиля, но зато она уже вынесла много уроков и сделала ценные выводы на проектах других клиентов. Вдобавок можно выбирать подрядчика исходя из двух моделей разработки в early stage стартапах:

• Качественный код, но долго
• Минимум внимания качеству кода, но быстро  

Правильного пути здесь нет, все будет зависеть от количества ресурсов и выбора скорости реализации фичей.

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

• Опытный специалист уже много раз ошибался и теперь готов поделиться инсайтами со стартапом, приносящим пользу обществу.
• Сильный разработчик будет рад мгновенно видеть результаты своего труда. В больших корпорациях цикл «‎усилие — результат» может занимать гораздо больше времени.  
• Возможность получить хороший опцион и в перспективе заработать внушительную сумму денег. Вероятность совсем небольшая, но она все-таки есть.

Когда наняты первые сотрудники, важно синхронизировать их и дать возможность самостоятельно определять цели. Проверенный способ синхронизации — ставить цели снизу вверх. Так сотрудники начнут понимать, как они влияют на рост и развитие стартапа. Затем можно определить 3-4 метрики на каждую цель — по ним будут оцениваться результаты работы.

Early stage стартапы могут не успевать с разработкой, когда у CEO нет опыта управления, и он плохо нанимает кадры — разработчики занимаются мелочами и не видят big picture. Также проблемы с процессами разработки могут возникнуть, когда CTO постоянно микроменеджерит команду. На ранней стадии SCRUM — не всегда идеальное решение, можно потестировать собственные методы организации процессов. 

А чтобы избежать проблем с разработкой и повысить ее скорость, CTO/техлид могут брать консультации у компетентных специалистов, уже решавших схожие проблемы. Или пойти дальше и привлечь эдвайзера — он поможет выстроить процессы, нанять сильного специалиста и наладить коммуникацию с комьюнити. Как правило, взамен стартап может предложить эдвайзеру долю до 1%.  

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

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

• описание проекта и архитектуры
• соглашение разработчиков (как ведут разработку)
• пользовательская документация
• описание кода 
• API документация
• список функций и их роль

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

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

Долг накапливается, когда внедряются сиюминутные решения без оглядки на best practices. Код постепенно усложняется и долгосрочно может затруднить масштабирование продукта. 

При наличии накопленного технического долга важно привлекать ресурсы не только на разработку новых фичей, но и на рефакторинг кода.

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

Невнимание к лучшим практикам разработки приводит к ошибкам в ПО, снижению скорости работы сервисов и т.д.

Чтобы уменьшить технический долг, стартапы могут предпринять следующие меры: 

• Выделить временные слоты для устранения проблем. Здесь важно соблюдать баланс между разработкой новых фичей и «ремонтом» старого кода. Возникающие из-за технического долга проблемы должны быть вовремя выявлены и решены, поэтому можно установить сроки, в которые команда будет регулярно оптимизировать код.
• Уделять внимание качеству кода. Не переписывать, а сразу писать «чистый» код. Команда может принять документ о том, как нужно писать код, какие практики соблюдать, когда проводить проверки кода. 
• Делать рефакторинг кода. Срочно рефакторить, если разработчик постоянно не может оценить, какое количество времени ему потребуется для решения задачи. Рефакторить нужно постоянно, без долгих перерывов. Лучше немного, но регулярно. При этом рефакторинг не должен стать для команды способом избегать внедрять новую функциональность. 
• Сообщать о техническом долге. Вся команда, стейкхолдеры должны понимать влияние технического долга на показатели стартапа ранней стадии. 

Оценка любой задачи — фундамент для команды разработки в early stage стартапе. Разработчики должны максимально вникнуть в контекст задачи и выделять на анализ не менее 5-10% от времени, которое заложено на саму задачу. 

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

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

Учитывая скорость процессов в стартапе, важно с первых дней следовать фундаментальным принципам: 

• Прописывать требования к проекту. Закрепить на бумаге первые ключевые фичи и очередность их реализации, цели и структуру нового бизнеса (например, специфику архитектуры, интеграции с другими сервисами и пр.). 
• В случае недостатка компетенций и знаний, обратиться к опытным командам разработки с хорошим портфолио реализации схожих проектов. 
• Уделять внимание написанию технической документации.
• Не игнорировать технический долг. Инвестировать время в рефакторинг кода.