Инструкция: как строить дерево текущей реальности для решения бизнес-проблем
Вы — владелец бизнеса или управленец. И у вас на каком-то проекте или управленческом контуре творится неведомая херня: конфликт между сотрудниками, проблемы с клиентом и его проектом, нарушенные договоренности или всё это вместе.
Можно, конечно, просто вызвать подчинённых на ковёр и наорать, но это не решит проблему. А можно — взять и разобраться. Долго, нудно, подчас — неприятно и больно. И кусочек за кусочком, восстанавливая картину и все причинно-следственные связи, построить Дерево текущей реальности — диаграмму, которая нравится прошаренным управленцам за её наглядность и результативность. В этом материале мы пошагово покажем на реальном примере, как это сделать.
Можно, конечно, просто вызвать подчинённых на ковёр и наорать, но это не решит проблему. А можно — взять и разобраться. Долго, нудно, подчас — неприятно и больно. И кусочек за кусочком, восстанавливая картину и все причинно-следственные связи, построить Дерево текущей реальности — диаграмму, которая нравится прошаренным управленцам за её наглядность и результативность. В этом материале мы пошагово покажем на реальном примере, как это сделать.
Задачка со звёздочкой
Можно долго писать про деревья текущей реальности и Теорию ограничений систем теоретически (если что, мы подробно рассказали об этом вот тут), но куда круче разобрать на реальном примере.
Дано:
Проект со сложной интеграцией — 1 штука. Менеджер проекта — 1. Разработчик, занимающийся интеграцией, — 1.
Ситуация:
Спринт прервался.
Задача:
Найти истинные причины ситуации и предложить решение проблемы.
Решение:
Чтобы решить проблему, надо сначала отмотать назад и понять, почему она произошла. Поэтому добро пожаловать в кресло психолога начальника: предстоят разговоры «по душам».
Беседуем с менеджером и разработчиком. Задавая вопросы, «копаем» до истинных причин — как правило, людьми они не осознаются, и приходится в этом им помогать. Будьте готовы к тому, что на вас вывалится поток формулировок, многие из которых могут быть токсичными.
Дано:
Проект со сложной интеграцией — 1 штука. Менеджер проекта — 1. Разработчик, занимающийся интеграцией, — 1.
Ситуация:
Спринт прервался.
Задача:
Найти истинные причины ситуации и предложить решение проблемы.
Решение:
Чтобы решить проблему, надо сначала отмотать назад и понять, почему она произошла. Поэтому добро пожаловать в кресло психолога начальника: предстоят разговоры «по душам».
Беседуем с менеджером и разработчиком. Задавая вопросы, «копаем» до истинных причин — как правило, людьми они не осознаются, и приходится в этом им помогать. Будьте готовы к тому, что на вас вывалится поток формулировок, многие из которых могут быть токсичными.
Для поиска негативных явлений есть множество инструментов (5-WHY и прочие) — многие из них мы подробно рассматриваем на Курсе управления проектами.
Раскручивая ситуацию с разных сторон, выясняем следующее:
- некоторые задачи не были сделаны в соответствии с постановками;
- задачу разработчик оценить — оценил, но как попало: вопросы по делу стал задавать, когда дошёл до реализации (а должен был подумать об ограничениях и всех непонятках ещё на этапе оценки затрат времени);
- разработчик приходил к менеджеру с проблемой, а не с вариантами решения;
- разработчик смиренно ждал ответа от менеджера, пока тот не отвечал (был на другой задаче, например);
- как следствие — срыв сроков и напряженные отношения между разработчиком и менеджером.
Всё, что мы сейчас перечислили — это нежелательные явления (НЖЯ, Undesirable Effect). Если коротко, то НЖЯ — это то, без чего любой бизнес-системе стало бы гораздо лучше.
Собрали немножко НЖЯ у себя в студии :)
Как узнать, что нечто — это НЖЯ? Есть несколько критериев для проверки:
- НЖЯ — постоянная проблема, которая мешает достичь лучших результатов;
- НЖЯ объективно и не содержит оценочных суждений;
- НЖЯ никого не обвиняет;
- НЖЯ описывает состояние, а не разовую ситуацию;
- НЖЯ устранимо (в его отношении можно что-то предпринять);
- НЖЯ не может быть предполагаемой причиной проблемы;
- НЖЯ не может быть завуалированным решением проблемы;
- НЖЯ не требует объяснений своего негативного эффекта;
- НЖЯ не содержит причинно-следственных связей;
- НЖЯ находится в вашей, как руководителя, области ответственности.
Подробнее об этом можно почитать в книге Одеда Коуэна и Елены Федурко «Основы Теории Ограничений».
Важно: при формулировании НЖЯ не растекайтесь мыслию по древу, коротко сформулируйте их в виде предложений в настоящем времени. Простые формулировки помогут прочитывать Дерево текущей реальности и выстраивать из отдельных фраз предложения, добавляя между НЖЯ логические связки вроде «если-то».
нет
«низкая удовлетворенность потребителей»
«напряженная атмосфера в коллективе»
«напряженная атмосфера в коллективе»
да
«потребителям не нравится продукт»
«сотрудники конфликтуют»
«сотрудники конфликтуют»
Решение задачи — Дерево текущей реальности
Дерево текущей реальности (ДТР) — по сути, большая диаграмма, которая помогает взглянуть на проблемы комплексно, увидеть их взаимосвязи и найти корневую причину конкретной негативной ситуации. Для её построения нам и понадобятся собранные ранее НЖЯ.
В списках маст-рид литературы для владельцев бизнеса и управленцев вы наверняка встречали книги Элияху Голдратта. Его схема решения проблем рабочая и крутая, но требует много временного и человеческого ресурса — на сбор НЖЯ и построение дерева текущей реальности уйдёт N-цать часов вашей жизни (чем запущеннее процессы, тем больше времени вы на это потратите).
В списках маст-рид литературы для владельцев бизнеса и управленцев вы наверняка встречали книги Элияху Голдратта. Его схема решения проблем рабочая и крутая, но требует много временного и человеческого ресурса — на сбор НЖЯ и построение дерева текущей реальности уйдёт N-цать часов вашей жизни (чем запущеннее процессы, тем больше времени вы на это потратите).
Владимир
CEO & Founder
До недавнего времени мне на глаза не попадались удобные инструменты, в которых можно было бы строить деревья текущей реальности. Делать это на бумаге, в xmind (обычно этим и заканчивалось), visio или в каком-нибудь draw. io — крайне неудобно.
Но всё-таки есть пара программ для построения ДТР, где думать над проблемой — удобно. Это Flying Logic Pro и Knowflow.io.
 |
 |
