2015-11-13: Agile для государства - какое нужно регулирование

Короткая ссылка: GosAgile-2015-11

На AgileKitchen по теме Гибкие методы в государственных проектах собрались не только представители ИТ, чтобы обсудить свои трудности в работе по Agile в проектах для государственных и близких к ним заказчиков. Было много представителей заказчиков, то есть государственных и регулирующих структур. Как уже применяющих Agile при ведении своих проектов, так и желающих получить преимущества, которые дает Agile, прежде всего прозрачность продвижения проекта, для государственных проектов повсеместно. В том числе перенести практики на не-ИТ проекты, там, где это уместно. И основным вопросом при подготовке встречи как раз и было: какое нужно регулирование в виде стандартов, методических рекомендаций или других документов, чтобы достичь этих целей. А то, что встреча проходила в Аналитическом центре при Правительстве Российской Федерации подчеркивает заинтересованность.

Замечу, кстати, что мнение о том, что Agile-подход не предполагает нормативных документов - ложное. По Scrum есть нормативные документы, согласованные в Scrum Alliance и отделяющие от других методов. Есть сообщества и по другим методам, и Agile в целом тоже имеет свои нормативные документы, такие как Agile Manifest. Другое дело в характере нормирования и заложенной в нем гибкости и адаптивности методов, а также в ценностях и мышлении, которые и обеспечивают успех проектов.

Надо сказать, что в государственных проектах Agile как способ ведения достаточно широко применяется. Об этом были рассказы не только со стороны ИТ, но и со стороны Заказчиков. Включая неожиданные для меня - опыт принуждения заказчиком, Ростехнадзором, своего подрядчика к переходу на Agile для обеспечения предсказуемости и скорости выполнения доработок по проекту. Хотя традиционно федеральные ведомства считаются неповоротливыми и консервативными противниками новых гибких методов. И был интересный рассказ из Тюменской области о практике контрактования проектов с нефиксированным scope в рамках 44-ФЗ. Вообще входе обсуждения на openspace конкретных вопросов было интересно наблюдать диалог между заказчиками и подрядчиками в стиле "Мы делаем это, потому что наши ИТ-подрядчики это не делают - Нет, таких заказчиков не бывает, это делаем мы, потому что наши заказчики никогда этого не делают."

Подводя резюме встречи, можно зафиксировать следующее (это - авторское мнение, а не официальная резолюция).

Нынешнее нормативное регулирование (ГОСТ, ФЗ) не препятствует проводить проекты по Agile при желании с обоих сторон. При этом желание может быть как начальным, добровольным, так и транслироваться с одной стороны разными просветительско-административными методами. Вместе с тем есть традиция применения нормативных документов, которая противоречит способу ведения Agile-проектов, и преодоление этой традиции требует существенных усилий в каждом случае.
Признано, что точно будут полезны методические указания, рассчитанные на начинающих заказчиков и типовые категории проектов, которые помогут гос.заказчиком начать выполнять проекты в этом стиле. Особенно в регионах. Для тех ситуаций, когда есть взаимное желание заказчика и подрядчика, но не хватает подсказок, как сопрячь это с нормативными требованиями, включая защиту перед различными контролирующими органами.
Есть интенция со стороны государства создать такое нормативное регулирование проектной работы, которое бы обеспечила прозрачность хода проекта, достижимость его результатов и другие, которые дает Agile-подход. Вообще говоря, не ограничиваясь ИТ-проектами. При этом сделать это через регламентацию метода, а не результата. Способ подтверждается опытом ряда стран, которые именно так и поступили.
- С моей точки зрения, нормативного документа будет не достаточно, необходимо формирование определенной культуры. Но регламентирующий документ может этому способствовать, быть способом убеждения, особенно в государственной среде. Замечу, кстати, что такой подход отчасти противоречит философии Agile "Люди и взаимодействие важнее процессов и инструментов" - нормированием процесса пытаются подменить убеждение людей.
- А еще обсуждение показывает, что есть набор конкретных практик, давно известных и принятых в отрасли, таких как тестовая интеграционная среда, например, которые не обеспечивают успех проекта, но устраняют давно (с 70-х) известные грабли на его завершении, и которые, тем не менее, не применяются в конкретных проектах. Или вера в идеальные конструкции, такие как идеальное проектирование и затем реализация с неизменными требованиями. И вот их - можно разрушать нормативно, например, ограничивая сроки или стоимость первых этапов, оканчивающихся внедрением продукта или наличия на проекте соответствующей инфраструктуры и методик, тоже в привязке к этапности. Но к нормативам должна прилагаться практика, в виде соответствующей службы, готовой помочь на конкретном проекте, иначе они будут восприниматься как "опять эти теоретики требуют невозможного".
Придуман конкретный сценарий инициации проекта для неквалифицированного заказчика без четких требований. Сценарий довольно жесткий для подрядчиков.
1. Запрос предложения рамочной темой. На него надо ответить набором user story (или другим описанием функционала) с ценой. В процессе формирования предложения - есть право контактировать с Заказчиком, который выделяет ресурсы.
2. На основе полученных предложений, а также используя опыт коммуникации с потенциальными подрядчиками, Заказчик понимает и формирует scope проекта, который будет являться предметом заказа и именно его выставляет на конкурс.

