Как стать профессиональным Problem Solver’ом?

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

А, между тем, система Lean успешно развивается уже более 80 лет и приносит несомненную пользу.

Наша студенческая аудитория все чаще стала задавать вопросы и просить осветить эту тему. Сегодня мы делимся с вами статьей Михаила Рыжикова про одну из областей бережливого производства — Problem Solving (алгоритм решения проблем).

Михаил практикует Agile/Lean более 7 лет, прошел путь от консультанта по по Agile/Lean в компании Петер-Сервис до руководителя лаборатории разработки.

—————————————————————————————-

Как стать профессиональным Problem Solver’ом?

Популярно о ценностях, подходах и техниках Lean.

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

Что вы можете сказать о своем умении решать проблемы, которые возникают в ваших проектах, командах, продуктах? Есть ли у вас для этого какой-то эффективный подход или методика, гарантирующая результат?

В общем,

есть ли у вас проблемы с решением проблем? =)

Если вы на этот вопрос ответили “да”, то эта статья для вас. А если “нет”, то я бы с удовольствием прочитал статью о вашем опыте.

В статье мы рассмотрим фреймворк “по решению проблем”, пришедший к нам из бережливого производства (Lean / Toyota Production System) и “обкатанный” десятилетиями. Причем рассмотрим как теорию, так и применение этого фреймворка на примере из моей реальной практики. И я очень надеюсь, что вы попробуете его в работе, освоите, наберетесь опыта и станете настоящими Problem Solver’ами! Приступим?

Матчасть…

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

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

стат1

Вам, наверное, уже не терпится узнать: как же построить этот мост???

A3 — Problem Report

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

Можно сказать, что A3  —  это инструмент “три в одном”!

С одной стороны, A3 — это checklist, который задает тебе алгоритм для работы над проблемой и выработки решения (т.е. построение моста). И предлагает разбирать и решать проблему последовательно:

  • Background: сформулировать проблему, записать стартовую формулировку (как есть, главное не “буксовать” на этом этапе);
  • Current Conditions: разобраться в “контексте проблемы” и выписать все факты;
  • Goal/Target: сформулировать желаемое состояние, отразив его самые существенные атрибуты и метрики;
  • Analysis: провести анализ и выявить первопричины проблемы, построить дерево/граф причинно-следственных связей;
  • Countermeasures: разработать и описать концепт решения(ий) для этой проблемы;
  • Plan: выписать набор практических шагов для реализации концепта решения на практике;
  • Follow-Up: выписать контрольные точки и метрики, которые будут говорить нам об успешности нашего решения.

стат 2

С другой стороны, A3 — это формат бумаги А3 (canvas), который заставляет тебя быть лаконичным, использовать визуализацию и отмечать только самые важные аспекты рассматриваемой проблемы и предлагаемого решения. В результате, ты получаешь весь “контекст” проблемы и ее решения на “одном листе”, наглядно и доступно!

стат 3

А также, А3 — это инструмент достижения консенсуса, сбора мнений, валидации решения с привлечением умов твоих коллег. Имея такой артефакт, ты достаточно быстро можешь погрузить в контекст, любого из твоих коллег и презентовать ему решение для получения обратной связи (согласия, предложений/улучшений идеи).

стат 4

Root Cause Analysis  —  это важный ингредиент!

Прежде чем двинемся дальше, хочется остановиться подробнее на одном из этапов в работе над проблемой по формату А3 и обсудить техники поиска первопричин (Root Cause Analysis или Analysis). Для этого в бережливом производстве есть две очень мощные техники “5Почему” (5Whys) и Диаграмма Ишикавы (fishbone).

Я в основном применяю технику “5Почему” (5Whys). А реальный пример применения увидите в статье ниже, где мы будем использовать фреймворк при решении реальной проблемы.

В итоге, у нас теперь есть понимание, из каких “ингредиентов” состоит проблема (текущее состояние — пропасть — желаемое), у нас есть алгоритм выработки решения (A3  —  Problem Report) и мы владеем техникой 5Whys. К сожалению, этого может не хватить, чтобы эффективно решать проблемы…

