Как принимать эффективные управленческие решения на основе канбан-метрик?

Метрики для управления проектами — тема, которую невозможно раскрыть за одну статью, но в этом материале мы пройдемся по основным аспектам корректной постановки сроков управленцем. 

Статья написана на основе выступления Василия Савунова —  Kanban-тренера (KU AKT), Agile Coach,  партнера ScrumTrek, автора курса «Основы Канбан-систем» — где он поделился своим личным опытом и краткой теорией о том, как руководителю в IT-компании собирать и анализировать Kanban-метрики. 

Экономическое чудо Японии, Деминг и Agile

Знакомьтесь, это Эдвардс Деминг — научный деятель и автор книг об управлении качеством, «волшебник», который помог Японии встать на ноги после Второй Мировой войны.

В 1946 году он впервые прибыл в страну восходящего солнца, где прочитал лекцию на 45 человек, каждый из которых принадлежал руководящему звену крупнейших компаний Японии. Благодаря ему целая страна «обратилась» в религию статистических методов управления, а японское производство стало синонимом качества и постоянного улучшения процессов. 

На основе трудов Деминга возникли:

• знаменитая производственная система Тойота;
• бережливое производство;
• Lean Software Development;
• Канбан-метод;
• цикл Шухарта-Деминга;
• Agile: XP, Scrum, DSDM, ASD, AUP, Disciplined;
• DevOps.

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

Система глубинных знаний и метрики 

Еще одно изобретения Деминга — это система глубоких знаний (SoPK — System of Profound Knowledges). Она состоит из аспектов, которые должен учитывать каждый руководитель, чтобы выстроить предсказуемые прозрачные процессы создания продукта. 

Разберем аспекты системы Деминга.

Понимание системы

В английском варианте используется слово «appreciation», что означает не просто понимание, как принятие, но уважение к сложной выстроенной системе. 

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

В работе со сложной системой руководитель не может принимать простые решения и игнорировать какие-либо аспекты работы предприятия. 

Знание вариаций

Результат работы любой системы вариативен — он не может постоянно быть одинаковым. Даже если на производстве точно выверено время установки деталей, число инструментов и людей за конвейером, стоимость каждой минуты работы системы и т. д. — даже настолько контролируемая система будет иметь вариативность. И управленец должен понимать причины этой вариативности, чтобы контролировать допуски. 

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

Теория познания

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

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

Психология людей

Насколько великолепно не были бы выстроены процессы, они не будут работать без корректной системы мотивации сотрудников. Например, при создании Scrum-команды руководитель может оставить персональную систему мотивации каждому сотруднику — зарплаты будут зависеть не от коллективного результата, от выработки каждого члена команды по отдельности. Но это противоречит концепции Scrum как командного метода разработки и разрушает процессы работы. 

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

Практика: как отсутствие данных губит процессы и добавляет лишние затраты

Представим, что в компанию пришел новый руководитель цифровых решений. Он задается вопросом: «Куда делся прошлый руководитель?». Бизнес-заказчик отвечает ему: «Прежний руководитель не мог управлять командой — не выполнил ни одной задачи в срок.»

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

• Внедрение тотального контроля, который занимает много ресурсов для мониторинга и обучения сотрудника практикам по предоставлению информации руководителю. Результат такого решения: потраченное время и деньги бизнеса.
• Кнут и пряник. Например, премия за выполненный дедлайн и штрафы за просроченный. Но на дистанции мы видим, такой подход помогает зарабатывать сотрудникам, но не закрывает бизнес-цели. Результат: люди подгоняют данные под цифры, нет вовлеченности в цели компании.
• Найм новых сотрудников для увеличения производительности. Но их обучение занимает время и порождает новые иерархии. Результат: новые затраты и удлинение цепочки коммуникаций.
• Бездумное внедрение «модной» методологии работы. Это трансформация ради трансформации, цель которой — что-то внедрить, а не выстроить эффективные процессы. Результат решения: насильно внедренная концепция, в которой половина практик не работают или мешают команде. 

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

Что нужно знать управленцу перед внедрением изменений, чтобы сделать процессы предсказуемыми

Чтобы понять, как руководителю взять процессы под контроль и сделать их предсказуемыми, стоит следовать следующим этапам.

Этап I: Выяснить характеристики системы

Пройдем по основным аспектам системы Деминга на нашем примере и начнем с понимания системы.

Новому руководителю важно понять: 

• какой результат работы может выдавать система сейчас;
• как система устроена в реальности, а не на словах.

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

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

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

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

И есть точка отдачи обязательств, в которой другой отдел или руководитель считает задачу завершенной. 

То есть первое, что должен сделать новый руководитель — найти реперные точки процесса:

• точка начала проработки идеи;
• момент принятия обязательств;
• точка отдачи обязательств. 

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

Также у нас есть время:

