Техническое задание для закупки программного обеспечения: где оно ломается

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

Четыре типовых дефекта

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

Как выглядит рабочая структура

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

Про измеримость

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

Связь с выбором решения

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

Кто пишет

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

Что делаем мы

Собираем задание в проверяемом виде, включая критерии приёмки и требования к данным. Услуга описана на странице технического задания для закупки.