ДЕБОРА СИЛЛС, национальный директор подразделения Deloitte Consulting по консультированию органов власти США
КЭВИН ТУНКС, эксперт Deloitte Consulting по информационным технологиям
ДЖОН О’ЛИРИ, руководитель центра Deloitte по исследованию государственных практик
Популярность методов и принципов agile в государственном секторе растет. Но что можно сказать о применении гибких технологий менеджмента в масштабных, сложных проектах, которые типичны для госсектора? На этот вопрос отвечают эксперты консалтинговой компании Deloitte (входит в «большую четверку» международных консультантов). Этот материал продолжает серию публикаций об agile. Вводная статья опубликована в апрельском номере журнала «Бюджет».
Масштабирование управления в духе agile может столкнуться с трудностями. Например, большие проекты требуют нескольких команд. Координирование работы многочисленных небольших групп, на которых строится гибкое управление, будет сложным. Процесс будет еще сложнее, если у вас нет детальной дорожной карты — а ведь agile старается избавиться от подобных документов.
Кроме того, гибкое управление стремится к быстрым результатам, а при реализации масштабных проектов их трудно достичь. Наконец, при увеличении масштаба сложно избежать бюрократии, которую так не любит управление по гибким методикам.Тем не менее гибкие методики могут быть использованы в государственных мегапроектах, но это требует усилий.
Agile — это не просто способ реализации проектов. Гибкие методики требуют построения высокоэффективных команд, которые должны функционировать внутри больших государственных структур. Agile — это способ мобилизовать лучшие качества людей, как профессиональные, так и личностные, для того чтобы работать вместе и решать задачи любого масштаба.
Формирование успешной agile-модели
Успешная реализация проектов с помощью гибких методик требует трех основных элементов.
Первое — это четко описанные задачи и понимание, что решение этих задач принципиально важно. Второе — это интеграция взглядов руководителей и тех, кто непосредственно внедряет планы в жизнь. Третье — постоянный пересмотр на фоне изменяющихся условий желаемых результатов.
Существует много технологий и методик, которые относятся к agile, можно сказать, много «различных оттенков» этой философии. Тем не менее несколько характеристик являются обязательными. Мы перечислим их:
-
поставка промежуточных результатов в течение краткосрочных, ограниченных во времени операций;
-
постоянный пересмотр как желаемого результата, так и самого процесса работ и внесение необходимых изменений;
-
постоянный контакт между государственными агентствами, профильными экспертными (чаще всего это ИT) группами и поставщиками товаров или услуг, направленный на создание лучших результатов в рамках существующих бюджетных и временных ограничений.
Перечисленные характеристики процессов в духе agile — вызов для традиционных государственных систем, особенно когда речь идет о крупных проектах. Госорганам необходимо создать ситуацию, когда agile останется agile, но потребности крупной организации будут удовлетворены.
Мы остановимся на четырех важных элементах перехода к agile при реализации крупных проектов — работа с ними позволит значительно улучшить процесс. Это:
-
долгосрочные дорожные карты на несколько лет с детализацией заданий;
-
общее управление;
-
взаимозависимость между командами;
-
тестирование функционала.
Базовый принцип достаточно прост: нужно создать общий управленческий механизм, который позволит небольшим agile-командам решать задачи в ходе коротких «прыжков» (итераций) при тесном взаимодействии с конечными пользователями.
Давайте разберем подробнее вышеперечисленные элементы.
Долгосрочные дорожные карты с детализацией заданий
Государственное управление, как правило, требует долгосрочного планирования, построения растянутых на многие годы дорожных карт. Это в некоторой степени противоречит управлению в духе agile.
Гибкие методики предполагают, что основные функции конечного продукта становятся понятны в ходе реализации проекта, а не в результате первоначального теоретического планирования. Они приспособлены для решения задач в условиях неизвестности, когда первоначальные планы построить тяжело.
Тем не менее без единого видения многочисленные agile-команды могут прийти в никуда, даже если выполнены правильные метрики, а участники делали все верно. Эту проблему как раз могут решить долгосрочные, детализированные дорожные карты, принятые в госуправлении. С их помощью руководители проектов могут помочь командам следовать по верному пути, чтобы решать задачи, постепенно переходя на следующие этапы развития проекта. Дорожные карты помогут командам распределить обязанности, правильно выстроить баланс сил.
Однако при управлении в духе agile это будут не жесткие, а жестко-гибкие дорожные карты. Они должны описывать основные этапы работ и задания для команд, но в них нужно внедрить принципы гибкого управления, возможность для изменения планов, пересмотра первоначальных задач.
Общее управление
Масштабирование agile на большие проекты требует как минимум нескольких кросс-функциональных команд, иногда расположенных в разных местах.
При масштабировании agile важно координировать работу всех этих команд под единым управлением. Часто это требует создания дополнительных ролей менеджеров, которые помогли бы выстроить коммуникацию и снять конфликты. Лидерам нужны управленческие способности, которые превосходят требования в обычных проектах.
Как правило, взаимодействие в agile-командах требует регулярных церемоний, на которых ставятся задачи или подводятся итоги. Масштабирование гибких методик требует «церемоний для церемоний» (то есть некоторых мероприятий «второго уровня»), которые позволяют выстроить коммуникацию между командами.
Для больших проектов также нужна система общей отчетности и отслеживания того, что происходит. Таким образом, высший менеджмент, руководство и заинтересованные лица должны получить возможность оперативно отслеживать процесс и видеть промежуточные результаты. Это позволяет понять, как развивается проект, и при необходимости внести коррективы.
Зависимость между командами
Часто одной команде нужно, чтобы другие закончили свою часть работ, и только тогда она может двигаться дальше. Такая взаимозависимость команд требует дополнительной координации и планирования. Необходимо найти баланс между гибкостью и координированием работ сверху.
При масштабировании agile руководители проекта должны постоянно видеть всю картину проекта в то время, как команды интенсивно решают задачи. Когда небольшие группы сосредоточены каждая на своем участке, кто-то должен удостовериться, что реализуемый проект соответствует тому, что от него ожидают.
В ИТ-проектах взаимозависимость команд часто можно сгладить за счет постоянной сверки демонстрационных версий уже выполненных подпроектов. Как правило, каждая agile-команда устраивает ежедневно сессию планирования на 15–30 минут. В ходе такого мероприятия обсуждают не только планы, но и что мешает дальнейшему прогрессу. Эту информацию можно собирать и анализировать для нескольких команд сразу, либо устраивать встречи второго уровня, где есть представители нескольких групп.
Тестирование функционала
Традиционно agile требует тестирования функционала проекта и контроля качества после каждого короткого этапа работ. При масштабировании гибких управленческих методик необходимо предусмотреть еще один, внешний уровень контроля качества. Он должен помочь удостовериться, что все элементы системы, разработанные разными командами, вместе работают так, как должны.
Хорошим решением может стать микросегментация задач проекта, что еще больше увеличит его гибкость. Как пример приведем ИТ-проекты. Если код на одном из участков написан плохо, то его нельзя встроить в систему. Однако тратить силы на создание идеального кода также глупо. Секрет в том, чтобы заканчивать и тестировать микросегментированные задачи как можно быстрее и чаще, а также получать по ним обратную связь.
Применение agile в крупных проектах — это баланс, когда нужно избежать обычной для масштабных задач стандартизации всего проекта сверху вниз на этапе планирования, но и не допустить атмосферы беспорядка и хаоса, которая не позволит решать проблемы и осуществлять необходимую поддержку.
Если говорить об ИТ-проектах, то программисты ненавидят, когда им говорят, как писать код. Именно поэтому самоорганизованные гибкие команды стали настолько эффективны в сфере информационных технологий. Они предлагают инновации и новые решения гораздо чаще, чем жестко контролируемые группы.
Однако крупные проекты, даже реализуемые в духе agile, потребуют больше контролеров, чем маленькие. Указать границы для творчества также очень важно.
Один и тот же механизм не работает для всех
Понятие agile, или «гибкие подходы в управлении», покрывает широкий спектр методик, и нет единого рецепта, как использовать их при масштабировании на большие проекты. Среди всех возможных подходов нужно помнить, что одним из главных принципов управления остаются реалистичные ожидания.
Agile — это не волшебная палочка, которая заставит трудности масштабных проектов магическим образом исчезнуть. Большие проекты останутся вызовом как с технологической, так и с управленческой точки зрения. В них сложно все — от подбора персонала до поиска поставщика.
При реализации больших проектов государственной структуре следует переходить на постановку модульных задач, когда большое задание разбирается на несколько маленьких и передается разным исполнителям. Такая практика значительно расширяет число компаний, которые могут быть привлечены для подрядных работ. Тем не менее далеко не все поставщики могут организовать внутри себя agile-процессы и выстроить эффективную коммуникацию с другими участниками.
Более того, наем нескольких малых подрядчиков с одним руководящим общим подрядчиком может создать еще больше проблем в коммуникации. В то же время взаимодействие с одной главной компанией часто оказывается более удобным для конечного заказчика. Это значит, что государственная структура должна качественно проработать иерархию и взаимодействие подрядчиков перед запуском проекта. Нужно оценить необходимые ресурсы и предусмотреть центральное управление, о котором говорилось раньше. Сильный государственный подрядчик может замечать проблемы раньше и обеспечить, чтобы государственное агентство, со своей стороны, также предоставило все, что нужно для успеха проекта. Например, это экспертиза или доступ к инфраструктуре.
В любом случае успех масштабирования гибких методик управления на госслужбе зависит от того, насколько удастся сформировать правильные ожидания и подобрать наиболее правильные техники проектного управления.
Agile в масштабных государственных проектах: три кейса
Система хранения данных ФБР. После террористических атак 11 сентября 2001 года Федеральное бюро расследований США поставило задачу создать единую электронную базу данных, которая бы позволяла легко управлять и обмениваться информацией. Сначала проект попробовали реализовать с помощью традиционного, водопадного подхода. В результате до 2010 года организация потратила сотни миллионов долларов на многочисленные варианты такой системы, но получила разочаровывающие результаты.
Тогда в ФБР адаптировали гибкие технологии для реализации этого проекта. Это потребовало значительных изменений в культуре организации; тем не менее, используя этот подход, в течение года бюро смогло представить первый работающий вариант системы.
Комиссия здравоохранения и социальных услуг штата Техас. Эта комиссия — один из крупнейших государственных органов в одном из самых больших американских штатов. Ее годовой бюджет составляет около 30 миллиардов долларов.
Решение ведомства внедрить гибкие методики управления в свою работу потребовало значительного изменения внутренней культуры и структуры. Сначала в ведомстве провели пилотный проект, который показал позитивные результаты.
Однако для того, чтобы осуществлять крупные проекты, комиссии пришлось вложить значительные инвестиции в переподготовку персонала. В результате внедрение новых ИТ-проектов в ведомстве ускорилось в несколько раз.
Сервис социальных услуг для детей в Калифорнии. Долгое время Агентство здравоохранения и социальных услуг Калифорнии работало в рамках классического водопадного подхода, однако в результате ведомство решило перейти на agile.
По словам заместителя секретаря по инновациям и отчетности правительства штата Стюарта Драуна (Stuart Drown), в 2015 году проект стоимостью 500 миллионов долларов переживал уже седьмую реинкарнацию.
Даже седьмая попытка была неудачной. Переход на гибкие методики казался катастрофой, однако он закончился успехом. Проект был разбит на несколько самостоятельных моделей, и каждую из них передали отдельному исполнителю. В результате ведомству удалось в кратчайшие сроки сдать работающий сервис.
Перевел
К. В. ОВЧАРУК
