Стартап для чайников: 10 первых вопросов

Каждая студия со специализацией на стартапах и сложных интернет-проектах много раз в день слышит одни и те же вопросы от заказчиков. И терпеливо на них отвечает. Тот факт, что вопросов не становится меньше (да и сама их суть особо не меняется год от года), и подтолкнул нас к написанию этой статьи. Можно воспринимать ее как FAQ для авторов ИТ-стартапов.

Вопрос 1. Какой должна быть команда ИТ-стартапа?

Команда – это один из самых рисковых компонентов ИТ-стартапа. Какой она должна быть?

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

Во-вторых, сработавшейся. Внутрикомандные недопонимания – как песок в часовом механизме. Конечно, со временем любая команда способна «притереться», но последствия от самого процесса могут быть непредсказуемыми.

В-третьих, и это желательно, собранной в одном помещении. Но это уже в отдельный пункт.

Вопрос 2. Своя команда или аутсорс?

Есть несколько типов команд, и у каждого свои особенности.

Распределенная команда

Когда дизайнер в Киеве, программисты в Мумбаи, а вы в Москве. Или наоборот, не суть важно.

+

– Можно найти оптимальное соотношение цена-качество под свой проект

– Не надо платить за офис

– Не нужно ограничиваться кадрами из вашего города/региона при формировании команды (актуально, так как хороших кадров на рынке действительно мало)

–

– Трудно контролировать людей

– Есть неудобства, связанные с часовыми поясами

– Стереотипный образ безответственного фрилансера-удаленщика часто подтверждается

– Сложности с привлечением средств: инвестора скорее заинтересует проект со стабильной командой «здесь и сейчас»

Нераспределенная команда в офисе

Оптимальный вариант для стартапа: все сидят под одной крышей и делают общее дело.

+

– Удобно контролировать и управлять

– Команда проникается духом проекта

– Можно оперативно проводить коллективные брейнштормы

– Можно быстро внедрять новые идеи в проект

– Своя команда привлекательнее для инвестора

–

– Затраты на офис, технику, обслуживание и т.д (часто это самый дорогой вариант)

– Человеческий фактор: люди могут уволиться или заболеть на пару недель

– Нужно организовать процесс обучения

– Нужно плотно заниматься HR (в том числе – быстро восполнять потери в отряде)

«Аренда» нераспределенной команды

Команда физически находится в одном офисе, но не в вашем.

+

– У вас в распоряжении готовая сработавшаяся команда

– Подрядчик берет под свой контроль вопросы HR, замену сотрудников

– Возможность «собрать» любую команду под ваши потребности

– Подрядчик решает вопросы быстрого масштабирования команды (снять с проекта лишних людей или расширить команду в два раза)

– Структура затрат понятна и все риски заложены в финальную стоимость команды

–

– Сложности удаленной коммуникации (если подрядчик в другом городе)

– Услуги готовой команды будут дороже услуг фрилансеров

– Низкая эмоциональная вовлеченность команды в проект

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

Вопрос 3. Какие бывают схемы оплаты работы?

Есть два типа: за факт сдачи проекта и за время.

В случае с фиксированной оплатой за проект всё понятно: подрядчик сдает проект, заказчик принимает, деньги перечисляются. Возможно, частями и с предоплатой. Схема работала бы идеально, если бы задачи были строго определены на старте, требования не менялись и конечный результат с вероятностью 100% сразу бы принимался заказчиком (ведь он не отступает от ТЗ).

В реальности же, тем более в разработке стартапов, все сложнее. Лично наш опыт говорит о том, что через 1-2 месяца работы сам заказчик больше вникает в тему, меняются приоритеты проекта, появляются новые задачи. Это просто неизбежно, и к этому надо быть готовым. Фиксированной такую схему оплаты можно назвать с очень большими оговорками.
Поэтому, когда вам называют жесткую сумму после оценки, – не верьте. Лучший способ разрешить подобный конфликт – начать работать по фиксированной оплате, проверить команду в действии, чтобы со временем перейти на повременную оплату.

