Правда ли, что agile и проекты в госорганизациях – «вещи несовместные»? Доклады сессии «Опыт» практической конференции «Agile.DevOps.ITSM 2018», проведенной издательством «Открытые системы», демонстрировали, что это не так.
Цифровизация в госорганизациях стоит на повестке дня, меняется стиль госуправления, власть стремится реализовать взаимодействие с гражданами посредством электронных услуг, стать максимально открытой с помощью порталов и сайтов и совершенствовать свою деятельность, опираясь на современные ИТ-инструменты. Поэтому в соответствующие ИТ-проекты неизбежно проникают новые веяния. Правда, творческий подход, без которого немыслим agile, в таких проектах не всегда очевиден. Как заметил Сергей Добриднюк из компании «Диасофт»: «творчество в госорганизациях – явление, которое есть, но возможно у нас нет тех органов чувств, которые позволяют его заметить».
Полноценному проникновению гибких подходов в госпроекты мешает множество объективных условий, некоторые из них перечислил Добриднюк. Это необходимость долгой экспертизы и согласований любого изменения («в итоге, когда все сделано, реализовывать проект, возможно, придется другому поколению чиновников»), строгие правила финансирования (их нарушение исключено), фискированные рамки проекта, недостаток высококвалифицированных кадров, избыточная отчетность.
Тем не менее в реальной практике элементы agile, необходимые для успешного и оперативного завершения проекта, удается интегрировать с этими, казалось бы, «железобетонными» принципами госИТ. Добриднюк поделился некоторыми рецептами на примере запуска в июле этого года «Перспективной платежной системы России», инициированного Банком России, реализованного государственным «МСП банком» в партнерстве с компанией «Диасофт» и задействовавшего все банки страны.
В частности, оказалось, что современные чиновники и даже топ-менеджеры госкорпораций, как правило, не избегают присутствия в соцсетях, более того, дорожат своей репутацией там, и этот канал можно использовать как действенный инструмент оперативной связи. Для доходчивого описания заказчику бизнес-архитектуры решения применили удобные средства визуализации в стиле «комиксов», что позволило наглядно объяснить основные идеи проекта прежде чем они были формализованы в строгом ТЗ. Взаимной вовлеченности заказчика и исполнителя способствовал «перехват ответственности»: участники команды разработки брали на себя часть функций заказчика из госорганизации, на которые у последнего не хватало компетенций, и, наоборот, давали «порулить» заказчику в процессе выработки деталей технического решения и управления разработчиками, если это помогало лучше донести входные требования.
![]() |
Сергей Добриднюк рассказал, что мешает проникновению гибких подходов в госпроекты и как их тем не менее можно там использовать |
Департамент информационных технологий Москвы не может не быть примером показательного исключения из правил работы ИТ в госорганах, иначе столица не выбилась бы в лидеры мировых рейтингов цифровых городов. Михаил Потоцкий, руководитель продукта Service Manager в ДИТ, рассказал о придуманной им agile-схеме реализации запросов на изменения платформы, на которой базируется техподдержка всех информационных систем «электронной Москвы». «Мы просто обязаны показывать пример качественной и при этом гибкой работы другим продуктам, которые использует город», — отметил Потоцкий.
С платформой постоянно работают около 700 пользователей, в ней функционируют десятки взаимосвязанных процессов, что необходимо учитывать при проведении изменений («меняя одну функцию, нельзя сломать множество других»). При этом технологическое окно для вывода изменения в продуктив – несколько ночных часов, в рабочее время никакие простои не допустимы.
До недавнего времени удавалось выполнять три-четыре запроса на изменения в месяц, скопилась солидная очередь нереализованных изменений. Для того чтобы увеличить скорость выполнения запросов, работы были распараллелены. Но возникла проблема – как в этих параллельных потоках разработки организовать тестирование, чтобы в очередной итоговый релиз попадали только работоспособные функции. Решение оказалось на первый взгляд очевидным, но, как рассказал Потоцкий, оно потребовало серьезной трансформации не только процессов, но и культуры работы команд.
Теперь в параллель выполняется только рабочее тестирование, и за него отвечают команды разработки, а приемочное реализуется для релиза в целом и выполняется с минимальными затратами, поскольку в итоговый релиз попадают отфильтрованные рабочим тестированием, полностью готовые функции (а не компонуются технологически близкие, как это делалось раньше). В итоге скорость выполнения запросов на изменения выросла до 20-30 в месяц, очередь запросов сократилась почти на половину.
«Это было не упражнением по изменению технологий тестирования, но трансформацией подхода к работе, синтезировавшей несколько методологий управления. Из принципов Lean была взята нацеленность на результат – ускорение обработки запросов – и отсечение всего лишнего, что достижению этого результата мешает. Из ITSM – организация процессов, из Agile – коллективные методы работы. И очень важна корпоративная культура – проведение этих идей в жизнь стало плодом совместной работы команды, а не бездумным исполнением воли руководителя», – рассказал Потоцкий.
Скоринг вместо драки
Выступая на конференции, руководитель продуктового офиса «М.Видео и Эльдорадо» Ирина Марчева рассказала, как в компании нашли способ снизить остроту конкуренции за один из самых дефицитных ресурсов – компетентных ИТ-специалистов. Наибольший поток ИТ-задач образуют запросы на изменения, поступающие из множества подразделений, которые иногда имеют конкурирующие KPI. Чтобы приоритизировать задачи в этом потоке запросов в компании взяли за основу принцип вычисляемых значений работ Weighted Shortest Job First (WSJF). При таком подходе приоритетными оказываются задачи, приносящие максимальную ценность бизнесу, но обладающие минимальной трудоемкостью. Для практического применения базовую скоринговую модель пришлось адаптировать. Помимо выгоды и скорости внедрения в формировании скоринговой оценки учитываются также мнения экспертов, участвующих в ежемесячных продуктовых комитетах, где рассматриваются заявки. Кроме того, в разработку принимают небольшие ИТ-задачи с низким рейтингом, которые не несут прямой бизнес-ценности, однако влияют на «счастье клиента».
В результате понятного и прозрачного для всех процесса приоритизации удалось сэкономить немало времени топ-менеджеров, которое раньше тратилось на «драку» за ресурсы, и повысить зрелость процессов компании. «ИТ воспринимаются как черный ящик, и обычно люди не сопоставляют, что принесет компании решение поставленной ими задачи, и сколько это будет стоить, – отметила Марчева. – Поэтому c точки зрения осознанности это очень крутая история». По ее словам, описанный подход очень эффективно работает на этапе внедрения продуктового подхода в компании, когда «владельцы продуктов» (product owners) еще не набрали достаточно опыта и уверенности в себе.
– Ирина Шеян, «Директор информационной службы»