Agile в функциональном проекте. Организация работы на IT‑рельсах

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

Опуская множество НО, в целом, философия Agile (а никак иначе язык сказать не поворачивается) показала довольно неплохие результаты с точки зрения организации команд в других, околоайтишных направлениях.

И возник вопрос, возможно ли этот подход положить на понятный, последовательный и очевидный проект в области Охраны труда. Казалось бы, зачем? А затем, что помимо понятной и очевидной части есть совершенно непредсказуемая и многогранная — работа с Заказчиком, пользователями и экспертами.

Именно здесь возникают сложности, которые создают проблемы в понятной механической части. К слову, понятная часть реализуется по чистому Waterfall и менять это не нужно. Вопрос лишь в усилении второй части более подходящими инструментами.

Так как человеческий мозг пользователей продуктов способен генерировать огромное количество уникальных идей и воплощать их в бесконечные причины «Почему у нас не получилось», было принято решение вывести эту часть проекта в отдельный подход. На это сразу напрашивался Agile.

Задача довольно простая:

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

2. Определить целевое состояние (и это не обязательно 100% следование фреймворкам).

3. Сформулировать мероприятия по движению из текущего состояния в целевое.

За абсолютную Agile‑зрелость команды было выбрано — полное понимание и следование 12 принципам Agile. А как понять, что команда понимает и следует им — нужны какие‑то индикаторы, метрики оценки, на которые все однозначно могут ответить либо «Да», либо «Нет».

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

Оценка проводилась через наблюдение за стандартными встречами команды + интервью. Большой фокус при этом уделялся не только соблюдению алгоритмам ритуалов, но и косвенным признакам: невербальным знакам, интонациям, позам, которые нередко противоречили тому, что говорил Заказчик, команда и пользователи. Потому что есть правильные ответы, а есть честные.

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

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

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

Текущая оценка составила 2 балла из 5. Потенциал быстрого роста — до 3,7 баллов.

Здесь стоит отметить, что стремиться к 5 и не нужно. Целевая граница устанавливается командой. И у нее нет цели стать самой тру‑эджайл командой в мире, чтобы все остальные ей завидовали.

Если говорить про быстрые мероприятия — они все организационные и внедряются моментально. Просто берешь и делаешь.

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

Подводя итог, из того, что зацепило, первое — команды старались проводить ритуалы Scrum, но независимо от названия все ритуалы всегда превращались в планирование. Это не критично, но это факт, и с ним надо работать.

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

Второе — как ни крути, без поддержки принципов со стороны руководства никуда. Это прописано в каждой второй статье про Agile. Просто, понятно, но следуют этому правилу не все. А потом никто не понимает, почему же культура в компании не прижилась.

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

Четвертое. Отдельные элементы Agile хорошо помогают выстраивать процесс (например, фокус на Заказчике и пользователях через интервью и демо ускоряют работу над проектом), но здесь есть нюанс.

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

И, наконец, пятое. В описанном кейсе это соблюдалось, но дабы предупредить всех любопытствующих — Agile хорош в проектах с высокой долей неопределенности. Не нужно понятные и последовательные задачи пытаться делать гибкими, потому что это модно, стильно, молодежно. Это только добавит хаоса.

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