Оплата за время и ресурсы (Time & Material) – это почасовая оплата труда задействованных в проекте специалистов, «мозги в аренду по часам». У каждого специалиста свой рейт (стоимость часа): руководитель проекта стоит дороже программиста, программист дороже тестировщика и так далее. С одной стороны, схема удобна для стартапов: возникли новые пожелания, захотели что-то переделать – пожалуйста, платите по тарифу, не обязательно все учитывать в оценке на старте. Но есть и сложности. Так, например, схема требует определенного уровня доверия между заказчиком и исполнителем, в противном случае будут возникать неизбежные разговоры из серии «а что это вы так медленно работаете, я ведь вам деньги плачу!».

Другие важные недостатки почасовой оплаты:

– Если генерировать слишком много изменений – получится дорого. Например, если взять базовую ставку 2000 рублей за час и среднюю загрузку специалиста 168 часов в месяц, то стоимость сотрудника составит 336 000 рублей в месяц. Поэтому почасовая схема применяется на небольшом объеме работ в фазе поддержки работающего проекта.

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

Аренда команды на фиксированный срок (например, месяц). Более предпочтительная схема, у вас появляется закрепленная за вами команда нужных специалистов, стоимость которых рассчитывается по формуле «себестоимость + наценка». Команда работает исключительно над вашим проектом и готова в рабочее время решать любые задачи. Кроме того, многие команды дают скидки, если их нанимают «оптом».

По теме: Работодателям могут повысить ответственность за задержку зарплаты

Вопрос 4. Сколько стоит команда стартапа?

Есть одна маленькая, но очень важная деталь. Называется «загруженность специалиста».

По нашему опыту – рабочая команда из 5 человек стоит 450-550 тысяч рублей в месяц.

Вопрос 5. Какие риски актуальны для ИТ-стартапа?

Рисков много. Например:

– Отсутствие контроля за разработчиками

Последствия могут быть довольно неприятными: от постоянного рефакторинга кода до экспериментов программистов с «новыми интересными технологиями». В результате через полгода придется разгребать последствия экспериментов.

– Проект вот уже 6 месяцев находится в фазе «сделано на 80%, запуск через 2 недели»

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

– Проблемы с человеческими ресурсами

Кто-то может уволиться, заболеть, а кому-то пообещают лучше условия в другом стартапе. Когда программист уходит с незаконченного проекта – остается недописанный код. Чтобы найти кодеру замену, уходит в среднем 2 месяца. И еще столько же уйдет у него на то, чтобы новый сотрудник мог освоиться на проекте. И не факт, что его все устроит и он останется в команде (или – что он устроит вас).

– Недостаточно внимания QA

Тестирование – чуть ли не ключевая задача команды проекта. Частые изменения в коде гарантированно ведут к возникновению ошибок, независимо от качества кадров. Если нет тестировщика (а лучше нескольких) – ошибки будут наслаиваться друг на друга, а отлавливать их причины со временем станет все труднее. Программисты могут говорить об автотестировании, но автотесты обеспечивают проверку на стороне бэкенда и не находят проблем типа «кнопка сползла влево».

Риски стартапов – это отдельная тема для увесистой статьи. Или даже книги. Поэтому слишком заостряться на ней не будем, подробнее расскажу в следующий раз.

Вопрос 6. Какие проблемы связаны

с разными процессами разработки

(Agile, Waterfall)?

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

Waterfall (или «водопадная» модель)

Это когда проект разрабатывается целиком, неитеративно. Подразумевает написание всеобъемлющей документации и четко определенных целей проекта.

Плюсы:

– Четко определенные цели, стабильные требования

– Процесс разработки легко понятен и хорошо структурирован

– Жесткие временные рамки

– Прогнозируемость расходов времени, ресурсов

Возможные проблемы:

– Необходимость определить функциональность проекта уже на этапе предварительного обсуждения

– Неповоротливость проекта, неприспособленность к быстрым изменениям

– Долгая и дорогая разработка технической спецификации проекта (которая уже через два месяца неактуальной)

Agile (или «гибкая» модель)

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

Плюсы:

