Программная инженерия и платформы в государственном секторе

Почему это важно: программная инженерия в государственном секторе

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

Напряжение, которому посвящена эта тема, носит структурный характер. Программное обеспечение по своей природе развивается итеративно: требования проясняются по мере того, как пользователи работают с действующей системой, а лучшая инженерная практика состоит в том, чтобы построить нечто небольшое, извлечь уроки и адаптироваться. Циклы государственных закупок и подотчётности (см. тему 3.7 — Государственные закупки и заказ услуг), напротив, создавались для капитального строительства и оборонных контрактов: фиксированная спецификация, один крупный контракт, поэтапные платежи и бизнес-кейс, утверждённый за годы до начала реализации. Когда законодательный орган или аудитор ожидает контракта с фиксированной ценой и фиксированным объёмом, а инженерной команде после первого релиза нужно изменить курс, это несоответствие проявляется как расползание объёма работ, перерасход бюджета или система, которая была верно специфицирована в 2019 году и устарела к моменту запуска.

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

Основные понятия

Решение «создавать или покупать» — это выбор между заказом индивидуального программного обеспечения, написанного под потребность одной организации, и внедрением настраиваемого типового продукта, уже созданного для рынка схожих покупателей. Покупка обычно дешевле и менее рискованна для потребности, не имеющей подлинной специфики, — расчёт заработной платы, электронная почта, стандартное управление делами; создание оправдано лишь там, где требование настолько своеобразно, что ни один настраиваемый продукт не подходит, либо где сама эта возможность является стратегическим активом, которым организация должна владеть и который должна развивать.

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

Унаследованная система (legacy system) — это устаревшая технология, приложение или платформа, остающиеся в активной эксплуатации, нередко потому, что их замена дорога или потому, что в организации не осталось никого, кто полностью понимал бы, что она делает. Унаследованные системы особенно живучи в государственном управлении: основные налоговые системы, системы пособий и социального страхования, написанные десятилетия назад на таких языках, как COBOL (Common Business-Oriented Language — «общий деловой ориентированный язык», созданный в 1960 г. для административных вычислений), по-прежнему обрабатывают операции миллионов граждан, потому что системы работают, а институциональные знания, необходимые для их безопасного вывода из эксплуатации, нередко уходят на пенсию раньше самих систем.

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

Паттерн «душащий фикус» (strangler fig pattern) — подход к поэтапной модернизации, названный по лиане, которая обвивает дерево-хозяина и постепенно заменяет его: новая функциональность создаётся рядом с унаследованной системой, а нагрузка переключается на неё частями, вместо того чтобы заменять всю систему одним переключением. Паттерн «душащий фикус» важен тем, что позволяет протестировать, откатить или приостановить каждый шаг, не останавливая всю услугу, — в отличие от замены «одним ударом» (big-bang), когда старая система выключается, а новая включается в один момент, без пути назад, если что-то пошло не так.

Зависимость от поставщика (vendor lock-in) возникает, когда заказчик настолько зависит от проприетарной технологии, форматов данных или договорных условий одного поставщика, что переход к другому сопряжён с непомерными затратами или риском. Зависимость от поставщика особенно опасна в программном обеспечении государственного сектора, поскольку покупатель — постоянный клиент, практически не способный отказаться от системы, обеспечивающей критически важную услугу, а это ослабляет его переговорные позиции при каждом последующем продлении контракта.

Свободное программное обеспечение и программное обеспечение с открытым исходным кодом — программы, распространяемые по лицензии, которая даёт пользователям свободу использовать, изучать, изменять и распространять исходный код. Свободное программное обеспечение и программное обеспечение с открытым исходным кодом лежит в основе политики «открытость по умолчанию», при которой государственный орган по умолчанию публикует заказанный им исходный код, если только особая причина — чувствительность с точки зрения безопасности, права третьих лиц — не оправдывает отказ от публикации. Обоснование обычно сводят к формуле «общественные деньги — общественный код»: программное обеспечение, однажды оплаченное из государственных средств, не должно оплачиваться повторно в другой юрисдикции другим государственным органом, решающим ту же задачу.

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

