Замечено, что за менеджерами может тянуться хвост проблемных проектов. Чем опытнее менеджер — тем длиннее. Самая большая проблема — то что хвост этот мешает двигаться и развиваться дальше. Коллеги могут припоминать что-то типа «э.. это Васька. Он знаешь уже сколько проектов завалил». И очень хочется этот хвост отрубить. Ретроспективы помогают мало (как правило — мало времени на глубинный разбор сложных проблем). Нужно что-то посильнее.

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

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

Хансей

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

Итого, что требуется: 

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

Кому интересно узнать больше — почитайте книгу Джеффри Лайкера «Дао Toyota». Опять же, Япония... У нас за «хансей» могут сразу в морду дать. Нужно что-то более систематичное. И более западное :) 

Root Cause Analysis
(собственно, с английского «анализ причин»).

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

Кого можно привлекать: Можно самостоятельно, можно привлекать небольшую группу. 

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

Как проводить:

  1. На первом этапе нужно выявить проблемы. Зафиксировать их. Мне удобно это делать в майндмэпе (XMind) или на маркерной доске (ну или ватмане).
  2. Построить диаграмму причинно-следственных связей по выявленным проблемам. Для этого нужно по каждой проблеме задавать вопросы: «почему?», «почему это произошло?», «по какой причине?». Искренне, как бы ни было неприятно это сознавать — сообщать о причинах проблем. Записывать причины на диаграмме, строить причинно-следственное дерево.
  3. Не уходить в неконструктивные ветки («В программе баг, потому что Вася мудак»). Исходить из того, что все люди хорошие, но в рабочей системе есть какие-то ограничения, которые мешают им правильно выполнять процесс. Стараться найти такие ветки, которые являются истинными причинами и ограничениями.
  4. После того, как дерево проблем построено, пройдите по всем веточкам и всем узлам, предложите противодействия, которые нейтрализуют проблему (одно или несколько конкретных действий, инноваций или изменений рабочего процесса).
  5. Убедитесь, что изменения помогут. Убедитесь, что эти изменения можно внедрить и их внедрение рационально. Поговорите об этом с вашим начальником. Согласуйте с ним, какие именно изменения вы будете внедрять. Договоритесь о способе внедрения. Запланируйте работы в собственный google calendar или в календари тех сотрудников, которых планируется привлечь к внедрению изменений.
  6. Внедрите изменения. Проанализируйте последствия. Сообщите о результатах вашему начальнику. Без внедрения вся проделанная ранее работа — бессмысленна. 

Пример диаграммы

Я лично предпочитаю обычное дерево, но многим удобно использовать Fishbone-диаграмму (рыбий скелет или диаграмму Исикавы).

Источник: https://blog.sibirix.ru/2012/10/05/root-cause/ Там же, кстати, есть пример заполненной диаграммы. 

 

Рекомендуемая литература, источники информации:

Последние статьи:

Кейс: как ускорить развитие проекта

Публикую этот пост, чтобы он всегда был "под рукой". Авторство и повествование от имени Carrot Quest. Представители ФРИИ, Илья Красинский и Carrot Quest провели воркшоп, главной задачей которого было улучшение юнит-экономики 5 стартапов. ... читать далее
10.01.18

Что такое эскалация в управлении проектами и зачем она нужна?

Отдельно хочу отметить, что я являюсь поклонницей Юлии Бажановой. Статья - Что такое эскалация в управлении проектами и зачем она нужна? - ее авторства. Юлия легко и непринужденно рассказывает о проектном менеджменте. ... читать далее
12.12.17

Что такое тестирование. Большая и крайне полезная статья от Алексея Баранцева

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

Возможно Вам будут интересны другие статьи из категорий:

Интересно, полезно? Поделитесь у себя:



comments powered by HyperComments