– Поэтапность, итеративность, выдача функционального проекта небольшими «порциями»

– Возможность быстрого запуска на рынок

– Ранние корректировки проекта с учетом обратной связи конечных пользователей

– Легко меняются приоритеты без ущерба рабочему процессу и бюджету

Возможные проблемы:

– Вероятность «бесконечной» разработки ввиду неопределенности конечных целей

– Постоянно растущий «технический долг». Часто при гибком подходе стремятся запустить еще сырую версию продукта, откладывая доведение до ума на потом. В итоге это может вылиться в накапливание так называемого «технического долга», который подрядчик не всегда в состоянии «выплатить»

– В критический момент может не оказаться актуальной документации по проекту, если ей не уделялось достаточно внимания

Нельзя однозначно называть какой-либо подход хорошим или плохим. Одна и та же команда может работать по agile или waterfall по-разному. Но гибкость для стартапов все же приоритетнее стабильности – так, уже окрепшие проекты переходят на еще более гибкие модели разработки (например, DevOps, где сотни изменений вносятся в проект ежедневно, запускается множество A/B-тестов и экспериментально выясняется, что больше нравится пользователям).

Вопрос 7. Как найти команду?

На этот вопрос уже был дан частичный ответ.

HR – очень проблемное место для стартапа. В начале, помимо рекрутинга, у вас будет достаточно головных болей. Но и набор команды – тот еще квест: кадров на рынке мало. Вариант с выращиванием собственных специалистов стартапу не подходит: это долго, а нам нужен быстрый взлет. Хантить из других проектов? Или у вас должен быть очень интересный и перспективный проект, или у вас должен быть очень толстый кошелек.

Даже если у вас все получилось и вы набрали свою первую команду ­– кто сказал, что эти люди сработаются? Что вам не понадобится заменить кого-то? Или добрать еще специалистов? А если человек вдруг заболеет или уволится? Он вообще может просто по-тихому слиться, особенно если вы работаете с удаленщиками. Все это не стоит упускать из виду.

О том, на что обращать внимание при поиске людей, а также о плюсах и минусах своей команды и «команды в аренду», мы писали в ответе на вопрос 2.

По теме: Где найти команду для стартапа?

Вопрос 8. Сколько ждать готовый проект?

Конечно, вопрос сугубо индивидуальный, однако кое-какие типовые сроки есть.

Мы выделяем такие вехи в разработке стартапа:

– 1,5-2 месяца – сроки запуска MVP (минимально функционального продукта) Такой можно запускать с закрытым или ограниченным доступом, проверять на кроликах и делать выводы о дальнейшем развитии.

– 4-5 месяцев – сроки запуска финальной версии проекта любой сложности

Вопрос 9. Стоит ли задумываться о технологическом масштабировании проекта с самого начала?

В ста процентах случаев требования к проекту меняются после запуска MVP и оценки последствий. Поэтому – нет, не стоит.

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

Кстати, посещаемость в 50 000 человек в сутки ­– это не повод для паники, их комфортно выдержит и один хороший сервер.

По теме: Словарь предпринимателя – Пивот

Вопрос 10. Как не допустить ситуации, когда программисты за ваши деньги изучают новые технологии?

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

Самый очевидный способ не допустить ситуации, когда на ваш бюджет разработчики осваивают незнакомые технологии – договорить о технологиях «на берегу». Наличие у вас техлида будет большим плюсом. Специализация команды на определенных технологиях (например, Ruby, Python и PHP для веба, Swift для iOS, Java для Android) – еще один плюс.
В качестве пожелания: не стоит цепляться за модные новые технологии. Языков и фреймворков сегодня великое множество, но нет никакой гарантии, что они будут жить и про них будут помнить через год-полтора. Вряд ли вам нужен проект, написанный с помощью мертвых технологий.

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

Бонус

Сравнение рисков при использовании разных видов команд и схем работы.

И в заключение: понятно, что ни один FAQ не способен развеять все те сомнения, которые роятся в головах у начинающих ИТ-предпринимателей. Будут вопросы — обращайтесь.

Фото: Shutterstock.