🔥 Пятничное: Методики не работают

Что общего между SMART, “5 почему”, Definition of Done, ретроспективами и Acceptance Criteria? Все про них слышали. Все кивают на тренингах. И никто этим не пользуется.

Давайте честно: все знают как ставить задачи по SMART. Конечно все. А теперь откройте свой Service Desk и посмотрите на реальные заявки:
“Ой, у меня что-то не работает, нашел незакрытые задачи, кстати процесс не работает, и надо проверить документы по старой заявке, в бюджете не те статьи, сбросьте мне пароль и принесите чай”.

🎭 Красивые фреймворки и грустная реальность

“5 почему” - элегантный метод поиска корневой причины. На тренингах все восторгаются: “Вот это да! Так просто!” Через неделю в продакшне падает сервис.

• Почему упало?
• Потому что Вася криво настроил.
  Все, нашли виноватого, расходимся.
  Никаких пяти “почему”. Никакого поиска системной проблемы.

👌 Definition of Done - который никто не соблюдает

Definition of Done фиксирует, что значит “готово” для задачи: не “код скомпилился”, а “цель достигнута без сюрпризов”. Когда DoD есть только в Confluence, а в жизни им не пользуются, релизы превращаются в русскую рулетку.
Как это выглядит на практике:

• “Код я написал”
• “В моей базе работает”
• “Один из двадати сценариев проверен”
  DoD - не плакат в вики. Это контракт команды с бизнесом и поддержкой: если “готово” - то готово без кавычек.

⏪ Ретроспективы, которых нет

Scrum Guide прямо говорит: ретроспектива обязательна. Это время, когда команда анализирует, что пошло не так и как улучшить процессы. В теории.
На практике:

• Ретро не проводятся вообще, потому что “и так все понятно”
• Ретро превращаются в формальность: 15 минут, все молчат, Scrum Master сам с собой говорит
• На ретро находят проблемы, записывают action items… и забывают про них до следующей ретро
  Методика есть. Время выделено. Результата ноль. Потому что команда не верит, что что-то изменится. И правда не меняется - потому что action items никто не выполняет.

✅ Acceptance Criteria - которых никто не написал

Acceptance Criteria должны фиксировать, что именно считается приемкой результата: условия, сценарии, границы. Когда AC нет, встречаемся на тестировании и узнаем, что бизнес “имел в виду другое”. Начинается пинг-понг: правки - возвраты - обиды.

• Задача сформулирована общими словами: “сделать удобнее”, “ускорить обработку”, “поддержать интеграцию”. Ни одного конкретного критерия.
• UAT превращается в квест: каждый видит по-своему, спорим о вкусе, а не о критериях.
• В проде появляются сюрпризы: поведение на краях не обсуждалось, регламенты не обновлены, смежные роли не предупреждены.

🤡 Что смешного

Все знаю SMART, ITIL, Agile и много других красивых слов.
Мы внедряем фреймворки, чтобы показать инвесторам или руководству: “Смотрите, мы современные, мы по ITIL работаем!” А на деле продолжаем как раньше - по наитию, через хаос и героизм отдельных людей.
И самое смешное? Мы жалуемся: “Вот эти ваши методики не работают!” Работают. Просто вы ими не пользуетесь.