Практика — это когда всё работает, но никто не понимает, как. Теория — когда ничего не работает, но все точно знают, почему. Мы же пришли к сочетанию теории с практикой: ничего не работает — и никто не понимает, почему.
В функционировании любого растущего бизнеса — не только в IT, но и в других областях — наступает момент, когда заброшенные в дальний угол и уже успевшие покрыться благородной патиной проблемы становится невозможно игнорировать. Их последствия дают о себе знать в самых неожиданных ситуациях. Есть не один десяток методик, позволяющих разобраться с проблемами и заставить бизнес работать, но начинать приходится всегда с одного и того же: анализа первопричин этих самых проблем. И сегодня Роботам хотелось бы поговорить об этом — не только переведя статью о методах поиска первопричин бизнес-тренера по IT и специалиста по Agile, Scrum и Kanban Хенрика Книберга — но и рассказав о том, как Роботы исправили несколько собственных поломок.
Хенрик Книберг. Цель статьи
Причинно-следственные диаграммы (cause-effect diagrams) — простой и удобный способ выполнения анализа первопричины (root cause analysis). Я применяю эти диаграммы долгие годы, помогая бизнесу распознавать и решать широкий спектр проблем — как технических, так и организационных. Цель статьи — показать, как работают причинно-следственные диаграммы и научить читателя строить их для собственных нужд.
Устранение проблем, а не симптомов
Ключ к эффективному решению проблем — перво-наперво убедиться в том, что вы понимаете ту проблему, которую пытаетесь решить. Почему она требует решения, как определить, когда она будет решена, и в чем первопричина этой проблемы.
Нередко “симптомы” проявляются в одном месте, хотя истинная причина проблемы находится совсем в другом. Если просто заниматься устранением симптомов, не пытаясь оценить ситуацию более глубоко, велика вероятность, что проблема вновь даст о себе знать позднее — но уже в иной форме.
Проблема: Дым в спальне.
Плохое решение: Открыть окно и снова лечь спать.
Хорошее решение: Найти источник дыма и разобраться с ним. Упс! А в подвале-то пожар! Дальнейшие действия — потушить огонь; понять, почему он вообще возник; установить пожарную сигнализацию, чтобы в следующий раз узнать о проблеме раньше.
Проблема: Горячий лоб, усталость.
Плохое решение: Приложить ко лбу лёд, чтобы остудить его. Съесть сахара для бодрости. Продолжить работу.
Хорошее решение: Померить температуру. Да у меня жар! Дальнейшие действия — отправиться домой отдыхать.
Проблема: Утечка памяти на сервере.
Плохое решение: Докупить памяти.
Хорошее решение: Найти и устранить источник утечки памяти. Провести тестирование, чтобы избежать утечек в будущем.
… и далее в том же духе.
Большая часть проблем в организациях носит системный характер. Система (бизнес) сбоит, и сбой надо устранить. Пока не ясна первопричина этого сбоя, большинство попыток разобраться с проблемой будут неэффективны или даже контрпродуктивны.
Мышление в формате A3 и бережливый подход к решению проблем
Один из основополагающих принципов бережливого мышления — это Кайдзен — постоянное совершенствование процессов. В одной из самых успешных компаний мира, Toyota, связывают значительную долю успеха со своей высокой дисциплиной в том, что касается подхода к решению проблем. Иногда такой подход именуют “мышлением в формате A3” (знания, полученные в ходе каждой “сессии” по решению проблем, фиксируются на листах A3).
Вот пример и темплейт:
www.crisp.se/gratis-material-och-guider/a3-template
При “A3-подходе” значительная часть времени (левая сторона листа) отводится на анализ и визуализацию анализа первопричины проблемы и предшествует выработке каких-либо решений. Причинно-следственные диаграммы — не единственный метод анализа первопричины. Существуют и другие: например, систематизация потока создания ценности (value stream mapping) и построение диаграммы Исикавы или, как ее еще называют, диаграммы “рыбьей кости”. Образец A3 выше содержит карту потока создания ценности (сверху слева) и причинно-следственную диаграмму (снизу слева).
Причинно-следственные диаграммы хороши своей интуитивностью и отсутствием необходимости в дополнительных разъяснениях (особенно в сравнении с диаграммами “рыбьей кости”). Еще одно преимущество — возможность иллюстрировать повторяющиеся порочные циклы, что с точки зрения системного мышления крайне полезно. Далее речь пойдет о том, как эффективно создавать и использовать такие диаграммы.
Как использовать причинно-следственные диаграммы
Базовый процесс выглядит следующим образом:
Следующий этап — follow up. Если контрмеры сработали — мои поздравления! Если нет — не отчаивайтесь. Проанализируйте, почему они не сработали, обновите диаграмму с поправкой на полученные знания и попробуйте другие контрмеры.
По сути контрмеры являются не решением, а экспериментом. Ваша гипотеза состоит в том, что контрмеры решат (или минимизируют) проблему, но тут никогда нельзя быть полностью уверенным. На самом деле, вы “тыкаете острой палкой” в свою систему, проверяя, как она среагирует. Поэтому follow up — это важно.
Ошибка, на самом деле, означает, что ваша система посылает вам сигналы, к которым стоит прислушаться. Единственная реальная ошибка — это неспособность учиться на ошибках!
Пример 1: нехватка парного программирования
Один клиент попросил помочь ему выяснить, из-за чего в его бизнесе не используются приемы XP вроде парного программирования и разработки через тестирование (TDD). “Мы знаем, что должны это делать, но не делаем”, говорил клиент.
Является ли отсутствие TDD и парного программирования реальной проблемой? Как обычно, зачастую вещи, которые мы называем проблемами, ими не являются, а оказываются просто симптомами.
Q: Каковы последствия игнорирования парного программирования и TDD?
A: Мы считаем, что использование этих практик улучшило бы качество кода.
Q: Каковы последствия плохого качества кода? Сталкивались ли вы с реальными проблемами, вызванными плохим качеством кода?
A: Да, у нас вылетали демо. Демо – ключевой элемент нашего бизнеса, поэтому это реальная проблема.
OK, рассмотрим один из элементов и проверим, можем ли мы выстроить связь до самой “основы”.
Q: Почему же вы не практикуете парное программирование?
A: Потому что многие боятся, что оно не сработает и мы потратим время впустую. У нас нет доказательства того, что оно работает.
Q: Какие доказательства вам нужны?
A: Ну, мы видели исследования, которые показывают, что это эффективно. Но у нас в компании никто по сути не пытался внедрить такие практики, поэтому мы не уверены в успехе.
Вот первая петля:
Они не хотят внедрять новые практики, потому что не уверены, сработают ли они. И не знают, работают ли они, поскольку не пробовали их внедрять…
Q: Почему вы хотя бы не сделали попытку использовать парное программирование в порядке эксперимента?
A: У нас нет времени на эксперименты.
Q: Почему?
A: Потому что у нас нет временного резерва. Каждый час подотчетный. А клиенты продолжают заваливать нас работой.
Q: Почему клиенты не дают вам возможность самостоятельно управлять своим временем и считают возможным наваливать на вас работу в любой удобный момент?
A: Они не доверяют нам самостоятельно распределять время.
Отсутствие доверия также ведет к боязни неудачи в целом, что, само собой, уменьшает вероятность экспериментального использования новых приемов вроде парного программирования без гарантий, что они сработают.
Получается, что здесь две глобальных первопричины: отсутствие доверия и управленческая установка на учет каждого часа. А теперь вернемся к общей картине.
Отсутствие доверия между клиентом и заказчиком оказалось первопричиной того, что не внедряются XP-практики, такие как TDD и парное программирование. Это влечет за собой плохое качество, из-за которого вылетают демо. И вы ни за что не догадаетесь: вылетающие демо снижат взаимное доверие еще больше. Это — порочный круг!
Интересно, что мы выполняли этот анализ в ходе двухдневного воркшопа примерно с 25 людьми. Вначале мы говорили в основном о технических вещах — как начать работу с TDD и парным программированием. Такой подход оказался не особенно эффективным, вместо этого мы разделились на группы и решили, что каждая группа выбирает собственную проблему и начинает строить причинно-следственную диаграмму и формулировать решение проблемы на листах A3. Интересно, что несколько групп, которые анализировали на первый взгляд разные проблемы, в итоге пришли к одной и той же первопричине: отсутствие доверия. Диаграмма выше — лишь один из примеров, которые иллюстрируют это.
Таким образом, к концу мастер-класса разговор шел уже о том, как увеличить степень доверия между клиентом и девелопером. Это был неожиданный поворот воркшопа. Для начала мы условились, что в следующий раз пригласим на воркшоп “их” (клиентов), что должно снизить частоту противопоставления “мы” и “они”.
Пример 2: долгий релизный цикл
Предположим, у нас есть проблема: мы всегда срываем дедлайны. Точнее говоря, наши релизы всегда выходят позже запланированного времени.
Проблема является проблемой только если она мешает вам в достижении цели. Поэтому в первую очередь стоит определить цель и думать о последствиях проблемы непосредственно в контексте вашей цели. В этом поможет вопрос “И что?”, который надо задавать, пока не удастся выявить очевидный урон.
Предположим, что цель — осчастливить клиентов и получить макcимальную выручку. Диалог может выглядеть примерно так:
Q: “В чем негативный эффект того, что релизы откладываются? Какие могут быть последствия?”
A: “Задержки делают наши релизные циклы длинными”
Q: “И что?”
A: “Это откладывает получение выручки и негативно влияет на скорость денег в компании. Еще мы из-за этого теряем клиентов, так как они нетерпеливы.”
В процессе диалога мы добавляем ячейки и причинно-следственные стрелки в диаграмму. Обычно я стараюсь двигаться “по восходящей” от изначально заявленной проблемы, “составляя карту” ее последствий. Но это не строгое правило.
То есть выходит, что задержка релизов на самом деле проблемой не является. Истинные проблемы — это задержка выручки и потеря клиентов. На этом этапе необходимо рассмотреть три момента:
Есть ли иные факторы, ведущие к потере клиентов и задержке выручки? Если да, можно ли считать, что всему виной задержка релизов или нам стоит переключить внимание на что-то еще? Можно ли выразить проблему количественно? Сколько мы потеряли денег? Сколько ушло клиентов? Эти данные помогут нам оценить объем усилий, которые оправдывают себя в решении обозначенной проблемы.
Как мы поймем, что решили проблему? Предположим, в кабинет врывается счастливый консультант и гордо заявляет: “Я решил проблему!”. Как определить, что это не блеф?
После анализа последствий проблемы приходит время копать вглубь — к первопричине.
И тут на помощь приходят вопросы “Почему”. Да, существует техника “пяти почему”, о который вы могли слышать, если изучали бережливое мышление.
Q: “Почему релизы задерживаются?”
A: “Потому что растет объем работы.”
Q: “Почему?”
A: “Потому что клиенты выдумывают все новые и новые фичи и настаивают на том, что их надо добавить в текущий релиз, отказываясь исключить из него фичи с низким приоритетом.”
Q: “Почему? Почему бы не отложить добавление новых фич до новых релизов?”
A: “Потому что релизный цикл столь долог, что новые требования возникают до очередного релиза”
Тут пока только три “Почему”. Но вы поняли принцип. Диалог позволяет сформировать следующую картину:
Порочный цикл отмечен красными стрелками. Повторяющиеся проблемы почти всегда включают в себя подобные “петли”, но на то, чтобы их выявить, требуется некоторое время. Если вы нашли такую петлю, то шансы на успешное и бесповоротное решение проблем в разы возрастают!
Наша цель — выявить первопричину этой проблемы, чтобы мы могли достичь максимального эффекта минимальными усилиями. На первом этапе можно легко упустить из вида важные причины, поэтому вернемся назад и зададим еще несколько вопросов.
Q: “Почему релизный цикл долгий? Задержка релизов — единственная причина?”
A: “Ну, на самом деле, даже без задержек наши запланированные релизные циклы достаточно длинные.”
Q: “Насколько долог ваш запланированный релизный цикл?”
A: “Раз в квартал.”
Q. “Но почему он такой долгий?”
A: “Потому что релизы — вещь дорогостоящая и сложная.”
Q: “Почему?”
A: “Потому что в каждом релизе куча деталей и еще потому что это ручной труд.”
С левой стороны мы видим очередной порочный цикл (красные стрелки)! Долгий интервал между релизами означает, что каждая новая версия включает большое число обновлений, что делает выпуск продукта сложным и дорогим процессом. Из-за этого мы не хотим делать релизы часто.
Как вы заметили, тут я решил отметить две первопричины. А теперь — контрмеры:
Первопричина
Недостаток автоматизации в процессе подготовки релизов
Контрмера
Автоматизировать процесс подготовки релизов
Первопричина
Низкоприоритетные фичи не исключаются из релизов
Контрмера
Договориться с клиентом, что новые фичи могут быть добавлены в релиз только если из него исключается то же число низкоприоритетных фич
Не существует строгого правила, говорящего, какая причина является первопричиной, но некоторые признаки есть:
Техника “пяти почему” называется так потому, что обычно от первопричины нас отделяет примерно пять вопросов. Есть тенденция останавливаться преждевременно. Этого делать не надо: продолжайте копать!
Стоит принять во внимание, что изначально поставленная проблема — задержка релизов — на деле оказалась не проблемой и не первопричиной. Это был просто симптом. Мы использовали его в качестве предлога для того, чтобы выстроить причинно-следственную связь по восходящей, чтобы выявить истинную проблему, а затем — по нисходящей, чтобы определить первопричину. Это позволяет выработать эффективные контрмеры со всем знанием дела.
Без анализа этого типа есть риск прийти к поспешным выводам и совершить неэффективные и контрпродуктивные изменения. Например, наняв дополнительных сотрудников, хотя суть проблемы лежит вовсе не в количестве рабочей силы. Или изменив систему поощрения (поощряя людей за то, что они делают работу в срок, и наказывая за сдачу работы с опозданием), хотя существующая система поощрения не имела ничего общего с проблемой.
Пример 3: дефекты, в производственном цикле
Представим, что у нас проблемы с дефектным кодом, который запускается в продакшн.
Q: И что?
A: Дефекты злят наших клиентов
Q: Почему дефекты запускаются в продакшн?
A: Потому что они не прошли необходимое тестирование до релиза.
Q: Почему не было тестирования?
И т.д.
И вот что у нас получается:
Два порочных цикла! Смотрите на красные стрелки.
Петля 1 (внутренняя петля): Дефекты в продукте вынуждают вносить срочные изменения, что отвлекает команду от работы. Поскольку сотрудники не освобождаются от основного объема задач, они находятся в стрессе и не имеют времени, чтобы должным образом протестировать новые релизы. Что, само собой, ведет к еще большему числу дефектов на уровне всего производства.
Петля 2 (внешняя петля): Так как сотрудники пребывают в стрессе, времени на написание автоматических тестовых скриптов у них также нет. Следствие — общий недостаток автоматизации в тестировании, что все больше усложняет регрессионное тестирование новых релизов. Это, само собой, ведет к дефектам в продакшене и необходимости вносить срочные изменения. И как следствие — к еще большему стрессу.
Но и это еще не все!
Команды терпеть не могут, когда их отвлекают. Процесс работы нарушает и в конечном итоге убивает мотивацию. Это может быть объяснением высокой текучки кадров! Таким образом, решая лежащую в корне проблему (дефекты в продакшене), мы получаем дополнительный бонус в виде уменьшения текучки персонала.
Это еще одно преимущество причинно-следственного анализа. Обычно первопричина является причиной более, чем одной проблемы (именно поэтому она называется “root” — основной или корневой).
Причинно-следственный анализ: опыт Роботов
Борис Рябчиков, менеджер проектов:
Пример 4: Целая куча проблем
А вот и более масштабный пример. В организации использовали методологию Scrum, но столкнулись с некоторыми проблемами. В результате нескольких интервью и воркшопов родилась причинно-следственная диаграмма, которая показала, что на самом деле в команде неправильно использовали Scrum, что и вызывало проблемы.
Всем стало очевидно, что многие из первопричин можно было бы устранить путем верного использования Scrum (например, реорганизация в кросс-функциональные команды, уверенность в том, что в каждой команде есть владелец продукта). Это послужило толчком для организационных изменений, которые в итоге устранили многие из первопричин (зеленые звезды). Следующим шагом должно было стать улучшение автоматизации тестирования.
Конечно, Scrum — не панацея. На самом деле, иногда Scrum сам по себе является проблемой и тогда для решения требуются другие техники, например, Kanban.
Практические вопросы — как создавать и поддерживать диаграммы
Работа в одиночку
Когда я делаю диаграммы один, самыми удобными инструментами мне представляются Visio или Powerpoint. Они позволяют быстро перемещать элементы, менять размеры ячеек и оперативно осуществлять бэкап в процессе работы над изображением.
Работа небольшими группами (2 — 8 человек)
Соберитесь около доски или флипчарта. Вместо ячеек используйте стикеры, соединяя их стрелками, нарисованными от руки. Доска предпочтительнее, так как на ней можно стирать и перерисовывать стрелки по мере перемещения стикеров. Пусть участвуют все члены группы, а не один человек. Важно не забыть сделать четкое фото того, что получилось, и разослать его всем участникам после завершения встречи.
Работа более крупными группами (9 — 30 человек)
Пусть члены группы разобьются на небольшие команды, каждая из которых сфокусируется на определенной проблеме. Работа несколькими командами над одной и той же проблемой полезна: можно прийти к одному и тому же или разным выводам, и оба результата будут интересны. Каждая команда работает с помощью отдельного флипчарта/доски и стикеров. Периодически команды должны собираться на короткие совместные обсуждения и делиться опытом.
Работа с диаграммой в перспективе
Пусть диаграмма останется в программе, которую вы использовали: Visio или Powerpoint. Если вы решите к ней снова вернуться в рамках воркшопа, определите его цель: демонстрация диаграммы или ее обновление. Если это обновление, повторите ее на доске/флипчарте при помощи стикеров и стрелок, чтобы участники воркшопа могли эффективно сообща работать над диаграммой. После встречи “синхронизируйте” получившиеся результаты с электронными инструментами.
Этот тип синхронизации отнимает некоторое время, но зачастую оно того стоит. Для совместной работы ничто не превзойдет реальные инструменты: доску и стикеры.
Опасности
Чересчур много стрелок и ячеек
Случается, что диаграмма становится настолько хаотичной, что ее невозможно разобрать. Тогда ее надо упростить. Вот некоторые техники:
Простота
Это упрощенный тип причинно-следственных диаграмм — так задумано специально. Он не заменяет собой личное взаимодействие. Если вам требуются более продвинутые или формализованные методики, обратитесь к литературе по системному мышлению. Например, “Пятая дисциплина” Питера Сенге. Но учтите: даже “совершенная” диаграмма не имеет особой ценности, если понять ее может только доктор наук.
Переход на личности
Избегайте персональных обвинений такого типа:
Проблемы решаются максимально эффективным образом, если исходить из того, что все они системны. Конечно, есть неуклюжие люди. Но даже если это доставляет нам существенные недобства, проблема все равно носит системный характер: существует система, в которой неуклюжие люди не считаются таковыми, или система, которая впускает внутрь ужасно неуклюжих людей, но при этом не помогает им становиться менее неуклюжими, и так далее. Следует особо подчеркнуть: относитесь ко всем проблемам как к системным.
В функционировании любого растущего бизнеса — не только в IT, но и в других областях — наступает момент, когда заброшенные в дальний угол и уже успевшие покрыться благородной патиной проблемы становится невозможно игнорировать. Их последствия дают о себе знать в самых неожиданных ситуациях. Есть не один десяток методик, позволяющих разобраться с проблемами и заставить бизнес работать, но начинать приходится всегда с одного и того же: анализа первопричин этих самых проблем. И сегодня Роботам хотелось бы поговорить об этом — не только переведя статью о методах поиска первопричин бизнес-тренера по IT и специалиста по Agile, Scrum и Kanban Хенрика Книберга — но и рассказав о том, как Роботы исправили несколько собственных поломок.
Хенрик Книберг. Цель статьи
Причинно-следственные диаграммы (cause-effect diagrams) — простой и удобный способ выполнения анализа первопричины (root cause analysis). Я применяю эти диаграммы долгие годы, помогая бизнесу распознавать и решать широкий спектр проблем — как технических, так и организационных. Цель статьи — показать, как работают причинно-следственные диаграммы и научить читателя строить их для собственных нужд.
Устранение проблем, а не симптомов
Ключ к эффективному решению проблем — перво-наперво убедиться в том, что вы понимаете ту проблему, которую пытаетесь решить. Почему она требует решения, как определить, когда она будет решена, и в чем первопричина этой проблемы.
Нередко “симптомы” проявляются в одном месте, хотя истинная причина проблемы находится совсем в другом. Если просто заниматься устранением симптомов, не пытаясь оценить ситуацию более глубоко, велика вероятность, что проблема вновь даст о себе знать позднее — но уже в иной форме.
Проблема: Дым в спальне.
Плохое решение: Открыть окно и снова лечь спать.
Хорошее решение: Найти источник дыма и разобраться с ним. Упс! А в подвале-то пожар! Дальнейшие действия — потушить огонь; понять, почему он вообще возник; установить пожарную сигнализацию, чтобы в следующий раз узнать о проблеме раньше.
Проблема: Горячий лоб, усталость.
Плохое решение: Приложить ко лбу лёд, чтобы остудить его. Съесть сахара для бодрости. Продолжить работу.
Хорошее решение: Померить температуру. Да у меня жар! Дальнейшие действия — отправиться домой отдыхать.
Проблема: Утечка памяти на сервере.
Плохое решение: Докупить памяти.
Хорошее решение: Найти и устранить источник утечки памяти. Провести тестирование, чтобы избежать утечек в будущем.
… и далее в том же духе.
Большая часть проблем в организациях носит системный характер. Система (бизнес) сбоит, и сбой надо устранить. Пока не ясна первопричина этого сбоя, большинство попыток разобраться с проблемой будут неэффективны или даже контрпродуктивны.
Мышление в формате A3 и бережливый подход к решению проблем
Один из основополагающих принципов бережливого мышления — это Кайдзен — постоянное совершенствование процессов. В одной из самых успешных компаний мира, Toyota, связывают значительную долю успеха со своей высокой дисциплиной в том, что касается подхода к решению проблем. Иногда такой подход именуют “мышлением в формате A3” (знания, полученные в ходе каждой “сессии” по решению проблем, фиксируются на листах A3).
Вот пример и темплейт:
www.crisp.se/gratis-material-och-guider/a3-template
При “A3-подходе” значительная часть времени (левая сторона листа) отводится на анализ и визуализацию анализа первопричины проблемы и предшествует выработке каких-либо решений. Причинно-следственные диаграммы — не единственный метод анализа первопричины. Существуют и другие: например, систематизация потока создания ценности (value stream mapping) и построение диаграммы Исикавы или, как ее еще называют, диаграммы “рыбьей кости”. Образец A3 выше содержит карту потока создания ценности (сверху слева) и причинно-следственную диаграмму (снизу слева).
Причинно-следственные диаграммы хороши своей интуитивностью и отсутствием необходимости в дополнительных разъяснениях (особенно в сравнении с диаграммами “рыбьей кости”). Еще одно преимущество — возможность иллюстрировать повторяющиеся порочные циклы, что с точки зрения системного мышления крайне полезно. Далее речь пойдет о том, как эффективно создавать и использовать такие диаграммы.
Как использовать причинно-следственные диаграммы
Базовый процесс выглядит следующим образом:
- Выберите проблему — все что угодно, что вас беспокоит — и запишите ее.
- Проследите ее “движение по восходящей”, чтобы оценить последствия для бизнеса, “очевидный урон”, который наносит ваша проблема.
- Проследите ее “движение по нисходящей”, чтобы выявить первопричину (или первопричины).
- Определите и подчеркните порочные циклы.
- Повторите вышеуказанные шаги несколько раз, чтобы скорректировать диаграмму.
- Определите, решением каких из первопричин вы займетесь, какими методами будете это делать (какие контрмеры можно принять).
Следующий этап — follow up. Если контрмеры сработали — мои поздравления! Если нет — не отчаивайтесь. Проанализируйте, почему они не сработали, обновите диаграмму с поправкой на полученные знания и попробуйте другие контрмеры.
По сути контрмеры являются не решением, а экспериментом. Ваша гипотеза состоит в том, что контрмеры решат (или минимизируют) проблему, но тут никогда нельзя быть полностью уверенным. На самом деле, вы “тыкаете острой палкой” в свою систему, проверяя, как она среагирует. Поэтому follow up — это важно.
Ошибка, на самом деле, означает, что ваша система посылает вам сигналы, к которым стоит прислушаться. Единственная реальная ошибка — это неспособность учиться на ошибках!
Пример 1: нехватка парного программирования
Один клиент попросил помочь ему выяснить, из-за чего в его бизнесе не используются приемы XP вроде парного программирования и разработки через тестирование (TDD). “Мы знаем, что должны это делать, но не делаем”, говорил клиент.
Является ли отсутствие TDD и парного программирования реальной проблемой? Как обычно, зачастую вещи, которые мы называем проблемами, ими не являются, а оказываются просто симптомами.
Q: Каковы последствия игнорирования парного программирования и TDD?
A: Мы считаем, что использование этих практик улучшило бы качество кода.
Q: Каковы последствия плохого качества кода? Сталкивались ли вы с реальными проблемами, вызванными плохим качеством кода?
A: Да, у нас вылетали демо. Демо – ключевой элемент нашего бизнеса, поэтому это реальная проблема.
OK, рассмотрим один из элементов и проверим, можем ли мы выстроить связь до самой “основы”.
Q: Почему же вы не практикуете парное программирование?
A: Потому что многие боятся, что оно не сработает и мы потратим время впустую. У нас нет доказательства того, что оно работает.
Q: Какие доказательства вам нужны?
A: Ну, мы видели исследования, которые показывают, что это эффективно. Но у нас в компании никто по сути не пытался внедрить такие практики, поэтому мы не уверены в успехе.
Вот первая петля:
Они не хотят внедрять новые практики, потому что не уверены, сработают ли они. И не знают, работают ли они, поскольку не пробовали их внедрять…
Q: Почему вы хотя бы не сделали попытку использовать парное программирование в порядке эксперимента?
A: У нас нет времени на эксперименты.
Q: Почему?
A: Потому что у нас нет временного резерва. Каждый час подотчетный. А клиенты продолжают заваливать нас работой.
Q: Почему клиенты не дают вам возможность самостоятельно управлять своим временем и считают возможным наваливать на вас работу в любой удобный момент?
A: Они не доверяют нам самостоятельно распределять время.
Отсутствие доверия также ведет к боязни неудачи в целом, что, само собой, уменьшает вероятность экспериментального использования новых приемов вроде парного программирования без гарантий, что они сработают.
Получается, что здесь две глобальных первопричины: отсутствие доверия и управленческая установка на учет каждого часа. А теперь вернемся к общей картине.
Отсутствие доверия между клиентом и заказчиком оказалось первопричиной того, что не внедряются XP-практики, такие как TDD и парное программирование. Это влечет за собой плохое качество, из-за которого вылетают демо. И вы ни за что не догадаетесь: вылетающие демо снижат взаимное доверие еще больше. Это — порочный круг!
Интересно, что мы выполняли этот анализ в ходе двухдневного воркшопа примерно с 25 людьми. Вначале мы говорили в основном о технических вещах — как начать работу с TDD и парным программированием. Такой подход оказался не особенно эффективным, вместо этого мы разделились на группы и решили, что каждая группа выбирает собственную проблему и начинает строить причинно-следственную диаграмму и формулировать решение проблемы на листах A3. Интересно, что несколько групп, которые анализировали на первый взгляд разные проблемы, в итоге пришли к одной и той же первопричине: отсутствие доверия. Диаграмма выше — лишь один из примеров, которые иллюстрируют это.
Таким образом, к концу мастер-класса разговор шел уже о том, как увеличить степень доверия между клиентом и девелопером. Это был неожиданный поворот воркшопа. Для начала мы условились, что в следующий раз пригласим на воркшоп “их” (клиентов), что должно снизить частоту противопоставления “мы” и “они”.
Пример 2: долгий релизный цикл
Предположим, у нас есть проблема: мы всегда срываем дедлайны. Точнее говоря, наши релизы всегда выходят позже запланированного времени.
Проблема является проблемой только если она мешает вам в достижении цели. Поэтому в первую очередь стоит определить цель и думать о последствиях проблемы непосредственно в контексте вашей цели. В этом поможет вопрос “И что?”, который надо задавать, пока не удастся выявить очевидный урон.
Предположим, что цель — осчастливить клиентов и получить макcимальную выручку. Диалог может выглядеть примерно так:
Q: “В чем негативный эффект того, что релизы откладываются? Какие могут быть последствия?”
A: “Задержки делают наши релизные циклы длинными”
Q: “И что?”
A: “Это откладывает получение выручки и негативно влияет на скорость денег в компании. Еще мы из-за этого теряем клиентов, так как они нетерпеливы.”
В процессе диалога мы добавляем ячейки и причинно-следственные стрелки в диаграмму. Обычно я стараюсь двигаться “по восходящей” от изначально заявленной проблемы, “составляя карту” ее последствий. Но это не строгое правило.
То есть выходит, что задержка релизов на самом деле проблемой не является. Истинные проблемы — это задержка выручки и потеря клиентов. На этом этапе необходимо рассмотреть три момента:
Есть ли иные факторы, ведущие к потере клиентов и задержке выручки? Если да, можно ли считать, что всему виной задержка релизов или нам стоит переключить внимание на что-то еще? Можно ли выразить проблему количественно? Сколько мы потеряли денег? Сколько ушло клиентов? Эти данные помогут нам оценить объем усилий, которые оправдывают себя в решении обозначенной проблемы.
Как мы поймем, что решили проблему? Предположим, в кабинет врывается счастливый консультант и гордо заявляет: “Я решил проблему!”. Как определить, что это не блеф?
После анализа последствий проблемы приходит время копать вглубь — к первопричине.
И тут на помощь приходят вопросы “Почему”. Да, существует техника “пяти почему”, о который вы могли слышать, если изучали бережливое мышление.
Q: “Почему релизы задерживаются?”
A: “Потому что растет объем работы.”
Q: “Почему?”
A: “Потому что клиенты выдумывают все новые и новые фичи и настаивают на том, что их надо добавить в текущий релиз, отказываясь исключить из него фичи с низким приоритетом.”
Q: “Почему? Почему бы не отложить добавление новых фич до новых релизов?”
A: “Потому что релизный цикл столь долог, что новые требования возникают до очередного релиза”
Тут пока только три “Почему”. Но вы поняли принцип. Диалог позволяет сформировать следующую картину:
Порочный цикл отмечен красными стрелками. Повторяющиеся проблемы почти всегда включают в себя подобные “петли”, но на то, чтобы их выявить, требуется некоторое время. Если вы нашли такую петлю, то шансы на успешное и бесповоротное решение проблем в разы возрастают!
Наша цель — выявить первопричину этой проблемы, чтобы мы могли достичь максимального эффекта минимальными усилиями. На первом этапе можно легко упустить из вида важные причины, поэтому вернемся назад и зададим еще несколько вопросов.
Q: “Почему релизный цикл долгий? Задержка релизов — единственная причина?”
A: “Ну, на самом деле, даже без задержек наши запланированные релизные циклы достаточно длинные.”
Q: “Насколько долог ваш запланированный релизный цикл?”
A: “Раз в квартал.”
Q. “Но почему он такой долгий?”
A: “Потому что релизы — вещь дорогостоящая и сложная.”
Q: “Почему?”
A: “Потому что в каждом релизе куча деталей и еще потому что это ручной труд.”
С левой стороны мы видим очередной порочный цикл (красные стрелки)! Долгий интервал между релизами означает, что каждая новая версия включает большое число обновлений, что делает выпуск продукта сложным и дорогим процессом. Из-за этого мы не хотим делать релизы часто.
Как вы заметили, тут я решил отметить две первопричины. А теперь — контрмеры:
Первопричина
Недостаток автоматизации в процессе подготовки релизов
Контрмера
Автоматизировать процесс подготовки релизов
Первопричина
Низкоприоритетные фичи не исключаются из релизов
Контрмера
Договориться с клиентом, что новые фичи могут быть добавлены в релиз только если из него исключается то же число низкоприоритетных фич
Не существует строгого правила, говорящего, какая причина является первопричиной, но некоторые признаки есть:
- Ячейка имеет только исходящие стрелки, но не имеет входящих
- Присутствует ощущение, что с этого момента копать глубже (задавать дополнительные “Почему?”) нет смысла
- Ячейка «имеет решение» и, возможно, окажет существенное позитивное влияние на проблему
Техника “пяти почему” называется так потому, что обычно от первопричины нас отделяет примерно пять вопросов. Есть тенденция останавливаться преждевременно. Этого делать не надо: продолжайте копать!
Стоит принять во внимание, что изначально поставленная проблема — задержка релизов — на деле оказалась не проблемой и не первопричиной. Это был просто симптом. Мы использовали его в качестве предлога для того, чтобы выстроить причинно-следственную связь по восходящей, чтобы выявить истинную проблему, а затем — по нисходящей, чтобы определить первопричину. Это позволяет выработать эффективные контрмеры со всем знанием дела.
Без анализа этого типа есть риск прийти к поспешным выводам и совершить неэффективные и контрпродуктивные изменения. Например, наняв дополнительных сотрудников, хотя суть проблемы лежит вовсе не в количестве рабочей силы. Или изменив систему поощрения (поощряя людей за то, что они делают работу в срок, и наказывая за сдачу работы с опозданием), хотя существующая система поощрения не имела ничего общего с проблемой.
Пример 3: дефекты, в производственном цикле
Представим, что у нас проблемы с дефектным кодом, который запускается в продакшн.
Q: И что?
A: Дефекты злят наших клиентов
Q: Почему дефекты запускаются в продакшн?
A: Потому что они не прошли необходимое тестирование до релиза.
Q: Почему не было тестирования?
И т.д.
И вот что у нас получается:
Два порочных цикла! Смотрите на красные стрелки.
Петля 1 (внутренняя петля): Дефекты в продукте вынуждают вносить срочные изменения, что отвлекает команду от работы. Поскольку сотрудники не освобождаются от основного объема задач, они находятся в стрессе и не имеют времени, чтобы должным образом протестировать новые релизы. Что, само собой, ведет к еще большему числу дефектов на уровне всего производства.
Петля 2 (внешняя петля): Так как сотрудники пребывают в стрессе, времени на написание автоматических тестовых скриптов у них также нет. Следствие — общий недостаток автоматизации в тестировании, что все больше усложняет регрессионное тестирование новых релизов. Это, само собой, ведет к дефектам в продакшене и необходимости вносить срочные изменения. И как следствие — к еще большему стрессу.
Но и это еще не все!
Команды терпеть не могут, когда их отвлекают. Процесс работы нарушает и в конечном итоге убивает мотивацию. Это может быть объяснением высокой текучки кадров! Таким образом, решая лежащую в корне проблему (дефекты в продакшене), мы получаем дополнительный бонус в виде уменьшения текучки персонала.
Это еще одно преимущество причинно-следственного анализа. Обычно первопричина является причиной более, чем одной проблемы (именно поэтому она называется “root” — основной или корневой).
Причинно-следственный анализ: опыт Роботов
Борис Рябчиков, менеджер проектов:
Моей задачей было отследить существующие в компании проблемы. Главную проблему производства мы обозначили заранее. Гипотеза была следующей: мы не отдаем проекты в срок, и, как следствие, в компании низкая скорость денег. Ряд причин также был исключен на старте: мы предположили, что планирование осуществляется правильно, и проблема находится где-то в другом месте. Остальные проблемы рассматривались через эту призму, и все, что не относилось к теме, просто выкидывалось. Мы хотели разобраться с основной проблемой и строили карту исходя из этого.
Был графически обозначен процесс производства: где мы находимся и где теряем время и деньги.
Для начала надо было выбрать источники информации. На практике оказалось, что самый эффективный способ — собирать проблемы индивидуально с каждым сотрудником. В ретроспективах и стандартных отчетах обычно появляются вещи, которые сотрудники и так озвучивают при всей команде — на общих собраниях, при начальстве. Если в компании несколько подразделений, они нередко конкурируют между собой и “перекидывают” проблемы друг на друга. Когда все сотрудники собираются вместе, порядочность, как правило, берет верх и в лицо друг друга никто не обвиняет. То есть проблемы могут замалчиваться. При индивидуальном интервьюировании они выходят на поверхность.
Приходилось общаться с людьми в неформальной обстановке — в курилке, по дорогое к метро. Некоторые проблемы формулировались именно в таких разговорах. Как оказалось, “метод пяти почему” не всегда хорошо работает на практике. Зачастую людей нервируют многочисленные “почему” и некоторые сразу включают защиту. То есть в каждом случае требуется индивидуальный подход.
Полученные данные постепенно собирались и вносились в диаграмму, которая получилась достаточно большой. По результатам проведенного анализа я подготовил краткий отчет, в котором было обозначено четыре первопричины и одна основная проблема. Все они были сгруппированы по центрам компетенций в компании.
Работать стали с несколькими первопричинами одновременно. При таком подходе существует риск не понять, какая из первопричин была главной. Но в данном случае он оправдан.
Были выработаны контрмеры для ликвидации первопричин и определены критерии успешности их устранения. Следующий этап — анализ промежуточного результата и подготовка нового скорректированного отчета. Зачастую окончательное решение проблем становится достаточно длительным процессом.
Пример 4: Целая куча проблем
А вот и более масштабный пример. В организации использовали методологию Scrum, но столкнулись с некоторыми проблемами. В результате нескольких интервью и воркшопов родилась причинно-следственная диаграмма, которая показала, что на самом деле в команде неправильно использовали Scrum, что и вызывало проблемы.
Всем стало очевидно, что многие из первопричин можно было бы устранить путем верного использования Scrum (например, реорганизация в кросс-функциональные команды, уверенность в том, что в каждой команде есть владелец продукта). Это послужило толчком для организационных изменений, которые в итоге устранили многие из первопричин (зеленые звезды). Следующим шагом должно было стать улучшение автоматизации тестирования.
Конечно, Scrum — не панацея. На самом деле, иногда Scrum сам по себе является проблемой и тогда для решения требуются другие техники, например, Kanban.
Практические вопросы — как создавать и поддерживать диаграммы
Работа в одиночку
Когда я делаю диаграммы один, самыми удобными инструментами мне представляются Visio или Powerpoint. Они позволяют быстро перемещать элементы, менять размеры ячеек и оперативно осуществлять бэкап в процессе работы над изображением.
Работа небольшими группами (2 — 8 человек)
Соберитесь около доски или флипчарта. Вместо ячеек используйте стикеры, соединяя их стрелками, нарисованными от руки. Доска предпочтительнее, так как на ней можно стирать и перерисовывать стрелки по мере перемещения стикеров. Пусть участвуют все члены группы, а не один человек. Важно не забыть сделать четкое фото того, что получилось, и разослать его всем участникам после завершения встречи.
Работа более крупными группами (9 — 30 человек)
Пусть члены группы разобьются на небольшие команды, каждая из которых сфокусируется на определенной проблеме. Работа несколькими командами над одной и той же проблемой полезна: можно прийти к одному и тому же или разным выводам, и оба результата будут интересны. Каждая команда работает с помощью отдельного флипчарта/доски и стикеров. Периодически команды должны собираться на короткие совместные обсуждения и делиться опытом.
Работа с диаграммой в перспективе
Пусть диаграмма останется в программе, которую вы использовали: Visio или Powerpoint. Если вы решите к ней снова вернуться в рамках воркшопа, определите его цель: демонстрация диаграммы или ее обновление. Если это обновление, повторите ее на доске/флипчарте при помощи стикеров и стрелок, чтобы участники воркшопа могли эффективно сообща работать над диаграммой. После встречи “синхронизируйте” получившиеся результаты с электронными инструментами.
Этот тип синхронизации отнимает некоторое время, но зачастую оно того стоит. Для совместной работы ничто не превзойдет реальные инструменты: доску и стикеры.
Опасности
Чересчур много стрелок и ячеек
Случается, что диаграмма становится настолько хаотичной, что ее невозможно разобрать. Тогда ее надо упростить. Вот некоторые техники:
- Избавьтесь от нерелевантных ячеек (ячейки, которые не добавляют диаграмме дополнительного смысла).
- Возьмите на вооружение принцип “сперва вглубь” вместо “сперва вширь”. Не пытайтесь зафиксировать каждую причину той или иной проблемы, запишите только одну или две наиболее важных, а дальше двигайтесь вглубь.
- Смиритесь с несовершенствами. Подобная диаграмма никогда не будет совершенной. “Все модели неправильные, но некоторые из них полезны”, говорил Джордж Бокс.
- Может быть, ваша проблемная область слишком широка: постарайтесь ограничиться более узко очерченной проблемой.
- Разделите диаграмму на части, как я демонстрировал в Примере 3 выше.
Простота
Это упрощенный тип причинно-следственных диаграмм — так задумано специально. Он не заменяет собой личное взаимодействие. Если вам требуются более продвинутые или формализованные методики, обратитесь к литературе по системному мышлению. Например, “Пятая дисциплина” Питера Сенге. Но учтите: даже “совершенная” диаграмма не имеет особой ценности, если понять ее может только доктор наук.
Переход на личности
Избегайте персональных обвинений такого типа:
Проблемы решаются максимально эффективным образом, если исходить из того, что все они системны. Конечно, есть неуклюжие люди. Но даже если это доставляет нам существенные недобства, проблема все равно носит системный характер: существует система, в которой неуклюжие люди не считаются таковыми, или система, которая впускает внутрь ужасно неуклюжих людей, но при этом не помогает им становиться менее неуклюжими, и так далее. Следует особо подчеркнуть: относитесь ко всем проблемам как к системным.
