Почасовое китобойное судно. Как НЕ стоит продавать каждую секунду на галере

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

Time & Material на самом деле честная модель, в теории. Разработчик пишет, студия отгружает часы, клиент платит за то, что реально сделано. Никакого угадывания, буфера, никакого скрытого бюджета, никаких сюрпризов. Справедливо, прозрачно, логично.
Только вот беда — в момент острого кризиса или просто затяжного давления по объёмам это превращается в совсем другой вид модели. Даже не в модель, а в режим паразитического "выжиМания" всех жизненных соков, когда интересы того, чтобы проект реально запустился, потихоньку отползают на второй, третий план, а во главу выползает одна единственная парадигма: держи команду загруженной, держи трубопровод денег открытым, и самое главное не давай ему захлопнуться.
Потому что если проект встанет — а он рано или поздно встанет, когда текущие задачи кончатся — то что? Надо будет откуда-то брать загрузку, согласовывать её — а это простои, неопределённость невыполнение плана, нищета и смерть. Примерно такой масштаб катастрофы в голове у рядового менеджера обвязанного KPI.

Time & Material сама по себе — честная, правильная, я бы сказал, взрослая модель. Но тут как со спичками - надо уметь этим пользоваться, иначе пожар. Когда смотрят на проект не как на продукт, который должен родиться и встать на ноги, а как на источник часов, которые можно брать в работу бесконечно, начинается то, что убивает проект гораздо хитрее, чем даже банальное отсутствие денег.

Начинают говорить "да" каждой хотелке клиента. Не потому, что это правильно для продукта. Просто потому, что это задачка. А задачка — это часы. А часы — это деньги на зарплату. Клиент хочет переделать базовый сценарий пользователя? Окей, этот манёвр будет стоить нам ещё часов семьдесят. А во время вдруг пришло осознание что и дизайн чёт приелся (хотя его ещё никто не видел во вне команды и самого заказчика). Да-да, мы же на T&M, переделаем, и это отдельные часы.

Результат? Проект раздувается как пузырь, но не растёт как организм.

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

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

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

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

Когда уже потрачено в три раза больше, чем планировали, становишься заложником. Нельзя просто так забрать проект и не запустить его, потому что это будет больно. Это будет выглядеть как провал. Это будет признание, что деньги потрачены впустую.

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

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

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

Но если можно бесконечно платить за новые слои функциональности, если нет чёткого финиша, то будут пилить и пилить. И нейросеть в голове будет генерировать всё новые и новые идеи, потому что это же интересно, это же важно, это же улучшает продукт.

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

С наступлением "черного понедельника" мы осозновали что бесконечная работа по Т&M одна из причин нашего текущего положения, но было ощущение что мы тоже подсознательно хотим таким образом вычислить ведьму среди честных горожан и свесить все шишки на неё. Ну в смысле найти корневую причину, повесить все огрехи на неё и спокойно двигаться дальше. Но! Недавно случилось кое-что, что показало эту проблему во всей её наготе. К нам пришёл клиент, для которого несколько месяцев назад делали разовую небольшую работу. Он попросил посмотреть на его проект, на который уже было потрачена просто неприличная сумму. Всё инкогнито, под NDA, без имён и названий — просто мнение со стороны.И то что увидели, заставило увидеть себя же в кривом изуродованном зеркале.В логах и отчётах разработчики сгружали всё подряд — даже собственные созвоны между собой (по 3-6 часов в неделю), за которые платил клиент фуллпрасом. Создавали какие-то артефакты в виде планов развития и масштабирования, но без какой-то конкретики. Успели даже рефакторинг провести (даже без первого релиза). А под капотом приложения функционала на 2-3 простых сценария. Видно было, что проект высасывал бюджеты, видно было, что клиент понимает, что что-то не так, и видно было, что это было похоже на себя самих.

Это не была ошибка. Это была система. Система, в которой каждый день генерируются задачи, каждый час закрывается, каждый отчёт показывает активность, но продукта всё нет и нет. Это была ловушка, в которую они сами себя загнали, не осознав этого.

Вот здесь-то и встаёт вопрос позиции менеджера. Нужно удержать несколько вещей одновременно: рентабельность проекта (часовая ставка была нормальной чтобы не работать в минус), загруженность команды (чтобы люди не сидели без работы, простои это потери же), своевременные платежи (чтобы клиент платил, а не задерживал), и — самое главное, что очень часто забывается — развитие проекта.

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

Проект иссох? Несите следующий!

В какой-то момент наступает кризис, когда старые проекты уже не генерируют столько сколько нужно нам для удовлетворения аппетитов, а новых доноров нет. Становится ясно - с нами что-то не так.Проектов становится меньше. Денег становится меньше. Бюджеты сжимаются.

И вдруг — о, чудо! — появляется стимул сделать что-то смертельно важное: закончить проект и запустить его.

Потому что если он не запустится, то вообще не будет никакого дохода. Ни сейчас, ни потом. Пустая трата бюджета, пустая трата времени команды. И клиент, и студия начинают смотреть на проект уже не как на источник часов, а как на результат, который должен быть.Вдруг становятся видны приоритеты. Вдруг становится ясно, какие фичи действительно критичны, а какие можно выпилить без ущерба для идеи. Вдруг появляется честный разговор: что мы вообще пытаемся делать, какая дорожная карта, когда финиш.

И вот парадокс: кризис, который давит со всех сторон, становится тем самым механизмом, который спасает проекты. Потому что он навязывает измеримые результаты. Он говорит: результатом является не потраченный бюджет, а работающий продукт, который люди используют или хотя бы готовы попробовать.Можно существовать в режиме бесконечного T&M долгие годы, если вокруг благоприятная среда. Если хватает денег, если нет конкуренции, если никто никуда не торопится. Это вполне себе жизнеспособный режим. Неэффективный, болезненный, но жизнеспособный.Но как только контекст меняется, вся та мягкость и удобство рассыпается, и остаётся только холодная реальность: либо проект работает, либо нет. Либо он приносит деньги, либо он их жрёт.

И вот что важно понимать: проблема была не в T&M как модели оплаты. Проблема была в том, что забыли, что T&M — это инструмент управления неопределённостью, а не инструмент бесконечного выживания. Когда сроки неясны, когда требования плавают, когда нельзя точно предсказать, что и как долго делать — да, T&M спасает жизнь. Это честно, это прозрачно, это справедливо.Но T&M должен быть не целью, а средством. Целью должен быть запуск проекта. Средством достижения этой цели может быть T&M, может быть Fixed Price, может быть гибридная модель. Но цель всегда одна: движение к результату.Менеджер должен постоянно держать в голове это напряжение: с одной стороны, нужно обеспечить рентабельность, загруженность команды, стабильный доход. С другой стороны, нужно не забывать, что проект — это не средство для этого, а цель, которой нужно послужить.

И когда давление высокое, когда хочется просто захватить любой объём работ, чтобы выжить, — в эти моменты как раз нужно остановиться и спросить: а мы вообще это в сторону финиша двигаем, или мы тут просто часы считаем и деньги принимаем?Потому что если выбор второе, то финиш никогда не наступит. А проект станет тем самым вечным MVP, который сжирает бюджет, деморализует команду и заставляет клиента потихоньку разочаровываться в идее, потому что видит, что она не работает.

Кризис учит жестоко, но он учит правильному. Он говорит: ставьте результаты выше процессов, запуски выше часов, работающие продукты выше идеальных архитектур.

____________________________________

Никого не принуждаю, ничего не продаю. Во всяком случае пока что.

Просто заходите, просто читайте: