Мы привыкли смотреть на график МакЛими как на финансовую таблицу. Мол, вот тут мы тратим копейки, а вот тут - миллионы. Но у этой кривой есть изнанка, о которой принято молчать на совещаниях. Это не просто график изменения себестоимости. Это кардиограмма команды, создающей продукт. И если следовать этому графику слепо, он ведет не к прибыли, а к эмоциональному выгоранию и медленному профессиональному самоубийству.
«В начале проекта вы можете сильно влиять на результат... а внимание к цифрам просыпается в точке А, когда деньги уже потрачены», - гласит классика. В IT-разработке это означает одно: кто-то героически пишет код ночами, чтобы потом героически его переписывать. Давайте разберем этот путь не в долларах, а в человеческих нервах.
Точка Б: Эйфория «Бумажной» стадии и смысл
Точка Б на вашем графике - это пик кривой «Внимание к эффективности». В строительстве это чертежи, в разработке - это Product Discovery. Это время, когда продукт существует только в головах, на макетах и в схемах архитектуры.
Почему это лучшая точка для создателей? Потому что здесь царит созидание.
- Влияние на результат максимально. Разработчик чувствует себя архитектором вселенной: он может предложить гениальное решение, переписать логику взаимодействия сервисов, придумать элегантный интерфейс.
- Цена ошибки минимальна. Изменить схему базы данных на доске - бесплатно. Изменить её в проде - это ночные деплои и седые волосы.
- Здесь команда работает на смыслах, а не на «горящих сроках». На «бумажной» стадии энергия создателей (зеленая кривая) бьет ключом. Мы чувствуем, что делаем что-то важное и правильное.
Когда команда тратит достаточно времени на точку Б, она не просто экономит деньги. Она создает психологический буфер безопасности. Это фундамент, который позволяет потом не сойти с ума.
Точка А: Дом боли и рождение «слепых кротов»
А теперь перенесемся в точку А. Фиолетовая кривая влияния на себестоимость падает вниз, а синяя кривая затрат на изменения устремляется в космос. Внимание бизнеса наконец-то переключается на «освоенные бюджеты». И вот здесь начинается ад.
В IT это выглядит так:
- Бизнес спохватывается: «Почему так дорого? Почему так долго? Где фичи?»
- Команда, которая пропустила этап проектирования, уже нагородила архитектурных «костылей». Каждая новая фича - это не добавление кирпичика, а попытка пристроить антресоль к несущей стене без чертежей.
- Начинается режим пожарной команды (Crunch time).
Именно в точке А мы и превращаемся в тех самых «слепых кротов», о которых вы писали. Мы роем в темноте. Мы не видим ничего, кроме ближайшей задачи в Jira. Мы лепим, потому что «дальше будет видно». Но слепой крот не видит, что роет в сторону пропасти. Он просто инстинктивно двигается вперед, повинуясь давлению сверху.
Но самое страшное здесь - это эрозия смысла. Разработчик больше не творец. Он - ремесленник на конвейере, который тушит пожары. Он знает, что его работа - это «технический долг», который он сам же и создал. Он видит, что код становится уродливым, но у него нет времени его исправить.
Кривая затрат на изменения (синяя линия) в точке А - это не только деньги инвестора. Это цена человеческой энергии. Каждая правка в этот момент стоит команде кусочка души. Именно здесь начинается выгорание: цинизм, апатия, ненависть к продукту и к пользователям, которые «не понимают, как это круто работает».
Ловушка «Героизма» и иллюзия контроля
Почему мы раз за разом попадаем в точку А, зная о графике МакЛими? Почему бизнес продолжает требовать «быстрый MVP вчера», а разработчики соглашаются работать «через жопу»?
Потому что в IT-культуре (особенно в стартапах) процветает культ героизма.
- «Мы спасли проект, переписав бэкенд за выходные!» - звучит гордо.
- «Мы взяли невозможный дедлайн и выжили!» - это путь к инфаркту в 30 лет.
Мы путаем скорость с эффективностью. Мы думаем, что если быстро написать код, то мы обгоним конкурентов. Но мы забываем, что в точке А скорость разработки падает почти до нуля из-за сложности системы. И тогда бизнес делает логичный, но губительный шаг: нанимает еще людей. (Закон Брукса: «Добавление человеческих ресурсов в опоздавший проект только замедляет его»). Больше людей - больше коммуникации - больше хаоса - больше выгорания.
Как выбраться из точки А, не потеряв команду?
Идеальных команд, которые всегда работают в точке Б, не существует. Мы все люди, и мы все иногда ошибаемся. Но чтобы не превратить проект в кладбище сгоревших надежд, нужно смещать фокус с управления бюджетом на управление вниманием и энергией.
- Защита Точки Б (Право на чертежи). Не начинайте писать production-код, пока не поймете архитектуру. Это не бюрократия. Это забота о психике команды. Потратьте 20% времени на то, чтобы подумать. Это спасет 80% нервов.
- Институт «Технического здоровья». Если вы уже в точке А, не пытайтесь выбраться одним прыжком. Выделяйте 10-15% времени каждого спринта на рефакторинг и выплату технического долга. Это не «потеря времени», это психотерапия для команды. Возможность сделать код красивым возвращает разработчикам веру в себя.
- Легализация ошибок. Ошибка в точке Б - это ценный опыт. Ошибка в точке А - это катастрофа. Создайте культуру, где плохие новости сообщают рано, когда их еще можно исправить дешево.
- Отказ от культа героизма. Не премируйте за овертаймы. Премируйте за предсказуемость и качество. Здоровый разработчик, который уходит в 6 вечера, напишет больше качественного кода за год, чем выгоревший «герой», который живет на работе.
Вместо заключения
Кривая МакЛими - это не про то, как сэкономить деньги. Это про то, как не потерять людей.
Мы, создатели программных продуктов, не слепые кроты. Мы архитекторы цифровых миров. И если мы будем помнить об этом в точке Б, нам не придется в точке А героически разгребать завалы, проклиная всё на свете и роя вслепую в темноте.
Считать надо не только деньги. Считать надо ресурс своей команды. Потому что код можно переписать. А выгоревшего человека - почти невозможно.