Главная 10 популярных вопросов о разработке стартапов с ответами

10 популярных вопросов о разработке стартапов с ответами

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

Можно воспринимать ее как FAQ для авторов ИТ-стартапов.

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

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

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

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

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

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

Бывает несколько типов команд, у каждой есть особенности:

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

Несомненные плюсы такой команды:

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

Минусов тоже хватает:

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

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

Хорошие моменты:

• Удобно контролировать и управлять.
• Команда проникается духом проекта.
• Можно оперативно проводить коллективные брейнштормы.
• Можно быстро внедрять новые идеи в проект.
• Своя команда привлекательнее для инвестора.

Недостатки:

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

3. “Аренда” нераспределенной команды. Команда физически находится в одном офисе, но не в вашем.

Плюсы:

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

Минусы:

• Сложности удаленной коммуникации (если подрядчик в другом городе).
• Услуги готовой команды будут дороже услуг фрилансеров.
• Низкая эмоциональная вовлеченность команды в проект.

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

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

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

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

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

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

У почасовой оплаты есть еще несколько важных недостатков.

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

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

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

Вопрос 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. Стоит ли задумываться о технологическом масштабировании проекта с самого начала?

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

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

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

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

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

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

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

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

Бонус

Таблица 1

Риск	Аренда команды	Аутсорс: почасовая оплата	Аутсорс: фиксированная оплата	Своя команда	Фрилансеры
Проблемы с трудоустройством	Отсутствует	Отсутствует	Отсутствует	Полный перечень ответственности, налогов, больничных и отпускных	Отсутствует
Долгий поиск сотрудника	Нет	Нет	Нет	До 2 месяцев	Есть
Долгое вхождение сотрудника в проект	Нет	Нет	Нет	До 3 месяцев	Нет
Расходы на обучение	Нет	Нет	Нет	Есть	Нет
Расходы на отпуск и больничные	Нет	Нет	Нет	Есть	Нет
Риск “исчезновения” сотрудника	Нет	Нет	Нет	Есть	Есть
Риск увольнения и долгой замены	Быстрая замена другим исполнителем	Быстрая замена другим исполнителем	Быстрая замена другим исполнителем	Защиты нет	Защиты нет
Проблемы увеличения команды	Быстрое включение новых сотрудников	Быстрое включение новых сотрудников	Срок и стоимость исполнения закреплены в контракте	Полный цикл: поиск, найм, испытательный срок, обучение	Риски совместной работы нескольких фрилансеров
Проблемы уменьшения размера команды	Нет риска	Нет риска	Нельзя уменьшить стоимость контракта	Увольнением сотрудников, на обучение которых вложены деньги.	Нет риска
Юридическая защита	Есть	Есть	Есть	Есть	Нет
Цена	Средняя	Высокая	Средняя	Средняя	Низкая
Инфраструктурные расходы	Нет	Нет	Нет	Офис, оборудование, хозтовары	Нет
Ощущение “это моя команда”	Есть	Нет	Нет	Есть	Нет
Итого	0/13	2/13	2/13	10/13	6/13

Заключение

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

Будут вопросы — пишите, мы подскажем.

Концепт Riddler взят с DevianArt.