Comments 4
сколько по вашему опыту длится каждый из этапов по времени?
нет какого-то конкретного времени, сколько длится каждый из этапов, поскольку каждый стартап уникален и сталкивается с различными вызовами. Это итерационные процессы, и продолжительность каждого этапа зависит от сложности технологии, целевой аудитории и многих других факторов. Например, технология может надолго застрять на этапе прототипа, если требует сложной разработки или тестирования, или продукт может долго искать свой рынок, чтобы сходилась unit-экономика. Важно не столько время, сколько осознание текущего этапа стартапа и готовность двигаться вперёд через итерации, настраивая продукт, стратегию и подходы по мере необходимости
А можете, исходя из своего опыта, дать какие-то рекомендации по размеру\составу команд на этапе Prototype и MVP?
Тут больше интересуют фопросы в формате:
На сколько нормально на этапе Prototype работать в составе 1 менеджер + 1 разработчик?
Стоит ли на Prototype\MVP заморачиваться на счет безопасности (ну например я могу секреты складывать без шифрования или вообще в шивать в код для упрщения разработки)?
Какую команду стоит закладывать на MVP? Стандартную (2 FrontEnd + 2 BackEnd + 2 DevOps + Lead (он и арзитектор и аналитик будет)) или какой-то более урезанный вариант тоже имеет место быть?
Спасибо за хороший вопрос. В действительности, конечно, размер команды зависит от сложности проекта, можно зависнуть на этапе прототипа, если вы, например, делаете гуманойдоподобных роботов, но видимо и инвестиции соответствующие, что можно нанять себе команду исследователей :) но мы рассмотрим стандартный кейс: есть данные, нужно обучить модель, завернуть в сервис, далее подключить интерфейс и начать тестировать гипотезу на реальных пользователей, какая команда для этого нужна.
1. Размер и состав команды на этапе Prototype:
Иметь одного продакта и одного разработчика - это необходимая и достаточная конфигурация. Продакт формулирует гипотезу и ставит требования разработчику. Разработчик в свою очередь создает прототип продукта, который может быть даже не обернут в сервис - условного юпитер ноутбука достаточно, если модель показывает хорошую метрику, которую можно заворачивать в сервис.
2. Про безопасность на этапе Prototype:
О безопасности важно думать на каждом этапе развития продукта. Любое техническое задание является интеллектуальной собственностью компании, его необходимо защищать, а уж код и данные тем более. Конечно, не стоит перегибать, тут важно правильно идентифицировать риски, а базовой защиты достаточно: доступ к коду через безопасные каналы, простые методы шифрования, датасет не отправлять никому по почте :)
3. Про размер команды на этапе MVP:
На этапе создания минимального продукта команду также не стоит раздувать, тк гипотеза может быть не верна, а вы возьмете на себя лишние обязательства по содержанию небольшого штата сотрудников. Для разработки интерфейса можно воспользоваться услугами качественных подрядчиков или также обойтись минимальной командой: 1 backend, 1 frontend достаточно, в идеале 1 full-stack разработчик. По-моему опыту 2 frontend, 2 backend и 1 devops появляются на этапе, когда основная гипотеза продукта проверена, пошли продажи и начался поиск Product-Market-Fit. Опять же, все зависит от инвестиций: представьте, что вы делаете проект на свои деньги, это позволяет лучше понимать кто вам нужен на корабле для выживания)
Важно понимать: чем меньше людей на первых этапах развития продукта, тем лучше - это железное правило. Если вам для проверки гипотезы нужна команда из более, чем 6 человек - возможно что-то не так с гипотезой. К примеру, Тильду начали делать 4 человека. Сегодня я вижу тренд на технических фаундеров: они сочетают в себя и навыки продакта, и могут разрабатывать продукт - это теперь не редкость, можно увидеть множество подобных кейсов в Y Combinator. Конечно, если инвестиции позволяют, то можно и нанять небольшую команду на начальных стадиях, но очень больно будет увольнять сотрудников, когда инвестиции будут заканчиваться :) Знаю не по наслышке, у меня было 3 таких кейса, когда инвесторы давят на ранее масштабирование, потом проект не приносит ожидаемой прибыли и приходится урезать штат, чтобы проверять новые гипотезы, а команда "сильно много ест", в общем надеюсь общую идею донес - и упралять малой группой людей намного легче, нанять всегда успеете! Важно сосредоточиться на проверке гипотез и понять, что вы двигаетесь в нужном направлении, лучше взять на борт крутого разработчика в роли CTO, поделиться долей и он будет расти по мере роста стартапа - этот кейс проверен) В будущем вырастить менеджера из технаря не так уж сложно. Успехов!
Введение в технологическую стратегию для ИИ-стартапа