Как стать профессиональным Problem Solver’ом?
Популярно о ценностях, подходах и техниках Lean.
Как бы мы не пытались тщательно планировать, составлять подробные реестры рисков или закладывать в оценки “буфер”, на нашем пути возникают преграды. И от того, насколько эффективно мы умеем решать возникающие проблемы, зависит успех нашего проекта, производительность и сплоченность нашей команды, качество и востребованность продукта.
Что вы можете сказать о своем умении решать проблемы, которые возникают в ваших проектах, командах, продуктах? Есть ли у вас для этого какой-то эффективный подход или методика, гарантирующая результат?
В общем,
Есть ли у вас проблемы с решением проблем? =)
Если вы на этот вопрос ответили “да”, то эта статья для вас. А если “нет”, то я бы с удовольствием прочитал статью о вашем опыте.
В статье мы рассмотрим фреймворк “по решению проблем”, пришедший к нам из бережливого производства (Lean / Toyota Production System) и “обкатанный” десятилетиями. Причем рассмотрим как теорию, так и применение этого фреймворка на примере из моей реальной практики. И я очень надеюсь, что вы попробуете его в работе, освоите, наберетесь опыта и станете настоящими Problem Solver’ами! Приступим?
Матчасть…
В бережливом производстве проблема — это разница между стандартом и реальностью, т.е. есть текущее состояние, в котором мы находимся и есть желаемое состояние, в котором мы хотели бы находиться, а между ними пропасть!
Соответсвенно, решение проблемы — это создание моста для перехода из текущего состояния в желаемое.
Вам уже наверное не терпится узнать, как же построить этот мост???
A3 — Problem Report
Для этого в бережливом производстве есть очень интересный инструмент, который называется A3 — Problem Report.
Можно сказать, что A3 — это инструмент “три в одном”!
С одной стороны, A3 — это checklist, который задает тебе алгоритм для работы над проблемой и выработки решения (т.е. построение моста). И предлагает разбирать и решать проблему последовательно:
1. Background: сформулировать проблему, записать стартовую формулировку (как есть, главное не “буксовать” на этом этапе);
2. Current Conditions: разобраться в “контексте проблемы” и выписать все факты;
3. Goal/Target: сформулировать желаемое состояние, отразив его самые существенные атрибуты и метрики;
4. Analysis: провести анализ и выявить первопричины проблемы, построить дерево/граф причинно-следственных связей;
5. Countermeasures: разработать и описать концепт решения(ий) для этой проблемы;
6. Plan: выписать набор практических шагов для реализации концепта решения на практике;
7. Follow-Up: выписать контрольные точки и метрики, которые будут говорить нам об успешности нашего решения.
С другой стороны, A3 — это формат бумаги А3 (canvas), который заставляет тебя быть лаконичным, использовать визуализацию и отмечать только самые важные аспекты рассматриваемой проблемы и предлагаемого решения. В результате, ты получаешь весь “контекст” проблемы и ее решения на “одном листе”, наглядно и доступно!
А также, А3 — это инструмент достижения консенсуса, сбора мнений, валидации решения с привлечением умов твоих коллег. Имея такой артефакт, ты достаточно быстро можешь погрузить в контекст, любого из твоих коллег и презентовать ему решение для получения обратной связи (согласия, предложений/улучшений идеи).
Root Cause Analysis — это важный ингредиент!
Прежде чем двинемся дальше, хочется остановиться подробнее на одном из этапов в работе над проблемой по формату А3 и обсудить техники поиска первопричин (Root Cause Analysis или Analysis). Для этого в бережливом производстве есть две очень мощные техники “5Почему” (5Whys) и Диаграмма Ишикавы (fishbone).
Я в основном применяю технику “5Почему” (5Whys). Теорию о ней вы можете почитать на Wikipedia. А реальный пример применения увидите в статье ниже, где мы будем использовать фреймворк при решении реальной проблемы.
В итоге, у нас теперь есть понимание, из каких “ингредиентов” состоит проблема (текущее состояние — пропасть — желаемое), у нас есть алгоритм выработки решения (A3 — Problem Report) и мы владеем техникой 5Whys. К сожалению этого может не хватить, чтобы эффективно решать проблемы…
Принцип: “Иди и смотри”
Еще в бережливом производстве есть очень важный принцип, которым должны владеть все “бережливые” менеджеры, он называется “Иди и смотри” (или по японски “Генти Генбуцу”).
Основной смысл этого принципа очень прост: для того, чтобы принять правильное решение вы должны “увидеть все своими глазами” (т.е. ни в коем случае не решать проблемы или принимать решения из своего кабинета с видом на Манхэттэн, основываясь на чужих выводах, рассказах и своих догадках), т.е. пойти в эпицентр проблемы, собрать факты и выработать решение на месте совместно со всеми участниками и пострадавшими.
К сожалению, часто происходит иначе. Либо за решение проблемы берутся люди, имеющие о ней лишь отдаленное представление… Либо, в процессе обсуждения проблемы, все оперируют выдуманными фактами и основываются “на догадках и предположениях…
Хотя всего-то надо:
- собирать на сессию решения проблемы людей, непосредственно соприкоснувшихся с ней (переживших ее) и способных рассказать о ней в фактах (даже, если это люди из других подразделений или компаний);
- если отсутствуют реальные факты и данные (например, вы не помните деталей, сомневаетесь), надо остановиться, не полениться и пойти собрать их, отложив решение проблемы;
Резюмируем…
В итоге у нас есть емкое определение проблемы, которое ставит акценты, что для эффективного решения проблем важно хорошо понять текущее состояние и представить себе желаемое. У нас есть чеклист в формате A3-Problem Report, который задает нам структуру работы над проблемой и выработки решения. У нас есть мощный инструмент для поиска первопричин 5Whys, т.е. позволяющий нам хорошо понять причины текущего состояния. Мы понимаем, руководствуясь принципом “Иди и смотри”, что в решении проблемы должны принимать участие люди “прочувствовавшие проблему”. Также мы понимаем, что при выработке решения надо оперировать реальными фактами и если их нет, остановиться и пойти в “эпицентр проблемы” и собрать их.
Остается только одна проблема, для которой мы не получили инструмент — это генерация идей и решений, т.е. как искать ответ на вопрос: “каким должно быть желанное состояние и как к нему можно было бы прийти (концепты решений)?”.
И это на самом деле проблема… Я часто встречаюсь с тем, что люди не могут “помечтать” и представить себе желаемое состояние и описать его важные атрибуты, а как мы теперь знаем, это очень важно для эффективного решения проблемы (надо же знать куда строить мост =). Чаще всего это случается по причине узкого профессионального кругозора и сильной “зашоренности”, который можно развивать только читая, изучая паттерны решений из отрасли, других отраслей, размышляя и т.д.
На данный момент, лично я решаю эту проблему собирая на сессию “решения проблем”, людей “хорошо представляющих себе проблему” еще и приглашаю парочку “генераторов”, людей с широким кругозором и хорошим воображением. В результате наши брейншторминги по генерации желаемого состояния и концепций решений проходят интереснее! Ну и конечно, надо стараться иметь, как можно больше таких “генераторов” прямо в составе вашей команды.
Хватит теории, покажи на практике…
Ок, будем считать, что с матчастью закончили, теперь давайте рассмотрим применение этого фреймворка на одном из реальных примеров, произошедших недавно в моей практике.
Команда разработки “отгрузила” клиенту очередную версию системы, которую она итеративно (2-х недельными итерациями) разрабатывает уже третий год. Новая версия была успешно установлена в промышленное использование и пользователям стала доступна новая функциональность!
Но, возникла проблема в “старой” функциональности…
Проблема: “После обновления системы до версии 2.1.2 у пользователя сломалась функциональность копирования “пакетов”, т.е. в результате копировался не тот “пакет”, который был выбран пользователем. Исправление этой ошибки (предоставления временного решения) он ждал 3 часа.”
Прежде чем продолжить разбирать решение этой проблемы, хочется отметить, что у этого продукта были большие проблемы с качеством, пользователи постоянно жаловались на возникающие ошибки, система тормозила и была неудобна в использовании. Надо было начинать принимать серьезные меры по скачкообразному выводу качества продукта на новый уровень (лучше поздно чем никогда). И поэтому было принято решение (и согласовано с клиентом), что при возникновении подобных ошибок в промышленной среде, стоит останавливать все работы, выполняемые в рамках итерации, и вырабатывать контрмеры, исключающие не просто эту ошибку, но и целый класс “подобных ошибок”.
В бережливом производстве есть принцип, который называется “Остановка конвейера” (Stop Line), т.е. если по линии “пошел брак”, он обязан остановить весь конвейер и вовлечь коллег в решение этой проблемы “на корню”.
В этот раз мы так и поступили. Все работы взятые в итерацию были остановлены. Команда разработки предоставила временное решение и собралась на сессию по решению возникшей проблемы (Problem Solving Session), грустно сев в кружок вокруг доски. В рамках сессии предполагалось разобрать случившуюся проблему “по косточкам” и выработать ряд контрмер, которые должны были исключить целый класс подобных проблем в будущем. Я проводил эту сессию в роли фасилитатора (будучи консультантом в этой компании).
Структура сессии была построена по формату А3 - Problem Report, т.е. в начале мы зафиксировали стартовую формулировку проблемы: “После обновления системы до версии 2.1.2 у пользователя сломалась функциональность копирования “пакета”, т.е. в результате копировался не тот “пакет”, который был выбран пользователем”.
Дальше перешли к анализу текущей ситуации, начали разбираться в природе проблемы. Для начала мы зафиксировали на флипчарте пользовательский сценарий и определенные условия в которых воспроизводилась ошибка. После этого начали описывать/рисовать (на доске) текущий алгоритм копирования “пакета”. В процессе описания алгоритма выяснилось, что никто не представляет себе “как на самом деле работает алгоритм”, были только догадки, но ни у одного из специалистов не было уверенности.
Строить свое решение на догадках было бы неверно и мы договорились, что разобьемся на пары и разойдемся на часа, чтобы провести исследование. Каждая пара должна была “посмотреть в код” и разобраться как работает текущий алгоритм копирования, чтобы вернуться к обсуждению проблемы во всеоружии.
Применение принципа “Иди и смотри” (Генти Генбуцу)
Увидев отсутсвие реальных фактов при рассмотрении “текущей ситуации”, мы остановили сессию и разошлись разбираться и выявлять достоверную информацию (да, нам для этого потребовалось реверс-инжинирить свою систему =).
В результате этого часового исследования, команда хорошо представляла себе текущий алгоритм копирования и нашла несколько “слабых мест” в его работе, т.е. алгоритм (который был спроектирован 3 года назад и ни разу не пересматривался) был мягко говоря “не железный”, хотя это одна из самых частых функций, которая применяется пользователем. Как выяснилось позже, в ней и раньше находились ошибки, подправлялись и находились снова…
Также исследование показало, что этот алгоритм используется для копирования и других сущностей в системе, и там есть риск возникновения подобных ошибок при “определенных условиях” (причем где-то этот алгоритм был просто скопирован copy-paste…). Кроме этого, алгоритм зависит от механизма фильтрации данных
Мы собрались снова для продолжения сессии по выработке контрмер и теперь достаточно быстро визуализировали на флипчарте текущий алгоритм копирования и двинулись дальше в анализ первопричин, используя технику 5Whys.
Начав от стартовой формулировки проблемы, мы последовательно задавали себе вопрос: “Почему?” и искали на него ответы, строя на доске дерево причинно-следственных связей.
Вот несколько примеров вопросов, которые мы перед собой ставили в процессе поиска первопричин и искали на них ответы:
- Почему после обновления некорректно работает копирование?
- Почему мы не отловили эту ошибку на стабилизации?
- Почему эта проблема не проявлялась ранее?
- Почему эта область не покрыта unit-тестами?
- Почему мы не проверяем подобные сценарии на стабилизации?
- Почему тестовая среда не позволила бы отловить подобную ошибку?
и т.д.
В результате у нас получилось дерево причинно-следственных связей с следующими ветвями:
- ветвь причин “неоптимальности текущего алгоритма копирования”;
- ветвь причин “почему не отловили это тестами”;
- ветвь причин “почему наша тестовая среда неоптимальна и не позволяет отлавливать подобные проблемы”;
На основании понимания текущего состояния мы сформировали перечень контрмер (концептов решения) для каждой ветви нашего дерева:
- переписывание текущего алгоритма на новый (совместно спроектировав новый алгоритм), с учетом что механизм используется для нескольких сущностей;
- рефакторинг механизма фильтрации;
- рефакторинг кода участвующего в сценарии копирования, чтобы покрыть unit-тестами;
- улучшение тестовой области, которая позволит писать тесты на подобные сценарии (генерация данных с определенной структурой и увеличение количества этих данных);
- покрытие функциональности копирования интеграционным тестами (улучшение имеющихся тестов) с учетом выявленного реального сценария;
Одним из самых сложных брейнштормингов в этой сессии была выработка нового “железного” алгоритма копирования, ребята долго спорили, предлагали и взвешивали решения и в результате пришли к единому видению удачного алгоритма.
В итоге мы составили план рефакторинга (с учетом, что будем реализовывать этот план в течение нескольких итераций) и ряд небольших задач по улучшению тестовой среды и улучшению покрытия интеграционными тестами.
Так как работ по рефакторингу было много, мы договорились с Заказчиком, что эту итерацию мы полностью 100% тратим на рефакторинг, а в последующих итерациях мы выделяем по 20% на рефакторинг, чтобы все задуманное планомерно реализовать.
Метрика, за которой мы договорились следить в процессе внедрения контрмер и оценивать их успешность — это количество ошибок выявляемых в этих функциональных областях как на этапе “стабилизации”, так и в процессе эксплуатации (т.е. в функциональности копирования “пакетов” и других сущностей). Для этого мы добавили в Jira возможность помечать ошибки “функциональными областями” и строим по этим данным статистические отчеты.
В итоге, мы за 1 день выработали контрмеры, за 3 итерации реализовали весь запланированный рефакторинг и за 6 месяцев подобных работ, количество выявляемых в системе ошибок при эксплуатации упало с 10–15/месяц до 1 ошибки в месяц. Магия!? Нет, кропотливый труд по “вдумчивому” решению всех возникающих проблем в продукте. Но расслабиться команде разработки пока рано у них еще уйма проблем с производительностью, качеством входных требований и т.д.
Как вы наверное и сами уловили, этот фреймворк для решения проблем можно применять как индивидуально, так и использовать для командного решения проблем (например как один из форматов проведения регулярных ретроспектив или при возникновении серьезных проблем, как описано в примере).
В завершении статьи, хотелось бы сказать, что мы рассмотрели только одну из областей бережливого производства, которая называется Problem Solving и может принести очень большую пользу вашим проектам, продуктам, командам. Но, это всего лишь небольшая часть бережливого производства, хотя и очень важная!
Вообще, бережливое производство — это целая система ценностей, принципов, подходов, техник и инструментов, которая развивается уже более 80 лет и позволяет организовать производство или разработку ПО так, чтобы поставлять ценность вашему потребителю быстро, качественно и затрачивать при этом все меньше и меньше усилий!
Чтобы проникнуться этим учением глубже, у вас есть уйма возможностей:
1. Можете почитать книги, вот ссылка на рекомендуемый список литературы;
2. Можете задать мне уточняющие вопросы и обсудить вашу ситуацию, добавляйтесь в друзья в Facebook;
3. Можете посетить мой тренинг в Стратоплане
(ближайший из них состоится 24–25.02.2017);
Удачи и до встречи!