Гибкая разработка программного обеспечения (agile) — собирательный термин для итеративных подходов к созданию программ, которые отдают предпочтение работающему продукту, частым поставкам и реакции на изменения перед следованием заранее согласованному жёсткому плану. Гибкая разработка программного обеспечения противопоставляется каскадной модели (waterfall) — последовательному подходу, при котором требования, проектирование, разработка и тестирование полностью завершаются каждый до начала следующего. Привлекательность каскадной модели для государственных органов всегда состояла в том, что её этапы чётко соотносятся с контрактом с фиксированной ценой и годовым бюджетным циклом; поэтому значительная часть законодательства о закупках по-прежнему исходит из неё, даже когда фактическая разработка ведётся гибко.

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

Лучшие практики

1. По умолчанию покупайте то, что не требует особой специфики, а создание оставляйте для действительно уникального. Расчёт заработной платы, электронная почта и общие потребности в управлении делами редко настолько отличаются от потребностей другой организации, чтобы оправдывать индивидуальную разработку; создавайте лишь там, где требование, масштаб или необходимость владеть возможностью и развивать её десятилетиями действительно отличаются от того, что предлагает рынок.
2. Сделайте технический долг видимым, прежде чем решать, какую его часть нести. Ведите реестр известных упрощений, отложенных исправлений и неподдерживаемых зависимостей для каждой эксплуатируемой системы и пересматривайте его по установленному циклу, чтобы ещё один год с этим долгом был осознанным компромиссом, а не следствием того, что никто не смотрел.
3. Никогда не планируйте единственное необратимое переключение как единственный путь отказа от критически важной унаследованной системы. Отдавайте предпочтение поэтапным подходам, таким как паттерн «душащий фикус», позволяющим протестировать, откатить и постепенно развернуть каждую часть; замена «одним ударом» системы, от которой зависят миллионы людей, концентрирует многолетний риск в одних выходных без пути назад в случае сбоя.
4. Относитесь к исходному коду, за создание которого платит ваша организация, как к активу, которым она владеет, а не как к арендуемой услуге. Договаривайтесь о депонировании исходного кода (escrow) или о полном владении им в момент заключения контракта, а не после начала спора: поставщик, у которого хранится единственная копия кода вашей критически важной услуги, — это зависимость от поставщика по замыслу.
5. Публикуйте исходный код открытым по умолчанию и требуйте конкретного обоснования для отказа от публикации. Последовательно применяемая политика «открытость по умолчанию» превращает индивидуально разработанное программное обеспечение каждого ведомства в общий актив всего правительства вместо разовых расходов и позволяет внешним специалистам находить уязвимости, которые упустила бы одна лишь внутренняя команда.
6. Составляйте программные контракты так, чтобы итеративная поставка была законной, а не только технически возможной. Контракт, оплачивающий только соответствие спецификации, согласованной при подписании, вынуждает команду выбирать между честной гибкой практикой и договорным соответствием; вместо одного этапа в конце используйте поэтапные пороги финансирования, привязанные к продемонстрированному работающему программному обеспечению.
7. Финансируйте модернизацию как непрерывную программу, а не как разовый капитальный проект. Унаследованная система, модернизированная один раз и затем оставленная ещё на двадцать лет, накапливает тот же риск, с которого начинала; закладывайте бюджет на непрерывное поэтапное обновление, как дорожное ведомство закладывает бюджет на переустройство покрытия, а не на грандиозную замену раз в поколение.
8. Выбирайте открытые стандарты и переносимые форматы данных, даже закупая коммерческое программное обеспечение. Требование к системе поставщика хранить и экспортировать данные в открытых, документированных форматах удерживает затраты на смену поставщика низкими, даже если само программное обеспечение проприетарное, и нередко это более достижимая в ближайшей перспективе защита от зависимости, чем требование, чтобы каждая система была с открытым исходным кодом.
9. Создайте минимально жизнеспособный продукт и покажите его реальным пользователям, прежде чем брать на себя обязательства по полному объёму. Выпуск действительно минимальной версии с последующей доработкой на основе полученных уроков позволяет выявить ошибочные предположения, пока их исправление ещё недорого, а не после того, как полномасштабная система уже построена на их основе.
10. Сохраняйте собственные инженерные компетенции в объёме, достаточном для того, чтобы быть грамотным покупателем, даже если разработка передана подрядчикам. Государственный орган, утративший техническую экспертизу, не может оценить предложение поставщика, заметить первые признаки проблемного проекта или выйти из зависимости от поставщика путём переговоров — что бы ни говорили его закупочные правила на бумаге.
11. Устраняйте профиль рисков унаследованной системы раньше, чем её интерфейс. Приоритетно заменяйте неподдерживаемые языки, необновлённую инфраструктуру и недокументированные интеграции — то, что вызывает сбои и утечки, — прежде визуальной модернизации, которая несёт гораздо меньше операционного риска.
12. Измеряйте состояние поставки инженерными показателями, а не только отклонениями от бюджета и графика. Частота развёртываний, доля дефектов и возраст самого старого неустранённого элемента технического долга расскажут управляющему совету о том, добьётся ли программа успеха, больше, чем сведения о том, укладывается ли она сейчас в бюджет, — а этот показатель нередко меняется последним.

