Через бюрократию к «цифре» или как готовиться к разработке IT-систем в госсекторе

Привет, я Максим из Sailet. Мы специализируемся на заказной разработке, работаем с 2017 года, выполнили множество интересных проектов, рассказываем про автоматизацию и развиваем свой СЭД.
Мы разрабатывали несколько крупных государственных систем, а еще больше не разрабатывали именно по этим причинам. Начнем!)

Проектирование — фундаментальный процесс, который определяет структуру и функциональность будущей системы. Отсутствие глубокой проработки на этапе проектирования часто ведет к ошибкам, которые сложно и/или дорого исправлять в будущем. Это не ТЗ на 150 страниц, в котором описано, что «система должна быть функциональной и масштабируемой». Это формирование детального и конкретного результата работы системы и понимание этого результата всеми участниками процесса.


Почему это важно:

• Четкое понимание всех аспектов проекта помогает избежать неожиданных проблем в процессе разработки и внедрения.
• Позволяет оптимизировать расходы и сократить время на разработку за счет минимизации необходимости вносить изменения после начала работ.
• Не создаются ложные ожидания на старте проекта и не разрабатывается лишний функционал, который впоследствии переделывается или исключается.

Проект Healthcare.gov, федеральный веб-сайт, разработанный для реализации Акта о доступном медицинском обслуживании (ACA) в США, столкнулся с серьёзными проблемами сразу после запуска в октябре 2013 года. Несмотря на первоначальный бюджет в 93,7 миллиона долларов, к моменту запуска затраты превысили 200 миллионов долларов, а общие расходы в конечном итоге достигли приблизительно 1,7 миллиарда долларов.


Основные проблемы проекта включали:

1. Сайт не был адекватно протестирован перед запуском, что привело к многочисленным техническим сбоям, включая перегрузки серверов и ошибки в программном обеспечении. На пике нагрузки сайт не смог обработать большое количество пользователей, что стало одной из причин его отказа.
2. Healthcare.gov требовалось интегрировать данные из различных федеральных баз данных, включая базы данных IRS, SSA и DHS. Недостаток опыта и плохое управление проектом привели к тому, что эта задача была выполнена неудачно.
3. Проект характеризовался частыми изменениями в требованиях и спецификациях, что создавало дополнительные сложности в разработке и внедрении системы.

Вывод:

Многие из проблем Healthcare.gov могли быть предотвращены, если бы были соблюдены основные принципы управления проектами и технологической разработки.

Первый шаг в правильной разработке это получение качественной структуры будущего проекта от крутых специалистов (это мы, если что). Поэтому, заполняйте форму, получайте бесплатную консультацию и видение вашего будущего продукта. Делаем не всем, только после квалификации.

Согласно исследованиям, проведенным IBM, проекты, в которых не проведено должное проектирование, в 75% случаев сталкиваются с серьезными проблемами при запуске, включая перерасход бюджета и несоответствие заявленным требованиям (Источник: IBM Global Software Survey 2020). Другое исследование от McKinsey показало, что тщательное планирование и проектирование могут сократить общие затраты на разработку на 20−30% (Источник: McKinsey & Company report, «IT project failures: Lessons learned and best practices»).

Одна из наиболее сложных задач в управлении проектами — это управление изменениями требований после начала разработки. Другими словами, корреляция между увеличением срока и бюджета и «хотелками» чаще всего напрочь отсутствует. При этом, всегда появляется кто-то главнее со своими «вот эту кнопку надо убрать, а этот текст выделить жирным», пока не придет единственный специалист на котором этот процесс держится. Только он погружен в предметную область и реально может сказать, что необходимо. Но, конечно же, он не возьмет на себя ответственность, потому что завтра ему вручат выговор/уволят/посадят и т. д. Негоже начальникам перечить. Поэтому, превращается это все в аттракцион: сначала необходимо каждому «самому главному» донести зачем, защитить, объяснить, что это «кнопка», это основная функция системы, что каждое «хочу» стоит денег и только потом работать.

Проект, который изначально был оценен в 4 месяца разработки и 1 месяц внедрения делался 9 месяцев с завершением на 40% от изначального плана. 40% фактически это MVP, которое закрыло основной процесс. Вы думаете, что мы промазали с оценкой, плохо написали ТЗ, собрали требования, неверно определили ответственных, недоработали? И вообще не бывает же виновата одна сторона, верно? Положа руку на сердце, наша основная ошибка была в том, что мы поздно начали говорить нет, пересматривать условия и инициировать расторжение.

В общей сложности, сменилось порядка 20ти! ответственных. Каждый со своими супер решениями. «Я здесь решаю!" — Сказал руководитель департамента на встрече. Две переделки, увеличение срока в 2 раза, увеличение бюджета в 1,5 раза после проработки процесса с главным спецом. И это был только один процесс.


Решения

• Установите процесс управления изменениями с чёткими правилами внесения любых корректировок в проект. Все изменения должны проходить через формализованный процесс утверждения.
• Внедрите систему отслеживания изменений, чтобы каждое из них было задокументировано и имело обоснование.
• Регулярно проводите тренинги и семинары для всех заинтересованных сторон проекта, чтобы у всех было единое понимание целей и задач.
• Делайте онбординг для новых членов команды и не пускайте их, пока не разберутся, чтобы минимизировать риски, связанные с непониманием проекта.
• Разработайте комплексную систему документации, которая будет включать всю историю проекта, от исходных данных до любых изменений в проекте.
• Используйте инструменты и платформы для совместной работы, которые позволяют всем участникам проекта иметь доступ к актуальной информации в реальном времени.

На одном из вебинаров «С чего начать автоматизацию?», я рассказывал, что конкретный ответственный со стороны заказчика это обязательный человек в любом проекте. В среднем, ответственный тратит от 10 до 20% от времени подрядчика. Он должен вести процесс с вашей стороны с учетом всех «артефактов», необходимых вашему бизнесу.

• Исследовательский подход

Используется, когда задача новая или не имеет чётких границ. Заказчики предоставляют общие вводные данные и просят подрядчика изучить проблему и предложить решение. Такой подход позволяет гибко подходить к определению требований и разработке системы, однако точный бюджет в таком случае сложно/невозможно спланировать изначально.


• Подход с фиксированными требованиями и бюджетом

В этом случае заказчик предоставляет подробное ТЗ с четко описанными задачами и функциями, которые должна выполнить система, а также строго определенный бюджет. При этом, погружает подрядчика в РЕАЛЬНЫЕ процессы, контекст и только после этого получает РЕАЛЬНУЮ оценку. Это требует от заказчика более тщательной подготовки и детальной проработки всех аспектов проекта заранее. Так можно уменьшить риски непредвиденных расходов и задержек, но вложить кратно больше усилий на начальной стадии проекта.