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

Основная идея

Шкала готовности полезна не тем, что точно измеряет зрелость технологии, а тем, что заставляет спорящих указать одну и ту же ступень и сообщить, каких доказательств не хватает.

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

Что изменилось и почему это важно сейчас

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

Построение операционной модели

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

Рабочая версия с пятью ступенями: 1) работает на машине разработчика с выбранными входными данными; 2) функционирует на общей инфраструктуре с реальными историческими данными; 3) обслуживала реальных пользователей в ограниченном объёме с возможностью отката; 4) выдержала типичную пиковую нагрузку с мониторингом и назначенным ответственным; 5) прошла полный цикл бизнеса, включая сезонные моменты и передачу персонала. Часто команды пропускают последнюю ступень — она отделяет систему, которая работает, от системы, которую организация может поддерживать.

Измеряйте результат решения

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

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

Где возникают проблемы в исполнении

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

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

Как это выглядит на практике

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

Аргумент против

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

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

30-дневная последовательность внедрения

Добавьте колонку готовности на доске на этой неделе, заполните для всего, что в работе, и требуйте одно предложение с доказательствами для каждого уровня.

День 1: сформулируйте определения пяти уровней своими словами и разошлите — заимствованные редко выживают при адаптации к конкретной команде. День 2: каждый ответственный назначает уровень своему элементу и называет доказательства. День 3: совместно рассмотрите назначение, ожидая, что примерно треть уровней снизится после озвучивания доказательств. Вторая неделя: используйте шкалу на одной сессии планирования и оцените, изменилась ли дискуссия. Четвёртая неделя: оставьте шкалу, если обсуждения стали короче.

Проверяйте доказательства, а не цифры

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

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

Заключение редактора

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