Михаил Кечинов

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

Михаил Кечинов, CEO «Студии веб-разработок Михаила Кечинова», написал краткий гид для начинающего стартапера: где искать команду, какой она должна быть и как ей правильно управлять. Об этом, а также о других важных вещах, которые беспокоят на старте, читайте в материале.


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



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

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

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

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

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



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

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

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

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

+

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

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

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

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

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

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

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

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

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

+

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

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

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

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

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

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

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

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

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



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

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

+

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

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

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

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

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

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

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

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

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



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

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

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

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

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


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

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

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


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



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



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

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

Пример: Если считать, что часовой рейт программиста составляет, 2000 рублей, а дизайнера 1000 рублей, то по такой арифметике месяц команды программист+дизайнер обойдется вам в (2000+1000)*8*22 = 528 000 рублей. Но на самом деле дизайнер не нужен вам пять дней в неделю, а программист 8 часов в сутки. Поэтому итоговая сумма будет существенно меньше – за счет правильного распределения нагрузки.

По нашему опыту – рабочая команда из 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) – еще один плюс.
В качестве пожелания: не стоит цепляться за модные новые технологии. Языков и фреймворков сегодня великое множество, но нет никакой гарантии, что они будут жить и про них будут помнить через год-полтора. Вряд ли вам нужен проект, написанный с помощью мертвых технологий.

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



Бонус

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


Риск

Аренда команды

Аутсорс: почасовая оплата

Аутсорс: фиксированная оплата

Своя команда

Фрилансеры

Проблемы с трудоустройством

Отсутствует

Отсутствует

Отсутствует

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

Отсутствует

Долгий поиск сотрудника

Нет

Нет

Нет

До 2 месяцев

Есть

Долгое вхождение сотрудника в проект

Нет

Нет

Нет

До 3 месяцев

Нет

Расходы на обучение

Нет

Нет

Нет

Есть

Нет

Расходы на отпуск и больничные

Нет

Нет

Нет

Есть

Нет

Риск «исчезновения» сотрудника

Нет

Нет

Нет

Есть

Есть

Риск увольнения и долгой замены

Быстрая замена другим исполнителем

Быстрая замена другим исполнителем

Быстрая замена другим исполнителем

Защиты нет

Защиты нет

Проблемы увеличения команды

Быстрое включение новых сотрудников

Быстрое включение новых сотрудников

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

Полный цикл: поиск, найм, испытательный срок, обучение

Риски совместной работы нескольких фрилансеров

Проблемы уменьшения размера команды

Нет риска

Нет риска

Нельзя уменьшить стоимость контракта

Увольнением сотрудников, на обучение которых вложены деньги.

Нет риска

Юридическая защита

Есть

Есть

Есть

Есть

Нет

Цена

Средняя

Высокая

Средняя

Средняя

Низкая

Инфраструктурные расходы

Нет

Нет

Нет

Офис, оборудование, хозтовары

Нет

Ощущение «это моя команда»

Есть

Нет

Нет

Есть

Нет

Итого

0/13

2/13

2/13

10/13

6/13

 



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

Фото: Shutterstock.


comments powered by Disqus

Подпишитесь на рассылку RUSBASE

Мы будем вам писать только тогда, когда это действительно очень важно