За последние пять лет я довёл до релиза три MVP: маркетплейс бытовых услуг, внутренний сервис для логистической компании и небольшое приложение для аналитики рекламных кампаний. На первом проекте я потерял примерно четыре месяца не на разработку, а на метания вокруг технологий, и с тех пор отношусь к выбору стека как к бизнес-решению, а не как к творчеству. Ниже — пять ошибок, которые я собирал собственными руками и граблями.
Ошибка первая — выбирать стек под резюме, а не под задачу. На первом MVP мне очень хотелось попробовать Go с gRPC и Kubernetes, хотя продукт представлял собой обычный CRUD с авторизацией и оплатой. В итоге вместо проверки гипотезы о том, нужен ли сервис людям, я три недели настраивал кластер, логи и CI, а клиенты так и не увидели ни одной новой кнопки. Правило, к которому я пришёл: инфраструктура должна быть скучной, а интересной должна быть только та часть, где живёт ваша уникальность.
Ошибка вторая — фраза «потом всё равно перепишем». Она звучит как оправдание, а работает как ловушка: под неё я разбил монолит на четыре микросервиса, добавил брокер сообщений и event-driven слой, хотя монетизация ещё не была подтверждена. Честно говоря, переписывать пришлось именно эту архитектуру, потому что мы не понимали, какие границы сервисов действительно нужны. Монолит с одной базой данных доехал бы до первых платящих клиентов в три раза быстрее, и это не преувеличение.
Ошибка третья — не проверить рынок труда и подрядчиков. Однажды я выбрал довольно экзотический стек, потому что он нравился мне эстетически. Через полгода выяснилось, что найти второго разработчика почти нереально, а дорогой консультант доступен раз в две недели. Автобусный фактор в MVP — это не абстрактная теория: если единственный человек, который понимает ваш код, уходит, проект встаёт. Перед выбором я теперь просто открываю несколько досок вакансий и смотрю, сколько специалистов по этому направлению ищут работу в моём регионе и по рынку в целом.
Ошибка четвёртая — не сделать спайк на самом рискованном месте. Мы строили основное приложение, а интеграцию с платежами и генерацию сложного документа оставили «на потом». Когда дошли, выяснилось, что одно ограничение внешнего API ломает весь сценарий. Два дня проверки в самом начале сэкономили бы полтора месяца переделок. Поэтому теперь я выделяю на каждый MVP так называемую неделю рискованных проб: берусь за самое неизвестное, пишу грязный прототип и только потом проектирую всё остальное.
Ошибка пятая — игнорировать стоимость владения и связанность с платформой. Я считал только время разработки, но не считал хостинг, лицензии, платные модули, время на поддержку и цену переезда. Один раз мы крепко привязались к фреймворку, который отлично стартовал, но требовал оплаченного хостинга под каждую среду, и на масштабировании это съедало бюджет быстрее, чем приносила выручка. С тех пор я всегда прикидываю три цифры: сколько проект стоит в разработке, сколько в месяц в эксплуатации и насколько больно будет уйти, если что-то пойдёт не так.
Что я советую читателю, который прямо сейчас собирает стек для MVP. Выбирайте то, что уже знаете или что легко найти на рынке; держите архитектуру настолько простой, насколько терпит ваше эго; проверяйте самые рискованные гипотезы руками в первую очередь; считайте стоимость владения, а не только сроки; и записывайте решение с обоснованием, чтобы через месяц не возвращаться к тем же спорам. Стек — это инструмент проверки гипотезы, а не памятник вашей инженерной зрелости, и лучший стек тот, который позволил вам быстрее услышать от клиента слово «да» или честное «нет».
А теперь вопрос к форумчанам: какой стек вы выбрали для своего последнего MVP и что бы вы сделали иначе, если бы начинали снова? Расскажите, где ваш выбор сэкономил вам недели, а где, наоборот, обернулся неожиданной переделкой — уверен, вместе мы соберём отличную копилку чужого опыта и сэкономим кому-то пару месяцев жизни.
Ошибка первая — выбирать стек под резюме, а не под задачу. На первом MVP мне очень хотелось попробовать Go с gRPC и Kubernetes, хотя продукт представлял собой обычный CRUD с авторизацией и оплатой. В итоге вместо проверки гипотезы о том, нужен ли сервис людям, я три недели настраивал кластер, логи и CI, а клиенты так и не увидели ни одной новой кнопки. Правило, к которому я пришёл: инфраструктура должна быть скучной, а интересной должна быть только та часть, где живёт ваша уникальность.
Ошибка вторая — фраза «потом всё равно перепишем». Она звучит как оправдание, а работает как ловушка: под неё я разбил монолит на четыре микросервиса, добавил брокер сообщений и event-driven слой, хотя монетизация ещё не была подтверждена. Честно говоря, переписывать пришлось именно эту архитектуру, потому что мы не понимали, какие границы сервисов действительно нужны. Монолит с одной базой данных доехал бы до первых платящих клиентов в три раза быстрее, и это не преувеличение.
Ошибка третья — не проверить рынок труда и подрядчиков. Однажды я выбрал довольно экзотический стек, потому что он нравился мне эстетически. Через полгода выяснилось, что найти второго разработчика почти нереально, а дорогой консультант доступен раз в две недели. Автобусный фактор в MVP — это не абстрактная теория: если единственный человек, который понимает ваш код, уходит, проект встаёт. Перед выбором я теперь просто открываю несколько досок вакансий и смотрю, сколько специалистов по этому направлению ищут работу в моём регионе и по рынку в целом.
Ошибка четвёртая — не сделать спайк на самом рискованном месте. Мы строили основное приложение, а интеграцию с платежами и генерацию сложного документа оставили «на потом». Когда дошли, выяснилось, что одно ограничение внешнего API ломает весь сценарий. Два дня проверки в самом начале сэкономили бы полтора месяца переделок. Поэтому теперь я выделяю на каждый MVP так называемую неделю рискованных проб: берусь за самое неизвестное, пишу грязный прототип и только потом проектирую всё остальное.
Ошибка пятая — игнорировать стоимость владения и связанность с платформой. Я считал только время разработки, но не считал хостинг, лицензии, платные модули, время на поддержку и цену переезда. Один раз мы крепко привязались к фреймворку, который отлично стартовал, но требовал оплаченного хостинга под каждую среду, и на масштабировании это съедало бюджет быстрее, чем приносила выручка. С тех пор я всегда прикидываю три цифры: сколько проект стоит в разработке, сколько в месяц в эксплуатации и насколько больно будет уйти, если что-то пойдёт не так.
Что я советую читателю, который прямо сейчас собирает стек для MVP. Выбирайте то, что уже знаете или что легко найти на рынке; держите архитектуру настолько простой, насколько терпит ваше эго; проверяйте самые рискованные гипотезы руками в первую очередь; считайте стоимость владения, а не только сроки; и записывайте решение с обоснованием, чтобы через месяц не возвращаться к тем же спорам. Стек — это инструмент проверки гипотезы, а не памятник вашей инженерной зрелости, и лучший стек тот, который позволил вам быстрее услышать от клиента слово «да» или честное «нет».
А теперь вопрос к форумчанам: какой стек вы выбрали для своего последнего MVP и что бы вы сделали иначе, если бы начинали снова? Расскажите, где ваш выбор сэкономил вам недели, а где, наоборот, обернулся неожиданной переделкой — уверен, вместе мы соберём отличную копилку чужого опыта и сэкономим кому-то пару месяцев жизни.