В 2025 году одна крупная российская компания потратила полгода на разработку идеального регламента взаимодействия отделов. Документ на 120 страниц утвердили, разослали, провели обучение. Через три месяца выяснилось: 80% сотрудников продолжают работать по-старому. Регламент стал ещё одним файлом в папке «Ознакомиться».
Эта история — не про лень или недисциплинированность. Она про фундаментальную ошибку, которую IT-индустрия уже обожгла на методологии Specification-Driven Development (SDD). Идея звучит соблазнительно: напиши идеальную спецификацию — и разработка пойдёт как по маслу. Но реальность оказалась куда сложнее, а уроки из этой истории напрямую касаются любого руководителя, который пытается навести порядок через регламенты, KPI и модели компетенций.
Что на самом деле означает «driven»
В аббревиатуре SDD слово «driven» (управляемый) — не просто фигура речи. Оно утверждает: когда код расходится со спецификацией, неправ именно код. Спецификация — истина в последней инстанции. Именно этот постулат и приводит к катастрофе.
Представьте, что вы внедрили модель корпоративных компетенций. Документ согласован, подписан, разослан. Через полгода выясняется, что реальное поведение сотрудников с этой моделью не совпадает. Что вы сделаете? Если вы скажете: «Люди должны подстроиться под модель», — вы попали в ловушку «driven». Вы сделали бумагу главнее реальности. Правильный ответ: модель устарела, её нужно менять. Но тогда модель не управляет ничем — она просто документация. Полезная, но не истина.
Авторы SDD-методологий сами признают: спецификация должна итеративно обновляться вслед за изменениями. Но тогда где же «управление»? Это честное описание цикла обратной связи, а не диктат документа.
Спецификация не управляет даже агентом
Второй удар по идее «источника истины» нанесли большие языковые модели (LLM). Компилятор жёстко следует входным данным. Агент на базе ИИ — нет. Он может неправильно интерпретировать спецификацию, домыслить лишнее или проигнорировать часть требований. Чем объёмнее документ, тем выше вероятность, что агент «съедет».
Для руководителя это означает: если вы делегируете контроль регламентов и стандартов исключительно автоматизированным системам (пусть даже с элементами ИИ), вы рискуете получить «галку» о выполнении при полном расхождении с реальностью. Автоматизация верификации не отменяет необходимости человеческой валидации.
Верификация vs валидация: почему галочки не спасают
В SDD часто путают два понятия. Верификация — это проверка того, что продукт соответствует спецификации. Валидация — проверка того, что спецификация вообще была правильной. Можно иметь идеально работающую систему, которая никому не нужна, потому что изначальные требования были ошибочны.
В корпоративном обучении эта ловушка встречается повсеместно. Компания внедряет оценку персонала по чётким критериям. Сотрудники проходят тесты, набирают баллы — верификация пройдена. Но бизнес-показатели не растут. Почему? Потому что никто не задал вопрос: «А те ли компетенции мы вообще измеряем?» Валидация осталась без ответственного. За верификацию у нас отвечают HR-аналитики, за валидацию — никто. Именно так рождаются проекты, которые «всё сделали правильно», но провалились.
Экономика ошибки: почему дешевле пробовать, чем прописывать
Раньше детальное планирование было экономически оправдано. Цена ошибки в коде или процессе была высока, переделывать — дорого. Сегодня, когда прототип можно создать за день, а пилотный тренинг запустить за неделю, дешевле проверить гипотезу на практике, чем месяцами выписывать идеальный документ.
По данным исследований, 84% российских компаний инвестируют в обучение персонала, но лишь 25% измеряют его реальную эффективность. Остальные довольствуются «галочками»: количество часов, пройденных курсов, заполненных анкет. Это и есть подмена валидации верификацией. Гораздо полезнее провести стратегическую сессию с быстрой проверкой гипотез, чем разрабатывать годовую программу обучения, которая устареет через квартал.
Именно поэтому в группе компаний «Алмаз» мы всё чаще рекомендуем клиентам формат быстрых пилотов и итеративной разработки учебных решений. Это не отказ от планирования, а перенос акцента с документа на результат.
Что делать руководителю: практические рекомендации
- Начните с гипотезы, а не с документа. Вместо «разработаем регламент» скажите: «У нас есть гипотеза, что если мы изменим процесс Х, то показатель Y вырастет на Z%». И проверьте её на малой группе.
- Встройте цикл обратной связи. Любой регламент или модель компетенций должны иметь встроенный механизм пересмотра. Не раз в год, а по факту расхождений с реальностью. Назначьте ответственного за валидацию — того, кто будет сравнивать документ с жизнью, а не с другими документами.
- Разделите верификацию и валидацию. Пусть за соблюдение стандартов отвечает один человек или отдел, а за их актуальность — другой. Иначе вы будете идеально соблюдать устаревшие правила.
- Используйте AI для ускорения прототипирования, а не для контроля. Нейросети могут быстро набросать драфт регламента или учебной программы, но окончательное решение о его пригодности должен принимать человек, опираясь на данные реального использования.
- Не дайте названию методологии вас обмануть. Если вам предлагают «единственно верный» подход, который обещает навести порядок через спецификации, спросите: «А что будет, когда реальность изменится?» Если ответ — «спецификация главнее», бегите.
Заключение
Спецификации, регламенты и модели компетенций — это не бесполезные артефакты. Они полезны как документация, как способ договориться о терминах, как основа для автоматизации. Но они не управляют ни людьми, ни проектами. Управляют решения, принятые на основе обратной связи, и готовность признать, что вчерашний документ устарел. В мире, где скорость изменений только растёт, скромность перед реальностью становится главным управленческим навыком.
Часто задаваемые вопросы
Чем SDD отличается от обычного планирования?
SDD предполагает, что спецификация является главным артефактом, из которого автоматически генерируется код или процессы. Обычное планирование рассматривает план как руководство, которое может и должно меняться. SDD в своей жёсткой форме пытается зафиксировать истину, что в динамичной среде невозможно.
Почему спецификации не работают в проектах с AI?
Потому что большие языковые модели не детерминированы. Они могут интерпретировать спецификацию по-своему, добавлять несуществующие требования или игнорировать часть условий. Спецификация не компилируется в поведение модели, а лишь задаёт вероятностный контекст.
Как понять, что наша методология буксует?
Главный симптом — когда вы тратите больше времени на поддержание регламентов в актуальном состоянии, чем на саму работу. Или когда отчёты показывают «всё хорошо», а бизнес-результаты падают. Это верный признак подмены валидации верификацией.
Что делать, если руководство требует детальные регламенты?
Не отказывайтесь от регламентов, но предложите пилотный подход. Договоритесь, что документ будет считаться «версией 0.1» и через месяц практики вы соберёте обратную связь для корректировки. Так вы удовлетворите потребность в порядке и сохраните гибкость.
Можно ли вообще отказаться от спецификаций?
В большинстве случаев — нет. Но можно изменить их статус: не «источник истины», а «лучшее известное на данный момент описание». Тогда команда будет относиться к ним как к рабочему инструменту, а не как к священному писанию.
