Лучшие статьи и кейсы стартапов
Включить уведомления
Дадим сигнал, когда появится
что-то суперстоящее.
Спасибо, не надо
Вопросы Проекты Вакансии
Центр управления конверсией
Рекомендуем
Продвинуть свой проект
Лучшие проекты за неделю
30
Битрикс24

Битрикс24

www.bitrix24.ru

22
Отследить-посылку

Отследить-посылку

B2B-сервис трекинга посылок

13
WebResidentTeam

WebResidentTeam

webresident.agency

12
Devicerra

Devicerra

devicerra.com

12
Perezvoni.com

Perezvoni.com

perezvoni.com

11
Expresso

Expresso

www.expresso.today

11
myPreza

myPreza

mypreza.ru

9
Reader

Reader

Интернет-журнал о современных технологиях.

9
ADN Digital Studio

ADN Digital Studio

adn.agency

Показать следующие
Рейтинг проектов
Подписывайтесь на Спарк во ВКонтакте

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

5 678 18 В избранное Сохранено
Авторизуйтесь
Вход с паролем
Всё, что вы хотели знать о запуске собственного стартапа, но стеснялись спросить.

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

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

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

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

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

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

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

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

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

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

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

  • Трудно контролировать.
  • Есть неудобства, связанные с часовыми поясами.
  • Стереотипный образ безответственного фрилансера-удаленщика часто подтверждается.
  • Сложности с привлечением инвестиций: инвестора скорее заинтересует проект со стабильной командой «здесь и сейчас».
  1. Нераспределенная команда в офисе. Оптимальный вариант для стартапа — все сидят под одной крышей и делают общее дело. Хорошие моменты:
  • Удобно контролировать и управлять.
  • Команда проникается духом проекта.
  • Можно оперативно проводить коллективные брейнштормы.
  • Можно быстро внедрять новые идеи в проект.
  • Своя команда привлекательнее для инвестора.

Недостатки:

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

Плюсы:

  • У вас в распоряжении готовая сработавшаяся команда.
  • Подрядчик берет под свой контроль вопросы 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 недели». Из-за неправильно построенной архитектуры проект с каждым месяцем может делаться все дольше и дольше. Причина неправильной архитектуры — не только недальновидность программистов, но часто и постоянные смены концепции проекта. Например, сервис, который изначально был для читателей книг, потом вдруг решили переделать под издателей. Аудитория изменилась, а архитектура — нет. Если каждая новая задача делается все дольше и дольше, каждая выполненная задача порождает одну или несколько новых ошибок — это первый симптом описанной проблемы.
  • Недостаточно внимания 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) — еще один плюс.

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

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

P.S. У себя в блоге сделали сводную сравнительную таблицу рисков при использовании разных типов команд и схем работы. Кому интересно, жмите: mkechinov.ru/startup_development_faq.html

