Choose your WoW

Дисциплинированная поставка гибкими методами (DAD - disciplined agile delivery) и с чем ее едят?

Примерно два года назад Прожект Менеджмент Институт (PMI) в лице Скотта Амблера выпустил очередную Энциклопедию по управлению Вселенной в тайне от санитаров. Пытаясь ответить на главный вопрос: «А туда ли мы свернули, когда начали масштабировать скрам направо и налево?», – автор настрочил аж 451 страницу текста мелким кеглем. Такую толстую книгу в пору бы сразу сжечь, но ее даже не перевели.

Характерная для PMI энциклопедичность, помноженная на отвратительную наглядность материала, привела к тому, что за два года в русском сегменте интернета появилась только одна статья, представляющая вольный пересказ аннотации к книге. Скажу больше, за 10 лет на тему DAD был сделан только один перевод статьи того же Амблера. Кажется, что консалтинговые агентства решили, что этого слона все равно не продать и не стали даже рассказывать про него.

Эту книгу мне посоветовал один очень приличный менеджер, посему я решил для начала посмотреть на выступление несчастного Скотта Амблера на ютубе, чтобы понять, стоит ли его читать. И вот в этом выступлении меня зацепил один тезис, которым Амблер отсылает к книге Джеффа Сазерленда «Революционный метод Скрам». Джефф говорит о том, что скрам - это способ, позволяющий «делать в два раза больше работы за вдвое меньшее время». То есть обещает 4-х кратную эффективность скрам-команд по сравнению с вотерфольщиками (теми, кто умеет раскаленными клещами доставать из заказчиков все требования до начала работы).

Однако, если посмотреть фактам в глаза, то никакого 4-х кратного роста эффективности нет и в помине. Исследование более 3000 команд из 155 организаций показало, что скрам дает прирост эффективности в пределах 7-12%, а масштабированные фреймворки типа SAFe или Less вообще дают прирост эффективности в пределах статистической погрешности 3-5%! Это подводит к простому выводу: важней достигать желаемых результатов, чем быть гибким. Просто нож в спину мне, фанату SAFe, сертифицированному SAFe 5.0 agilist. Вот так внезапно заморскому дядьке удалось меня заинтриговать, и я решил разобраться в деталях.

С чем лично я сталкиваюсь, работая в больших программах или трайбах, так это с тем, что владельцы программ и продуктов вместо работы в заданном фреймворке (а в корпорациях это чаще всего SAFe или Less) занимаются имитацией. Надо работать спринтами – пожалуйста! Надо раз в квартал два дня планировать и обсуждать риски с бизнесом – хорошо. Нужно мерить трудоемкость в сторипойнтах – черт с вами. Делает ли владельцев такая конформистская позиция плохими людьми? Вряд ли. Им говорят красить заборы и они красят заборы. Да, это не имеет отношения к эффективной поставке продукта, но это имеет отношение к выживанию в организации.

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

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

Книга состоит из 5 ключевых разделов:

1. Дисциплинированная гибкая поставка в ореховой скорлупе – странный набор слов, который мне, видимо, удастся попозже перевести более адекватно (пока только дословный перевод). Но в целом в главе делается обзор методологии, объясняется, что значит быть дисциплинированно гибким, суть ролевой модели, принципов целеполагания и выбора WoW (Way of Work) – наилучшего способа работы. Насколько я понял, самое ценное в этом разделе – модель и инструменты диагностики внутренней и внешней среды, в которой менеджеру предстоит заниматься работой. О'кей, проверим.

2. Как успешно запустить свою команду. Здесь я надеюсь увидеть набор инструментов для сборки команды из того, что есть, но с учетом всех возможных рисков. Реально, сколько нужно разработчиков, чтобы вкрутить лампочку? От 3 до 7, плюс скрам-мастер (снова шутки за 300).

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

4. Выпуск в продакшн. Это будет самый короткий блок (видимо хотфиксинг багов методология не предусматривает;) Про то, как обеспечить готовность производства и развернуть решение. Там реально всего пять страниц. Интересно даже, почему DevOps инженеры такие дорогие )))

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

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

P.S.

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

И да прибудет с нами сила.