{"id":14262,"url":"\/distributions\/14262\/click?bit=1&hash=8ff33b918bfe3f5206b0198c93dd25bdafcdc76b2eaa61d9664863bd76247e56","title":"\u041f\u0440\u0435\u0434\u043b\u043e\u0436\u0438\u0442\u0435 \u041c\u043e\u0441\u043a\u0432\u0435 \u0438\u043d\u043d\u043e\u0432\u0430\u0446\u0438\u044e \u0438 \u043f\u043e\u043b\u0443\u0447\u0438\u0442\u0435 \u0434\u043e 1,5 \u043c\u043b\u043d \u0440\u0443\u0431\u043b\u0435\u0439","buttonText":"\u041f\u043e\u0434\u0440\u043e\u0431\u043d\u0435\u0435","imageUuid":"726c984a-5b07-5c75-81f7-6664571134e6"}

Кейсы agile-трансформации, часть вторая: корпорации и госструктуры

В двадцатой статье серии «Менеджмент цифрового мира» (оглавление) я продолжаю рассмотрение кейсов agile-трансформации, чтобы в совокупности дать многовариантную картину.

В прошлой статье я рассказывал про кейсы банков, в этой – про корпорации и госструктуры: Ростехнадзор, Пенсионный фонд, «Банк России», «Росатом», «Северсталь». А в следующих статьях будут кейсы на производстве и самая любопытная часть — agile в школах.

Как я писал в прошлой статье, мои источники – доклады на профильных конференциях AgileDays, Agile Business и других, по которым я обычно выкладываю подробные отчеты на моем сайте, а также разговоры в кулуарах конференций и другие частные разговоры. Конечно, рассказ на конференциях часто дает идеальную картину, однако разница с реальностью обычно не слишком велика. К тому же присутствие среди участников сотрудников компаний, о которых рассказывают в докладе и общение с ними позволяет оценить объем лакировки. В любом случае, если у кого-то есть иная картина – напишите в комментариях, читателям будет интересно, и мы сможем обсудить разницу. Все написанное – моя собственная интерпретация, однако в статье много ссылок на видео докладов и мои конспекты, так что вы можете составить свое собственное мнение.

Disclaimer: все изложенное – моя личная интерпретация событий

Ростехнадзор

Рассказ про кейсы госструктур я начну с интересной истории о том, как Ростехнадзор заставил своего IT-подрядчика перейти на Agile-методы от классической проектной разработки. Обычно в историях ситуация ровно обратная: компания-разработчик применяет Agile-методы, и у нее возникают проблемы при взаимодействии с государственными заказчиками, потому что те мыслят в терминах классического подхода. А здесь – наоборот.

Кейс старый, о нем рассказывала Марина Макарчук на уже упоминавшейся в моих статьях Agile Kitchen по Agile в госпроектах в конце 2015 года (мой отчет), и тогда ему было уже два года. На AgileDays-2016 она тоже делала доклад об этом опыте.

Если кратко, то IT-ландшафт Ростехнадзора состоит из 17 систем, которые разрабатывал один крупный подрядчик, так исторически сложилось. Изменение нормативной базы часто требует изменений в IT, эти доработки заранее планируются и подрядчик раз в полгода устанавливал новые версии. Которые совместно не работают, и для сотрудников Ростехнадзора начинался кошмар на пару месяцев, потому что системы сбоят, а установленный нормативно двухнедельный срок для отклика на запросы для них никто не отменял. Каждый раз следовали разборки, а потом ситуация повторялась.

Чтобы принципиально ее изменить, от подрядчика потребовали перейти на трехнедельные релизы. Он доказывал, что это невозможно, потребовалась эскалация до замминистра, и вопрос был решен. Трехнедельные релизы потребовали внедрить и другие практики Agile, в рамках классического подхода это было невозможно. В результате было получено предсказуемое развитие системы без особых проблем при обновлении версий.

Кстати, зарубежный опыт тоже говорит, что упертых защитников старого можно убедить только директивно. Во всяком случае, истории зарубежного опыта, которые я услышал то той же AgileKitchen в докладе Асхата Уразбаева говорит, что именно так были вынуждены поступить правительства Великобритании и Штатов, когда после крупных провалов проектов, управляемых традиционно, делали применение Agile обязательным для госпроектов, в 2011 и 2014 годах соответственно. В Англии подробности можно посмотреть на сайте Government Digital Service, а в Штатах - на сайте United State Digital Service в разделе The USDS origin story.

Вообще на той Agile Kitchen довольно много говорили о практиках IT-разработки для государства. Вопреки распространенному мнению, заказчики это тоже часто хотят. И при взаимной воле сторон это вполне возможно, включая контрактование по 44-ФЗ – это научились делать в Тюменской области, о чем рассказывал в докладе Иван Дубровин, у него в презентации были ссылки. Отметим, что уже прошло много времени, и практика может быть шире.

Самарский пенсионный фонд

Там же я услышал про очень интересный кейс Самарского пенсионного фонда, который применял Agile-методы для улучшения операционной деятельности. На встрече был краткий рассказ и видеоролик, а вот здесь есть подробный вебинар об этом опыте. Изменения касались не только внутренней деятельности. Самый интересный кейс – как с помощью Agile-методов решили проблему выдачи материнского капитала.

