Не то чтобы я много продуктов сделал, но у меня, конечно, есть мнение на этот счет. При старте нового B2B продукта (про другие рынки я нихрена не знаю) можно руководствоваться несколькими принципами, на которые уже будут нанизываться практики. Принципы такие:
В первые месяцы работы над продуктом невероятно важна плотность коммуникации. Идеальный вариант — один разработчик, который является еще и доменным экспертом. Тогда он может двигаться вперед максимально быстро, погружаясь в потоковое одиночество и выныривая оттуда для еды и сна. К сожалению, такие гении встречаются не очень часто (но бывают). Чем меньше команда, тем плотнее коммуникация. Спонтанные обсуждения важных вопросов возникают спонтанно и ответы находятся максимально быстро. Для старта продукта обычно достаточно нескольких человек. Если в команде хотя бы 10 человек, плотность коммуникации сильно уменьшается, команда распадается на 2–3 группы и связи между ними уже не такие прочные. Так что потолок для старта — это 8 человек.
Нужно убирать любые вещи, которые препятствуют коммуникации. Например, разность часовых поясов вносит негативный момент, так что лучше один часовой пояс. Желательно, чтобы все люди хорошо говорили на каком-то одном языке. Люди в этой команде просто обязаны уметь выражать свои мысли ясно, иначе много времени будет теряться на достижение понимания. Ну и, очевидно, всем этим людям лучше сидеть в одной комнате, потому что удаленное общение всегда менее плотное.
На старте команде нужен один доменный эксперт, который хорошо понимает, что мы вообще собираемся сделать. Еще нужен дизайнер, который будет плотно работать с доменным экспертом. Все остальные люди — это разработчики (или ученые, если проект требует такой экспертизы). Тестировщики не нужны, впрочем, как и все остальные роли.
Небольшой размер команды надо компенсировать опытом разработчиков. Желательно, чтобы у них не было больших разрывов в знаниях, иначе общение будет не очень эффективным. Чем опытнее разработчики, тем лучше. Я бы начинал с 10–20 лет опыта. Такие люди уже понимают, где можно срезать углы, а где не очень. Что такое синдром второй системы. Как поступать с прототипами. И почему нельзя особо доверять Фаулеру.
Я думаю, что одна маленькая кросс-функциональная команда опытных людей на старте с точки зрения продуктивности будет равна 4–5 командам средних разработчиков. Более того, средние разработчики может быть будут вообще не способны решить проблемы, которые возникнут в первые месяцы разработки. И все пойдет прахом.
Не стоит бросаться в бой и сразу имплементировать фичи, типа логина и управления пользователями. Несколько месяцев нужно посвятить анализу. Команда должна найти несколько решений и, по возможности, проверить как можно большее их количество, чтобы выбрать лучшее. Это занимает время. Вообще самое важное — правильно поставить проблему. Правильная постановка проблемы содержит в себе львиную долю решения.
Для проверки решений лучше всего создавать прототипы. Пусть это и не реальный продукт, но хотя бы можно пощупать какие-то вещи. Прототипы нужны и функциональные, и технические. Из функциональных прототипов полезно сделать видео и показать его потенциальным клиентам. Можно сделать веб сайт и поглядеть на регистрацию желающих попробовать продукт. Это не ответит на вопрос о его нужности, но хотя бы будет чем занять дизайнера и доменного эксперта, пока программисты работают.
Крайне желательно выпустить первый релиз через год. Это может быть очень закрытая бета, которую использует один клиент, но это уже продакшн. Только настоящий релиз даст вам правильную обратную связь. Прототипы, видео, интервью, разговоры — все это суррогаты, которые очень часто дают неверную и неполную информацию. Только столкновение с реальностью даст вам то, что нужно.
Работать больше года без релиза тяжело чисто психологически. Год — это где-то предельное время, когда можно работать без потери энтузиазма и глубоких эмоциональных спадов. Если релиз занимает, скажем, полтора года, то будьте готовы к снижению продуктивности и сильному выгоранию программистов.
Когда и как начинать скейлить команду? Я бы начал делать это только после публичного релиза и получения доказательств жизнеспособности продукта. Архитектура должна предусматривать независимость компонентов (low coupling, high cohesion). Новые команды должны отвечать за достаточно независимые компоненты, договорившись о протоколах общения.
Я верю в закон Конвея. Монолиты скалируются плохо, потому что огромные команды не эффективны, а независимые команды будут иметь проблемы по координации своих действий в монолите. Поэтому нужно заранее закладывать модульную архитектуру и понимать, какие части системы могут быть отданы отдельным командам. Это сложно, занимает время и обычно никто об этом не задумывается. Все хуячат монолиты, чтобы время сэкономить. Действительно, чего думать о росте, когда будущее продукта туманно? На самом деле это тоже нормальная стратегия, просто нужно понимать, что как только вы с монолитом захотите расти, все придется переписать.
Если очень кратко, то стартовать новый продукт нужно маленькой, плотной, нераспределенной, профессиональной командой за один год. Короче, сначала морские котики, а потом регулярная армия.