• реализации и поставки ценности продукта, за которое мы отвечаем (Downstream Time);
• подготовки и согласования — период до точки принятия обязательств (Upstream Time);
• время, которое ждет заказчик, чтобы получить продукт (Time to Market).

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

Если руководитель хочет спрогнозировать сроки, он должен обратиться к графику Time to Market Distribution, который отображает:

• по горизонтали: число дней, которые ждал заказчик;
• по вертикали: сколько раз клиент получал продукт за определенное количество дней. 

С помощью этого графика можно увидеть:

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

Предположим, мы получим такой результат: 

• с вероятностью 85% подготовка задачи займет 68 дней;
• 85 дней с той же вероятностью занимает ее реализация IT-отделом.

Downstream — это статистика времени реализации задачи непосредственно в производственном подразделении ( отдел разработки, например ). За этим показателям менеджер проекта обязан следить постоянно, даже если тот принимает нежелательные значения, чтобы вовремя реагировать на нежелательные отклонения.

Какие графики в Kaiten помогут прогнозировать сроки задач 

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

Спектральный график

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

График позволяет увидеть аномально долгие сроки выполнения задач и спрогнозировать сроки с помощью вероятности на перцентилях. 

Пропускная способность команды

Отражает число задач, которые команда может выполнить за выбранный период. На оси Y мы видим разные периоды, на Х – число закрытых карточек с задачами. 

График помогает руководителю соотнести объем входящих задач (левый столбец) и реальные способности команды (правый столбец). 

Распределение карточек

Диаграмма с процентным распределением закрытых задач разного типа. Карточки могут делиться по разным категориям: владелец, ответственный, тип карточки, колонка, размер, метка.

Влияние буферов на процесс работы 

Нам важно отследить, сколько дней карточка в среднем проводит в колонке «Буфер». В Kaiten руководитель может увидеть это в отчете «Время цикла».

На графике мы видим, что в среднем карточка проводит в буферной колонке «Запланировано» 2 дня 22 часа. Но она одна из задач пребывала в ней 10 дней. Руководитель должен снова окунуться в эту задачу и узнать причину такой задержки в буфере, чтобы сократить Downstream Time.

Этап II: Исследовать вариации

На этой стадии исследования процесса управленец должен узнать:

• какие паттерны поведения демонстрирует система;
• где у системы «узкие» места;
• что сбоит и вызывает простои больше всего.

Для этого исследуем систему в динамике. В этом руководителю поможет график кумулятивного потока:

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

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

Поиск узких мест

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

Например, руководитель видит, что задачи проводят много времени в колонках «Разработка» и «Тестирование». Тогда его задача – узнать у сотрудников, как устроен их реальный процесс работы. Для этого важно использовать психологию и общаться с командой — объяснить сотрудникам, как им поможет сбор метрик, которые покажут их реальные возможности производительности. Это позволит отделу  выстраивать диалог с заказчиком на равных, так как тому будет очень сложно опровергнуть статистику, собранную за длительный срок и «перекроить» прогнозы на свой лад. 

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

Если сотрудники продолжают сопротивляться сбору метрик или открытому диалогу, не нужно сразу увольнять человека — важно найти причину его недовольства. Например, коллега может опасаться, что замер метрик отразится на его зарплате или производительности. Исходя из реальных опасений сотрудника руководитель объясняет тому ситуацию, а не просто закрывает глаза на саботаж.  Также он обязан обеспечить безопасносность сбора метрик для сотрудника — не использовать данные для привязки премии и зарплаты к статистике. Это приведет к тому, что сотруднику будут «подкручивать» цифры, чтобы не терять доход. 

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

Если контакт налажен, то при общении с командой, которая непосредственно работает «на земле», управленец может выделить общие этапы — их сами назовут вовлеченные в процесс сотрудники. 

И получаем новую доску, которая состоит не из двух колонок «Разработка» и «Тест», а прозрачно отражает процессы с детально проработанными колонками. Например, после общения доска может содержать колонки:

• ожидание свободного разработчика;
• анализ;
• разработка;
• ожидание свободного тестировщика;
• ручной тест;
• интеграционный тест;
• регресс;
• передача в релиз.

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

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

Оптимизация узких мест

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

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

Внедрение новой методологии ради внедрения также принесет нагрузку, а не решение. 

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

Чтобы больше разобраться в оптимизации узких мест, рекомендуем прочитать книги «Цель» и «Цель 2» Элияха Годрата, которые дополняют труды Деминга. 

Резюме: канбан-метрики, которые помогают руководителю выстраивать предсказуемую систему

Канбан-метрики помогают руководителю принимать стратегические решения, основанные на реальных данных. Анализ системы позволяет выявить узкие места, прогнозировать сроки и выстраивать прозрачные процессы — создавать рабочие доски, которые будут соответствовать реальности, а не обобщать процессы.

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