Работа будет продолжена через рабочие группы и серию мероприятий. На встрече были и выступали люди из Аппарата Правительства и Минкомсвязи, хотя не все светили должности в программе. И они заинтересованы в результате.

А сейчас - резюме докладов. Видео будет выкладываться на канале ScrumTrek на youtube, первое уже есть. А презентации уже выложены, тоже на канале ScrumTrek на slideshare.

Водопад и Agile. Альтернативы или дополняющие подходы? Шестопалов Павел, референт Департамента экономики и финансов Аппарата Правительства Российской Федерации. Презентация, видео.

В своем докладе Павел давал версии областей применимости Agile-методов внутри традиционного проектного управления. В терминах областей в матрице Предметы-Процессы, и в терминах фаз жизненного цикла. На мой взгляд, это в этих терминах можно говорить не о применимости Agile вообще, а о применимости конкретных методов. Но при этом сейчас правильно использовать не карты из PMBOK и других прежних стандартов проектного управления, а карты стандарт OMG Essence, полученные анализом и обобщений практик управления проектами в ИТ. Там представлен гораздо более адекватный взгляд на жизненный цикл как совокупность прохождения стадий по отдельным предметам, которые, в общем случае, не вытянуты в одну последовательность. При этом, в отличие от прежних стандартов методу присущ минимализм: не "возьмите все, и вычеркните лишнее", а "возьмите минимальный каркас и дополните по необходимости".
Я считаю ценным тезис, высказанный Павлом, о том, что государственный заказчик, как правило, - неквалифицированный заказчик: он не разбирается в том предмете, который заказывает, а обращается к специалисту. При этом ему нужны методы наблюдения за ходом проекта и контроля рисков. Собственно, этот тезис дает указание на характер и способ коммуникации при продвижении Agile-практик, которые во многом направлены на то же самое, они призваны обеспечить такой способ ведения проекта, при котором стейкхолдеры проекта, не разбирающиеся в предмете ИТ-разработки, могут, тем не менее. наблюдать за ходом проекта и динамикой его выполнения, а также контролировать риски. В ответе на вопросы Павел подтвердил: если вы укажете на способ контроля рисков для стейкхолдера, то вы продадите ему свой метод.

Внедрение проектного управления в Сочи-2014 и Agile. Андрей Бадин, Управляющий партнер компании «Проектные сервисы», Заместитель председателя Совета по внедрению проектного управления в органах власти при Минэкономразвития России. Презентация

Очень интересная история про внедрение проектного управления в Сочи-2014 от того, кто практически вел это внедрение. При том, что когда он пришел (в 2009), был уже год отрицательного опыта неудачного внедрения. И в условиях большого разнообразия проектов - строительство, ИТ, подготовка спортивных мероприятий по требованиям МОК, культурные проекты. Ему удалось решить это за три месяца - отстраивание организационной машины и поддержка ее на уровне автоматизированной системы, обеспечивающий мониторинг хода проектов на всех уровнях.
Способ - через легкие и минимальные практики. Основой стала работа по контрольным точкам проектов, которые были выделены во всех типах проектов. При этом отчетность по контрольным точкам была сквозная по всем уровням, но был практически разработано сбалансированное разделение ответственности по уровням так, что у каждого руководителя в ней был обозримый набор контрольных точек. И практическая работа с людьми, помощь и обучение через совместную деятельность в подготовке отчетов.
Возникает вопрос: а при чем здесь Agile? А он здесь в культуре, способе работы или даже философии работы, которой он отличается от традиционного менеджмента и проектного управления. Но в нем культура еще и поддержана практиками и методами, что сильно облегчает деятельность в соответствии с ней. И это - именно то, что хочется достичь в проектах.

Госзаказчик и исполнитель - коллеги или враги? Антон Душутин, ЗАО Сфера. Презентация

Практические кейсы использования agile-методов ведения проектов с военным блоком, МВД и другими тяжелыми заказчиками. И проблемные точки. которые возникают при осуществлении, в которых наличие соответствующих нормативных документов могло бы сильно облегчить коммуникацию. В докладе, правда, звучало. что при наличии документа заказчики сами проникнутся таким подходом, потому что должны будут исполнять. Я думаю, документа недостаточно, но он поможет. А набор проблемных точек, который звучал в докладе - полезен.

Практический опыт создания и развития Комплексной системы информатизации Ростехнадзора. Макарчук Марина Владимировна, советник, Управление специальной безопасности, Ростехнадзор Презентация видео.

Крайне интересный доклад. Ростехнадзор, большая корпоративная система, действующая в рамках всего ведомства на всей территории России. 17 подсистем, которые непрерывно дорабатываются.
Интересно тут, что инициатором перехода на Agile был Заказчик, и он заставил подрядчика перейти на 3-недельные поставки релизов и внедрить другие практики. В результате сейчас (уже три года) - все хорошо, система развивается удовлетворительным и предсказуемым образом. А что было раньше и ушло - тоже есть на слайдах презентации.

