От выгорания команды до удвоения частоты релизов кейс agile коуча

Диаграмма Исикавы: инструмент анализа причинно-следственных связей

Диаграммы причинно-следственных связей — полезная техника, которую можно использовать в работе QA-специалиста. Гленфорд Дж. Майерс (Glenford J. Myers) писал, что уязвимость анализа граничных значений и использования техники классов эквивалентности заключается в том, что они не исследуют комбинации входных обстоятельств. Техника, которую можно использовать для изучения и описания комбинаций входных обстоятельств, — это диаграмма причинно-следственных связей.

Диаграмма Исикавы

Особенно полезной диаграммой причинно-следственных связей я считаю диаграмму Исикавы или диаграмма Фишбоун. Она получила название от имени своего создателя — профессора Каору Исикавы (Kaoru Ishikawa). Также она известна как диаграмма рыбья кость или рыбий скелет, потому что визуально похожа на строение костей рыбы.

Пример диаграммы показан ниже:

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

Пять М

Диаграммы Исикавы были названы так Джозефом Джураном и являются ярким примером того, как их идеи из Японии проникли в Северную Америку и Европу. Исикава разделил причины анализируемой проблемы на пять групп, названных для краткости Пять М:

• Метод
• Машина
• Материал
• Миловидная работа
• Мера

Применение диаграммы Исикавы

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

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

Преимущества

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

Два недостатка диаграмм Исикавы

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

Существует множество шаблонов для создания диаграмм Исикавы. Чтобы найти их, просто загуглите Ishikawa diagram templates. Вы должны быть в состоянии найти шаблон для приложения, которое вы используете.

Метод 5 почему

Также приглашаем всех желающих на открытый урок, посвященный методам тестирования требований.

Описание метода 5 почему

Техника 5 почему (5 Whys) – это метод анализа корневых причин проблемы или неполадки в бизнесе или в другой сфере деятельности. Он был разработан в рамках Toyota Production System (системы производства Toyota) и используется для выявления глубоких причин проблемы, а не только ее поверхностных симптомов.

Процесс метода 5 почему

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

Преимущества метода 5 почему

Польза метода 5 почему заключается в том, что он помогает выявить не только видимые симптомы проблемы, но и ее истинные корни. Это позволяет предпринимать более эффективные меры для ее решения.

Пример применения метода 5 почему

Давайте рассмотрим пример применения метода 5 почему на случае приема лекарственных средств.

Проблема:

Пациент испытывает побочные эффекты от лекарства, которое он принимает.

1. Вопрос №1: Почему пациент испытывает побочные эффекты от лекарства?

   • Ответ №1: Потому что дозировка лекарства может быть слишком высокой.

2. Вопрос №2: Почему дозировка лекарства слишком высокая?

   • Ответ №2: Потому что врач назначил максимальную рекомендованную дозу лекарства для этого пациента.

3. Вопрос №3: Почему врач назначил максимальную дозу лекарства?

   • Ответ №3: Потому что врач не учел индивидуальные особенности пациента и не провел детальный анализ его состояния.

4. Вопрос №4: Почему врач не провел детальный анализ состояния пациента?

   • Ответ №4: Потому что у врача было ограниченное время на приеме, и он опирался на стандартные рекомендации.

5. Вопрос №5: Почему у врача было ограниченное время на приеме?

   • Ответ №5: Потому что в медицинской клинике не хватает медицинского персонала, и у врачей мало времени на каждого пациента.

Корневая причина проблемы:

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

Решение проблемы

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

Пример использования метода 5 почему

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

Как найти первопричину проблемы?

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

Суть метода

Метод 5 почему помогает найти первопричину проблемы или конфликта. Столкнувшись с негативным моментом в своей работе, мы можем задать вопрос, почему так произошло. Найдя прямую причину, мы задаем следующий вопрос уже отталкиваясь от этой причины — почему произошла она? Так выстраивается цепочка причин, в конце которой (в среднем через 5 вопросов) обнаруживается истинная причина нашей изначальной проблемы.

Наследие Toyota

Метод 5 почему был разработан основателем японской компании Toyota — Сакити Тоёда. В 70-х годах метод получил широкую популярность как способ решения производственных проблем.

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

Сакити Тоёда (Sakichi Toyoda) — японский предприниматель, изобретатель и промышленник, основатель компании Toyota

Как найти причину проблемы

Грамотно применяя этот метод, можно легко найти корень проблемы или конфликта. Методика строится на прохождении следующих этапов:

Метод 5 почему для решения проблем

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

Например, диаграмма рыбьей кости (Fishbone Diagram), графически похожая на рыбный скелет. Она позволяет визуализировать причины разных уровней, повлиявшие на возникновение основной проблемы.

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

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

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

