Driven-подходы: антипаттерны разработки

Движущая сила: негативная — страх, паника, дедлайны, крик; то, чем процесс разработки управлять не должен.

Уровень применения: организация и команда (культурные антипаттерны).

Статус: сатирический/ироничный жанр индустриального фольклора — ярлыки без канонических первоисточников, но с вполне реальными прототипами в каждой второй компании.

Назначение материала: диагностическое. Это не методологии для внедрения, а распознавательные ярлыки для больных режимов: чем раньше режим распознан — тем раньше применим антидот.

Общее #

В серии о driven-подходах уже разобрано одиннадцать «настоящих» методологий — от TDD до Readme-DD. У каждой есть движущая сила — артефакт или практика, которая направляет решения: тест, домен, контракт, реестр рисков, гипотеза. Система координат «что движет процессом» оказалась удобна не только для описания хорошего: индустриальный фольклор давно присвоил суффикс «-Driven Development» режимам, в которых движущей силой становится эмоция или давление — паника, страх, срок, громкость самого громкого участника.

Эта статья — оборотная сторона серии: сводка «сатирических» *DD. Жанр у них особый, и его важно проговорить заранее.

Это антипаттерны, а не методологии. Термин «антипаттерн» ввёл Эндрю Кёниг (1995), по аналогии с паттернами проектирования: антипаттерн — часто встречаемое решение, которое систематически даёт отрицательный результат. Книга Брауна, Малво, Маккормика и Моубрея AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis (1998) собрала десятки таких «решений» с полями «симптомы, причины, последствия, рефакторинг». Сатирические *DD следуют той же схеме — только распространяются они не книгами, а блогами, конференционными шутками и разговорами на кухнях. Именно поэтому у большинства из них нет канонического первоисточника: термин живёт в фольклоре, и это часть жанра.

Почему суффикс «-Driven» прижился у негативных режимов. Формула «X Driven Development» изначально продавала методологию: она обещала, что некая разумная сила X направляет процесс. Фольклор развернул формулу в зеркале: если процессом движет паника — это тоже «Panic Driven Development», только без обещаний и с гарантированным результатом противоположного знака. Ирония названия работает как ярлык-диагноз: она одновременно признаёт, что процессом действительно кто-то (что-то) управляет, и называет этого управляющего по имени. Управление не исчезает никогда — вопрос всегда только в том, что именно сидит за штурвалом.

Цель статьи — диагностическая. Описываемые ярлыки полезны как инструмент распознавания: назвать режим по имени («у нас сейчас Deadline DD») — первый шаг к тому, чтобы перестать считать его нормой. Внедрять их не нужно и невозможно: ни один из них не выбирают сознательно. Они возникают сами — как побочный эффект управленческих решений (или их отсутствия) — и закрепляются, если их не распознать и не встретить антидотом.

Ирония — инструмент памяти, а не высмеивание. Лёгкий сарказм в названиях и описаниях помогает ярлыку закрепиться — «Panic Driven Development» запоминается лучше, чем «реактивный режим управления с нарушением приоритизации». Но за каждым ироничным названием стоит реальная боль конкретных команд: выгоревшие люди, заброшенные стратегии, тонущий в дефектах продукт. Именно поэтому жанр статьи — ирония в названиях, но нейтральный разбор в содержании.

Наконец, дизамбигуация. Два ярлыка из этой статьи образуют аббревиатурные коллизии с настоящими методологиями серии: Fear Driven Development совпадает по аббревиатуре с FDD — Feature Driven Development, а Deadline Driven Development — с DDD — Domain Driven Design. Обе коллизии разобраны явно в соответствующих разделах; при использовании аббревиатур FDD и DDD в разговоре первым делом стоит уточнять, о чём идёт речь.

PDD — Panic Driven Development #

Panic Driven Development (PDD) — режим, в котором приоритеты, планы и технические решения определяются самым свежим инцидентом. Внешне это выглядит как «оперативная работа с проблемами», по сути — полный отказ от управления: процессом управляет не план и не ценность, а последняя неприятность. Второе название режима — «пожарный» (firefighting mode): команда из инженеров превращается в бригаду пожарных, которая мечется от одного возгорания к следующему, не успевая разобраться в причинах возгораний.

