Skip to main content
Improvado
Международный агрегатор рекламных кампаний
60 млн $
капитализация
22 млн $
инвестиции в серии А
Создаем стартапы на блокчейне Cardano с использованием платформы Plutus, написанной на Haskell
Узнать больше

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

planets

Рассказываем, какие ошибки основатели допускают чаще всего, как команде расставить приоритеты, всегда успевать с разработкой и что делать при отсутствии необходимой экспертизы.

Опросили экспертов, которые сталкивались с проблемами в организации разработки в early stage стартапах. 

Неправильная оценка задач по разработке

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

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

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

Увеличение количества разработчиков не всегда дает прирост в качестве. Перед привлечением аутсорса или наймом разработчиков, основателям нужно сначала описать проект, его архитектуру, какие проблемы решает, как будет масштабироваться и т.д. Для нашего стартапа пока хорошо работает привлечение консультантов на отдельные задачи, которые мы не можем решить своей экспертизой.
Uladzislau Rymasheuski
Основатель и CEO Askpot

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

Неправильный подбор исполнителей для разработки

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

Привлечение разработки зависит от специфики early stage стартапа и его технологической составляющей. Например, AI или блокчейн проектам с первых дней нужно писать код. В нашем стартапе аутсорсная разработка появилась спустя месяц после запуска. Надо понимать, что инхаус разработку невозможно развернуть быстро, за исключением случая, когда сам CTO пишет весь код. В моем прошлом проекте (необанк Nomad) мы закрылись как раз из-за слишком дорогой инхаус разработки — по сути, она убила стартап.
Олег Аксенов
CTO Unlock.auto

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

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

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

В нашем стартапе разработка долго шла к текущему состоянию, и в итоге мы пришли к поиску команды разработчиков, которым нужно задавать направление и корректировать раз в день-два. Сейчас это 6 разработчиков — в нашем случае минимально возможный setup. Мы выбирали исполнителей, способных взять на себя детали реализации фичей, и если что-то пойдет не так — быть готовыми быстро всё починить. А если нет решения в моменте, не говорить «у меня лапки, я не знаю что делать». Всегда должны быть варианты выхода из ситуации.
Kirr Simakovs
Основатель и CEO Monosnap.com

Недостаток опыта и синхронизации

На ранней стадии стартапам дорого нанимать в штат сильных разработчиков. Поэтому зачастую они сотрудничают с неопытными специалистами, которые мало знают о стандартах кода, как правильно оформляется техническая документация и т.д. Без привлечения инвестиций качество разработки на early stage будет страдать. На мой взгляд, даже в стартапе CTO следует заниматься менеджментом, а не писать код на ежедневной основе. Уход CTO в микропроцессы — губительно для проекта.
Олеся Шелестова
CTO Oasix

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

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

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

Синхронизация в стартапе играет ключевую роль в вопросе его выживания. Нужно сразу подбирать заинтересованных ребят: не знаешь — идешь гуглить. Большим преимуществом растущих стартапов является возможность сотрудников самостоятельно принимать решения, совершать ошибки и быстро исправлять их. Не стоит пренебрегать давать обратную связь команде — от этого зависит ее долгосрочная мотивация и вовлеченность.
Нелли Камаева
Senior Product Designer, FH

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

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

Нет внятной технической документации

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

На этапе быстрого роста стартапа техническую документацию не успевают детально прописывать (или такой документации просто нет). Например, если архитектура монолитная, а не микросервисная, то на ранней стадии все зависят от общей модели данных и все завязывается на нескольких людей в команде. В стартапе, в котором я работала, улучшение качества технической документации значительно повысило скорость разработки.
Нелли Камаева
Senior Product Designer, FH

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

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

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

Технический долг

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

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

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

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

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

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

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

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

Выводы

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

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

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

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

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

Елизавета Черная

Редактор Бренд-медиа

Статьи

web3
nft
business
launchpad
twa
Тренды блокчейна и криптоиндустрии 2024: Telegram Mini Apps (TMA)

Елизавета Черная

Редактор Бренд-медиа

Статьи

web3
buildings
anonymus
выбор редакции
Zero-knowledge proof: один из трендов 2024 в блокчейне

Евгений Биктимиров

Венчурный аналитик

Статьи

ethereum
web3
dApps
cpay
выбор редакции
AA zksync
zero knowledge proofs
выбор редакции
stock market chart
выбор редакции
planets
fundraising
выбор редакции
cto
wallet
tokens
выбор редакции
rocket computer
выбор редакции
Как создать дизайн для MVP стартапа за 7 дней

Юлия Черепанова

Head of Design Office

Статьи

startup
MVP
design
nft
AI
crypto wallets
выбор редакции
Account Abstraction: что это такое и зачем нужно криптомиру

Павел Найданов

Solidity разработчик

Статьи

ethereum
web3
business
red space
выбор редакции
speed up development
myths
выбор редакции
Мифы о разработке блокчейн продуктов

Николай Бордуненко

Project manager at MetaLamp

Статьи

web3
dApps
startup
launching
выбор редакции
Кого нужно нанимать в команду для запуска MVP?

Алексей Сухарев

Head of Sales Department

Статьи

business
startup
MVP
galaxy
magazine
spaceman
выбор редакции
coffee
investors
nft
Первый NFT marketplace на Cardano

Станислав Жданович

Haskell разработчик

Статьи

cardano
web3
nft
stair
выбор редакции
bridge
rocket
abstraction
Как мы нанимаем Plutus инженеров через собственную программу обучения

Светлана Дульцева

Супервизор программы обучения

Статьи

education
cardano
web3
mountains
blockchain
salary
salary increase
app
developer with books
keyboard
abstract