Вопросы для обсуждения в вашей команде

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

Если бы нашу самую критически важную унаследованную систему нужно было заменить начиная с сегодняшнего дня, планировали бы мы переключение «одним ударом» или поэтапный переход — и почему? Стремление заменить старую систему целиком нередко диктуется бюджетными циклами и удобством управления программой, а не технической необходимостью, и оно концентрирует огромный риск в одном моменте. Используйте этот вопрос, чтобы конкретно, шаг за шагом, представить, как выглядел бы поэтапный переход вашей самой критически важной унаследованной системы в духе паттерна «душащий фикус». Обсудите, что мешает вам выбрать такой путь уже сегодня: финансирование, выстроенное вокруг единой даты запуска, процесс управления, требующий одного чёткого этапа, или подлинное техническое ограничение, делающее для этой системы поэтапный переход невозможным.

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

Где мы по привычке выбираем закрытое проприетарное программное обеспечение, хотя подход «открытость по умолчанию» подошёл бы нам не хуже или лучше? Политики «открытость по умолчанию» существуют именно потому, что большинство государственных органов решают пересекающиеся задачи независимо друг от друга, и каждый оплачивает полную стоимость программного обеспечения, которое другой орган уже создал и мог бы им предоставить. Используйте этот вопрос, чтобы выбрать одну систему, которая сейчас создаётся или специфицируется, и спросить, существует ли уже аналог в виде программного обеспечения с открытым исходным кодом где-либо в правительстве или может ли создаваемая вами система быть с пользой выпущена для повторного использования другими. Обсудите, какое конкретное препятствие — соображения безопасности, закупочная привычка, отсутствие чёткой политики — на самом деле мешает такому повторному использованию, а не предполагайте, что к вам это не относится.

Позволяют ли наши процессы закупок и подотчётности честную гибкую разработку, или они лишь переименовывают этапы каскадной модели в спринты? Нередко команда проводит формально гибкие церемонии, но по-прежнему финансируется, управляется и отчитывается по фиксированной спецификации, согласованной при подписании контракта, что воспроизводит все типичные сбои каскадной модели под гибкой вывеской. Используйте этот вопрос, чтобы проследить одну действующую цифровую программу от бизнес-кейса до нынешней управленческой отчётности и спросить, допускает ли структура финансирования смену направления программы на основе того, чему её научил настоящий ранний релиз. Обсудите, что должно измениться в способе финансирования и отчётности программы, чтобы итеративная поставка была реальной, а не косметической (см. тему 3.7 — Государственные закупки и заказ услуг).

Достаточно ли у нас собственных инженерных компетенций, чтобы быть грамотным покупателем систем, от которых мы зависим больше всего? Организация, передавшая подрядчикам всё своё техническое суждение, а не только исполнительские мощности, не может определить, обоснованно ли предложение поставщика, не движется ли проект тихо к неприятностям и какова справедливая цена работы. Используйте этот вопрос, чтобы выяснить, сколько человек в вашей организации могли бы убедительно рассмотреть предложение по технической архитектуре вашей самой важной системы и как это число изменилось за последние пять лет. Обсудите, что потребуется для восстановления этой способности там, где она ослабла, и что ваша организация теряет — в переговорных позициях не меньше, чем в рисках поставки, — за каждый год без неё.

На практике: пример общественной ценности

Вымышленное региональное правительство — пример приводится лишь для иллюстрации и не описывает какую-либо реальную юрисдикцию — обрабатывало заявления на пособие по безработице в системе, впервые написанной более тридцати лет назад и поддерживаемой сокращающимся числом инженеров, понимавших её исходный язык программирования. Объём заявлений намного превысил то, что предполагали разработчики системы, ночные циклы обработки всё чаще не успевали завершиться до начала утренних операций, а руководство ведомства по технологиям предупреждало, что незапланированный сбой, затрагивающий выплату пособий, — теперь вопрос не «если», а «когда».

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

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

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