Единственный подход серии, который не нужно внедрять: он возникает сам, как только совпадают три условия — плохая наблюдаемость (о проблемах узнают от пользователей), отсутствие приоритизации (любая жалоба становится задачей номер один) и отсутствие анализа причин (каждый инцидент тушится симптомно).

Механика режима — самоподдерживающийся цикл. Инцидент обнуляет план; команда в спешке выпускает хотфикс «лишь бы работало»; хотфикс, сделанный без понимания причин и без тестов, порождает новые дефекты; новые дефекты дают новый инцидент. На каждом обороте команда убеждается, что «планировать бессмысленно — план всё равно сорвут», и перестаёт пытаться вовсе. Так режим становится устойчивым равновесием: выход требует сознательного усилия против очевидного «сейчас-горит-же».

   инцидент ──▶ обнуление плана ──▶ спешный хотфикс без анализа
      ▲                                          │
      └────────── новый дефект ◀─────────────────┘

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

Симптомы:

• Планирование вырождается в «тушим, что горит»: спринты формальны, roadmap не переживает первой недели.
• Почти любая задача помечена «срочно»; слово «срочность» обесценилось и перестало что-либо сообщать.
• Появляются герои-пожарные — люди, которые «спасают проект» по ночам и получают за это признание и награды. Героизм становится системой поощрения, а не сигналом системного провала.
• Постоянный контекст-свитчинг: ни одна задача не доводится до конца, всё прерывается.
• Количество инцидентов со временем растёт: тушение симптомов порождает новые пожары (торопливые хотфиксы ломают смежное).

Причины:

• Отсутствие наблюдаемости (мониторинга, алертов, метрик) — команда узнаёт о проблемах позже пользователей.
• Отсутствие процесса приоритизации: «последний крик» механически вытесняет всё.
• Культура героев, в которой спасательство ценится выше предотвращения.
• Симптомное тушение без анализа причин: инцидент закрыт — фиксация причин не проводилась.

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

Последствия:

• Круг замыкается: чем больше тушим — тем больше горит. Спешка порождает дефекты, дефекты — новую панику.
• Растёт технический долг: в панике выбираются самые быстрые (самые грязные) решения.
• Выгорание: режим тушения физиологически несовместим с долгим горизонтом работы.
• Вокруг героев возникает узкое место: знания о «пожароопасных местах» не распределены, bus factor падает.

Антидоты режима — инженерные и процессные: наблюдаемость, реестр рисков (Risk-DD), регулярные безобвинительные пост-мортемы и систематический анализ причин инцидентов. Подробный разбор — в разделе «Антидоты».

Fear Driven Development #

Fear Driven Development (Fear DD) — режим, в котором решения в разработке диктуются страхом: страхом наказания за ошибку, публичной порки на разборе, плохой оценки в отчёте, потери доверия руководителя. Движущей силой перестаёт быть ценность или качество — ими становится избегание личной угрозы. Формула режима: каждый участник оптимизирует не результат работы, а собственную безопасность.

Дизамбигуация: FDD — Feature и FDD — Fear #

Аббревиатура FDD в индустрии закреплена за Feature Driven Development — модельно-ориентированной методологией Джеффа Де Луки (1997) с пятиэтапным процессом и Chief Programmer-командами. Fear Driven Development — фольклорный ярлык, не имеющий ни методологии, ни первоисточника, ни инструментов: только симптомы. Совпадение аббревиатур чисто случайное, но в разговоре «у нас FDD» может означать диаметрально противоположные вещи — дисциплинированный процесс или парализованный страхом. Первое уточнение в любом таком разговоре: о фичах идёт речь или о страхе.

Отдельно отметим второе, более узкое значение Fear DD, встречающееся в блогах: страх перед кодом — боязнь трогать легаси-модуль, «который работает, но никто не понимает как». Это частный случай того же механизма (страх ошибки парализует изменения), и антидот у него общий — регрессионная страховка тестами.

Симптомы:

• Никто не хочет быть автором рискованного решения: инициатива мигрирует вверх, каждое решение требует «подписи начальства».
• Ошибки скрываются до последнего: о проблеме узнают, когда она стала аварией, — потому что признание ошибки на ранней стадии наказывалось.
• Знания не делятся: документировать и обучать коллег безопаснее не делать — «незаменимый не увольняем».
• Тесты и документы пишутся «для прикрытия»: формально есть, по сути — защита автора, а не помощь читателю.
• Изобретательство угасает: новый подход — это риск, старый (даже плохой) — безопасен.
• Согласования множатся: каждое действие обкладывается подтверждениями, чтобы ответственность была «размазана».

