Как ЗАГС стал цифровым?
Дата: 14.03.2024
В чем главная сложность внедрения Agile в государственные структуры? Возможно ли вовлечь в процесс трансформации предприятия всех участников? И как победить отторжение новизны среди сотрудников?
История ФНС и ГНИВЦ с конференции ГОС-Agile 2.023 «Гибкие госконтракты» 27 июня 2023 года.
Дарья Ерещенко: Поговорим про старт работы над проектом ЗАГС в конце 2016 года – начале 2017. Я пришла руководителем проекта, и так и вышло, что это была достаточно стихийная, хаотичная разработка, но при этом, у проекта были очень сжатые сроки. Интуитивно получилось, что мы сразу объединились в команду с заказчиком. Мы практически 24/7 были вместе. Все время планировали наши работы, но все равно были нюансы неуправляемости процесса. Дальше, уже после нашего внедрения в 2018 году, в 2019 у Романа уже появился проект ЕРН и на нем с привлечением внешнего консалтинга, внешних подрядчиков был применен и раскатан в первый раз Agile-подход на таких крупных проектах. Потом мы его масштабировали на ЗАГС, плюс, у нас еще в компании родились команды, которые сами начали его внедрять. Это был неуправляемый процесс. Это были самоорганизующиеся инициативные команды. После чего мы поняли, что это эффективно работает и в 2021 году решили стартовать массовую трансформацию нашей компании.
Роман Баранов: Мы расскажем это на примере ЗАГСа, и сегодня мы уже строим ЗАГС 2.0, вторую итерацию этой же системы. Несколько слов о самом проекте для того, чтобы потом было понятно, насколько сложно было на самом старте. Это облачная система, в которой сегодня все органы ЗАГСа регистрируют записи актов гражданского состояния. Она должна работать 365 дней в году, 24/7. Люди рождаются, люди умирают.
С передачи нам полномочия оператора, мы получили также функцию централизованного предоставления сведений. На сегодняшний день у нас насчитывается более тысячи различных получателей сведений через СМЭВ. Была проведена огромнейшая работа по оцифровке почти 100-летней истории нашей страны с актовых книг, которые хранились на бумаге на полках в органах ЗАГС, начиная с 1926 года, почти 520 миллионов записей или судеб людей нашей страны были оцифрованы и перенесены в нашу систему.
С чем мы столкнулись на самом старте? Уже было сказано, что слева боль заказчика, сжатые сроки выполнения работ. Закон приняли. Меньше, чем через полтора года нужно войти в промышленную эксплуатацию. Большой ГИС за такой срок невозможно выполнить. А помимо того, что просто наделили полномочиями оператора, еще Минюсту нужно было поменять всю нормативу для того, чтобы она могла работать с новой системой в новом воплощении. И у заказчика, и у исполнителя на старте проекта отсутствовало понимание, как же должен выглядеть конечный образ результата, который они должны получить к 1 января 2018 года.
Да, не без сдвигов, мы переносили внедрение на 1 октября 2018 года, но все-таки это сделали, и нам помогли те рецепты, о которых мы расскажем дальше.
Дарья Ерещенко: Все эти особенности влияют на огромный неуправляемый и плохо приоритезированный бэклог, потому что все нужно сделать сейчас и сразу за год, и весь этот перечень задач накидывается. В результате у нас перегружена команда, перегружены сотрудники, и тогда еще мы не применяли итерационный подход и демонстрацию промежуточных результатов, поэтому несколько раз натыкались на свои грабли и достаточно сильно переделывали наш продукт. Для того чтобы это нивелировать, мы извлекли уроки из наших ошибок.
Роман Баранов: Знакомая, наверное, каждому государственному заказчику картинка. Планируешь ТЗ на год. Какие неопределенности были в Waterfall? Понятно, что на этапе планирования государственного контракта невозможно определить оптимальные технические решения, что должно быть под капотом, как это должно работать. Особенность госсектора, в том числе состоит в том, что делаются кастомные решения, которые невозможно купить на рынке в виде коробочных решений, принести себе и откалибровать для того, чтобы они считали налоги, регистрировали рождение.
Как правило, нет какой-то детальной проработки самих задач и вообще дизайна системы, если мы говорим о создании большого ГИСа. И ты получаешь, если делаешь какой-то большой блок в уже существующей системе, например, АИС «Налог-3», то ты имеешь непрогнозируемые последствия, как встраивание этого блока в прод повлияет на все смежные подсистемы и все смежные бизнес-процессы.
Боль, которую лично я испытывал, находясь на позиции технического заказчика в Департаменте информационных технологий, это то, что тот результат, который ты себе заказываешь в начале года, тебе приносят в конце года, и он может совершенно не совпадать с твоими ожиданиями. В контракте ты стремишься написать достаточно расплывчатые формулировки, чтобы было комфортно и тебе, и исполнителю. Появились нововведения в виде требований по импортозамещению. Возникает необходимость реализации каких-то неактуальных требований, которые уже не важны, и тебе они в системе не нужны, но они записаны в ТЗ, их нужно как-то закрывать. Но иногда мы сами вспоминаем о том, что до приемки осталось две недели.
На тот момент мы находились в серой зоне сектора, который не использовал подходы Agile. Что же с того момента изменилось и как мы попали в оранжевую зону?
Рецепт от заказчика. Так сегодня выглядит классический цикл разработки на наших проектах. Естественно, у нас есть бэклог проекта, мы проводим его груминг. На стороне заказчика в лице моего заместителя находится product owner. Она участвует в планировании всех спринтов, определяет цели спринта. Мы не разделяем задачи развития и задачи сопровождения, решаем их в рамках одного спринта. Отдельно выделяется пул ресурсов на сопровождение с неким люфтом ресурсов, чтобы можно было покрыть эти риски, если произойдет какая-то исключительная ситуация.
Работаем мы в режиме спринт один раз в две недели. Мы приняли концептуальное решение, что демо для заказчика проводит аналитик или тимлид аналитического блока. Почему пришли к такому решению? Потому что, первое, аналитики хорошо понимают язык заказчика, и они, в том числе, могут транслировать те риски, которые видят программисты или производство заказчику, и донести их в понятной форме. Это осмысленное решение. Демо спринта и от момента демо новой функциональности, мы видим его на нашем продакшене примерно через месяц, связано это с тем, что требуется время на сборку и на тестирование. У нас есть как ручное тестирование, так и синтетическое. Все эти процессы занимают время и не очень хочется большому заказчику с большим числом пользователей сильно будоражить прод частыми изменениями, потому что это иногда очень болезненно.
Мы не используем классическое ретро. Это наша особенность. Мы проводим его один или два раза в квартал со всеми участниками проекта. При этом, мы не обсуждаем какие-то тонкости прошедшего спринта, а синхронизируемся по вектору движения по проекту в целом для того, чтобы все были в одном информационном поле.
Элемент бюрократии, можно сказать, в хорошем смысле, в моем понимании, это статусы по проекту, которые проходят один или два раза, в зависимости от проекта, в неделю на площадке функционального заказчика или в режиме ВКС.
Дарья Ерещенко: Что же для нас, как для исполнителя всех этих работ, значит госконтракт, и как мы внедряем эти самые Agile-подходы в нашей системе? Моя задача – внедрять не только конкретные проекты, но и масштабировать это на нашу организацию в целом для того, чтобы она работала как единый механизм. Как вы понимаете, это достаточно сложная задача, потому что у команд и у заказчиков очень разный уровень вовлеченности. Какие-то заказчики как Роман, нам это просто достаточно внедрить. Есть и в Федеральной налоговой службе наши заказчики, с которыми долго приходится обсуждать, а как же мы это будем внедрять, как это встраивать в подходы, почему им это нужно, зачем и так далее. Но в результате каких-то определенных переговоров, итераций, внедрений и так далее у нас родились следующие подходы.
У нас есть два типа госконтрактов, как уже Роман сказал. Это госконтракт на развитие, это госконтракт на сопровождение. В целом, неважно, наверное, в данной ситуации какой это контракт, потому что за эпик мы берем пункт госконтракта, потому что пункт госконтракта несет в себе довольно длительную итерацию. Это может быть даже три месяца. И этот эпик делится на фичи, делится дальше на истории и уже дальше на конкретные точные подзадачи для команды. Эти задачи накидываются в двухнедельные итерации или необязательно, потому что для некоторых команд мы выбираем тот же Kanban-подход. Это тоже достаточно такой гибкий процесс, который мы настраиваем индивидуально.
После чего мы накидываем это в двухнедельный цикл. За две недели заказчик получает результат. У кого-то есть демо результата. Где-то мы отдаем, например, просто софт на тестовый стенд или контур опытной эксплуатации. Заказчик тоже может посмотреть самостоятельно. Это уже достаточно настраиваемый процесс.
Как мы это делаем на уровне компании? Почему? Когда мы в ЗАГСах начали эти подходы, и моя команда тоже ходила и думала: «Господи, что это такое? Зачем нам постоянные ретро? Зачем нам все время собираться?». Условно говоря, стендапы мы внедрили очень давно. Все остальные встречи воспринимались с трудом. Планирование стори поинтов тоже вызывало определенное отторжение долгое время. Они не понимали, что это, не понимали, зачем это. Но, с течением времени, тренируясь на кошечках, мы выработали определенные подходы.
И что же за подходы у нас есть? У нас в компании есть блок трансформации, в котором участвует определенное количество агентов изменений, которые заходят в команду и проводят обучение, настраивают все коммуникации, процессы, выбирают адаптивную модель для конкретной команды, формируют бэклог, формируют планирование. У нас в любом случае гибридный подход. Но все равно есть план по госконтракту на определенный период, до конца, например, года, внутри которого мы уже можем управлять бэклогом. Мы собираемся и корректируем подходы по результатам работы. Например, поработали квартал, собрались с командой и смотрим, действительно ли все, что привнес агент изменений в команду, работает. И потом дальше уже вносим какие-то изменения. Естественно, мы используем трекеры задач. Был определенный момент, когда мы переводили всю разработку в новые трекеры задач. Сейчас мы стараемся отслеживать нашу производительность, основываясь не на внутренних ощущениях, а на метриках. Настраиваем дашборды и определенные метрики для команд.
Если мы поговорим про рецепты успеха, все их в том или ином виде вы видели у других спикеров. Потому что самое первое — это постоянная коммуникация. Без нее никакой процесс, никакой проект невозможно изменить или внедрить.
Мы внедряем критерии приемки задач, чтобы были определенные стандарты, чтобы мы понимали, что будет на выходе, и чтобы заказчик уже на этапе проектирования тоже это понимал. Мы демонстрируем промежуточные результаты.
Естественно, мы очень большое внимание стали уделять тестированию, написаниям тестовой модели, тест-кейсов, постоянной их актуализации. Потому что без этого качественно внедрить какую-то систему невозможно. Потому что, если говорить про мои другие команды, которые не касаются ЗАГСа, они говорят: «Мы выполняем все задачи в срок. Мы все задачи по госконтракту закрываем. Зачем нам нужна трансформация, если мы и так успешны? Мы приносим деньги компании, мы все закрываем, у нас нет технического долга. Зачем вы к нам приходите со своими изменениями, со своей трансформацией? Мы прекрасно живем». А затем, что они закрывают, но вопрос как они закрывают и какое качество закрытия этих работ. Вопрос, удовлетворяет ли конечный результат заказчика и в том числе пользователей этой системы, налогоплательщиков или пользователей реестра ЗАГС. Формальное закрытие присутствует. Поэтому мы очень большое внимание уделяем всем этим вопросам.
Образ результата на год. И очень важно планирование работ по смежным командам в случае интеграционного подхода. Когда мы решаем задачи типа импортозамещения, например, где у нас огромная система АИС «Налог-3», которая содержит в себе очень большое количество компонентов. Когда мы говорим об импортозамещении какого-то ряда компонентов, мы идем по планам. В первом году импортозамещения у нас идет разработка и опытная эксплуатация условно пяти подсистем. В следующий год еще пяти. И везде у них есть точки зависимости. Поэтому без квартального планирования на таких командах просто невозможно реализовать проект такого масштаба.
Роман Баранов: Что не удалось сделать? ФНС большой, это более тысячи человек с точки зрения Центрального аппарата и 120 тысяч сотрудников территориальных налоговых органов. Невозможно такую массу участников вовлечь в процесс трансформации одновременно и с одинаковым уровнем вовлеченности. У нас остаются команды, скажем так, которым не интересен Agile, есть и со стороны подрядчика такие вопросы. Вот Даша не даст соврать. Приходят коллеги, говорят: «Мы же принесли продукт, он работает, чем вас не устраивает? Зачем вы нас тащите в Agile?»
Трудно выровнять уровни команд. Есть самоорганизованные команды, которые болеют результатом у них очень разная степень того, как у кого горят глаза. Кто-то приносит результат, готов информировать о рисках, управлять этими рисками, управлять ожиданиями заказчика с точки зрения этих рисков. Какие-то команды пытаются это скрыть, все оставить в себе, и из-за этого коммуникация ухудшается и ухудшается сам продукт. Страдает только продукт.
Не удалось внедрить подходы на всех уровнях, безусловно, с учетом нашей территориальной распределенности. Мы пытаемся привлечь территории, потому что они одни из основных пользователей нашей системы, в частности налогового администрирования, но не всегда это возможно ввиду часовых поясов и невозможно раздувать до бесконечности команду. Эффективная микрокоманда — это 7-8 человек.
Дарья Ерещенко: Поэтому мы не останавливаемся, у нас еще очень большой путь впереди. На вторую половину года мы запланировали перезапуск трансформации нашей компании, потому что она началась достаточно мягко, это больше были уговоры и такие «Давайте попробуем вот это, вот так не получилось, давайте попробуем это». Сейчас мы уже понимаем, что есть ряд определенных практик, которые у нас точно работают на госконтрактах, они точно работают с заказчиками, и они всем нравятся. И здесь мы вынуждены внедрить определенную степень бюрократии и директивности. Мы адаптируем использование лучших Agile-практик и не только практик. Создание такого шаблона внедрения для каждой команды и этот шаблон – это не пожелания, а минимально достаточный набор тех инструментов, которые должна использовать каждая команда в ГНИВЦ, и если она не использует или противится, то мы уже отдельно разговариваем с участниками на предмет того, что, либо ты с нами, либо мы будем строить новую команду и компанию самостоятельно.
Про интеграционное квартальное планирование я сказала, что это нужно делать, но у нас пока пилот сделан на команде импортозамещения, мы хотим масштабировать его на все наши команды, где это уместно, естественно. Например, в команде ЗАГС это необязательное условие для того, чтобы успешно реализовывать проекты.
Мы внедряем постоянную оценку наших команд по матрице зрелости по нашим базовым стандартам. То есть мы тоже полностью сформировали эту матрицу, которая нас устраивает и планируем запуск итерациями проводить ежегодно, либо раз в полгода.
Роман Баранов: Я от себя еще добавлю, что у нас есть зеркальная оценка друг друга как партнеров. Со стороны ФНС проводится анонимный опрос коммуникаций, и точно такой же опрос проводится на стороне ГНИВЦ, потом эти результаты демонстрируются и видно насколько в различных командах различная степень партнерства.
Дарья Ерещенко: Хочется сказать, что эти опросы за последний год стали гораздо более позитивными. Можно косвенно по ним увидеть, что результаты нашей совместной трансформации приносят свои плоды.