Еще ни разу на страницах наших блогов, в рассылках и статьях мы не говорили подробно про бережливое производство.
А, между тем, система Lean успешно развивается уже более 80 лет и приносит несомненную пользу.
Наша студенческая аудитория все чаще стала задавать вопросы и просить осветить эту тему. Сегодня мы делимся с вами статьей Михаила Рыжикова про одну из областей бережливого производства – Problem Solving (алгоритм решения проблем).
Михаил практикует Agile/Lean более 7 лет, прошел путь от консультанта по по Agile/Lean в компании Петер-Сервис до руководителя лаборатории разработки.
—————————————————————————————-
Популярно о ценностях, подходах и техниках Lean.
Как бы мы не пытались тщательно планировать, составлять подробные реестры рисков или закладывать в оценки “буфер”, на нашем пути возникают преграды. И от того, насколько эффективно мы умеем решать возникающие проблемы, зависит успех нашего проекта, производительность и сплоченность нашей команды, качество и востребованность продукта.
Что вы можете сказать о своем умении решать проблемы, которые возникают в ваших проектах, командах, продуктах? Есть ли у вас для этого какой-то эффективный подход или методика, гарантирующая результат?
В общем,
есть ли у вас проблемы с решением проблем? =)
Если вы на этот вопрос ответили “да”, то эта статья для вас. А если “нет”, то я бы с удовольствием прочитал статью о вашем опыте.
В статье мы рассмотрим фреймворк “по решению проблем”, пришедший к нам из бережливого производства (Lean / Toyota Production System) и “обкатанный” десятилетиями. Причем рассмотрим как теорию, так и применение этого фреймворка на примере из моей реальной практики. И я очень надеюсь, что вы попробуете его в работе, освоите, наберетесь опыта и станете настоящими Problem Solver’ами! Приступим?
В бережливом производстве проблема — это разница между стандартом и реальностью, т.е. есть текущее состояние, в котором мы находимся и есть желаемое состояние, в котором мы хотели бы находиться, а между ними пропасть!
Соответственно, решение проблемы — это создание моста для перехода из текущего состояния в желаемое.
Вам, наверное, уже не терпится узнать: как же построить этот мост???
Для этого в бережливом производстве есть очень интересный инструмент, который называется A3 — Problem Report.
Можно сказать, что A3 — это инструмент “три в одном”!
С одной стороны, A3 — это checklist, который задает тебе алгоритм для работы над проблемой и выработки решения (т.е. построение моста). И предлагает разбирать и решать проблему последовательно:
С другой стороны, A3 — это формат бумаги А3 (canvas), который заставляет тебя быть лаконичным, использовать визуализацию и отмечать только самые важные аспекты рассматриваемой проблемы и предлагаемого решения. В результате, ты получаешь весь “контекст” проблемы и ее решения на “одном листе”, наглядно и доступно!
А также, А3 — это инструмент достижения консенсуса, сбора мнений, валидации решения с привлечением умов твоих коллег. Имея такой артефакт, ты достаточно быстро можешь погрузить в контекст, любого из твоих коллег и презентовать ему решение для получения обратной связи (согласия, предложений/улучшений идеи).
Прежде чем двинемся дальше, хочется остановиться подробнее на одном из этапов в работе над проблемой по формату А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.
Начав от стартовой формулировки проблемы, мы последовательно задавали себе вопрос: “Почему?” и искали на него ответы, строя на доске дерево причинно-следственных связей.
Вот несколько примеров вопросов, которые мы перед собой ставили в процессе поиска первопричин и искали на них ответы:
В результате у нас получилось дерево причинно-следственных связей со следующими ветвями:
На основании понимания текущего состояния мы сформировали перечень контрмер (концептов решения) для каждой ветви нашего дерева:
Одним из самых сложных брейнштормингов в этой сессии была выработка нового “железного” алгоритма копирования, ребята долго спорили, предлагали и взвешивали решения и в результате пришли к единому видению удачного алгоритма.
В итоге мы составили план рефакторинга (с учетом, что будем реализовывать этот план в течение нескольких итераций) и ряд небольших задач по улучшению тестовой среды и улучшению покрытия интеграционными тестами.
Так как работ по рефакторингу было много, мы договорились с Заказчиком, что эту итерацию мы полностью 100% тратим на рефакторинг, а в последующих итерациях мы выделяем по 20% на рефакторинг, чтобы все задуманное планомерно реализовать.
Метрика, за которой мы договорились следить в процессе внедрения контрмер и оценивать их успешность — это количество ошибок, выявляемых в этих функциональных областях как на этапе “стабилизации”, так и в процессе эксплуатации (т.е. в функциональности копирования “пакетов” и других сущностей). Для этого мы добавили в Jira возможность помечать ошибки “функциональными областями” и строим по этим данным статистические отчеты.
В итоге, мы за 1 день выработали контрмеры, за 3 итерации реализовали весь запланированный рефакторинг и за 6 месяцев подобных работ, количество выявляемых в системе ошибок при эксплуатации упало с 10–15/месяц до 1 ошибки в месяц. Магия!? Нет, кропотливый труд по “вдумчивому” решению всех возникающих проблем в продукте. Но расслабиться команде разработки пока рано, у них еще уйма проблем с производительностью, качеством входных требований и т.д.
Как вы наверное и сами уловили, этот фреймворк для решения проблем можно применять как индивидуально, так и использовать для командного решения проблем (например как один из форматов проведения регулярных ретроспектив или при возникновении серьезных проблем, как описано в примере).
В завершении статьи хотелось бы сказать, что мы рассмотрели только одну из областей бережливого производства, которая называется Problem Solving и может принести очень большую пользу вашим проектам, продуктам, командам. Но это всего лишь небольшая часть бережливого производства, хотя и очень важная!
Вообще, бережливое производство — это целая система ценностей, принципов, подходов, техник и инструментов, которая развивается уже более 80 лет и позволяет организовать производство или разработку ПО так, чтобы поставлять ценность вашему потребителю быстро, качественно и затрачивать при этом все меньше и меньше усилий!
Чтобы проникнуться этим учением глубже, у вас есть уйма возможностей:
Удачи и до встречи!
Весь 2021 год мы уже работали как компания, юридически расположенная в Евросоюзе, и планомерно переносили в эту юрисдикцию основные бизнес-процессы, включая прием платежей, основные расходы и уплату налогов.
Справившись с первым шоком и стабилизировав работу команды, 01.03.2022 мы заявили, что останавливаем коммерческие проекты и ближайший месяц перебрасываем все силы на проведение поддерживающих психологических семинаров для всех, кому нужна поддержка в это непростое время.
Понимая, что наш статус EU-компании и принятое решение остановить все коммерческие активности дают нам немного времени (наши налоги уже не работают против людей), следующие 10 дней мы уделили организации и запуску открытого бесплатного проекта поддержки для всех наших клиентов и подписчиков.
За это время стало окончательно понятно, что мы больше не можем поддерживать своими налогами путь, который выбрала РФ, поэтому мы прекращаем экономическую деятельность в России — наша компания не принимает платежи и не платит налоги на территории РФ.
Текущие, запущенные проекты мы доводим до конца, так как всегда выполняем все взятые на себя обязательства, как и все предыдущие 12 лет нашей бизнес-практики.
Мы — бизнес-школа, учебное заведение. В мировой истории было достаточно позорных моментов, когда образование было недоступно людям с определенным цветом кожи, определенной национальностью или в силу других дискриминационных признаков.
Мы не поддерживаем дискриминацию в любом ее проявлении, в том числе по цвету паспорта людей, которые к нам приходят.
Мы будем работать с теми студентами, кто готов при поступлении подтвердить свою позицию относительно дискриминации и согласиться с нашими правилами работы.
Мы всегда работали на русском языке, с момента основания Школы. Русский — 8-й язык по количеству носителей в мире и это язык, на котором мы думаем и работаем. Наша задача — оставаться лучшей школой для тимлидов и менеджеров, и мы можем это сделать, работая на русском.
С пониманием ко всем, кто придерживается другой точки зрения, мы оставляем за собой выбор принимать обоснованные и последовательные решения в интересах наших клиентов во всех уголках мира.
