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

И в режиме выжимания менеджер начинает активно толкать именно подобное расширение, потому что это не требует трудных разговоров. Трудный разговор — это когда говоришь: “Слушай, нам нужно закончить MVP, это важнее, чем добавлять новую фичу”. Это же тихий конфликт, это потенциально может оттолкнуть клиента, за это нужно бороться. А вот просто закрыть новую задачу, назвать её уточнением или оптимизацией — это просто, это удобно, и это оплачиваемо.

Когда бюджет становится ловушкой Знаете что ещё страшное? Что в какой-то момент даже сам клиент перестаёт видеть финиш. Изначально был какой-то бюджет, была какая-то дорожная карта, было примерное понимание того, когда это всё закончится. Но потом месяц за месяцем идут новые запросы, новые уточнения, новые идеи. Бюджет раздувается, сроки ползут вправо по диаграммам Ганнта, а финиш всё ещё не видно. Когда уже потрачено в три раза больше, чем планировали, становишься заложником. Нельзя просто так забрать проект и не запустить его, потому что это будет больно. Это будет выглядеть как провал. Это будет признание, что деньги потрачены впустую. Поэтому продолжают. Убеждают себя, что нужно ещё немного, что вот-вот сделают идеальный MVP, который не стыдно выкатить на рынок. Ещё немного подправят, ещё немного оптимизируют. Может быть, добавят эту фичу, которая изменит всё. Но проблема в том, что в T&M-режиме у команды нет стимула торопиться с финишем.

Ловушка идеальной формулы И ещё одна хитрая вещь: клиент начинает верить, что вот ещё чуть-чуть — и вот будет идеальный MVP, который не стыдно показать. Вот ещё парочка фич, ещё парочка оптимизаций, ещё парочка тестирований, и вот оно, совершенство. Но проблема в том, что идеальный MVP — это утопия. Это вещь, которая не существует. Есть MVP, который готов к запуску, который выполняет основное обещание продукта и не содержит критических багов. И всё. Всё остальное — это либо разработка v1.1, либо пилотное тестирование на реальных пользователях, которые укажут, что нужно менять, а что нет. Но если можно бесконечно платить за новые слои функциональности, если нет чёткого финиша, то будут пилить и пилить. И нейросеть в голове будет генерировать всё новые и новые идеи, потому что это же интересно, это же важно, это же улучшает продукт.

Результат? Техдолг раздувается, бэклог превращается в какой-то зоопарк непонятных возможностей, команда запутается в направлениях, и в конечном итоге получится завалившийся проект с полусделанным кодом, которым никто больше не хочет заниматься.