Причины:

• Blame-культура: разбор инцидентов превращён в поиск виновных, а не в поиск причин.
• Наказание за честно признанные ошибки при игнорировании скрытых.
• Микроменеджмент и тотальный контроль: недоверие как явная управленческая политика.
• Конкурирующие системы оценки (принудительные распределения, публичные рейтинги), в которых помощь коллеге равна ослаблению себя.

Последствия:

• Разрушается психологическая безопасность — ощущение, что можно высказывать идеи, задавать вопросы, признавать ошибки, не боясь унижения или наказания. Исследование Google Project Aristotle (2015) показало: именно психологическая безопасность — первый по значимости фактор эффективности команды, сильнее состава, стажа и индивидуальных навыков.
• Уходят сильные: у лучших больше всего альтернатив, и первыми режим покидают именно они.
• Решения замедляются и дорожают: согласование страха всегда длиннее согласования задачи.
• Организация теряет раннее обнаружение проблем — самое дешёвое место исправления дефектов.

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

Разница с PDD: паника — это реакция на внешние события в моменте, страх — фоновое состояние системы, которое искажает все решения, включая спокойные. Панический режим — «про события», страховой — «про культуру».

Deadline Driven Development #

Deadline Driven Development (Deadline DD) — режим, в котором единственной координатой проекта становится срок. Вопросы «что именно делаем» и «какого качества» подчинены вопросу «к какому числу»; scope и качество превращаются в переменные, которые молча режутся, пока срок остаётся константой. Классическая формулировка симптома: «неважно как, к пятнице».

Дизамбигуация: DDD — Domain и DDD — Deadline #

Аббревиатура DDD прочно закреплена за Domain Driven Design — подходом Эрика Эванса (2003), в котором движущей силой проектирования выступает предметная область и единый язык. Deadline Driven Development — фольклорный антипаттерн, «тёзка» по случайному совпадению букв. Дополнительная путаница: в старых текстах DDD иногда расшифровывают и как Data Driven Development. В любом серьёзном контексте DDD — это Domain; если собеседник вдруг говорит про сроки — уточните, прежде чем обсуждать агрегаты и bounded context.

Симптомы:

• Критерий качества решения — «успели или нет», а не «работает ли оно и какой ценой».
• Тихое отсечение скоупа «в темноте»: тесты, ревью, рефакторинг, документация откладываются «после релиза» — и «после релиза» не наступает никогда.
• Сверхурочные и crunch как норма, а не как исключение; планирование ведётся из расчёта на них.
• Оценки деградируют: сроки назначаются сверху без участия исполнителей, а затем «удерживаются» ценой качества.
• Техдолг не учитывается в планах — он вообще не считается деньгами.

Что говорят законы. Режим прямым текстом описан классикой софтверного менеджмента:

• Закон Брукса: добавление людей в опаздывающий проект замедляет его. Типовая реакция на срывающийся дедлайн — «бросить ещё разработчиков» — предсказуемо ухудшает ситуацию: время на введение в контекст съедает выигрыш.
• Законы Паркинсона и Гофштеттера: работа растягивается на всё отведённое время, а любая задача занимает больше времени, чем ожидается, — даже если учесть этот закон. Дедлайн, назначенный без резервов и без декомпозиции, закладывает срыв в саму свою конструкцию.

Экономика отсечённого качества. Ключевая иллюзия режима: срезанные тесты и ревью будто бы «экономят время». Классическая экономика ПО (Барри Боэм, Software Engineering Economics, 1981) показывает обратное: стоимость исправления дефекта растёт на порядки с удалением от момента внесения — условная единица на этапе кодирования превращается в десятки и сотни в эксплуатации. Отложенное тестирование не отменяет работу — оно переносит её в самое дорогое место, добавляя стоимость поиска (в продакшене дефект ещё нужно найти и воспроизвести) и цену простоя. «Успели к пятнице» за счёт качества — это не экономия, а кредит: тело кредита — срезанная работа, процент — экспоненциальный рост её стоимости.

Последствия:

• Цена дефекта растёт нелинейно: пропущенное ревью и тестирование не отменяются, а переносятся в самое дорогое место — эксплуатацию, где дефект находит уже пользователь.
• Накопленный технический долг замедляет каждую следующую итерацию: скорость «к пятнице» покупается в кредит под возрастающий процент.
• Проект превращается в «марш смерти» (death march, Эдвард Йордон): все заранее знают, что срок нереален, но продолжают делать вид.
• Дедлайны девальвируются: после двух-трёх «смертельных» сроков, пережитых без последствий, слово «дедлайн» перестаёт мотивировать вообще.

Классическая иллюстрация тихого отсечения качества. За неделю до релиза принимается «временное» решение: автотесты для новой фичи напишем после, ревью сократим до беглого взгляда, документацию перенесём на следующий спринт. Релиз выходит в срок. Автотестов нет и через полгода — потому что «сейчас опять горит»; баги из непротестированной фичи всплывают в поддержке по одному, каждый требует воспроизведения «на живом»; следующий релиз наследует те же решения, ведь precedente уже создан. Ни одно из решений не было одобрено явно — качество срезалось не решением, а молчанием.

Отличие от здорового планирования: срок как ограничение — нормален (у релизов бывают окна, рынки и регуляторы); срок как единственная координата, определяющая качество решений, — антипаттерн. В Deadline DD дедлайн перестаёт быть инструментом и становится содержанием работы.

Scream Driven Development #

Scream Driven Development (Scream DD) — режим, в котором приоритеты распределяются по громкости: что делается первым, определяется не ценностью и не стратегией, а тем, кто громче и настойчивее требует. Английская формула режима — «the squeaky wheel gets the grease» («скрипучее колесо получает смазку»). Движущая сила здесь — декибелы: самый эмоциональный стейкхолдер де-факто владеет roadmap’ом команды.

Симптомы:

• План на неделю определяется тем, кто последним громко написал в чат или «поднялся до руководства».
• Бэклог забит «срочняками», у каждого из которых — свой настойчивый автор и ни одного — обоснования ценностью.
• Обходы процесса нормализованы: «написать напрямую разработчику» работает лучше, чем поставить задачу официально.
• Продажи и маркетинг обещают клиентам фичи напрямую, минуя приоритизацию, — потому что так исторически быстрее работало.
• Вежливые и стратегические задачи умирают в бэклоге: у них нет адвоката, который кричит.

Причины:

• Отсутствие явного, публичного процесса приоритизации: раз приоритеты непрозрачны — их место занимает давление.
• Слабое product-ownership: владелец продукта не принимает решений, и вакуум заполняет самый громкий.
• Поощрение скорости реакции вместо ценности: метрика «как быстро закрыли жалобу» вместо «что это дало».
• Управленческая трусливость: руководителю проще устать от крика и уступить, чем выдержать конфликт и объяснить «нет».

Последствия:

• Стратегия дрейфует: продуктовый план собирается из случайных требований, а не следует из целей.
• Все участники быстро обучаются правилу игры: команды тоже начинают «кричать» — экономика взаимного шантажа.
• Пропадает справедливость: усилия тратятся на тех, кто умеет давить, а не на тех, кому нужно.
• Доверие к процессу обнуляется — «планирование» становится ритуалом, все знают, что решает крик.

Типичная неделя в этом режиме выглядит так. Понедельник: план на спринт согласован. Вторник: продажам нужно «спасти сделку», и клиенту обещают доработку к концу месяца — в обход приоритизации. Среда: «почему по доработке нет движения?» пишется в общий чат с руководителем в копии. Четверг: задача вставляется в спринт первой, согласованный план откладывается. Пятница: планирование следующего спринта начинается с оговорки «если опять ничего не ввалится». Через месяц выясняется, что «спасённая сделка» не подписана, а отложенный план стал причиной ухода ключевого клиента — того, который не кричал.

Родственный режим — PDD: паника тоже реагирует на «последнее событие», но Scream DD отличается источником силы. Паника берёт энергию из инцидентов (событий), крик — из социальной настойчивости (людей).

Родственные антипаттерны: Coverage, Resume, Buzzword #

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

