Заимствуем уровни готовности технологий для команд, которые не строят космические корабли

Главная мысль: шкала готовности полезна не точностью, а общей ступенью

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

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

Заявленный уровень против подтверждений: что изменилось и почему это важно сейчас

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

Колонка готовности на доске: постройте операционную модель

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

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

Заимствованные фреймворки обычно не приживаются: измеряйте, что дало решение

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

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

Шкала полезна не точностью: где ломается исполнение

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

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

Спор о готовности — спор о значении слова: как это выглядит на практике

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

Не точность, а общая ступень: самый сильный довод против шкалы

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

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

Сверка уровня с подтверждениями: план внедрения на 30 дней

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

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

Проверяйте подтверждения, а не цифры

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

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

Вывод редакции: заимствованные фреймворки не приживаются, когда их берут целиком

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