Как строить ДТР — инструкция
Шаг 1
Закидываем в одну из программ все наши НЖЯ — пока можно в произвольном порядке. Для адекватной диаграммы достаточно 5−10 нежелательных явлений.
Закидываем в одну из программ все наши НЖЯ — пока можно в произвольном порядке. Для адекватной диаграммы достаточно 5−10 нежелательных явлений.
Шаг 2
Далее нужно установить связи между НЖЯ: у каждого НЖЯ должна быть хотя бы одна причинно-следственная связь с другим нежелательным явлением. На этом же этапе стоит оценить причины каждого НЖЯ, задав простой вопрос «Почему?». Добавить в диаграмму, установить связи с конкретными нежелательными явлениями.
В нашем случае мы накопали несколько причин:
- менеджер не провёл планинг;
- при оценке задачи на интеграцию разработчик не вчитывался в постановки;
- в протоколе интеграции промотали описание важного раздела (работа со скидками);
- сам менеджер не разбирается в проекте на все 100%, так как получил его «по наследству» от другого менеджера;
- менеджер не мог ответить на вопросы разработчика;
- менеджер тянул с ответом разработчику в скайпе.
Шаг 3
Теория ограничений — концепция менеджмента организаций, выведенная Голдраттом в 80-е, а теперь ставшая целой философией для управленцев. И её главная суть — разложить по полочкам процесс мышления, чтобы ответить всего на три вопроса:
- Что менять?
- На что менять?
- Как менять?
В условиях нашей задачи условия должны быть такими:
1) разработчик должен продумывать вопросы по реализации заранее, а если уж что-то идет не по плану, приходить к менеджеру с решением проблемы (а не с заявлением «Ситуация хелп, ситуация SOS!» или «Шеф, всё пропало!»).
2) менеджер же должен знать свой проект, как облупленный, а если он всё-таки чего-то не знает — у него должен быть план В (и желательно ещё план C), чтобы быстро добыть ту информацию, которую он не знает.
Шаг 4
Прогоняем получившееся дерево через Критерии проверки логических построений (КПЛП). Они помогают избавиться от двусмысленных формулировок и нестыковок и сделать диаграмму читабельной. Подробнее о них мы писали в этом материале, здесь — приводим краткие формулировки:
Шаг 5
Определить, какой объект влияет на остальные больше других. Бинго, вы нашликозла отпущения ограничение и корневую причину проблем. В нашем случае это — отсутствие планинга. Выделяем корневую причину цветом.
1) разработчик должен продумывать вопросы по реализации заранее, а если уж что-то идет не по плану, приходить к менеджеру с решением проблемы (а не с заявлением «Ситуация хелп, ситуация SOS!» или «Шеф, всё пропало!»).
2) менеджер же должен знать свой проект, как облупленный, а если он всё-таки чего-то не знает — у него должен быть план В (и желательно ещё план C), чтобы быстро добыть ту информацию, которую он не знает.
Шаг 4
Прогоняем получившееся дерево через Критерии проверки логических построений (КПЛП). Они помогают избавиться от двусмысленных формулировок и нестыковок и сделать диаграмму читабельной. Подробнее о них мы писали в этом материале, здесь — приводим краткие формулировки:
- Ясность (насколько ДТР понятно аудитории).
- Чёткие утверждения (причины и следствия верно сформулированы).
- Причины и следствия очевидны.
- Причины достаточны (не потеряны важные аспекты).
- Альтернативные причины проверены (ведет к такому же результату).
- Причины не подменяются следствиями.
- Указаны дополнительные результаты, имеющие в основании первоначальную причину.
- Нет зацикленной логики (причины явные, следствия достаточны).
Шаг 5
Определить, какой объект влияет на остальные больше других. Бинго, вы нашли
Шаг 6
Превращаем наши потребности в большие цели, которые приведут к выполнению основного желания (сдать проект) и устранят первопричину.
- для разработчика: подготовка вопросов до планинга для корректной оценки задач перед стартом, предложение решений при возникновении проблем — всё это ради 100%-ного качество работ.
- для менеджера: четкое формулирование задач с однозначной постановкой, понятная для разработчика декомпозиция задач, оперативные и достоверные ответы на вопросы (что в скайпе, что лично), высокая степень погружения менеджера в проект.
Получившаяся диаграмма — не конечный вариант ДТР, а лишь кусочек большого аналитического процесса
Что дальше?
Дерево текущей реальности не волшебная таблетка — готовых решений не предлагает. Оно обнажает проблемы и помогает ставить цели, которые требуют пересмотра процессов, введения дополнительных регламентов и прочих въедливых вдумчивых и продолжительных действий. В каждом случае — индивидуальных. И это — уже совсем другая история :)