А как у них? Agile в государственных проектах других стран. Асхат Уразбаев, ScrumTrek Презентация, видео - опыт США, Британии и Австралии.

Наиболее впечатляющий кейс - в США, где внедрение практик Agile как обязательной меры для государственных ИТ-проектов произошло после грандиозного фейла с сайтом национальной страховой программы здоровья HealthCare.gov. Создание сайта для регистрации страховок по первоначальным оценкам требовало 94 млн$, еще до старта работ сумма выросла до 292 млн$, а фактически сайт обошелся в 1.7 млрд.$ И при этом на момент старта сайт был практически не работоспособен: при планируемой нагрузке в 60000 посетителей тесты показывали максимум 1100, только 1% посетителей в первом месяце смогли завершить регистрацию из-за множественных ошибок и так далее. Проект велся по водопаду, подробности можно прочитать в вики и других источниках.
После этого был организован US Digital Service (история) как часть аппарата президента. Который выпустил ряд нормативки по ведению ИТ-проектов, в которых фактически требуется соблюдения тех же принципов и подходов, которые пропагандирует Agile. И руководил решением проблем с HealthCare.gov и другими проектами. При этом часть ролей является прямой калькой, например, Product Owner. Нормативка включает специальное руководство том, как помирить этот подход с регулированием федеральных закупок.
В Англии есть отдельный сервис электронного правительства (Goverment Digital Services), являющийся частью кабинета министров. И есть нормативные документы, регламентируюшие ведение ИТ-проектов по созданию сервисов, доступных как часть электронного правительства. В которых тоже достаточно жестко прописан Scrum-метод. Методика родилась в 2011, после того как предыдущий вариант был признан неработоспособным и было решено, что его следует разработать заново, новыми способами, вместо эволюции. Из интересного - там диктуется 5 фаз проекта - discovery, alpha, beta, live and retiretment, каждая из которых должна кончаться поставкой, при чем альфа - уже работающее ПО. И при этом есть относительно жесткое ограничение по общему бюджету первых двух фаз - таким образом практически добиваются ранней поставки.
Австралийский опыт интересен тем, что там премьер - из ИТ и он видит в управлении на основе Agile залог успешного развития страны - не только в ИТ, а и в других областях. Что касается конкретного регулирования, то оно взято у Британии
В презентации - много ссылок, смотрите.

Гибкая разработка ИС в рамках ГОСТ. Сергей Смирнов, начальник сектора разработки, СПб ГУП Санкт-Петербургский информационно-аналитический центр. Презентация видео

В докладе был рассказан практический кейс по одной системе совмещения Agile с нынешним нормативным регулированием. С представлением конкретных решений там, где они найдены и используются и тех проблемных вопросов, с которыми есть затруднения.
Часть из них были обсуждены в рамках open space на конференции и были даны вполне рабочие гипотезы возможных решений. Например, обязательное требование по обучению пользователей может реализовываться через предварительную публикацию видео-уроков, дополненную мониторингом просмотра при необходимости. А тестирование при частых, в перспективе непрерывных поставках - через согласование методики еще на этапе постановке, с дальнейшей автоматической фиксацией ее успешного прохождения, возможно - через автотесты. Пунктирно намечена конструкция контрактования с ранней поставкой системы, при том, что контрактуется полный функционал, поставляемый за год.
В целом доклад - это хорошая основа для оглавления методологических рекомендаций, а по ряду разделов - и для их наполнения.

Практика заключения и реализации контрактов на создание и развитие ИС по T&M-модели в рамках 44-ФЗ. Иван Дубровин, внештатный эксперт Аналитического центра при Правительстве РФ. Презентация видео

В докладе был представлен конкретный кейс контрактования проектов с переменным scope в рамках 44-ФЗ.Заметим, что это не оплата по T&M, тут авторы неправы (и сами признавали это). Способ применяется в Тюменской области и успешно проходит аудиторские и другие проверки. Правда, как признал докладчик, у нас в каждом регионе - своя правоприменительная практика, и это не означает. что в вашем регионе контролирующие органы одобрят такую конструкцию.
Контракт в этом случае выглядит из двух частей: не тарифицируемой и тарифицируемой. В не тарифицируемую входит сопровождение уже разработанного функционала, а в тарифицируемую - развитие системы. Тарифицируемая часть ограничена по бюджету и есть ставка за час. А дальше - самое интересное. Каждая доработка оценивается исполнителем в часах и идет торговля - нужна ли она Заказчику за столько часов, или нет. При этом Заказчик не обязан выбирать всю квоту тарифицируемых часов.
При заключении необходимо прописывать квалификационные требования к исполнителю, чтобы защититься от подрядчиков, пытающихся выиграть демпинговой ценой часа, а потом накручивать трудоемкость. Защитой также является возможность не заказывать дополнительные работы, кроме того в контракте можно нормировать типовые доработки.
В докладе были конкретные примеры контрактных условий со ссылкой на тендерный сайт - поскольку это было открыто опубликовано как условия конкретных тендеров.

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