Борьба с последствиями плохого ТЗ иногда ценится выше, чем работа по его предотвращению.
Кратко о парадоксе: все ругают костыли и авралы, но они повторяются вновь и вновь. Значит, это кому-то нужно? Посмотрим на экосистему проекта не с технической, а с экономической и карьерной точек зрения.
Бенефициары пожаров и их мотивация
1. Менеджер-герой (Пожарный начальник)
Быстрая карьера. Он не создает предсказуемую скучную рутину, он регулярно спасает проект в глазах высшего руководства. Его ценят за оперативность и пробивные качества.
Давит сроками (нам надо выйти первыми!), минимизирует этап анализа (сделаем по ходу), поощряет работу в ночи. После успешного тушения обязательно пишет победный отчет.
Цитата-штамп: «Ребята, я выбил нам премию за этот аврал! Без нас бы все рухнуло!».
2. Разработчик-звезда (Волшебник-одиночка)
Незаменимость, рычаг для роста зарплаты, профессиональный нарциссизм. Только он знает, как работает этот черный ящик из костылей. Его авторитет в команде держится на знании, где тут еще бомба заложена.
Может саботировать документирование и передачу знаний (некогда, тушим!). Предлагает быстрые сложные решения вместо простых, но требующих согласований.
Цитата-штамп: «Да я эту интеграцию за ночь на коленке слепил, пока вы тут со своими митингами!».
3. Внешний консультант/подрядчик (Пожарная команда на аутсорсе)
Прямая финансовая выгода. Чем больше кризисов и чем они непредсказуемее, тем больше часов по высокой ставке можно продать. Долгосрочный контракт на поддержку шаткого решения.
Поддерживает миф об исключительной сложности системы, которую могут поддерживать только они. Не заинтересованы в создании устойчивой архитектуры — это убьет поток заказов.
Цитата-штамп: «Ваша система — уникальный зоопарк. Нам придется выделить специального инженера, чтобы постоянно мониторить это...»
4. Поджигатель с бензином
Получение максимального функционала за минимальные первоначальные деньги и сроки. Возможность потом шантажировать подрядчика: «чините бесплатно, или мы не примем у вас работы и не заплатим».
Формулирует ТЗ как сделайте на уровне зарубежных аналогов, только лучше и на нашем ПО. Давит на низкую цену и скорость. На этапе тушения обвиняет команду в непрофессионализме, выбивая скидки или дополнительные фичи.
Цитата-штамп: «Как это не было в ТЗ? Это же очевидная вещь! Я думал, вы специалисты!»
Условия, при которых тушение становится выгодной стратегией
1. Культура героизма в компании. Поощряются доски почета с фотографиями тех, кто спал в офисе. Спокойная плановая работа считается ленью.
2. Короткий горизонт планирования. Проект/стартап должен показать хоть что-то инвесторам к следующему кварталу. Долгосрочное здоровье кода никого не волнует.
3. Неразбериха в финансировании. Деньги на проект выделяются по остаточному принципу или тушением можно обосновать внеплановое финансирование (дать денег, чтоб не позориться).
4. Отсутствие метрик качества. Руководство не измеряет время на поддержку, количество инцидентов, удовлетворенность команды. Измеряется только факт сдачи в срок.
Длинная цена пожарной экономики (Кто в итоге проигрывает?)
Накопительный техдолг, который через 2-3 года приводит к технологическому коллапсу, когда нельзя ни добавить фичу, ни масштабироваться.
Выгорание лучших специалистов, которые уходят туда, где ценят их умение создавать, а не чинить. Токсичная атмосфера.
Потеря гибкости и скорости на длинной дистанции. Конкуренты с чистой архитектурой начинают обгонять.
На рынке становится известно, что тут горящий ад, и перестают приходить сильные кандидаты.
Что делать? Как сместить стимулы с тушения на проектирование
Эффективнее не бороться с людьми, а менять систему оценки:
1. Внедрить метрики устойчивости. Количество инцидентов после релиза, время на развертывание, индекс удовлетворенности разработчиков (DevEx).
2. Вознаграждать скучные достижения. Премировать за снижение техдолга, за полное покрытие тестами, за отличную документацию.
3. Ввести право на дизайн. Выделять в каждом спринте обязательное время на проектирование и рефакторинг.
4. Менять риторику. Не мы героически потушили пожар, а мы допустили системный сбой на этапе проектирования. Вот план, как исключить это в будущем.
Кейс 1: CRM для производителя тяговых составов (Low-code платформа)
Крупному производителю нужна была CRM-система для управления продажами.
Заказчик решил, что сперва нужно идеальное техзадание. Процесс его создания с привлечением внешнего интегратора занял почти год. К моменту готовности ТЗ приоритеты, бюджет и условия бизнеса у заказчика изменились.
Проект был фактически заморожен ещё до начала разработки. Ресурсы (время, деньги на аналитиков) были потрачены впустую. Реального тушения не потребовалось, потому что пожар случился на этапе предпроектной подготовки.
Кому это было выгодно? В данном случае — внешнему интегратору, который получил долгосрочный контракт на составление документации. Сам процесс создания ТЗ стал самоцелью, оторванной от гибкости и скорости бизнеса.
Кейс 2: Неясная интеграция платежной системы
Добавление в мобильное приложение интеграции с платежной системой для автоматических платежей.
Требования были сформулированы поверхностно: интеграция должна работать без ошибок и быстро. Критически важные детали (безопасность транзакций по стандарту PCI DSS, обработка ошибок, логирование) в ТЗ отсутствовали.
Когда разработчики начали работу, они столкнулись с невозможностью реализовать задачу по общим формулировкам. Проект встал, начался хаос: команда тратила время на уточнения, а менеджер не мог назвать сроки.
Кому это было выгодно? В краткосрочной перспективе — никому. Но в культуре героизма такой кризис мог выдвинуть на первый план менеджера-пожарного, который будет спасать проект за счет авралов и переговоров, или разработчика-звезду, который на коленке быстро накинет решение, став незаменимым.
Кейс 3: Выбор технологии для хранения данных
Разработка системы управления контентом (CMS).
В ТЗ не был определен и обоснован тип базы данных (SQL или NoSQL). Менеджер проекта, не разбираясь в технических нюансах (масштабируемость, структура данных), не мог принять аргументированное решение.
Команда разработки тратила рабочее время на долгие объяснения основ. Процесс принятия решений затягивался, что увеличивало сроки и риск выбрать неэффективную для задачи архитектуру.
Кому это было выгодно? Ситуация создает почву для конфликта компетенций. Может усилиться позиция технического лида или архитектора, чье мнение становится абсолютным, так как формальный руководитель не может его оспорить. Это может привести к перекосу в управлении.
Выращивание сложного ИТ-продукта — это не тушение пожаров, а садоводство. Нужно не героически выкорчевывать сорняки, а создать такую экосистему (процессы, культуру, метрики), где у них нет шансов вырасти. Первый шаг — честно ответить на вопрос: а не кормится ли кто-то в вашем проекте от этих сорняков?