+2
Добавить в избранное Сохранено
Авторизуйтесь
Вход с паролем
Первые Новые Популярные
Evgeny Anisenkov
Недавно на семинаре от profipages рассказывали, что сейчас 90% IT-стартапов закрывается. Склонен считать, что это правда.
Ответить
Симулятор бизнес-процессов
Сервис имитационного моделирования и оптимизации бизнес-процессов
Prolis Labkk
Думаю, такой процент неудач заложен самой самой природой любых стартапов. Для всего остального есть проектное управление.
Ответить
Victor Suzdalev
Так это же коэффициент Страджона, вы чего. ))
Ответить
Startr.ru
Стартап чат, чат для команд, виртуальный коворкинг. Связи решают все.
Roman Yakovlev
Стоимость команды программист+ дизайнер все же может быть гораздо ниже за счет фикс рейта. Программист 80к фикс рейт + дизайнер в районе 60. Итого 140к в месяц вместо 528к. Цифра весьма усредненная конечно, сильно зависит от кандидатов, но даже если берем сильных кандидатов 120к+ 80к =200к в месяц все равно в 2 с лишним раза ниже вашей суммы.
Получается, что за миллион можно сделать работающий, функциональный и оттестированный проект, что по курсу доллара составляет $16700, что составляет месячную зарплату хорошего программиста в стартапе в долине например )
Ответить
Показать предыдущие комментарии
Виктор Рассоха
Так считать можно только если платить сотрудникам неофициально. Если к этому прибавить налоги, получается +50%, если прибавить больничные и отпуска получается еще +25%, если к этому прибавить расходы на офис и фонд обновления оборудования, получается еще +15%. Таким образом, себестоимость хорошей команды уже не 200, а, извините, 380 тысяч в месяц. И если основатель стартапа не хочет заниматься бюрократией, а арендовать, например, мою команду, то с какой стати мне это делать по себестоимости? Наценка в 38% сверху (считая по стоимости в 528 тысяч) более чем скромная, основатель же не в конверте деньги принесет, значит еще минус 6% минимум за упрощенку и 9% за вывод дивидендов, итого, месяц организации разработки чужого стартапа с душещипательными беседами на тему как все быстро, здорово и качественно делается приносит владельцу команды баснословные 70 тысяч рублей.
Ответить
Виктор Рассоха
Забыл упомянуть риск простоя команды, которая ест деньги как слон морковку. Этот риск нужно вычесть из уже попиленых на новый iWatch 70-ти тысяч... ;)
Ответить
Startr.ru
Стартап чат, чат для команд, виртуальный коворкинг. Связи решают все.
Roman Yakovlev
Конечно я не учитывал, что зарплата белая и больничные отпускные и команда не арендованная, а набранная лично либо с помощью специалистов. У вас крайний случай, а если не впадать в крайности, все равно получается в 2 раза меньше.
Ответить
Виктор Рассоха
Понятно, но если работать над проектом те же пять месяцев и постоянно проводить операций на сотни тысяч рублей как частное лицо, можно привлечь внимание. Плюс если работа идет на средства какого-нибудь фонда, нужен официальный оборот.
Ответить
Студия Михаила Кечинова
Круче всех делаем стартапы
Michael Kechinov
Работа специалиста по найму персонала стоит 240% от оклада сотрудника в среднем. Если нанимаете программиста программиста за 100К, то отдадите агентству 20% его годового оклада (240К).
Найм своими руками - дело долгое, мутное и длится месяцами.
На неофициальную работу переманить человека можно только очень хорошей зарплатой.
Так что кругом одни только крайности.
Ответить
GreenRed brand studio
разработка логотипа за 99$
Панченко Андрей
жирно! расписали, так расписали =)
Ответить
Денис Петренко
Смотришь подобные расценки на разработчиков, потом смотришь на фриланс биржы и слёзы на глаза наворачиваются.
Ответить
Студия Михаила Кечинова
Круче всех делаем стартапы
Michael Kechinov
Это обычные расценки.
Команда – это:
- backend
- frontend
- дизайнер
- админ
- менеджер проекта
- 1-2 тестировщика

Посмотрите зарплаты на ресурсах в вакансиями. Умножьте на 1.5 - налоги. Умножьте на 1.3 - офис, оборудование, отпускные, больничные. Умножьте на 1.7 - проваленные испытательные сроки, поиск и замена сотрудников. В итоге получите более-менее реальную цену.

А фриланс - это не про стартапы. Фриланс - это про небольшие разовые задачки типа поправить лендинг или написать парсер для сайтов.
Ответить
Роман Бутвинский
У меня такой вопрос, если стартап провалился, а мы договаривались на долю. То все уходят со своими наработками или основатель должен заплатить за работу? Это ведь стартап а не заказ заказчика.
Ответить
Студия Михаила Кечинова
Круче всех делаем стартапы
Michael Kechinov
Все зависит от договоренности на берегу. Если вы про coding-for-equity, то он не работает, вот наша статья об этом: http://habrahabr.ru/company/mkechinov/blog/246547/

Если стартап провалился, а вы не договаривались об оплате, то никто ничего не платит. Оплата возможна только по договору. Нет договора - нет обязательств.
Ответить
Администрация
Спасибо за статью. Вчера она была анонсирована в сообществах Спарка и издания «Цукерберг Позвонит»

http://vk.com/gospark?w=wall-64915591_3729
http://vk.com/smmrussia?w=wall-33393308_349041
https://twitter.com/morketolog/status/627212153045422080
Ответить
Выбрать файл
Читайте далее
Загружаем…
Блог проекта
Расскажите историю о создании или развитии проекта, поиске команды, проблемах и решениях
Написать
Личный блог
Продвигайте свои услуги или личный бренд через интересные кейсы и статьи
Написать