Принцип: “Иди и смотри”

Еще в бережливом производстве есть очень важный принцип, которым должны владеть все “бережливые” менеджеры, он называется “Иди и смотри” (или по-японски “Генти Генбуцу”).
Основной смысл этого принципа очень прост: для того, чтобы принять правильное решение, вы должны “увидеть все своими глазами” (т.е. ни в коем случае не решать проблемы или принимать решения из своего кабинета с видом на Манхэттэн, основываясь на чужих выводах, рассказах и своих догадках), т.е. пойти в эпицентр проблемы, собрать факты и выработать решение на месте совместно со всеми участниками и пострадавшими.
К сожалению, часто происходит иначе. Либо за решение проблемы берутся люди, имеющие о ней лишь отдаленное представление… Либо, в процессе обсуждения проблемы, все оперируют выдуманными фактами и основываются “на догадках и предположениях…

Хотя всего-то надо:

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

Резюмируем…

В итоге, у нас есть емкое определение проблемы, которое ставит акценты, что для эффективного решения проблем важно хорошо понять текущее состояние и представить себе желаемое. У нас есть чеклист в формате A3-Problem Report, который задает нам структуру работы над проблемой и выработки решения. У нас есть мощный инструмент для поиска первопричин 5Whys, т.е. позволяющий нам хорошо понять причины текущего состояния. Мы понимаем, руководствуясь принципом “Иди и смотри”, что в решении проблемы должны принимать участие люди “прочувствовавшие проблему”. Также мы понимаем, что при выработке решения надо оперировать реальными фактами и если их нет, остановиться и пойти в “эпицентр проблемы” и собрать их.

Остается только одна проблема, для которой мы не получили инструмент  —  это генерация идей и решений, т.е. как искать ответ на вопрос: “каким должно быть желанное состояние и как к нему можно было бы прийти (концепты решений)?”.

И это на самом деле проблема… Я часто встречаюсь с тем, что люди не могут “помечтать” и представить себе желаемое состояние и описать его важные атрибуты, а как мы теперь знаем, это очень важно для эффективного решения проблемы (надо же знать куда строить мост =). Чаще всего это случается по причине узкого профессионального кругозора и сильной “зашоренности”, который можно развивать только читая, изучая паттерны решений из отрасли, других отраслей, размышляя и т.д.

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

Хватит теории, покажи на практике…

Ок, будем считать, что с матчастью закончили, теперь давайте рассмотрим применение этого фреймворка на одном из реальных примеров, произошедших недавно в моей практике.
Команда разработки “отгрузила” клиенту очередную версию системы, которую она итеративно (2-х недельными итерациями) разрабатывает уже третий год. Новая версия была успешно установлена в промышленное использование и пользователям стала доступна новая функциональность!

Но, возникла проблема в “старой” функциональности…

Проблема: “После обновления системы до версии 2.1.2 у пользователя сломалась функциональность копирования “пакетов”, т.е. в результате копировался не тот “пакет”, который был выбран пользователем. Исправление этой ошибки (предоставления временного решения) он ждал 3 часа.”

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

В бережливом производстве есть принцип, который называется “Остановка конвейера” (Stop Line), т.е. если по линии “пошел брак”, он обязан остановить весь конвейер и вовлечь коллег в решение этой проблемы “на корню”.
В этот раз мы так и поступили. Все работы, взятые в итерацию, были остановлены. Команда разработки предоставила временное решение и собралась на сессию по решению возникшей проблемы (Problem Solving Session), грустно сев в кружок вокруг доски. В рамках сессии предполагалось разобрать случившуюся проблему “по косточкам” и выработать ряд контрмер, которые должны были исключить целый класс подобных проблем в будущем. Я проводил эту сессию в роли фасилитатора(будучи консультантом в этой компании).

