Вы придумали продукт. Посчитали финмодель, защитили концепцию перед руководством, получили одобрение. Все согласны — запускаем. Проходит месяц, два, пять — а продукта нет. Есть бесконечные обсуждения, письма на 15 пунктов и вопрос «А что, если пользователь откроет 10 вкладок одновременно?»
У меня это происходило одновременно в двух мирах. На основной работе — проект, который буксует пятый месяц. В личном — бот, который я собрал за 2 часа и за 5 недель довёл до продажи. Разница не в сложности. В подходе.
Я назвал это для себя «синдром Мавра» — когда каждый участник процесса искренне хочет помочь, но своими дополнениями оттягивает запуск на месяцы. И остановить его сложнее всего, потому что нельзя сказать «ты мешаешь» человеку, который помогает.
Как раздуваются проекты
Вы защитили концепцию, бизнес одобрил, финмодель посчитали. Передали в работу — и аналитик вместо каркаса ТЗ начал генерировать пользовательские сценарии. На каждый сценарий — обсуждение. Обсуждение рождает новые вопросы. Вопросы возвращают к пунктам, которые уже решили. Руководство подхватывает: «А давайте ещё добавим вот это.»
Аналитик спрашивает: «А что, если пользователь откроет 10 вкладок в разных браузерах и в каждой применит скидку?» Подрядчик объясняет: это стандарт — система пересчитывает сумму при оплате, раньше не может. Аналитик предлагает подрядчику доработать свой продукт. Вместо запуска — обсуждаем редкий сценарий.
Если вы владелец рекламного агентства — вы видели то же самое с другой стороны. Клиент согласовал макет лендинга, но при каждой встрече добавляет «ещё один блок». Три месяца — лендинг не запущен. Или вы продакт в IT-компании: ТЗ на интеграцию переписывают четвёртый раз, потому что каждый отдел добавил свои требования.
Паттерн один и тот же. Никто не говорит чётко: «Это — первая версия. Всё остальное — фаза 2.»
2 часа до рабочего продукта
Пока на работе шёл пятый месяц обсуждений, я собрал бота, который генерирует контент для турагентств. От идеи до рабочего прототипа — 2 часа. ИИ писал код, я собирал логику.
Дальше — недельные спринты.
Первая неделя: тестирую сам, записываю баги в бэклог. Ничего не трогаю — просто наблюдаю. В конце недели одним днём всё исправил.
Вторая неделя: запустил 8 тестеров — друзей-турагентов из целевой аудитории. Они начали пользоваться, присылать замечания. Собрал обратную связь, внёс правки — потратил 4 часа за два дня.
Третья неделя: тишина. Тестеры молчат — всё работает. Ни одного критического бага.
Четвёртая неделя: провёл кастдевы — подготовил вопросы вместе с ИИ, созвонился с каждым тестером. Оценка — 8 из 10. Один тестер полностью отказался от копирайтера и перешёл на контент из бота. Другой — руководитель крупного агентства — сказал, что бот закрывает задачу за 3 минуты вместо 5 часов.
Пятая неделя — запуск в продажу.
Всего не учёл? Конечно. Но за 5 недель прошёл путь от идеи до денег. А проект на основной работе за то же время — от черновика до черновика.
И вот что меня спасло: я был занят другими задачами и физически не мог сидеть и допиливать бота. Занятость защитила от перфекционизма лучше, чем дисциплина.
Почему прямые аргументы не работают
На основной работе я пробовал говорить: «Давайте упростим и запустим.» Каждая встреча заканчивалась новыми хотелками.
Тогда я подошёл иначе. Попросил подрядчика — он был на всех встречах и видел картину целиком — сформировать минимальную версию. И озвучить дилемму: «Простая версия к дедлайну или полная через полгода.» Отдельно проговорил то же самое с коллегами — каждому лично, в кулуарах.
Когда на общей встрече подрядчик озвучил рекомендацию разбить внедрение на этапы — все уже были готовы. Руководитель сказал: «Да, надо упростить, потом доработаем.»
Это не манипуляция — аргумент был честным. Но прозвучал от того, кого были готовы слушать. Мавр остановился — потому что «стоп» сказал не я, а внешний эксперт. Иногда ваши слова игнорируют не потому, что вы неправы, — а потому что вы «свой».
«У нас не стартап, у нас ответственность»
Покажите мне продукт, который с первого дня работает без багов и его никто не чинит. Я не встречал. За каждым сервисом — баги, которые разработчики ловят и чинят.
Аналитик принимает решения на основе своего опыта. Но пользователи живут в другой реальности. Продумать за пользователя, как ему будет удобно, — иллюзия. Узнать можно одним способом: дать попробовать.
Да, корпорация — не стартап. Но чем быстрее вы покажете продукт пользователям, тем быстрее поймёте, что им нужно. Пока вы проектируете сценарии на бумаге, кто-то уже запустил и собрал обратную связь.
Как защитить первую версию от доработок
1. Зафиксируйте первую версию письменно. Документ с датой. Все дальнейшие хотелки — в отдельный список «Фаза 2». Если потом будут искать виноватого — у вас есть история.
2. Считайте стоимость каждой хотелки в неделях. Не в функциях, а во времени. Фраза «эта доработка — плюс 3 недели к запуску, запускаем без неё или сдвигаем дедлайн?» работает сильнее, чем «давайте упростим». Попробуйте на ближайшей встрече.
3. Выбирайте, через кого озвучить аргумент. Внешний эксперт, подрядчик, партнёр — тот же тезис от них звучит иначе, чем от вас.
4. Готовьте почву с разных сторон. Проговорите позицию с каждым участником отдельно. Когда аргумент прозвучит на общей встрече — все уже будут готовы.
5. Задайте ритм недельными спринтами. Неделя — тестирую сам. Неделя — тестируют пользователи. Неделя — собираю обратную связь. Без сроков — бесконечные доработки.
6. Фиксируйте всё письменно — встречи, версии ТЗ, согласования. Это защита и источник контекста, который вы сами потом не вспомните.
Главное правило
Не пытайтесь нарисовать космическую станцию на бумаге. Начните строить — и тогда поймёте, как это нужно делать. Пока вы продумываете сценарий «один на миллион», кто-то уже запустил, собрал обратную связь и вышел на рынок.
Если сталкивались с бесконечными доработками — расскажите в комментариях. Как останавливали? Что сработало?