Ситуация следующая: каждый год в начале июня выходит постановление правительства, и с 01.07 большое количество матерей приходят в пенсионный фонд, рассчитывая быстро получить деньги, чтобы использовать летом или для подготовки к школе. Получались жуткие очереди, медленное обслуживание и ситуация рассасывается только к ноябрю. И они в итерационно-поисковом режиме решили эту проблему.

Изменения касались как IT-систем, и были нацелены на интеграцию и устранение ручной работы, так и организации приема – в холле компьютеры, на которых мамы сами могли заполнить нужные документы, а сотрудник им помогал. При этом компьютеры взяли с рабочих мест тех, кто был в отпусках, дополнительных закупок не делали.

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

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

В целом я хочу отметить, что эти кейсы ломают привычный стереотип о том, что государство – это обязательно медленные и тяжелые процедуры. Можно работать по-разному, и все зависит от конкретных людей. Отмечу, кстати, что с 2016 года в рамках премии «Проектный олимп» есть номинация по применению гибких методологий в госпроектах.

Банк России

Еще один кейс Agile в госструктурах рассказывали Светлана Иванова, Дарья Корнеева и Николай Арапов в докладе «Банк России: знать путь и пройти его — не одно и то же» на AgileDays-2018 (мой отчет). Я уже говорил немного про него, рассказывая про Kanban-доску в одном из департаментов в статье «Доска - визуализация текущего состояния работы», но в докладе было еще несколько кейсов. Есть феерические эффекты, когда по проекту, который не запускался полгода, после перезапуска в скрам-команде за 1.5 месяцев получали первую версию, или когда проект создания распределенной структуры, который сделать "за год - точно не реально" тоже выдавал первые результаты через пару месяцев. А в среднем производительность повысилась на 30-40%. Отметим, что все кейсы в докладе касались не IT-подразделений, а операционной работы и проектов изменений. В целом, насколько я понимаю, решение о применении Agile-методов дано руководителем подразделений и проектов, что логично: они отвечают за конечный результат, и значит могут выбирать способ его достижения. И есть те. кто делает ставку на Agile-методы.

​Kanban-доска департамента Банка России. Из моих презентаций

РосАтом

В Росатоме Agile применялся для адаптации проекта АЭС в Финляндии под требования Евросоюза, об этом на Agile Business-2017 рассказывал Сергей Малоземов в докладе «Применение Agile в проектах атомной отрасли» (мой конспект). Понятно, что сначала это попробовали сделать классическим способом, но адаптация оказалась недопустимо дорогой, а время ушло. И потребовалось за 3 месяца придумать способы снижения стоимости адаптации при соблюдении требований и без увеличения размеров здания. И здесь кроссфункциональные команды и открытое agile-общение в сочетании с легкой, но достаточно жесткой scrum-структуризацией процесса сыграли свою роль, результат был достигнут, проработка порожденных идей дало 26% экономии. Что важно — Agile был встроен в корпоративную среду крупной корпорации, принципиальных противоречий — не обнаружено, а наоборот, отмечен позитивный эффект от использования. Как сказал Сергей в заключении, они попробовали Agile-методы, представляют их возможности и будут и далее применять там, где это уместно.

Северсталь

Еще один кейс Александр Колобов, директор по развитию Севергрупп и Виталий Сухарев «Agile в металлургии - ускоряем Северсталь» на Agile Business-2018. Записи нет, есть интервью с Колобовым и мой конспект. Рассказ об изменении организации, был рассказ о принципах и о том, что инициировало трансформацию. Проблема понятна: Северсталь – это регулярный менеджмент в достаточно жесткой форме: производство, безопасность, нормативы, правила и контроль. Но при этом нужны новые продукты и идеи.

Решение в принципе понятно: собрать кросс-функциональные команды из людей разных функциональных подразделений, которые и разрабатывают продукты. Это ускоряет, проект перестает ждать взаимных согласований. Но при этом нарушает сложившуюся культуру, поэтому нужна поддержка топов, нужно следить за изменением культуры, а не только за способами организации. За счет пристального внимания к процессу выявлялись конкретные проблемы, которые топы решали не точечно, а системно.

Принципы, которыми они руководствуются:

  • единая сквозная цель, вдохновляющая и объединяющая
  • культура доверия - обеспечивает самостоятельность команд
  • радикальная прозрачность
  • понятные границы
  • постоянные эксперименты

При этом проектный офис организационно сохранился, просто часть Project Manager стали Scrum Master и начали работать по-другому. Разные проекты идут по разным путям, это зависит от характера проекта. Около 70 продуктов сейчас разрабатывают по-новому. И изменения успешны: на входе было Time to market разработки продуктов был 2-2.5 года, сейчас 1-1.5 года, и видят, что он еще будет сокращаться. Принципиальный фактор - людей собрали в команду по продукту, вместо функциональных подразделений - А

Интересно, что концерн Калашникова тоже применят Scrum при разработке нового оружия. Я узнал на этом на встрече в PMO club в сентябре 2017, там было три человека оттуда, приехали из Ижевска. У них в составе проектного офиса уже год как работают Scrum-команды. И за двухнедельный спринт успевают сделать в железе реальный кусочек, который можно пощупать и оценить, и благодаря этому получается быстро скорректировать маршрут движения проекта – а в обычном подходе это бы было проявлено через полгода.

На этом я завершаю вторую часть рассказа про кейсы Agile-трансфомации. Продолжение следует…

0
Комментарии
-3 комментариев
Раскрывать всегда