Структура сессии была построена по формату А3 — Problem Report, т.е. в начале мы зафиксировали стартовую формулировку проблемы: “После обновления системы до версии 2.1.2 у пользователя сломалась функциональность копирования “пакета”, т.е. в результате копировался не тот “пакет”, который был выбран пользователем”.

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

Строить свое решение на догадках было бы неверно и мы договорились, что разобьемся на пары и разойдемся на 2 часа, чтобы провести исследование. Каждая пара должна была “посмотреть в код” и разобраться как работает текущий алгоритм копирования, чтобы вернуться к обсуждению проблемы во всеоружии.

Применение принципа “Иди и смотри” (Генти Генбуцу)

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

В результате этого часового исследования, команда хорошо представляла себе текущий алгоритм копирования и нашла несколько “слабых мест” в его работе, т.е. алгоритм (который был спроектирован 3 года назад и ни разу не пересматривался) был мягко говоря “не железный”, хотя это одна из самых частых функций, которая применяется пользователем. Как выяснилось позже, в ней и раньше находились ошибки, подправлялись и находились снова…

Также исследование показало, что этот алгоритм используется для копирования и других сущностей в системе, и там есть риск возникновения подобных ошибок при “определенных условиях” (причем где-то этот алгоритм был просто скопирован copy-paste…). Кроме этого, алгоритм зависит от механизма фильтрации данных

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

Начав от стартовой формулировки проблемы, мы последовательно задавали себе вопрос: “Почему?” и искали на него ответы, строя на доске дерево причинно-следственных связей.

Вот несколько примеров вопросов, которые мы перед собой ставили в процессе поиска первопричин и искали на них ответы:

  • Почему после обновления некорректно работает копирование?
  • Почему мы не отловили эту ошибку на стабилизации?
  • Почему эта проблема не проявлялась ранее?
  • Почему эта область не покрыта unit-тестами?
  • Почему мы не проверяем подобные сценарии на стабилизации?
  • Почему тестовая среда не позволила бы отловить подобную ошибку?
    и т.д.

В результате у нас получилось дерево причинно-следственных связей со следующими ветвями:

  • ветвь причин “неоптимальности текущего алгоритма копирования”;
  • ветвь причин “почему не отловили это тестами”;
  • ветвь причин “почему наша тестовая среда неоптимальна и не позволяет отлавливать подобные проблемы”;

стат 6

На основании понимания текущего состояния мы сформировали перечень контрмер (концептов решения) для каждой ветви нашего дерева:

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

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

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

Так как работ по рефакторингу было много, мы договорились с Заказчиком, что эту итерацию мы полностью 100% тратим на рефакторинг, а в последующих итерациях мы выделяем по 20% на рефакторинг, чтобы все задуманное планомерно реализовать.

Метрика, за которой мы договорились следить в процессе внедрения контрмер и оценивать их успешность  —  это количество ошибок, выявляемых в этих функциональных областях как на этапе “стабилизации”, так и в процессе эксплуатации (т.е. в функциональности копирования “пакетов” и других сущностей). Для этого мы добавили в Jira возможность помечать ошибки “функциональными областями” и строим по этим данным статистические отчеты.

В итоге, мы за 1 день выработали контрмеры, за 3 итерации реализовали весь запланированный рефакторинг и за 6 месяцев подобных работ, количество выявляемых в системе ошибок при эксплуатации упало с 10–15/месяц до 1 ошибки в месяц. Магия!? Нет, кропотливый труд по “вдумчивому” решению всех возникающих проблем в продукте. Но расслабиться команде разработки пока рано, у них еще уйма проблем с производительностью, качеством входных требований и т.д.
Как вы наверное и сами уловили, этот фреймворк для решения проблем можно применять как индивидуально, так и использовать для командного решения проблем (например как один из форматов проведения регулярных ретроспектив или при возникновении серьезных проблем, как описано в примере).

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

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

Чтобы проникнуться этим учением глубже, у вас есть уйма возможностей: