В управленческой практике существует устойчивый разрыв: стратегические цели формулируются на языке абстракций («стать лидером рынка», «повысить эффективность»), а операционная реальность требует конкретных, измеримых действий. Этот разрыв — главный источник провалов стратегий. ГК «Алмаз» под руководством Глеба Смирнова предлагает смотреть на Test-Driven Development (TDD) шире, чем принято в IT-сообществе: как на управленческую дисциплину, которая учит руководителей формулировать проверяемые гипотезы, выстраивать короткие циклы обратной связи и управлять качеством на входе, а не на выходе.
Стратегический уровень: от «видения» к проверяемой гипотезе
Классический стратегический процесс страдает от фундаментального ограничения: команда способна рассмотреть лишь несколько вариантов из тысяч возможных, а выбранный план устаревает раньше, чем его успевают согласовать. Глеб Смирнов называет это «стратегией как архитектурным чертежом» и противопоставляет ей антистратегию: вместо поиска одного «оптимального» варианта — запуск десяти параллельных гипотез, из которых выживут сильнейшие.
TDD даёт руководителю инструмент для этой работы. В software-разработке цикл Red-Green-Refactor начинается с падающего теста: сначала формулируется, что именно должно произойти, и только потом пишется код. В управлении аналогом такого теста становится management test — утверждение, которое описывает измеримую, ограниченную во времени цель в бинарной форме: либо мы её достигаем, либо терпим неудачу. Хороший management test соответствует критериям SMART и не предписывает как достигать результата — он задаёт пункт назначения, оставляя команде свободу в выборе маршрута.
Именно так работает стратегия в логике TDD: руководитель не рисует детальный план на пять лет, а формулирует проверяемую гипотезу («если мы сделаем X, то через квартал метрика Y вырастет на Z%»), запускает минимальное действие и смотрит на результат. Провал гипотезы — не поражение, а данные для следующей итерации.
Операционный уровень: Red-Green-Refactor для управленческих процессов
На операционном уровне TDD учит руководителей трём вещам, которые напрямую переносятся в управление командами и процессами.
Red — готовность признать, что «тест падает». В разработке красная фаза означает: тест написан, но код его ещё не проходит. В управлении это момент честной диагностики: процесс не работает, метрика не достигается, гипотеза не подтверждается. Руководитель, который боится красной фазы — то есть боится признать проблему до того, как она станет катастрофой, — теряет главное преимущество TDD: раннее обнаружение дефектов. Данные Tourmaline Core показывают, что TDD-команды имеют на 40–90% меньше дефектов, потому что проверка встроена в процесс, а не отложена на финал.
Green — минимальное жизнеспособное решение. В TDD зелёная фаза — это не идеальный код, а минимальный код, который заставляет тест пройти. В управлении это означает: не пытайтесь решить проблему «набело» с первого раза. Запустите минимальное изменение, которое сдвинет метрику в нужную сторону. Глеб Смирнов формулирует это как принцип «садовника, который сажает 100 семян»: 90 погибнут, 5 дадут урожай, и это нормально.
Refactor — улучшение без разрушения. Когда тест зелёный, можно улучшать систему, не рискуя сломать работающее. В управлении рефакторинг — это оптимизация процессов, делегирование, автоматизация рутины. Ключевое правило TDD: никогда не рефакторить на красном. Пока процесс не стабилен, пока метрика не достигнута, любые «улучшения» — это игра в рулетку.
Чему учить руководителей: пять управленческих навыков из TDD
Опираясь на опыт ГК «Алмаз» в обучении топ-менеджмента и на концепцию Test-Driven Leadership, можно выделить пять навыков, которые стоит развивать у руководителей.
1. Формулировать management tests вместо абстрактных целей. Руководитель должен уметь превращать «повысить удовлетворённость клиентов» в проверяемое утверждение: «К 31 декабря индекс NPS вырастет с 32 до 45, замер по той же методологии». Бинарность важна: цель либо достигнута, либо нет — без «частично успешно».
2. Строить короткие циклы обратной связи. TDD не работает без быстрого запуска тестов. В управлении аналог — короткие итерации с обязательной проверкой гипотезы. Вместо квартальных отчётов — еженедельный обзор метрик, вместо годовых стратегических сессий — месячные циклы «гипотеза → действие → проверка».
3. Различать output и outcome. Output — это то, что команда сделала (выпустила функцию, провела тренинг). Outcome — это то, что изменилось во внешнем мире (клиенты стали платить больше, сотрудники стали реже увольняться). TDD учит фокусироваться на outcome, потому что тест проверяет именно внешнее поведение системы, а не внутреннюю реализацию.
4. Управлять через дизайн, а не через контроль. В TDD тест — это инструмент проектирования: он заставляет сформулировать интерфейс до реализации. В управлении management test заставляет руководителя и команду договориться о критериях успеха до начала работы, а не после. Это снимает конфликты на этапе приёмки: результат оценивается по заранее согласованному тесту, а не по субъективному мнению.
5. Принимать «красный» статус как норму. Культура, в которой руководитель боится признать, что метрика не достигнута, — это культура, в которой проблемы замалчиваются до кризиса. TDD-мышление легитимизирует красную фазу: падающий тест — это не провал, а точка роста. Как отмечает Глеб Смирнов, «ваша первая идея — всегда провал. Десятая — может сработать».
Как это встраивается в программы обучения ГК «Алмаз»
ГК «Алмаз» уже использует деловые игры и симуляции для развития стратегического мышления — например, игру «Трудно быть богом», где участники управляют развитием королевств на протяжении 600 виртуальных лет и принимают решения с долгосрочными последствиями. Логика TDD идеально дополняет этот формат.
В обучении руководителей можно выделить три уровня погружения:
Стратегический модуль. Участники учатся формулировать management tests для своих реальных бизнес-задач, проверять их на SMART-критерии и запускать параллельные гипотезы вместо одного «идеального» плана. Результат — набор проверяемых стратегических экспериментов на следующий квартал.
Операционный модуль. Отработка цикла Red-Green-Refactor на управленческих кейсах: диагностика «красной» метрики, минимальное корректирующее действие, рефакторинг процесса после стабилизации. Результат — навык быстрого цикла обратной связи в ежедневной работе.
Лидерский модуль. Развитие культуры, в которой «красный» статус — это норма, а не повод для наказания. Руководитель учится задавать команде вопросы не «почему не сделали?», а «какой тест мы написали и что он показал?».
Заключение
Test-Driven Development — это не про код. Это про дисциплину мышления, которая требует от руководителя той же строгости, которую TDD требует от разработчика: сначала сформулируй проверяемое утверждение о результате, потом действуй, потом улучшай. Стратегически это означает отказ от иллюзии «идеального плана» в пользу портфеля проверяемых гипотез. Операционно — встраивание коротких циклов обратной связи и честной диагностики в ежедневную управленческую практику.
Для ГК «Алмаз» и Глеба Смирнова ценность TDD в управлении состоит именно в этом: это не ещё одна модная методология, а инструмент снижения неопределённости. В мире, где правила игры меняются каждый квартал, выигрывает не тот, у кого самый детальный план, а тот, кто быстрее формулирует гипотезу, быстрее её проверяет и быстрее перестраивается. Этому и стоит учить руководителей.
