Все статьи
Панельная дискуссия
Дата: 22.02.2024
Панельная дискуссия с конференции ГОС-Agile 2.023 «Гибкие госконтракты» 27 июня 2023 года.
- Алёна Ёлкина, Руководитель проектов Департамента развития сервисов и клиентского опыта Минцифры России;
- Андрей Гирин, Руководитель направления офиса Agile-практик РТЛабс;
- Роман Баранов, Начальник управления регистра населения ФНС России;
- Дарья Ерещенко, Заместитель генерального директора АО «ГНИВЦ»;
- Дарья Криничная, Ведущий специалист отдела проектов цифровой трансформации ФБУ НЦПИ при Минюсте России;
- Дмитрий Гоков, Генеральный директор Smart Consulting;
- Алексей Колегов, Директор по цифровой трансформации Роснано;
- Михаил Иванов, Генеральный директор ProActor Solutions.
Содержание статьи
Что вам удалось изменить в управлении проектами с 2020 года?
Что нам удалось, это как раз переход к тому общему пониманию, что длительные планы, детально проработанные, зафиксированные с точки зрения каждой запятой уже не всегда являются актуальными в современном мире. Мы, как подрядчики, как государство, должны уметь к таким изменениям приспосабливаться. Нам более или менее это удалось, и это, наверное, главное достижение, которое у нас есть. Что не удалось – попозже.
С точки зрения заказчика, что удалось? Удалось немного переработать свое мышление. Если раньше мы думали, что без четкого ТЗ результат неопределён на этапе разработки контракта, то теперь мы понимаем, что это все будет на этапе конкретной заявки, а на этапе заключения контракта мы должны быть максимально готовы к тому, что точка Б в результате проработки может постепенно превратиться в точку В и в точку Я. И не нужно ждать, что мы придем туда, куда изначально планировали. Так не бывает.
С 2020-го года удалось в первую очередь наладить эффективные прямые коммуникации на уровне линейных руководителей с партнером в лице ГНИВЦ. И самое главное, что у всех участников команды горят глаза за тот единый результат. И это не страшно. Не страшно ошибаться, потому что даже работа, выполненная на корзину, ведет к еще большему положительному опыту.
Удалось преломить ощущения наших сотрудников с точки зрения исполнителя, что к заказчику можно прийти. Можно прийти, рассказать про риски, рассказать про свои опасения, невозможность реализовать ту или иную задачу так, как хочет заказчик, или в срок, или еще как-то, и попробовать найти определенный компромисс. С точки зрения коммуникации мы продвинулись значительно, потому что раньше это было, как называется, в одну сторону бросили мячик, может быть прилетит оттуда что-нибудь, а может быть и нет.
Касательно самого подхода Agile, у нас срок был короче, чем с 2020-2021 года. Мы за свои полгода поняли, что самое главное – это человеческий ресурс, человеческое общение. Всеми нами любимый 44-й ФЗ, и работа на корзину, часть мы так или иначе делаем на корзину, и соглашаемся в итоге, потому что время идет, время меняется, и мы понимаем, что это будет на корзину. Но то, что нам нужно по истечении времени, даже в короткий срок удается реализовать, хотя мы видим, что здесь этого не хватает или этого. Непосредственно в нашем проекте это было хорошо реализованное направление статистики и аналитики BI, которая у нас вообще не прописывалась в ТЗ, но она была реализована прямо хорошо. И все это на самом деле благодаря коммуникации.
Открытость и честность на проекте – это, наверное, два ключевых принципа, потому что вопросов, проблем всегда возникает много, и если мы их честно обсуждаем и вместе ищем решение, это, конечно, верный путь. Для нас новой была работа точка-многоточка, когда мы работаем параллельно с тремя-пятью клиентами на тиражируемых решениях, у нас был опыт, а вот так, чтобы на 10 или на 89, это другая история. На режиме тиражирования важно уделять внимание будущей эксплуатации, текущему обучению внедрения. Вот это те задачи, которые появляются уже на этапе внедрения, но они стратегически важны. Для нас это был очень большой опыт, очень интересный проект, и мы его превратили в опыты.
Не могу сказать, что было до 2020-го года, вот с 2020-го могу рассказать. Наблюдая за процессом изнутри и общаясь с коллегами, я заметил, что появилась мода на качественный результат. Хорошим тоном стало делать интересные проекты, не просто что-то типовое развернуть из коробки и сказать, что оно заработало. Появилась мода на инновации, на результат. В связи с этим появилось очень много качественных решений и качественных команд. Когда ранее смотрели на государственное IT, выглядело это все грустно. Казалось, что там сидят люди, которые не обладают прорывными методами. Сейчас общаясь с коллегами, я понимаю, что в госсекторе собраны одни из лучших представителей именно в IT, именно в процессах внедрения, в проектном управлении. Мне кажется, это великолепно и дальше это будет расти более экстенсивно.
Что мне удалось лично, и руководству всей нашей команды, это нормализовать сердцебиение при отклонении бюджета. Если до 2020-го года это было фатально, это был валидол, то сейчас мы этого достигли, убрав бюджет на второй план, результат выкатив на первый. Тем самым мы вообще сменили всю парадигму бытия частной IT-команды. Потому что, например, гос-IT это широкий спектр команд. Там есть и частные команды, и команды, которые давно работают и только с государством, а мы, например, работаем с государством всего лишь процентов на 20-25. Таких команд много, как мы. Эта отвязанность от строгого следования бюджету и финансовым показателям дает очень хорошие результаты с точки зрения качества проекта.
Какие инструменты, практики, артефакты позволили вам этих изменений добиться?
Чтобы избегать излишней математики, я думаю, что самой классной штукой, которая дает эффективный результат быстро, является четкое понимание фишек и функциональности. Когда с заказчиком в честном открытом общении фиксируется то, что называется «маст хэв», то, что надо сделать по-любому, любой ценой, с любыми переработками программного обеспечения, импортозамещением, очень классно упомянутым коллегами, понимание того, что мастхэв и что сверху «плюшек». Все знают, что «плюшек» обычно в пропорциональности где-то 2 от мастхэв. Весь проект 3x, из которых 2x составляют плюшки, и четкое, честное понимание этого.
Я думаю, что тезис, который я озвучил, что качество становится лучше, и запрос на результат. Это туман, неопределенность. Люди привыкают работать в состоянии неопределенности. И у людей появилось понимание, что нужно тестировать гипотезу. Делается ставка на гипотезу. Если гипотеза оказалась верной, мы получим качественный хороший результат. Если она оказалась неверной, то это не фатально, потому что неопределенность будет сохраняться, может быть, расти.
Мы продолжаем внедрять и настраивать SAFe. Классная машинка. Дальше мы используем живые, открытые повестки с клиентом. У нас есть другие инструменты, аварийный комитет и так далее. Есть те живые инструменты, которые помогают нам быстро превращать ошибки в опыт. Но и самая большая ценность — это прямая открытая коммуникация с нашим клиентом.
Я с позиции госзаказчика скажу, что есть еще третья сторона и, наверное, то, что мы для себя выявили огромным плюсом, мы все делаем это для конечного пользователя. Любой продукт мы делаем для конечного пользователя. И, как правило, ранее государство принимало решение о каком-то проекте и говорило: «Вот, будет так. Сейчас мы все напишем, мы знаем, как надо». И кто будет предоставлять услугу, кто будет ею пользоваться, государство решало само в большей степени. Глобальная аналитика, либо же статистика не проводилась. В нашем проекте мы, как госзаказчик, пошли от отраслевого эксперта. Это, наверное, один из больших шагов, которые были сделаны касательно нашего проекта, которые нам дали очень много плюсов. Мы на берегу избежали ряд ненужных вещей. Мы приехали к отраслевому эксперту, посмотрели, как он работает. Мы собрали всю информацию и для многих госзаказчиков, если ты что-то хочешь сделать и хочешь сделать хорошо, начни в первую очередь с полей и посмотри, кому это надо.
Действительно, мы столкнулись с тем, что в регионах работает очень много талантливых людей, вовлеченных, болеющих за свое дело. И это один из главных инструментов, потому что очень часто принимаются централизованные решения, что мы лучше за вас знаем. А понять боли или проблемы именно субъектов, услышать их и пойти навстречу – это, наверное, еще один источник нашего успеха.
Хочется сказать по поводу внедрения новых инструментов или новых подходов на любом уровне. Очень важен личный пример, потому что, когда ты стоишь со стороны и абстрактно что-то рассказываешь, «делайте хорошо, плохо не делайте», это зачастую не работает. Поэтому важно иногда даже не чураться плохого слова микроменеджмент, но залезть в команду и провести ее за руку по всему этому пути и показать на личном примере. Вот смотри, с заказчиком не страшно общаться, он такой же человек, с ним можно договориться о том, как мы будем планировать эти работы. Поэтому во всех этих вещах очень важна командность и личное участие, потому что быть условно выключенным лидером изменений, это в принципе путь в никуда.
Аргументированный диалог между исполнителем и заказчиком – это верное лекарство для разрешения всех спорных ситуаций. Надо иногда в себе заглушить заказчика и сказать: «Не имеет значения, что написано в техническом задании», или «Я заказчик, я знаю, как это должно работать», а нужно взять и прислушаться к мнению своих товарищей по команде.
По поводу второго вопроса, я коллег поддерживаю, мы с точки зрения Минцифры очень стараемся, у нас очень много стейкхолдеров, у нас очень много регионов, банков, мы взаимодействуем вообще с любым сектором, какой только есть, как регулятор в сфере цифровых технологий, и здесь мы стараемся показать, что мы не регулятор, то есть мы те, кто может и готов делиться тем, что мы наработали. И, например, визуальный конструктор услуг – очень хороший пример того, что мы просто разработали функционал. Что любое ведомство, региональное, муниципальное, любого уровня, свою конкретную услугу в соответствии со своим конкретным регламентом сможет собрать самостоятельно и выпустить ее в прод практически без нашего участия, только с нашим авторским контролем. Мы говорим: «Мы готовы отдавать наши инструменты в массы, пользуйтесь». То же самое с нашей платежной функциональностью. Мы разработали API, к которому можно подключиться, с вас только отображение в личном кабинете, мы отдадим вам все, мы отдадим вам платежки, мы отдадим вам начисления, мы дадим вам возможность, используя нашу платежную функциональность, оплачивать это на вашем портале. Пользуйтесь абсолютно бесплатно. Наши решения тиражируемы и уходят в массы.
Какие боли остаются нерешенными?
Мне кажется, очень важно правильно определить объект управления, и под этот объект подобрать правильные инструменты. В нашей практике за последний год были примеры, когда мы пытались управлять скоупом мастхэв разработок с точки зрения продуктового управления, и когда мы пытались управлять продуктом с позиции РПшника, когда нам надо уложиться в сроки и в скоуп. И то и другое приводит к одинаково нежелательным результатам. Это и есть залог нашего успеха. Там, где он есть, мы вроде правильно подобрали объект управления, поняли, кто этим объектом должен поуправлять и подобрали правильные инструменты. К сожалению, не везде так получается. Есть направления, есть команды, в которых product owner искренне считает себя человеком, который отвечает за скоуп и то, чтобы задачки людям раздать. Он использует для этого соответствующие инструменты, но почему-то результата такие команды достигают, не такого, какого хотелось бы от них ожидать. Как будто бы это и главный залог успеха, и главное пожелание нам самим себе в будущем.
Что касается болей, государственный аппарат все-таки пока очень сильно бюрократичен. Agile приходится модернизировать под него. Я очень люблю такую аналогию, что можно взять старый локомотив, поставить его на монорельсы и ждать, что он поедет со скоростью 200 километров в час. Он не поедет, пока вы его не модернизируете. Поэтому, чего бы я хотела, это чтобы бюрократии стало чуть меньше, чтобы законы можно было принимать чуть быстрее, чтобы не было директивного непонимания в некоторых органах, когда они принимают закон со сроком вступления завтра и говорят, что это должно быть завтра. К нам приходят и говорят, что вот это должно быть прямо сейчас и с этим ничего не поделать. Нам говорят: «У вас есть два месяца и тут хоть умрите, но сделайте». Приходится умирать и делать. А так не хочется, потому что результат получается некачественный. Это всё всегда должно быть в диалоге. Принятие любого закона, который влияет на IT-сферу, должно обсуждаться в том числе с IT-сферой. То же самое с банковской сферой. Мы должны меняться. Чтобы Agile заработал в госструктурах, госструктуры должны меняться в первую очередь, слушать IT-кластер, их советы и так далее. Проблемы с бюджетированием сейчас у всех. В этом нельзя не сознаться. Нам всем порезали бюджеты, и все наши большие планы иногда могут быть не реализованы, хотя очень хочется.
Я бы о такой боли около заключения госконтракта сказал. Сама процедура обоснования дополнительного финансирования и те методики, которые используются для их обоснования, в частности, расчеты по Росстату, ставкам, которые отличаются от действительности рынка, являются истинной болью многих IT-проектов в государственных органах. Этот барьер трудно преодолеть, ты долго согласовываешь, долго ходишь по стейкхолдерам для того, чтобы доказать, что этот проект важен для страны, тратишь кучу энергии для того, чтобы получить финансирование на новые задачи. Если бы эта процедура была упрощена и нас услышали, это в значительной степени ускорило инновации в госсекторе.
Когда госконтракт уже подготовлен, есть техническое задание, и здесь идет вопрос описания этой задачи, потому что оно должно быть написано так, чтобы было понятно, что сделать, но при этом, чтобы этот пункт госконтракта не раздувался до каких-то космических масштабов, потому что в зависимости от формулировки можно получить на выходе либо игрушечную машинку, либо космический корабль, а это будет одна и та же фраза. Поэтому здесь такая тонкая грань по подготовке госконтрактов. Когда есть уже готовый продукт, не нужно выделять финансирование на его развитие, это развитие должно быть в какой-то рамке. Рамке, на которую выделен бюджет.
Ко всему перечисленному, что касается нормативки, бюрократии, моментов, когда IT-сектор не хотят слушать и не понимают, почему, готовясь к контракту, подготавливая ТЗ, цена одна, а по факту, когда ты заключаешь контракт, понимаешь, что либо где-то что-то поменялось, и ты уже в эту цену либо не вписываешься, либо у тебя уже потребности другие. Но ко всему этому у нас еще одна такая боль. У меня конечный потребитель – это как гражданин, так и специалист, который дает функцию гражданину. И для меня боль – внедрить специалистам какую-то новую программу, потому что люди, с которыми мы работаем в регионах, во-первых, возрастные, поскольку у нас такое направление, в котором молодежи не так много присутствует, и когда взрослым людям приносят новую программу, проект, открывают перед ними систему и говорят, что им нужно здесь начинать работать, они просто сопротивляются. И вот это, конечно, один из таких моментов, которые тоже нужно продумывать на начальном этапе: как внедрять, как проводить обучение, как играть. Потому что этот протест, по крайней мере у меня, на нескольких регионах прямо виден.
Голубая мечта заказчика, у которого состоявшаяся информационная система – это играть только контракты на сопровождение, покупая объем команды и времени, тех ресурсов, которые ты можешь тратить на абсолютно любые задачи, ты никак не связан по рукам конкретными задачами развития.
Я как исполнитель остановлюсь на инструментах. Нам можно быть еще эффективнее, и эффективность, и гибкость надо наращивать. Неплохо бы нам друг к другу в гости поездить, потому что мы сидим на общих фреймворках, и есть куча команд, куча продуктов, проектов, которые так или иначе пересекаются. Мне кажется, переопыление опытом будет тоже хорошей практикой. Это то, что тоже пока не получилось. И сапожник без сапог. Мы IT-компания, но проектное управление у нас не автоматизировано. Вернее, слабо автоматизировано. Поэтому я бы туда очень сильно вложился. Это сильно повысит эффективность. У нас очень много цифровых следов, мы их собираем, у нас все неплохо оцифровано, но превратить это в интеллектуального помощника, натравить на это нейронки, чтобы они помогали администраторам проекта и так далее, подсвечивали что-то, помогали в операционной, рутинной деятельности. Это то, что хотелось бы сделать.
У меня недавно появилась такая идея, которую я озвучивал на похожей встрече, но в области информационной безопасности. Вообще в IT есть такое понятие open-source и понятие проприетарного продукта. И люди, которые создают open-source, как правило, в своей мотивации имеют нематериальную ценность, которую они получают в результате своего труда. Как я уже говорил, я не закупщик, не юрист, но мне кажется, что сегодня продукты, созданные либо силами госкомпании, либо с применением государственного финансирования, достаточно сложно просто открыть и отдать всем на общее пользование. Мне кажется, очень позитивная динамика наблюдалась бы, если бы именно полное раскрытие результатов проектов осуществлялось с точки зрения кода, тайм-трека этого проекта. И тогда эта open-source история, которая сегодня существует, и малыми итерациями в этих open-source продуктах иногда добавляются фишки, которые создают вообще отдельную ветку развития продукта, она была бы возможна и в нашем случае. Пусть это будут персональные права, которые при проприетарном использовании будут оплачиваться тем, кто участвовал в этой разработке. На сегодняшний день это все реализуемо через цифровой след, персональные профили. Но мне кажется, сократить количество финансирования можно через это. И нематериальную ценность получат очень многие, в том числе и в виде повышения своего социального статуса как разработчика значимых продуктов.
Чем мы не удовлетворены по результатам, если взять 2020 год и 2023 год, это тем, что приходится задавать заказчику те функциональности, которые ему не нужны, умудряться слепить их из того, что было, чтобы они соответствовали требованиям никому ненужного технического задания. Это трата ресурсов и нервной системы на никому ненужную деятельность. Это то, что не удовлетворяет совсем. И это выжигает очень немалый кусок ресурсов под проекты. Коллеги тут подняли вопрос как раз о том, что можно из строчки в ТЗ сделать и детскую лопатку и супер-экскаватор. И у нас нет практики в государственных системах изложения постановки технического задания в наборах user stories. Вообще нет такой практики. И поэтому формулировки, максимально приближенные к реальности, особенно в открытых конкурсах иногда ставят в тупик, потому что я сразу себе вижу, как технарь, тяжелый паровоз, а заказчик видел маленькую сопелку. И третье, что меня убивает, как в коммерческом рынке, но в большей степени в государственном, это то, что проводи ты бизнес-заказчику промежуточные показы, не проводи, пока он не принимает систему, он туда не вкладывается и глубоко не заныривает. Поэтому вся наша работа как команды начинается, когда? При вводе в промышленную эксплуатацию, которую я в 2020-м году, приходя на Agile, особо не рассчитывал. Согласитесь, Waterfall: раз cдали, соответствует пункту? Соответствует. Испытание прошло? Прошло. Молодцы. А сейчас оказывается «Ну-ка, ребята, подождите, работать-то неудобно», а мы ведь в Agile, мы слушаем, это финальный показ, и там можно сколько угодно показывать репетицию спектакля зрителями, но пока труппа не вышла на сцену, спектакль не сдан заказчику. Вот эта вот часть меня, конечно, очень сильно убивает.
И как звучит призыв ко вселенной?
Призыв ко вселенной звучит очень просто. Вот тут как раз и вопрос субъектности-объектности поднимался очень уместно, да? Вопрос субъектности руководителя проекта, стороны заказчика. Это должен быть субъект, который имеет права, полномочия и мотивацию слегка поддавливать на бизнес пользователя и отвечать за результаты их проработки. Согласитесь, мне как подрядчику несколько экономически неоправданно нести на себе риск того, что РПЗ оказался слишком мягкий, и те ему говорят: «О, знаете, а тут сделали не то». Но вы же смотрели. Ну и что, что смотрели? Мы несем за это никакой ответственности. За это несу ответственность я. Вот мой призыв.
Какие формулировки пишете в контракте? Откуда берется прогноз? И откуда берется уверенность в этом прогнозе?
Чтобы понять, что за формулировки написаны в постановке, нужно разговаривать. Большой вопрос, есть ли возможность поговорить с человеком, который субъектен. Когда он есть, когда есть такая возможность, очень часто государственный заказчик говорит: «ребята, мы вас приглашаем поучаствовать в конкурсе. Вот документация, предварительно хотим посмотреть вашу систему, а вы имеете возможность задать вопросы по техническому заданию». Вот это хорошо. Если готовиться нормально, с точки зрения подрядчика, то тогда список этих вопросов, что является лошадкой, что скаковым конем, они становятся шорт-листом. Их можно задать, и, если представитель субъектен, он на них ответит. К сожалению, так бывает далеко не всегда. Чтобы на эти вопросы дали честный ответ, это бывает в 5% случаев. И тогда мы участвуем в конкурсе. Если я этих вопросов не получил, я по всем понятным причинам в конкурсе не участвую, незачем.
Я в своем опыте применяю один подход. Результат нужно посмотреть. И доверие команде возникает тогда, когда есть референс. Лучше, если этих референсов несколько. Соответственно, формулировки, которые я буду применять в контракте будут всецело коррелировать с тем, что я увидел в конкретных решениях, которые делал исполнитель.
Если касаться формулировок, то было бы очень неплохо, если бы заказчик после выигранного конкурса мог скорректировать ТЗ. Потому что в процессе обследования новых изменений появились новые данные, и чтобы заказчик мог их скорректировать, мне кажется, это самый гуманный путь, потому что подрядчик либо убеждает в этом заказчика, либо нет. Но мне кажется, это был бы хороший ход.
Если привести конкретный пример, наша формулировка в контракте о том, что система должна содержать модули аналитики и статистики. Всё. Вы все понимаете, к чему быть готовыми. Мы приходим к тому, что и заказчик, и подрядчик, мы выходим на госконтракт, естественно, когда приближаемся к ЧТЗ, как мы решаем? Мы садимся и говорим, что аналитика и отчетность не должны быть данными, которые будут заливаться в Excel таблички. Давайте мы это будем решать. Покажите, какое у вас есть решение. Я думаю, что сейчас мы уже приходим к тому времени, когда результатам хотят остаться довольны, как и заказчик, так и исполнители. Поэтому находится решение, которое всех устраивает.
Если говорить про формулировки, заказчик у нас очень большой. Я выступаю от имени всего ГНИВЦа, а не конкретного проекта, могу сказать, что формулировки очень разные. Бывает детально написано до запятой, что нужно сделать, и это тоже бывает иногда плохо. Бывает очень размыто. Все зависит от команды и как мы договариваемся. Здесь проблема даже не в этом, на самом деле. Проблема в том, что аппетит растет во время еды. Госконтракт заключен, есть у нас пункт, мы начинаем обсуждать, и он вырастает в какого-то необъятного монстра. А под него, условно говоря, запланировано три человека. Мы здесь пытаемся управлять ожиданиями заказчика и не расстроить его очень сильно, что «Нет, мы не будем это делать». У нас большое количество продуктов. У нас есть буферные разработчики, в том числе, которых мы можем либо перераспределить с каких-то систем, где мы видим, что там не такая сейчас большая загрузка, для того чтобы усилить ту команду, которая сейчас нуждается в сотрудниках. Плюс, у нас идет годовое планирование, которое потом каждый квартал стараемся как-то балансировать, стараемся таким образом управлять ожиданиями.
По формулировкам. Могу сказать, что у нас был опыт написания размытых формулировок, когда заказываешь какую-то аналитику и подсистему отчетности. Это тоже плохая сторона. Был и второй абсолютно полярный опыт в том, когда ты прописываешь все до запятой, и потом исполнитель не может это сдать, а тебе уже и не нужно это в таком виде, как ты заказывал, потому что видение продукта поменялось. На самом деле сегодня наши формулировки – это примерно баланс между размытыми формулировками. В первую очередь могу только одно посоветовать. Не пишите исполнителю, как ему это сделать. Пишите, что вы хотите получить в результате. Ни в коем случае не ограничивайте его возможности принести вам этот результат.
Нам, наверное, проще, потому что у нас рамочный контракт. Мы не думаем о формулировках, потому что знаем, что у нас есть контракт, где есть кубики. Мы думаем о том, как спланируем на квартал, какие у нас ресурсы команды, что встраивается, что не встраивается. Я приношу на планирование определенный пул задач, и вместе с командой у меня идет мозговой штурм. Вот осталось, например, 3 миллиона. Есть задачка на 6. Я говорю, что в этой задачке у меня главная боль вот эта. Давайте вместе подумаем, как нам малой кровью решить эту боль, а все бантики, которые к этой боли потом нужно будет навязать, мы подумаем и сделаем тогда, когда у нас появятся на это ресурсы. Не знаю, насколько 44-й сейчас позволяет заключать рамочные контракты на развитие IT. Насколько я знаю, позволяет. Не позволяет? Это печально, потому что, когда я работала в Казначействе, все шло именно к этому, потому что это логично. В принципе, рамочные контракты должны распространяться на любые товары. Но тут надо с этой болью идти к регулятору, к Казначейству.
В формочке, которую мы делаем на квартальную задачку, есть несколько пунктов. Одни из них функциональные требования: «Что мы хотим получить на выходе? Как мы вообще поймем, что эта штука работает?» И нефункциональные требования. Каждый может сам примерно предположить, какой процент этих пунктов реально заполняется, а какой – прочерк рисуют и всё. Опять же, немного спасает то, что у нас действительно рамочный контракт на развитие текущего портала. И мы понимаем и нефункциональные требования, которые к абсолютному большинству тех функциональностей, которые мы развиваем, предъявляются примерно одни и те же. Если бы они там были чуть-чуть другие, то было бы грустно. А так вроде бы живем. Но на Enterprise Agile Russia в прошлом году Виктор Николаевич как раз рассказывал про прекрасную систему «Статус», которая позволяет нам и командам понимать, а сколько в них примерно входит, и должна защищать их от переполнения. И примерно 50 на 50 у нас распределяется ситуаций, когда команда берет на себя больше, чем она может сделать. В половине случаев это потому, что заказчик в нее ножками вталкивает задачи, говорит: «Ничего не знаю, должно быть сделано». А во второй половине случаев команда говорит: «Мы видим, что мы не сможем, но мы в себя очень верим». Я говорю: «Ребята, правда же, в прошлый раз не получилось». Они такие: «В прошлый раз были риски, которые мы не учли, сейчас мы все учтём». Чаще всего, конечно, тоже не справляются. Запретить людям сбрасываться со скалы нельзя, но мы пытаемся их отговаривать.
У нас есть еще такой классный инструмент в рамках планирования – это гипотеза о выгоде. Мы приходим и говорим: «А классно бы было сделать вот это, вот такую вот услугу вывести на портал». «Хорошо, а сколько человек в год такую услугу получает?» 10 тысяч, а у нас на портале 100 миллионов человек. Будем ли мы тратить 10 миллионов рублей ради 10 тысяч человек или все-таки пока эти 10 тысяч человек походят в МФЦ ножками? То есть баланс тут должен быть, потому что каждую задачу, которую мы в итоге возьмем в квартал, нужно защитить у министра и доказать ему, что это действительно то, на что нужно потратить деньги. И не с точки зрения «Это прописано в законе», а именно с точки зрения конечной её ценности. Потому что «Это написано в законе» для него точно не аргумент, потому что он министр цифровизации, а не министр юстиции.
Сколько сотрудников в описываемых контурах?
Вскрываем карты. Сколько у кого людей работает?
По последним данным – 2500.
У меня маленький кусочек от этих 2500. Всего 15 человек на моём маленьком проекте.
Если говорить про все проекты ФНС, то это, наверное, 2 тыс. человек: 1 тыс. в ГНИВЦе и 1 тыс. в ФНС. Если мы говорим про отдельно взятый проект, про который мы сегодня рассказывали, то это порядка 20 человек у заказчика и 100-130 человек на стороне исполнителя по крупной государственной системе.
Всё верно. Полторы тысячи уже, просто устаревшая информация по нашему набору. Мы очень быстро растем последнее время. Так и получается, что любой прям крупный enterprise проект, тот же ЕНС, это такой же порядок участников. Это 130 человек и где-то порядка 30 от ФНС.
А резерв, про который ты говорила: «если надо, то есть свободные руки». Это примерно сколько человек?
Все зависит от ситуации.
От того, насколько надо?
Насколько надо, да. И вопрос еще качества резерва, и кто пострадает. Опять же, если задача «умри, но сделай», мы вытащим весь доступный…
То есть это не пожарные команды там лежат в гамаках.
Пожарные команды мы вот как раз таки начали в начале года выстраивать. Разделили всех на определенное вовлечение в продукт. Тот, кого вообще нельзя никак оттуда исключить, иначе сразу продукт развалится. Кто может быть переиспользован. То есть мы с начала года занимаемся этими упражнениями.
Дай бог людям в отпуск ходить хоть когда-нибудь. Спасибо большое. Передавай. Так, вставка. Ну сколько там человек? Сколько сказали, кто помнит? Дим, ты помнишь, сколько на вас? 15 человек у них что ли.
Да откуда я знаю. Самоорганизация же. На PI мы выезжаем, на PI-планировании у нас зал и 150 мониторов. То есть, если говорить в компании, там 220-250. Это живая компания. Поэтому на PI-планирование примерно 150 человек. А на этом проекте работают разные команды в разное время. Где-то админы подключались и так далее. Где-то до 50 человек доходило, это из разных команд. У нас же это продукты разные и так далее. Здесь очень комплексный проект.
Постоянно в проекте на стороне заказчика я был один. Привлекали двух-трех специалистов, которые задействованы не всегда даже на фулл-тайм были, под конкретные задачи. То есть накатываем релиз – DevOps привлекли, нужна интеграция с 1С – поставили задачу, 1С-ники сделали.
С нашей стороны в первом спринте участвовало два человека, они оба здесь. Значит, в прыжке, это где-то в середине проекта, участвовало 12 человек. То есть, грубо говоря, из которых 5 было ключевых на всем проекте. Но тут надо понимать, что мы разрабатываем на лоу-код платформе. То есть мы экономим массу ресурсов на хардкоде, которая за нас сделала ELMA до. Поэтому нас так мало.
Вопросы. Как внедрять Agile-подходы при маленьком штате? И сколько ролей должны представлять заказчика?
Штука не в том, сколько у вас людей. Штука в том, на чем вы работаете. Тут как раз одна из болей предложений и проблем с появлением ГосТеха. По большому счету вход остальных коммерческих платформ в государственный сектор закрыт. Не может лоу-код платформа, условно ELMA или какая-то другая, зайти в госсектор, потому что там есть уже ГосТех как платформа. Но вот для маленьких команд нужно, чтобы они разрабатывали на платформе. Маленькая команда целую систему с нуля от архитектуры, заканчивая готовым решением, не создаст, и даже иллюзии не надо строить. Я согласен с оценками коллег, которые говорят 200 человек на крупный проект. Я сам участвовал в проектах, в которых было 300 плюс только на нашей стороне. Поэтому тут вот вопрос применения ноу-код и лоу-код систем. Но насколько они будут допущены в госсектор, это вопрос уже даже не к ДИТам, и тем более не к региональным органам исполнительной власти и тем более уж не к муниципалитетам. Это вопрос к Минцифре. Если тут создание конкурентной среды в лоу-код системы в госуправлении.
Что я знаю про Agile, Scrum-методология как раз предполагает, что у вас нет выделенных экспертов по каждому вопросу, который решает команда. И тем, кто не является глубоким экспертом в конкретной отдельной области, приходится иногда переключаться на смежную область. Суть в том, что задачу и спринт решает вся команда. Иногда приходится делать несвойственные для себя вещи или залезать в области, в которых ты не являешься экспертом. Это как раз история про маленькие команды. На сегодняшний день, когда я с HR-ами общаюсь по подбору персонала IT, я начинаю им перечислять, какие есть особенности у айтишников, которых надо принимать, и у меня возникает аналогия с врачами. Есть врач общей практики, а есть врач конкретный по специализации. Так вот, с IT примерно так же. Scrum, если его применять правильно, позволяет как раз научить офтальмолога немножко понимать в хирургии. Вы не получите офигенный результат DevOps-а, если его делает Windows-администратор. Но результат получите, и это не будет вас сдерживать.
Тут всплывает вопрос, как привлекать на бюджеты в регионы высокомотивированных самостоятельных профессионалов?
Мне кажется, вот наша пара как раз, или наша тройка – ответ. У нас функциональный заказчик выступал с презентацией, это была Инга. Как раз лидер проекта, менеджер проекта – Дарья, и она полностью его сопровождает и ведет. Я как исполнитель, поэтому вот ответ.
Тройка. Ну и давай уж реабилитируем тоже людей, которым не хватило кресла на сцене, в зале сидит Ольга. Как у вас распределяется? Смотрите, последний вопрос. У вас тройка? Но тут запрос был на второго человека от заказчика.
Да. Это одна из мыслей, с которой я шел на сегодняшнее мероприятие. Мне кажется, на сегодняшний день при создании продукта вопрос функционального заказчика становится очень сложным. Потому что внутри продукта множество процессов. Владельцев данных очень много. Кто будет потребителем продукта, тоже очень много. И образ этого потребителя продукта очень многогранный. Поэтому функциональный заказчик скорее всего какой-то сборный персонаж. Его в одном лице, как правило, нет.
Возвращаясь к тому, что тут сила руководителя проекта со стороны заказчика очень важна. Потому что он объединяет достаточно аморфную сущность, как функциональный заказчик. Нет такого должностного лица у заказчика, который готов сказать, что знает все процессы на всех уровнях. Поговорить с человеком, который знает процессы в зоне своей ответственности можно. Он даже немножко имеет представление о смежных. Но немножко. Со всеми не переговоришь. Тут как раз роль РПЗ очень велика.
При желании всегда можно найти какие-то нюансы. А по поводу пары, а не тройки, функциональный заказчик размыт. Потому что, да, есть функциональный заказчик, а есть человек, который отвечает за конечный результат по проекту. Он может быть не погружен во все функциональные области. Но когда мы говорим про периметр сотрудников 100-130 человек, это от 7 до 12 команд. И у каждой команды есть свой ответственный, тимлид, руководитель проекта, неважно как его назови. И у функционального заказчика есть такой же ответственный человек по своей области. Но все равно аккумулировать должен кто-то один, иначе все расползутся и ничего из этого в результате не получится.
Мне кажется, это какой-то философский больше спор относительно терминологии, которую мы используем. Условно говоря, я сегодня представитель функционального заказчика, я формирую ТЗ, отдаю его техническому заказчику, который ничего кроме самой процедуры как таковой не обеспечивает. Он отыгрывает контракт, его заключает, организует приемку. Все остальное лежит на мне как на функциональном заказчике. Да, проекты большие и у нас есть делегирование полномочий. Я не равен product owner в данном случае. Условно, у меня там роль директора проекта. Моя задача -управлять бюджетом и управлять рисками проекта и того, что он идет в нужном векторе направления. Есть product owner, который в единоличном виде моего зама принимает решение о том, брать ли эту доработку в спринт, делать ли эту функциональность или не делать. Да, некоторые вопросы эскалируются. Это простые вопросы управления. Они здесь не новы. Мне кажется, здесь не надо цепляться за слова, сколько людей должно быть, а все-таки выступать за результат, как его достичь. Это может делать один человек и несколько на больших проектах.
Что касается гибких контрактов в регионах. Как я уже говорила, первое, это платформа ГосТех и все наши масштабируемые решения. К этому нужно подключаться, в это нужно вникать. И на базе ГосТеха сейчас планируется делать очень много масштабируемых продуктов. Второе, если есть какой-то проект, который в сфере и в поле заинтересованности Минцифры, мы всегда даем субсидии. Например, когда мы внедряли оплату по QR-кодам в МФЦ, мы были готовы регионам дать субсидии. Они не взяли. Странно, да? Хотя жалуются на то, что у них проблемы с бюджетом. Дальше. Как уже говорили, здесь Agile – это не обязательно про большие команды. То есть мы говорили о том, что мы внедряем итеративность, в том числе в нормативку. Ешьте слона по частям, определите ваши главные боли, решите сначала их, потом дорабатывайтесь дальше. То есть нужно грамотно подходить к тому бюджету, который у вас есть, и планировать вашу работу исходя из того, что вы можете сделать прямо сейчас и должны сделать прямо сейчас, а что можно доделать потом. То есть три рецепта.
Андрей, есть у тебя рецепт? Добавить что-то к сказанному Алёной? Когда у вас мало людей, что делать с гибкими госконтрактами?
Да, давай. Добавлю голос Agile-коуча, можно взять любого из авторов Agile манифеста, выбрать тот фреймворк, который он принес на это собрание и предложил в качестве хорошего, работающего инструмента и понять, что он скорее всего на 5-12 человек рассчитан, как раз очень хорошо работает с ограниченными ресурсами и ограниченным бюджетом. Прямо идеально.
Вопрос вашей паре. Алёна, ты себя кем, функциональным заказчиком ощущаешь или больше руководителем проекта?
Я руководитель проекта, у нас функциональный заказчик очень сильно размыт. То есть в зависимости от того, какой из блоков госуслуг вы анализируете, там абсолютно разный функциональный заказчик. Это и регионы, это и ФОИВы, это органы власти, то есть у нас вообще нет в единственном лице функционального заказчика. Я у себя и директор, и владелец продукта. Я у себя одна на проекте с точки зрения заказчика, а функциональные заказчики у меня люди, которые платят, банки и те, с кем я взаимодействую в рамках внедрения своего конкретного сервиса. Поэтому их всех сюда точно не уместить.
Спасибо большое. Зато посмотрите, как себя чувствует, должно быть, Ник сейчас. Восемь высокооплачиваемых, авторитетных людей сидят и уговаривают: «Попробуй, давай у тебя получится». И я тоже присоединяюсь к пожеланиям успеха в этой борьбе. Если что, ну пишите конкретные кейсы, мы попробуем помочь. Главный рецепт – начать делать.
Вопросы экспертов друг другу?
У меня предложение, к спикерам: взять второй микрофон и задать вопросы друг другу. Алёна, хочешь ли ты при свидетелях что-то спросить у присутствующих?
Мы очень плотно взаимодействуем с коллегами из ФНС, у меня очень много даже друзей в ГНИВЦе, поэтому мы с ними всегда в диалоге.
Мне кажется, нет. Мне кажется, мы все уже несколько раз ответили на все вопросы.
Я хочу поблагодарить и отметить успехи Минцифры. То, с какой активностью и с каким темпом ребята проявляют тягу на вытягивание технологии сегодня у нас в России. Мне кажется, это заслуживает отдельных аплодисментов, потому что это тот двигатель, который позволяет хотя бы задуматься, даже тем, кто сегодня не готов, что это есть, нам к этому надо будет прийти. Моя благодарность, она связана с последним вопросом. Я в 2011 году точно также приехал из Ижевска в Питер на белые ночи и задавал вопрос, когда мне рассказывали, что скоро интернет будет из розетки. Я говорю: «Ребята, да вы что, вы там съездите к нам, у нас там сотовая связь еще не везде берет». Сотовая связь до сих пор не везде берет, да, а интернет из розетки уже есть. К тебе уже либо в квартиру, в которую ты заезжаешь, есть разведенные провода с сетью, либо провайдер к тебе приходит, сам ставит роутер, у тебя появляется чудесным образом вай-фай и тебе ничего не надо знать ни про модель роутера, ни про его пин-код и его настройки. Поэтому, я думаю, то, что делают коллеги из Минцифры, приведет ровно к этому же, что у нас появится и цифровое пространство, и цифровые сервисы, и собственные технологии. Даже если мы к этому еще сегодня не готовы, это кажется слишком амбициозным.
Так жизнь сложилась, что я из числа присутствующих знаю или людей, или проекты, причем не пересекающиеся. Поэтому присоединяюсь к Алексею и что хочу сказать. Мы все знаем в IT прекрасный постулат: если у тебя что-то уже чуть-чуть есть, но еще хорошо не работает, надо об этом говорить. И здорово, что мы поднимаем этот вопрос, хотя я думаю, что никто не живет в иллюзиях, что в рамках 44-го закона Agile возможен. Невозможен. В рамках 223-го плюс-минус, раньше тоже мобильной связи не было, и ничего. Это когда-то будет. Вот этот разговор должен быть бы поднят, потому что без него никогда не будет точно. Тут все просто. А как мы все понимаем, самый большой стопор развития государственных систем – это именно 44-й закон. И ничто, и никто другое. Поэтому его модернизация под современные реалии – это, наверное, самый актуальный вопрос. И он не будет решен без сегодняшней дискуссии. Поэтому всем коллегам огромное спасибо.
Напутствия экспертов для аудитории
Все вот эти методологии на самом деле не догмы. Это лишь фреймворки для того, чтобы подумать, и чтобы их применить к своим условиям наиболее, наверное, разумным способом. Поэтому дерзайте, ищите и обрящете.
Прежде чем что-то делать, всем рекомендую посмотреть, что уже сделано.
Я, наверное, хочу обратиться к региональным айтишникам. Сегодня были там боли. На самом деле болей у них действительно много. И, конечно, политика, которая сейчас в области информатизации высасывает все ресурсы из регионов, вместо того чтобы наращивать там компетенции, развивать тот же самый Agile. Поэтому я хочу вам пожелать любви к своему краю, развитию своего края, любви к своим гражданам. И делайте, пожалуйста, то, что вы делаете. Спасибо.
Я хочу пожелать, чтобы больше было мероприятий там, где люди могут делиться опытом, и все камни преткновения, чтобы они вот так обсуждались, потому что потом зазнакомившись, мы понимаем, общаясь, что мы можем ускорить, что мы можем обойти, что мы можем улучшить. Поэтому участвуйте, участвуйте, делитесь, и самые сложные моменты можно будет таким образом сдвигать.
Мне хочется пожелать не бояться падать, потому что можно встать, отряхнуться, понять, почему ты упал, и идти дальше, потому что все боятся совершения ошибок, а на ошибках мы, наоборот, дальше растем. То есть никакие изменения невозможны без ошибок.
Я бы, наверное, всем посоветовал браться и делать, а не рассуждать о том, как это сложно, и искать отговорки от того, почему бы это не сделать. И отдельную хотелось бы благодарность организаторам за предоставление этой площадки выразить. Большое спасибо вам за то, что пригласили и дали возможность высказаться по актуальным проблемам.
Я хотела сказать, что можно знать очень много красивых умных слов. Scrum, Agile, SAFe, Kanban и так далее, но если ты не любишь то, что ты делаешь, если ты не болеешь за то, что ты делаешь, у тебя не получится, какую бы методику ты ни использовал. Поэтому просто рекомендую всем заниматься тем, что они любят, и болеть за свое дело.
Самое главное, с чем нельзя не согласиться, это и правда «дорогу осилит идущий», мы, если все вместе понимаем, что есть какая-то проблемка, наверное, надо эту проблемку начинать решать. Да, не получится с первого раза, не получится со второго, может быть, получится вообще не у вас, главное, что проблема будет решена. Поэтому пытайтесь, ищите возможности. Я не могу вас в этом уверять, но вся моя жизнь, она может быть не длинная, может быть странная, но она меня уверила в одном: в нашей стране очень много классных людей, которые готовы вам помочь, которые откликнутся на ваши предложения. Надо просто суметь с ними встретиться. Я думаю, что все будет хорошо.