Coverage Driven Development (Coverage DD). Режим, в котором целью становится метрика покрытия тестами, а не проверяемое поведение. Команда гонит процент: тесты ради процента, без asserts, на очевидные геттеры, на код, который тестирует сам себя. Работает закон Гудхарта: когда метрика становится целью, она перестаёт быть хорошей метрикой. Покрытие — отличная диагностика (что ещё не протестировано) и катастрофическая цель (какой ценности ради). Классическое следствие — зелёный CI при красном продукте. Канонический пример деградации — тест, который вызывает метод и ничего не проверяет: строка исполнена, процент начислен, поведение не специфицировано вовсе. Антидот: TDD, где тест — это спецификация поведения, написанная до кода, а не числитель дроби в отчёте.

Resume Driven Development (Resume DD). Режим, в котором выбор технологий определяется резюме исполнителей, а не задачей проекта: микросервисы для команды из трёх человек, Kubernetes для одного сервиса, переписывание работающего монолита на модном языке — чтобы в CV появилась строчка. Мотивация понятна и даже по-человечески симпатична (инженер хочет расти и быть востребованным), но оплачивает эксперимент продукт: сложность растёт, а задача, ради которой сложность была бы оправдана, не существует. Симптоматичная реплика с планирования: «давайте перепишем монолит на микросервисы — и заодно возьмём Kubernetes»; вопрос «какую проблему решаем» встречает тишину, потому что проблема не формулируется — есть желание попробовать. Желание расти легитимно, но оплачивать его следует статьёй «обучение и развитие», а не статьёй «продукт». Антидоты: явная фиксация «зачем» до «чем» (Readme-DD), ADR с рассмотренными альтернативами, осознанный приём технологий через технологический радар. Здоровая альтернатива для роста инженеров — учить новое на песочницах и пилотах, а не на продакшене.

Buzzword Driven Development (Buzzword DD). Режим, в котором архитектура и roadmap собираются из пресс-релизов вендоров и хайповых слов: блокчейн, Big Data, AI — потому что «все так делают» и «инвесторы ждут». Отличается от Resume DD масштабом решения: резюме-драйвом движет отдельный инженер, базворд-драйвом — руководство и маркетинг. Симптом: невозможно сформулировать, какую задачу решает технология, — только почему она «модная». Антидот: HDD — Hypothesis Driven Development — любая модная технология входит в систему как проверяемая гипотеза с критерием отказа, а не как акт веры.

Сводная таблица антипаттернов #

Семь разобранных режимов удобно держать перед глазами одной таблицей — как чек-лист для экспресс-диагностики: по строке на режим, от «что давит» до «чем лечить» (последняя колонка отсылает к подходам серии — развёрнуто в разделе «Антидоты»).

Общий знаменатель строки «движущая сила»: во всех семи случаях процессом управляет не артефакт, а давление — эмоциональное (паника, страх), календарное (срок), социальное (крик, престиж, мода). Именно это отличает антипаттерны от настоящих подходов серии, где движущая сила — проверяемый артефакт: тест, доменная модель, контракт, риск-реестр, гипотеза.

Общие корни и как распознать #

Семь ярлыков — не семь независимых болезней. Это разные проекции одного сдвига: движущая сила сместилась с артефакта на давление. Сдвиг редко происходит одномоментно; у него есть культурные и процессные предпосылки, и по ним режим можно распознать раньше, чем он станет «нормой».

Культурные корни.

• Blame-культура. Поиск виновных вместо поиска причин — питательная среда Fear DD: рационально скрывать ошибки там, где за них наказывают.
• Культура героев. Поощрение спасателей вместо предотвращения пожаров воспроизводит PDD: герои нужны только там, где всё горит, и (часто неосознанно) поддерживают горение.
• Отсутствие психологической безопасности. Общая рамка для страха: люди не задают вопросов, не оспаривают абсурдные сроки, не признают проблему, пока она не взорвалась.
• Героический труд как норма. Сверхурочные и трудоголизм славятся как преданность — режимы с «горящими» дедлайнами получают бесплатное топливо и медленно выжигают команду (следующий пункт — текучка и выгорание).

Процессные корни.

• Нет явной приоритизации — вакуум заполняет крик (Scream DD) или инцидент (PDD).
• Нет наблюдаемости — проблемы узнаются от пользователей, и любая из них становится «пожаром уровня A».
• Метрики скорости вместо метрик ценности — Coverage DD и Deadline DD получают числовое прикрытие.
• Планирование без резервов и декомпозиции — срыв заложен в конструкцию, остаётся выбрать, чем платить (качеством, людьми или доверием).
• Отсутствие процессной дисциплины — решения о приоритетах и качестве принимаются стихийно, каждый раз заново и по-разному.

Ранние признаки. Режимы выдают себя раньше, чем формально фиксируются в метриках:

• Язык: «горит», «надо было вчера», «аврал», «тушим» становятся основными словами планирования.
• Доля «срочного» монотонно растёт; в списке задач не осталось ни одной не-срочной.
• Решения принимаются в ночной переписке, а наутро отменяются.
• Сверхурочные перестают быть событием и становятся фоном.
• Лучшие инженеры заводят разговоры «посоветуй, куда уходить» — маркер уже запущенного цикла: выгорание и текучка — не риск, а отложенное следствие перечисленных режимов.

Связь с выгоранием и текучкой заслуживает отдельного абзаца, потому что именно она превращает «просто нездоровый процесс» в финансовую проблему. Все четыре «эмоциональных» режима (PDD, Fear, Deadline, Scream) хронически держат людей в состоянии, которое в психологии occupational health называется выгоранием: истощение, цинизм, падение эффективности. Выгоревший инженер не уходит сразу — сначала он перестаёт предлагать идеи (Fear DD), перестаёт спорить с абсурдными сроками (Deadline DD), перестаёт дописывать до конца начатое (PDD) — и только потом пишет заявление. К моменту ухода организация теряет человека, который «всё знал и всех спасал», а вместе с ним — неявные знания о системе; на восстановление экспертизы уходят месяцы, и нагрузка на оставшихся растёт — круг замыкается уже на уровне персонала, без всякого менеджмента. Текучка в больном режиме — не отдельная проблема HR, а отложенный процент по кредиту, который режим взял у команды.

Практическая рекомендация руководителю: перечисленные признаки стоит проверять регулярно и честно — как симптомы, а не как поводы для поиска виноватых (поиск виноватых — это уже Fear DD, см. выше). Сам факт того, что режим назван по имени, — половина терапии; вторая половина — антидоты.

Компактный чек-лист самодиагностики — по одному вопросу на режим:

1. Scream/PDD. Может ли каждый член команды назвать топ-3 приоритета на текущую неделю? Если нет — приоритами управляет крик или последний инцидент.
2. PDD. Когда последний инцидент закончился документом с проанализированной причиной, а не просто закрытой задачей? «Не помним» — диагноз.
3. Fear. Что произошло с последним человеком, честно признавшим свою ошибку на разборе? Если был наказан или «поставлен на вид» — режим уже внедрён.
4. Deadline. Какая доля последних релизов обошлась без сверхурочных? Если overtime — норма, а не исключение, координатой проекта является календарь.
5. Scream. Кто может добавить команде задачу в обход процесса? Если ответ «любой настойчивый» — процесса приоритизации не существует.
6. Resume/Buzzword. Чем, кроме моды, обоснован последний крупный выбор в стеке? Если обоснование сводится к «все переходят» — это оно.

Три и более утвердительных ответа — сигнал, что режим не эпизод, а система; дальше имеет смысл идти в раздел «Антидоты» и начинать с того, что устраняет общие корни (приоритизация, наблюдаемость, психбезопасность), а не с самого громкого симптома.

Антидоты #

У каждого антипаттерна есть зеркальный «настоящий» подход серии и набор управленческих практик. Ниже — карта соответствий; она же — краткий ответ на вопрос «что делать, если узнали свой режим».

Против Panic DD — риск-ориентированность и обучение на инцидентах. Risk-DD переводит «что может гореть» из памяти героев в явный реестр рисков: усилия направляются туда, где цена неудачи высока, до инцидента, а не после. Наблюдаемость (метрики, алерты, трейсинг) снимает условие «узнаём от пользователей». Безобвинительные пост-мортемы и системный анализ причин инцидентов разрывают круг «тушим симптом — получаем новый пожар». Управленчески: перестать награждать героев и начать награждать предотвращения — культура следует за системой поощрений.

