Журнал

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

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

Мы разрабатывали несколько крупных государственных систем, а еще больше не разрабатывали именно по этим причинам. Начнем!)

Проблема 1: Отсутствие проектирования

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

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

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

Плохой пример

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

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

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

Вывод:

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

Божественная интеграция:

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

Реальная статистика

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

Как подготовиться к проектированию

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

Конечно, это не исчерпывающий список, но давайте начнем хоть с чего-то.

Проблема 2: Изменение требований и размытие ответственности

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

Пример из нашей практики

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

В общей сложности, сменилось порядка 20ти! ответственных. Каждый со своими супер решениями.

- "Я здесь решаю!"

Босс боссов (директор департамента на одной из встреч)

Две переделки, увеличение срока в 2 раза, увеличение бюджета в 1,5 раза после проработки процесса с главным спецом. И это был только один процесс.

Решения

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

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

Проблема 3: Размытые запросы и фиксированные бюджеты - разные пути реализации проектов

В государственном секторе Казахстана, как и во многих других странах, процедура закупки и оценки коммерческих предложений для IT-проектов часто сталкивается с фундаментальными трудностями. Эти проблемы начинаются ещё на этапе запроса предложений, когда задачи формулируются нечетко, а бюджеты фиксируются заранее без глубокого понимания реальной сложности или объема необходимых работ.

"Здравствуйте! Нам необходима система для приема заявок со всего Казахстана. Это республиканский проект. Вышлите коммерческое предложение до 18:00."

Какое-нибудь министерство всего

Запросы, примерно такого содержания, мы периодически получаем от различных государственных структур. Чаще всего, “девочка” на той стороне, даже не знает, какая цель будущей системы.

Оценить такое тоже вполне можно, но обычно вилка от десяти миллионов до десяти миллиардов никого не устраивает.

Фиксированные бюджеты, устанавливаемые заранее, дополнительно усложняют ситуацию. Когда бюджет проекта определен без учета детальной проработки задач и потребностей, IT-компании вынуждены либо недооценивать объем работ для соответствия бюджету (“рубить” функционал), либо перерасходовать ресурсы, чтобы выполнить все требования заказчика.

Два основных подхода к реализации проектов

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

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

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

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

Заключение

Казахстан - один из лидеров цифровизации государственного сектора и мы действительно сделали огромнейшие успехи в этом. Мы лишь пытаемся еще увеличить эти успехи, подсвечивая ключевые проблемы. Я уверен, что реальная оценка эффективности покажет, что объема ресурсов вложенных в нашу “цифру” хватило бы на сильно большее количество качественных систем.

А для этого, нужно всего лишь заказывать разработку у нас!)