Михайлов Кирилл

В первых двух частях мы разбирали крайности.

В первой части мы разобрали запросы, от которых долго молчим на созвонах.

Если не читали - вот ссылка:

Мы занимаемся автоматизацией и AI-разработкой. К нам регулярно приходят люди с идеями.

В конце 2025 года появился проект, который за несколько дней набрал десятки тысяч звёзд на GitHub.

За 24 часа - 9 000.

После моей статьи про запуск MVP за 4 недели появилась критика: «Сначала анализ, потом код. MVP не должен заменять исследование».

С этим тезисом сложно спорить. Но важно расставить акценты.

Триал казался обязательным.

Этот проект мы могли сделать «как обычно».Подписать договор, зафиксировать объём, спокойно разрабатывать 3-4 месяца и уже на приёмке узнать, что что-то пошло не так.

Вместо этого мы запустили MVP за 4 недели.А на 7-й день после запуска стало ясно: фича, ради которой проект вообще начинался, пользователям не нужна.

Жёсткое техническое задание выглядит как "надёжная опора".Чем подробнее всё описали, тем меньше рисков. По крайней мере, так принято считать.

На практике всё часто работает наоборот.

Проект по разработке приложения для ведения финансового учёта был принят клиентом. Клиент был доволен. Мы уже выдыхали. А через минуту стало понятно, что этот проект уйдёт в минус. Не из-за ошибок в разработке или коде и не из-за плохого прода — а из-за одного малейшего пункта в договоре, который никто не обсудил и не сказал.