Четыре секторальные перспективы

Местное самоуправление

Местное самоуправление, как правило, эксплуатирует множество небольших разрозненных систем, а не несколько платформ национального масштаба, поэтому технический долг накапливается в множестве отдельно закупленных и отдельно поддерживаемых приложений, а не в одной заметной флагманской системе. У местных органов обычно меньше всего собственных инженерных компетенций среди всех уровней власти, что делает довод в пользу покупки настраиваемого типового программного обеспечения вместо индивидуальной разработки особенно весомым, а общие региональные или национальные платформы — предмет темы 5.1 (см. тему 5.1 — Цифровое государство и цифровая трансформация) — особенно ценным способом избежать того, чтобы каждый орган самостоятельно воссоздавал одну и ту же возможность.

Национальное правительство

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

Социальный сектор и некоммерческие организации

Некоммерческие организации и благотворительные фонды редко сами создают крупные индивидуальные платформы, но часто оказываются получателями программного обеспечения, заказанного или навязанного государственным заказчиком финансирования, — портала отчётности или системы управления делами, использовать которую их обязывает грант или контракт, — практически не имея влияния на её устройство, технический долг или поставщика. Социальная организация, зависящая от навязанной государством системы, наследует её типичные сбои, не наследуя при этом никаких рычагов для их устранения, и это ещё одна причина, по которой отношения финансирования, основанные на результатах, должны учитывать операционную нагрузку навязанных технологий (см. тему 3.7 — Государственные закупки и заказ услуг), а не только сам показатель результата.

Многосторонние и международные организации

Многосторонние органы и агентства развития всё активнее продвигают программное обеспечение, созданное для государственного управления одной страны, как повторно используемое цифровое общественное благо, которое другие страны могут адаптировать, вместо того чтобы каждое правительство заказывало аналогичную систему у частного поставщика по полной цене. Особый риск здесь состоит в том, что цифровое общественное благо, созданное для правового и административного контекста одной страны, может быть принято в другой с недостаточной адаптацией, перенося допущения — об идентификации, праве на получение выплат или процедурах, — которые на самом деле не переносятся; обещание общей открытой инфраструктуры реально, но лишь там, где вместе с кодом имеется подлинный потенциал местной адаптации.

Типичные сбои и ошибки

Переключение «одним ударом», терпящее неудачу при запуске. Критически важная унаследованная система заменяется единым необратимым переключением после многолетней разработки без реального опыта промышленной эксплуатации, и дефект, проявляющийся только в реальном масштабе или в пограничном случае, который никто не тестировал, обнаруживается в первый же день полномасштабной работы, а вернуться к старой системе нельзя, поскольку она уже выведена из эксплуатации. Цена измеряется несостоявшимися выплатами, отказами в услугах или сбоями, затрагивающими именно тех граждан, которым система призвана служить, — в наихудший момент, когда все рассчитывали на работоспособность замены.

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

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

Косметическая гибкость. Команда разработки принимает гибкие церемонии — ежедневные собрания, спринты, перечень задач (backlog), — тогда как лежащие в основе контракт, финансирование и структура управления по-прежнему предполагают фиксированную спецификацию и единственный этап принятия решения «пускать или не пускать», так что команда отчитывается о скорости спринтов, фактически выполняя каскадный план. Цена в том, что ни одно из подлинных преимуществ гибкости — ранняя обратная связь от пользователей, меняющая направление, и раннее выявление рисков — не реализуется, а видимость современной практики затрудняет надзорным органам обнаружение и оспаривание скрытой жёсткости.

Политика открытого кода без плана поддержки. Государственный орган публикует исходный код во исполнение политики «открытость по умолчанию», но рассматривает публикацию как разовый шаг соблюдения требований, не выделяя ресурсов на рассмотрение внешних предложений, исправление уязвимостей и поддержание документации. Цена — опубликованный репозиторий, который выглядит открытым, но фактически оказывается заброшенным тупиком, что подрывает доверие ко всей программе «открытость по умолчанию» сильнее, чем это сделало бы отсутствие публикации вообще.

