При работе над любым продуктом всегда возникает много вопросов и проблем, причем не важно какой фреймворк вы используете Скрам, Канбан или еще что-то. И решение проблем- это одна из обязанностей команд разработки. Когда я пришла в проект проблембыло очень много: некоторые были явные и о них говорили все, некоторые выявлялись в процессе работы, о некоторых мы узнавали на ретро, а о некоторых не узнавали. Конечно, как ответственные самоорганизующиеся команды мы старались решать проблемы, но наши решения не проводили к их устранению, они возникали снова и снова: их становилось все больше, а времени на их решение все меньше, и никто не хотел ими уже заниматься: все хотели писать код.
Проблемы. Их меньше не становится
Я поняла, что дальше так не может продолжаться и решила вывести практику решения проблем на другой уровень. Как говорится хочешь изменить мир, начни с себя. Сначала я провела исследования какие же есть подходы. Конечно же, у меня была цель не только решать проблемы, но и постоянно шаг за шагом улучшать процесс создания нашего продукта, сам продукт и команду, которая с ним работает.
Из всего многообразия я выбрала классические PDCA и 8D(раз и два). С чего мы начали. Мы попробовали первый раз применить эту методику для решения классической проблемы: слишком медленное тестирование. В решении были задействованы, только тестировщики проекта (нас было 4). В итоге мы обнаружили, что истинная причина возникновения проблемы никак не связана с поиском виновных, а заключалась в самом процессе создания продукта. Такой подход помог выявить ряд факторов, на которые прежде никто не обращал внимание. И самое главное позволила изменить отношение команды к тестировщикам и тестированию: стало формироваться мнение, что тестировщики не являются виновными, а тестирование- бутылочное горлышко.
Проводим регулярные воркшопы
Окрыленные успехом и видимым результатом, мы начали проводить регулярные воркшопы по решению проблем (естественно их формат, форма проведения постоянно изменялись: старались учесть допущенные ошибки, устранить их, доработать саму методику решения проблем), привлекая различных участников: команду разработки, менеджеров, участников тех.поддержки и других заинтересованных лиц.
Интегрируем!
Такие воркшопы являются очень ресурсозатратными (но остались для решения сложных проблем). Мы постарались интегрировать наш опыт в другие наши мероприятия. Так как команда уже имела опыт работы с методикой, то то не вызвало проблем. Одним из такие является ректроспектива. Благодаря чему наше ретро стало более эффективны, где каждый участник может внести свой вклад в выявление проблем, поиска решений для их устранения.
Используем инсайт
Когда найдена корневая причина, то следующий этап- это формирование корректировочных действий, направленных на ее устранение. Но часто не получается сразу такие действия предложить: не было аналогичного опыта, не хватает знаний, очень сложная подобралась проблема или другие причины. Поэтому в этом случае можно использовать технику инсайта:
- Проводим «Problem Loading Meeting», на котором еще раз обсуждаем проблему, кратко вспоминанием, что было сделано на шагах 1-4, какая корневая причина была выявлена. Придумываем различные аналоги из жизни, из других сфер, вспоминаем различные паттерны, используемые для их устранения такой проблемы.
- На следующий день проводим следующий митинг, на котором собираем все идеи участников, можем использовать различные техники мозгового штурма, используем классические вопросы коучера.
- Делаем перерыв на пару часов.
- Ловим инсайт свой/коллег. Дорабатываем идею до реализации.
Подведем итоги
Систематическое решение проблем наша команда практикует около года, что же изменилось:
- вырос уровень зрелости команды,
- изменить образ мышления членов команды: повышение производительности.
- развилась способность выявлять проблемы, принимать решения и брать на себя отвественность.
- Позволило создавать продукты, улучшая не только процесс его создания (в рамках команды), сам продукт но и улучшать взаимосвязанные сервисы, для того чтобы изменять customer jorney map в лучшую сторону.