• Метод 5 почему может применяться в комплексе с другими логическими и аналитическими подходами — построением грозовой тучи, накопительной диаграммой потока (Cumulative Flow Diagram) и др.
• Это ценный мыслительный инструмент в процессе решения самых разных проблем.

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

Книги в тему

Это лишь один из множества инструментов. Метод 5 почему просто освоить и применять на практике, но он не является волшебной таблеткой.

Управляйте процессами, командами и задачами в едином информационном пространстве Kaiten.

Как правильно заданные вопросы помогают решать проблемы бизнеса.

Недостатки метода 5 почему

Изображения идут после этого абзаца.

Эта статья кратко описывает кейс работы agile коучей с реальной ИТ командой (внутренний продукт) от начала, включая валидацию запроса, сопровождение (реализация плана решения проблематики) до снятия метрик по результатам работы. Весь цикл занял около 4-5 месяцев.

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

Из статьи вы узнаете:

• Какой был запрос

К нам пришли представители ИТ команды (ИТ лид и деливери менеджер) со словами: «у нас выгоревшая команда, помогите! Надо что-то делать с уровнем стресса и психологическим здоровьем команды; обстановка сложная: слезы, нервы, успокоительные.»

В ходе интервью мы выяснили, что у команды были следующие предпосылки обратиться к коучам:

Этапы работы agile коуча с командой/периметром

Ниже перечислены этапы работы с запросом.

Валидация проблематики

При работе с любым запросом на изменения важно выявить реальную проблему или причину болей заказчика или команды, поэтому этап валидации проблематики является одним из ключевых. Часто если не соблюдать такую очередность этапов работы с запросом, можно столкнуться как минимум с большим сопротивлением команды, а как максимум не получить нужный результат (или вообще получить противоположный желаемому результат, усугубить проблему). И если не работать с реальной проблематикой (которую еще нужно выявить), то есть риск, что после ухода коучей из команды, все может вернуться к состоянию как было «до».

Этап валидации проблематики включал в себя, в частности, интервью с заказчиком, командой и владельцем продукта.

Интервью с заказчиками

Самое первое, это интервью с теми, кто пришел к нам с запросом. Обычно помогают следующие вопросы:

Это всего лишь небольшая часть вопросов для интервью. И дальше все вопросы интервьюера будут зависеть от ответов и контекста.

Интервью с участниками команды и владельцем продукта

Далее мы сделали серию интервью с разными ролями в команде и поговорили с новым владельцем продукта.

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

На этом этапе мы спрашивали следующее:

Выявление корневой причины или диаграмма причинно-следственных связей

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

Если кратко, то корневыми причинами были:

К тому же, в данном кейсе были и более системные проблемы (проблемы, которые лежат не в зоне влияния команды). Этот момент мы пока опустим и опишем именно работу с проблематикой команды.

Сокращенную диаграмму вы можете увидеть на картинке ниже.

Как мы измерим прогресс и успех (метрики)

Для измерения результатов мы взяли следующие метрики:

Можно было бы еще взять Lead time, но команда не вела достоверно jira, чтобы можно было измерить этот показатель.

Очная сессия – как окончательная валидация проблематики и начало работы с командой

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

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

У нас было 2 дня и структура встречи выглядела следующим образом:

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

Какой был план действий

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

2. Визуализация процесса создания потока ценности, настройка доски jira и критериев перехода задач из статуса в статус (definition of ready и definition of done).Это один из ключевых этапов. На картинке ниже визуализация потока создания ценности внутри команды (красными стикерами отмечены области, где были наибольшие проблемы в процессах).

3. Помощь команде в настройке командных событий, в особенности планирования. Также мы проводили для команды ретроспективы. Впоследствии, команда могла самостоятельно проводить все командные события без внешних фасилитаторов.

4. Помощь в разборе бэклога и приоритизации задач

5. Помощь в определении ответственности между лидами продукта: владельцем продукта, ИТ лидом, деливери менеджером и релиз менеджером

6. Помощь в проведении демо и получении обратной связи от пользователей. Впоследствии, команда начала собирать обратную связь на регулярной основе.

Какие agile (и не только) практики и инструменты мы использовали:

Результаты и метрики по результатам работы

В результате, команда действительно стала командой:

А теперь посмотрим на метрики до и после.

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

Из того, что нельзя измерить, но можно наблюдать – это атмосфера в команде и самостоятельность работы команды.

За счет чего получилось?

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

Автор статьи — Мария Сорока, agile coach, командный коуч и коуч лидеров, эксперт Академии Бизнес-Психологии.

Если вы хотите цитировать эту статью, то используйте ссылку на источник.