Модель зрелости

Контрольный перечень

• Провести инвентаризацию технического долга каждой критически важной системы и пересматривать реестр по установленному циклу.
• Применять документированную систему принятия решений «создавать или покупать» до принятия обязательств по любому значимому новому программному обеспечению.
• При замене любой унаследованной системы по умолчанию использовать метод поэтапного перехода и требовать явного обоснования переключения «одним ударом».
• Подтверждать условия владения исходным кодом или его депонирования в каждом программном контракте до подписания.
• Публиковать исходный код в рамках политики «открытость по умолчанию» с документированным порядком исключений.
• Обеспечивать ресурсами текущую поддержку каждого репозитория, опубликованного в рамках этой политики, а не только его первоначальный выпуск.
• Требовать открытых документированных форматов данных, даже если базовое программное обеспечение проприетарное.
• Выстраивать пороги финансирования вокруг продемонстрированного работающего программного обеспечения, а не единственного этапа с фиксированной спецификацией.
• Создавать и тестировать минимально жизнеспособный продукт с реальными пользователями до принятия обязательств по полному объёму.
• Отслеживать частоту развёртываний, долю дефектов и неустранённый технический долг как постоянные показатели управления.
• Оценивать собственные инженерные компетенции в сопоставлении с тем, что необходимо для роли грамотного покупателя, и устранять выявленные пробелы.
• Приоритетно устранять неподдерживаемую инфраструктуру и недокументированные интеграции раньше косметической модернизации.

Ключевые источники

• GOV.UK Service Standard, Government Digital Service, Великобритания — национальный стандарт цифровых услуг, требующий итеративной, ориентированной на пользователя поставки и открытых стандартов для государственных услуг.
• Office of Management and Budget (Управление по вопросам управления и бюджета США), Federal Source Code Policy (M-16-21), США — федеральная политика, обязывающая ведомства рассматривать повторное использование и публикацию с открытым исходным кодом индивидуально разработанного государственного программного обеспечения.
• Free Software Foundation Europe, кампания Public Money, Public Code — обоснование, разработанное для европейской аудитории, публикации исходного кода программного обеспечения, финансируемого из государственных средств, по свободным лицензиям и лицензиям с открытым исходным кодом.
• Ward Cunningham, «The WyCash Portfolio Management System» (OOPSLA 1992, отчёт об опыте) — первоначальное изложение метафоры технического долга.
• Digital Public Goods Alliance — многосторонняя инициатива, поддерживающая стандарты и реестр открытого программного обеспечения, данных и контента, предназначенных для достижения целей общественного развития.

Ссылки

1. Technical debt — Wikipedia — https://en.wikipedia.org/wiki/Technical_debt
2. Ward Cunningham — Wikipedia — https://en.wikipedia.org/wiki/Ward_Cunningham
3. Legacy system — Wikipedia — https://en.wikipedia.org/wiki/Legacy_system
4. COBOL — Wikipedia — https://en.wikipedia.org/wiki/COBOL
5. Software modernization — Wikipedia — https://en.wikipedia.org/wiki/Software_modernization
6. Strangler fig pattern — Wikipedia — https://en.wikipedia.org/wiki/Strangler_fig_pattern
7. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
8. Free and open-source software — Wikipedia — https://en.wikipedia.org/wiki/Free_and_open-source_software
9. Digital public good — Wikipedia — https://en.wikipedia.org/wiki/Digital_public_good
10. Agile software development — Wikipedia — https://en.wikipedia.org/wiki/Agile_software_development
11. Waterfall model — Wikipedia — https://en.wikipedia.org/wiki/Waterfall_model
12. Minimum viable product — Wikipedia — https://en.wikipedia.org/wiki/Minimum_viable_product
13. Service Standard — GOV.UK, Government Digital Service — https://www.gov.uk/service-manual/service-standard
14. Requirements for Achieving Efficiency, Transparency, and Innovation Through Reusable and Open Source Software (M-16-21) — Digital.gov, Office of Management and Budget — https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/
15. Public Money, Public Code — Free Software Foundation Europe — https://publiccode.eu/
16. «The WyCash Portfolio Management System» (OOPSLA 1992 experience report) — Ward Cunningham — http://c2.com/doc/oopsla92.html
17. Digital Public Goods Alliance — https://digitalpublicgoods.net/