DICE-фреймворк: простой способ понять, взлетит ваша инициатива или нет

Практическое применение разработки от Boston Consulting Group.

Всем привет!

Меня зовут Настя. 7+ лет руководила QA командами и строила процессы качества. Сейчас консультирую компании по тестированию и внедрению изменений. В этой статье хочу с вами поделиться классным инструментом, который здорово помогает в прогнозировании.

DICE — это фреймворк, который позволяет прикинуть вероятность успеха или провала реализации проекта до старта. И при необходимости скорректировать параметры внедрения, чтобы снизить риски неудачи. Придумали его в Boston Consulting Group.

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

На инструмент я наткнулась в сборнике статей от “Альпины” (не реклама, серия правда классная) при написании диплома MBA. Как раз в это время я пришла на новый проект и принесла вагончик новых инициатив в плюс к уже худо-бедно внедряемым. Так что DICE-фреймворк пришелся как раз в тему. Я подумала, а чего бы не попробовать? И попробовала)

И сейчас вам все расскажу!

DICE — это методика оценки успешности внедрения инициативы по четырем параметрам:

D — Duration

I — Integrity

C — Commitment

E — Effort

Каждый из параметров оценивается в баллах от 1 до 4, затем значения подставляются в формулу:

DICE = D + 2×I + 2×C1 + C2 + E

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

Обсудим поподробнее.

Duration — частота пересмотра этапов.

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

У меня на проекте была вот такая разбаловка:

1 балл - Пересмотр раз в 1-2 недели

2 балла - Пересмотр раз в 3-4 недели

3 балла - Пересмотр раз в 2 месяца

4 балла - Во всех остальных случаях

В оригинальной статье значения были другие. Я адаптировала под себя. Вы можете сделать так же. Тут главное сохранять логику: 1 — хорошо, 4 — плохо. Проекты все-таки штука уникальная и где-то раз в неделю будет слишком редко, а где-то раз в полгода — достаточно.

Integrity — профессионализм команды.

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

Мои значения:

1 балл - Руководитель и его подчиненные - профессионалы

2 балла - Скорее да

3 балла - Скорее нет

4 балла - Плохо по всем показателям

Значение этого параметра вносит значительный вклад в итоговый успех/не успех, поэтому в формуле он умножается на 2. Запомните, чуть позже это знание пригодится ;)

Commitment — приверженность идее преобразований со стороны руководства (C1 в формуле) и команды (C2 в формуле).

Это очень важный показатель! Так что поговорим про С1 и С2 отдельно.

Мои значения для С1:

1 балл - Руководство поддерживает проект

2 балла - Нейтрально

3 балла - Скрыто не поддерживает

4 балла - Открыто не поддерживает

Самые интересные пункты — это 3 и 4 балла. Когда такое может быть?

Например вы работаете в большой корпорации и биг босс спустил задачу покрыть все сервисы нагрузочными тестами. Ваше руководство и так все в мыле, а тут еще такое. Если вы хоть раз слышали “Да кому это надо?”, “У нас на фичи времени не хватает” или вариации, значит “Открыто не поддерживает”.

Второй пример. Начальник вас благословил на внедрение, но никому не рассказал об этом. Потом вы эскалируете на мешающего внедрению соседа, а начальник встает на его сторону. Это про “Скрыто не поддерживает”, хотя тут, конечно, все очень тонко, на то оно и “скрыто”, сразу не поймешь.

К этому пункту нужно отнестись крайне внимательно и крепко обдумать уровень поддержки сверху. В формуле у этого параметра, как и у профессионализма, вес удвоен.

Про уровень поддержки командой/исполнителями.

Тут все менее серьезно, видимо потому, что на подчиненных проще повлиять, чем на начальство. И в смысле пропаганды, и в смысле административного давления.

Мои значения для С2:

1 балл - Охотно принимают изменения

2 балла - В принципе не возражают

3 балла - Сопротивляются

4 балла - Возражают крайне резко

“Возражают крайне резко” это например ручные тестировщики на всех собраниях и 1-2-1 говорят, что не хотят учиться автоматизации. А “Сопротивляются”, если автоматизируют, но ноют или “опять не успели, потому что большая загрузка”.

Effort — усилия, необходимые для реализации.

Сколько времени нужно потратить на задачу от всего объема времени сотрудника.

Мои значения:

1 балл - Доп. объем работ не более 10% (или основная работа)

2 балла - 10 - 20%

3 балла - 21 - 40%

4 балла - Во всех остальных случаях

Если реализация проекта — основная или единственная задача сотрудника — ставила 1 балл. При таком условии риски, что времени будет не хватать — минимальные.

Совет из опыта:

Когда будете проводить оценку параметров, пригласите коллег, которые знают команду и процессы. Инструмент все-таки субъективный, коллективный разум помогает увидеть скрытые риски и сделать оценку более точной. Я часто использую DICE при аудите проектов — и почти всегда присутствует удивление, как сильно реальность отличается от ощущений.

Итак, параметры оценили, подставляем в формулу:

DICE = D + 2×I + 2×C1 + C2 + E

Вот тут собрала DICE-калькулятор, чтобы не считать вручную.

Полученный результат оценивается следующим образом*:

На этом этапе DICE снимает розовые очки. Интересно, что чаще всего проблемы сидят не в технологиях, а в людях и поддержке. Но на этом работа с фреймворком не заканчивается.

*границы интервалов немного отличаются от варианта BCG, адаптировала исходя из личного опыта применения.

Давайте сразу на примере.

Команда ручных тестировщиков решила, что ей нужна автоматизация. Лида вроде как уговорили. Решили успеть за квартал. При таких сроках на написание фреймворка нужно тратить 30% рабочего времени. Опыт автоматизации у инженеров отсутствует. Оценили объем работ, провели декомпозицию, завели задачки в джиру, раскидали по спринтам — вроде должны успеть. Ушли пилить.

При оценке в холодной воде на старте имеем:

D = 4 : Специальных встреч по обсуждению проекта автоматизации нет.

I = 4 : С профессионализмом все плохо, опыта автоматизации ни у кого нет.

C1 = 2 : Руководство нейтрально. “Лида уговорили”, значит ни “за”, ни “против”.

C2 = 1 : С инициативностью команды все хорошо, инициатива ведь их.

E = 3 : Тратить времени нужно достаточно много.

При подсчете получаем DIСE = 20. Это гарантированный провал. Почему так, давайте разберем риски:

Итог: команда встречается через квартал, а по фреймворку ничего не сделано. Грусть, тоска.

Как можно было снизить риски на старте?

1) Регулярные встречи раз в неделю, о проблемах узнаем сразу, можно порешать. При таком раскладе перетекание задач из спринта в спринт заметили бы сразу и можно было что-то предпринять.

D = 1 → DICE = 17. Сразу из зоны провала перешли в зону беспокойства, но тут пока нечему радоваться) Риск все еще большой.

2) Планируем на 2 квартала, а не на квартал. Cнижаем E до 20% (тут заложили риски на непрофессионализм, поэтому не 15%).

Е = 2 → DICE = 16. Все еще зона беспокойства.

3) Проводим кучу бесед с руководителем и убеждаем его в том, что автоматизация ну очень сильно поможет команде. Или железобетонно договариваемся не отказываться от задач на автоматизацию в пользу бизнесовых. Или показываем ему оценку по DICE и убеждаем, что проект 100 пудов взлетит, если он окажет более активную поддержку. В общем тут надо применить фантазию и все свои скилы ведения переговоров. Допустим, вышло)

C1 = 1 → DICE = 14. Все еще беспокойство, но хотя бы нижняя граница.

4) И вишенка на торте это конечно профессионализм команды. Помните, мы умножали I на 2? При митигации рисков это работает в обратную сторону. Например, если отдать написание фреймворка соседям с опытом (конечно при их наличии), то можно и руководителя не уговаривать и в квартал уложиться:

I = 1 → DICE = 8. Победа! Сделали все, что могли.

Но если таких соседей нет, то можно попробовать снизить I хотя бы до 3, например найти ментора или отправить кого-то на курсы. Или до 2, если взять в команду человека с опытом.

Вот такими нехитрыми манипуляциями можно очень сильно увеличить успешность реализации проекта или внедрения инициативы.

Еще можно сравнивать вероятность успеха при разных стартовых условиях. Например: проект делает команда А или команда Б? У кого мотивация выше? А поддержка руководства?

Но и это еще не все.

Работа с DICE не ограничивается только этапом до внедрения. В процессе реализации инициативы, DICE необходимо пересчитывать в случае изменения условий. Это контроль.

Например: из команды ушел синьер, экспертиза упала и теперь проект под угрозой. Итоговое значение DICE изменилось. Пересчитывать можно на встречах по пересмотру этапов (D — Duration).

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

DICE можно (и нужно) применять не всегда. Если задача маленькая, рутинная или все делает один инженер — можно не заморачиваться. А вот когда инициатива сложная, многокомандная и влияет на процессы, тогда стоит просчитать успех заранее.

Примеры задач, когда стоит применить DICE:

DICE-фреймворк простой, быстрый, незатратный. При этом помогает:

Подробно здесь не упоминала, но еще инструмент здорово помогает продавать идеи руководству через обоснование успешности реализации.

Так что всячески рекомендую взять на вооружение!