Против Fear DD — психбезопасственность и страховка изменений. Фундамент — безобвинительная культура разбора ошибок (наказывается сокрытие, а не признание) и осознанный менеджмент психбезопасности по Эдмондсон. Инженерно страх «трогать код» лечится TDD: зелёный набор тестов превращает страх изменений из глобального в локальный — однажды зафиксированное поведение нельзя сломать незаметно. Type-TDD добавляет страховку уровня компилятора: невалидные состояния невыразимы до запуска. Управленчески: делегировать решения вниз и публично благодарить за раннее признание проблем.

Против Deadline DD — управление scope’ом и реалистичные оценки. Во-первых, применять закон Брукса по назначению: не бросать людей на опаздывающий проект. Во-вторых, закладывать Паркинсона и Гофштеттера в оценки: резервы и декомпозиция, а не оптимистичные обещания. В-третьих, управлять сроком через scope: фиксировать качество и делать предметом торга объём — это дисциплина MVP, родственная FDD с её фичами, влезающими в короткий цикл. Наконец, сделать техдолг видимым: технический долг учитывается в планировании как явная статья расходов, а не как «потом». Полнота понимания «что именно делать» — через DDD и BDD — сокращает долю работы, сделанной «не туда» и выброшенной под давлением срока.

Против Scream DD — явная приоритизация. Публичный процесс оценки ценности (хоть RICE, хоть взвешенные баллы — конкретный метод важнее его выбора) лишает крик монополии на приоритет: требование любого стейкхолдера проходит один и тот же вход. FDD даёт единицу планирования — клиенто-ориентированную фичу с оценкой и статусом. HDD переводит спор «делать или не делать» в проверяемую гипотезу: данные вместо громкости. ATDD и BDD фиксируют критерии приёмки заранее — «переопределить задачу криком в процессе» становится заметным исключением, а не способом работы. Управленчески: руководителю придётся научиться говорить «нет» настойчивым — один раз процессно, вместо ста раз по факту крика.

Против Coverage DD — тесты как спецификация. TDD с его «тест до кода» восстанавливает смысл теста: проверять поведение, а не числитель метрики. Покрытие при этом остаётся полезной диагностикой «что ещё не специфицировано». ATDD поднимает тот же принцип на уровень приёмки.

Против Resume DD и Buzzword DD — «зачем» прежде «чем». Readme-DD требует описать ценность до реализации; ADR — зафиксировать рассмотренные альтернативы и причины выбора; технологический радар — осознанную стратегию принятия и вывода технологий. HDD добавляет главный фильтр против хайпа: формулируемую гипотезу с критерием отказа. Для роста инженеров (легитимный мотив Resume DD) — песочницы, пилоты и обучение, оплаченные как обучение, а не спрятанные в продакшен-задачи.

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

С чего начать, если режимов несколько. В живых организациях режимы сосуществуют и подпитывают друг друга: паника рождает сверхурочные, сверхурочные — выгорание, выгорание — текучку, текучка — потерю знаний и новые инциденты. Ломать этот круг «сразу всем» не нужно; устойчивый порядок обратный — от фундамента к симптомам:

1. Наблюдаемость и приоритизация. Сначала сделать видимым, что происходит (метрики, алерты, статус работ), и назначить единственный явный вход для задач. Это снимает топливо с PDD и Scream DD — самых «шумных» режимов.
2. Психобезопасность. Затем — безобвинительные разборы и защита признавших ошибку: без этого всё, что построено на шаге 1, будет активно скрываться людьми из страха.
3. Реалистичные оценки и явный техдолг. После — планирование с резервами и учёт долга в расходах: режим Deadline DD теряет почву, когда цена срезанного качества становится видимой в числах.
4. Инженерные практики серии. И только затем — TDD, пост-мортемы, ADR, гипотезы: они закрепляют здоровое состояние, но не заменяют управленческую работу. Внедрять TDD в команду, которой управляет паника, — классическая ошибка: практика будет отброшена первым же «горящим» релизом.

Связанные подходы #

Эта статья — сводка «оборотной стороны» серии о driven-подходах. Ниже — карта «настоящих» подходов: каждый из них — антидот к одному или нескольким режимам из этой статьи.

Смежные материалы базы знаний, прямо работающие как антидоты:

• Закон Брукса — почему «ещё люди» не спасают опаздывающий проект (антидот к типовой реакции Deadline DD).
• Законы Паркинсона и Гофштеттера — фундамент для реалистичных оценок и резервов.
• Технический долг — систематика того, во что превращается срезанное качество.
• Пост-мортем и метод анализа причин инцидентов — инструменты размыкания цикла Panic DD.
• Дисциплина — процессный каркас, лишающий больных режимов стихийной питательной среды.
• Трудоголизм — персональная проекция культуры героев и «горит всё».

Завершает серию обзорная статья — Driven-подходы: сравнение, сводящая все тринадцать материалов в единую карту движущих сил.

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

Краткий вердикт для руководителя #

Сатирические *DD — это не шутка для презентаций, а компактный диагностический словарь: по имени режима — «у нас Deadline DD» или «побеждаем Scream DD» — команда и руководство получают общее слово для общей проблемы, а спор о «кто виноват» заменяется спором «какой режим и чем лечим». Практический минимум из статьи: во-первых, периодически честно сверять команду со списком ранних признаков; во-вторых, помнить, что все семь режимов сходятся в одной точке — процессом управляет давление вместо артефакта; в-третьих, подбирать антидоты из «настоящих» подходов серии и управленческих практик, а не ждать, что «само рассосётся» — само не рассасывается ни один из описанных режимов, зато каждый из них постепенно выжигает людей, качество и стратегию. Названный по имени режим — наполовину побеждённый режим.

Источники и материалы #

Первоисточники и ключевые публикации #

• Andrew Koenig. Patterns and Anti-Patterns (Journal of Object-Oriented Programming, 1995) — введение термина «антипаттерн».
• William Brown, Raphael Malveau, Hays McCormick, Thomas Mowbray. AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis. Wiley, 1998 — канонический сборник антипаттернов со схемой «симптомы — причины — последствия — рефакторинг».
• Frederick Brooks. The Mythical Man-Month. Addison-Wesley, 1975 — «марши смерти», хирургические команды и закон Брукса (контекст Deadline DD).
• Edward Yourdon. Death March: The Complete Developer’s Guide to Surviving “Mission Impossible” Projects. Prentice Hall, 1997 — системное описание проектов с заведомо нереальными сроками.
• Steve McConnell. Rapid Development: Taming Wild Software Schedules. Microsoft Press, 1996 — каталог практик управления сроками и типовых ошибок.
• Amy Edmondson. The Fearless Organization: Creating Psychological Safety in the Workplace for Learning, Innovation, and Growth. Wiley, 2018 — психобезопасность как основа эффективных команд (контекст Fear DD).
• Google re:Work. Project Aristotle (2015–2016) — эмпирическое исследование факторов эффективности команд; психобезопасность — фактор номер один.
• Tom DeMarco, Timothy Lister. Peopleware: Productive Projects and Teams. Dorset House, 1987 — классика о том, как менеджмент делает команды неэффективными.
• Martin Fowler. TestCoverage (martinfowler.com) — почему погоня за процентом покрытия вредна (контекст Coverage DD).
• Marilyn Strathern. ‘Improving Ratings’: Audit in the British University System (1997) — каноническая формулировка закона Гудхарта: «когда метрика становится целью, она перестаёт быть хорошей метрикой».
• Терминология Panic/Fear/Deadline/Scream/Coverage/Resume/Buzzword Driven Development — индустриальный фольклор: устойчиво циркулирует в инженерных блогах и докладах без единого канонического первоисточника, что для жанра показательно.

Связанные материалы базы знаний #

• TDD — Test Driven Development — тесты как спецификация; антидот к Fear DD и Coverage DD.
• Risk-DD — Risk Driven Development — реестр рисков; антидот к Panic DD.
• HDD — Hypothesis Driven Development — гипотезы с критериями отказа; антидот к Scream DD и Buzzword DD.
• FDD — Feature Driven Development — фича как единица планирования; антидот к Scream DD. Не путать с Fear Driven Development из этой статьи.
• DDD — Domain Driven Design — домен как движущая сила. Не путать с Deadline Driven Development из этой статьи.
• Технический долг — во что превращается срезанное качество.
• Пост-мортем и анализ причин инцидентов — практики размыкания цикла паники.
• Закон Брукса и законы Паркинсона и Гофштеттера — классика управления сроками.
• Дисциплина и трудоголизм — процессная и персональная проекции здоровой рабочей культуры.