Как создать крутой ИТ продукт для государства

9 июля 2021, 16:21

Украина взяла курс на цифровизацию: отдельное министерство, регулярные релизы цифровых государственных сервисов, признание электронных документов. И это начало. Новые идеи требуют внедрения, а это — огромный рынок ИТ-услуг.

Итак, как государственные учреждения приобретают новые ИТ-сервисы? Спойлер: непросто.

Новый ИТ-продукт для государства. Где взять?

Если вы хотите новый ИТ-продукт, у вас есть три основных пути: купить один из имеющихся на рынке, разработать самостоятельно или заказать в профильной компании по вашим требованиям.

Видео дня

С первым все относительно просто: ищете нужное решение, оцениваете предложения и покупаете. При необходимости — вместе с настройкой. Такой путь подходит для стандартных продуктов (Е-коммуникации, CRM, ERP, другие сервисы широкого потребления). Когда же речь идет об уникальных сервисах — приходится или делать самим, или заказывать. Самостоятельная разработка имеет свои преимущества: появляется внутренняя экспертиза, можно быстро адаптироваться к изменениям, а любая задача берется в работу «здесь и сейчас». Но где взять собственную команду? Бороться за таланты приходится не только с украинскими компаниями, а и со всем миром.

Реалистичнее заказать новый ИТ-сервис у компаний, разрабатывающих программное обеспечение. Таких в Украине тысячи, само бизнес-направление существует десятки лет. Итак, что может пойти не так? На самом деле здесь есть всего два вопроса: что и как покупать? Здесь в игру вступает Закон «О публичных закупках».

Заложники стандартов

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

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

Что же нужно написать в техзадании? Существует много стандартов, когда можно использовать заранее разработанные формы документов. Это хорошо работает, например, в строительстве: все участники процесса, от архитектора до прораба, все равно читают типовые документы.

Но что делать, когда стандартов нет? Для ИТ-разработок, на бумаге существует 126 различных ДСТУ/ГОСТ, датированных от 1978 до 2009 годов. Представьте, новейшему стандарту уже 12 лет. И это в области, где подходы и технологии могут коренным образом меняться за год-два.

Гибкие решения

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

poster
Дайджест главных новостей
Бесплатная email-рассылка только лучших материалов от редакторов NV
Рассылка отправляется с понедельника по пятницу

Бизнес уже давно придумал решение для обоих ограничений. Это гибкие методологии разработки. В начале проекта фиксируется образ и ключевые цели. А что именно и как будет сделано, уточняется уже в ходе выполнения проекта. Фактически мы говорим, что «должно стать хорошо», но что мы вкладываем в это понятие и как этого достигать — решаем в процессе.

Гибкие методологии широко применяются уже десятилетия и доказали свою эффективность. Поэтому, почему бы не использовать подобный подход и в госсекторе? Все дело в закупке. Немного ранее мы говорили, что хороший тендер — это тендер с максимально четкими требованиями к предмету закупки. Но разработка по гибкой методологии по своему определению противоречит этому тезису. Заказчику, стремясь работать по гибкой методологии, будет просто нечего написать в техническое задание кроме видения и абстрактных целей. А если все же кто-то попытается, то в лучшем случае на такой тендер никто не придет, а в худшем — халатный подрядчик, пользуясь пустой документацией, заберет деньги, не сделав ничего.

Лайфхак от Прозорро.Продажи

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

Time and Material — это подход к формату проектов, когда заказчик покупает не результат, а процесс. В случае с ИТ-разработкой специфические материалы не нужны: достаточно купить время специалистов и разумно им воспользоваться.

Этот подход имеет три важных ограничения. Во-первых, заказчик должен глубоко погружаться в процессы. Подписать контракт и просто дождаться результатов не получится: в команде заказчика должны быть люди, которые будут координировать работу исполнителя. Они будут определяться с приоритетами и следить за качеством результатов. Такая инвестиция времени себя оправдывает: команда заказчика получает лучший результат и экспертизу для вновь созданного продукта, что существенно продлевает срок его эксплуатации.

Второе ограничение — избыточное использование ресурсов. Вдруг вдруг заказчик получит счет на количество часов вдвое больше запланированного? Такая ситуация — вполне реальный риск, с которым сталкивается и бизнес. Здесь помогут гибкие методологии.

Для ИТ-разработок, на бумаге существует 126 различных ДСТУ/ГОСТ, датированных от 1978 до 2009

Мы взяли за основу методологию Scrum, адаптированную под реалии взаимодействия с подрядчиками. Практическая польза для нас, как заказчиков, в планировании работы. Исполнитель до начала работы оценивает в часах каждую отдельную задачу. Соответственно, перед каждым циклом разработки нас это — две недели) уже известно ориентировочное количество часов, которое мы планируем потратить. Условия договора, который заключает госпредприятие по результатам открытых закупок, исчерпывающе описывают процесс планирования, допустимую погрешность в оценке, последовательность работы над каждым заданием и тому подобное. Выдумывать это не пришлось. Классические документы Scrum дают всю необходимую информацию.

Еще одно ограничение — возможные злоупотребления. А вдруг исполнитель решит обмануть и скажет, что работа заняла 100 часов, хотя на самом деле на нее потратили только 10? Держать в штате специалистов, которые объективно оценят честность исполнителя, неэффективно. Альтернатива, которую мы практикуем — параллельная оценка одних и тех же задач разными исполнителями. Закон позволяет проводить несколько тендеров на закупку часов специалистов «по требованию» (когда у заказчика появляется потребность в использовании этих часов). После заключения двух или более подобных контрактов каждую задачу можно предоставлять для оценки всем законтрактованным исполнителям. Фактический заказ конце получит участник из лучшей оценкой. В целом такой подход напоминает рамочные закупки, а их комбинация с практиками Scrum позволяет эффективно управлять и процессом разработки, и результатом.

Показать ещё новости
Радіо NV
X