Когда речь идет о проектах в методологии Agile, на ум приходит IT-команда, работающая над разработкой программного обеспечения. Однако Agile также показал хорошие результаты в других областях, включая Охрану труда, где взаимодействие с Заказчиком и пользователями создает сложности.

В этой связи возник вопрос: можно ли адаптировать Agile для проекта в области Охраны труда? Понятная часть проекта реализуется по модели Waterfall, но для работы с человеческим фактором и неопределенностью Agile может стать полезным инструментом.

Задачи проекта: 1. Оценить текущий уровень зрелости Agile в команде. 2. Определить целевое состояние (и оно необязательно должно соответствовать 100%). 3. Определить путь движения от текущего к целевому.

Для оценки зрелости команды были выбраны 12 принципов Agile, и для каждого из них разработаны метрики. Оценка проводилась через наблюдение за встречами и интервью, с акцентом на невербальные знаки и интонации, которые могли противоречить сказанному.

С помощью GenAI были созданы метрики, которые затем шлифовались с экспертами Охраны труда. В результате появилась матрица оценки, отражающая текущее состояние команды. Цветовая гамма метрик: зеленый — выполняется, синий — не выполняется, но быстро внедряется, красный — не выполняется и требует более 2 недель на внедрение. Текущая оценка составила 2 балла из 5, с потенциалом роста до 3,7.

При этом стремиться к 5 не обязательно; целевая граница устанавливается командой. Быстрые (синие) мероприятия легко внедряются, тогда как долгосрочные (красные) требуют ценностного роста внутри команды.

Какие выводы напрашиваются: 1. Команда пытается проводить ритуалы Scrum, но нередко они превращаются в планирование. С этим нужно работать. 2. Поддержка принципов Agile со стороны руководства критически важна для успешной культуры. Об этом сказано везде, но мало кто следует этому. 3. Если команда не поддерживает культуру Agile, работа превращается в рутину без понимания ценности. 4. Элементы Agile могут улучшить процесс, но результаты должны быть ощутимыми. Помочь в процессе Agile может, но мы же все-таки нацелены на результат. 5. Agile эффективен в проектах с высокой неопределенностью; не стоит пытаться сделать гибкими понятные задачи, иначе это превратится в хаос.

Выделять мутные задачи под Agile, а весь проект превращать в гибрид не есть плохо, если вы понимаете, что делаете. Потому что если есть запрос и творческая готовность, любой подход можно улучшить. И даже в самых проверенных и надёжных методологиях стоит периодически задавать вопрос: "А как это можно сделать по-другому?".