Комментарии
Статья с vc.ru
Инструкция: как строить дерево текущей реальности для решения бизнес-проблем
Вы — владелец бизнеса или управленец. И у вас на каком-то проекте или управленческом контуре творится неведомая херня: конфликт между сотрудниками, проблемы с клиентом и его проектом, нарушенные договоренности или всё это вместе.

Можно, конечно, просто вызвать подчинённых на ковёр и наорать, но это не решит проблему. А можно — взять и разобраться. Долго, нудно, подчас — неприятно и больно. И кусочек за кусочком, восстанавливая картину и все причинно-следственные связи, построить Дерево текущей реальности — диаграмму, которая нравится прошаренным управленцам за её наглядность и результативность. В этом материале мы пошагово покажем на реальном примере, как это сделать.
Задачка со звёздочкой
Можно долго писать про деревья текущей реальности и Теорию ограничений систем теоретически (если что, мы подробно рассказали об этом вот тут), но куда круче разобрать на реальном примере.


Дано:
Проект со сложной интеграцией — 1 штука. Менеджер проекта — 1. Разработчик, занимающийся интеграцией, — 1.

Ситуация:
Спринт прервался.

Задача:
Найти истинные причины ситуации и предложить решение проблемы.

Решение:
Чтобы решить проблему, надо сначала отмотать назад и понять, почему она произошла. Поэтому добро пожаловать в кресло психолога начальника: предстоят разговоры «по душам».

Беседуем с менеджером и разработчиком. Задавая вопросы, «копаем» до истинных причин — как правило, людьми они не осознаются, и приходится в этом им помогать. Будьте готовы к тому, что на вас вывалится поток формулировок, многие из которых могут быть токсичными.
Для поиска негативных явлений есть множество инструментов (5-WHY и прочие) — многие из них мы подробно рассматриваем на Курсе управления проектами.

Раскручивая ситуацию с разных сторон, выясняем следующее:

  • некоторые задачи не были сделаны в соответствии с постановками;
  • задачу разработчик оценить — оценил, но как попало: вопросы по делу стал задавать, когда дошёл до реализации (а должен был подумать об ограничениях и всех непонятках ещё на этапе оценки затрат времени);
  • разработчик приходил к менеджеру с проблемой, а не с вариантами решения;
  • разработчик смиренно ждал ответа от менеджера, пока тот не отвечал (был на другой задаче, например);
  • как следствие — срыв сроков и напряженные отношения между разработчиком и менеджером.

Всё, что мы сейчас перечислили — это нежелательные явления (НЖЯ, Undesirable Effect). Если коротко, то НЖЯ — это то, без чего любой бизнес-системе стало бы гораздо лучше.
Собрали немножко НЖЯ у себя в студии :)

Как узнать, что нечто — это НЖЯ? Есть несколько критериев для проверки:

  • НЖЯ — постоянная проблема, которая мешает достичь лучших результатов;
  • НЖЯ объективно и не содержит оценочных суждений;
  • НЖЯ никого не обвиняет;
  • НЖЯ описывает состояние, а не разовую ситуацию;
  • НЖЯ устранимо (в его отношении можно что-то предпринять);
  • НЖЯ не может быть предполагаемой причиной проблемы;
  • НЖЯ не может быть завуалированным решением проблемы;
  • НЖЯ не требует объяснений своего негативного эффекта;
  • НЖЯ не содержит причинно-следственных связей;
  • НЖЯ находится в вашей, как руководителя, области ответственности.

Подробнее об этом можно почитать в книге Одеда Коуэна и Елены Федурко «Основы Теории Ограничений».
Важно: при формулировании НЖЯ не растекайтесь мыслию по древу, коротко сформулируйте их в виде предложений в настоящем времени. Простые формулировки помогут прочитывать Дерево текущей реальности и выстраивать из отдельных фраз предложения, добавляя между НЖЯ логические связки вроде «если-то».
нет
«низкая удовлетворенность потребителей»
«напряженная атмосфера в коллективе»
да
«потребителям не нравится продукт»
«сотрудники конфликтуют»
Решение задачи — Дерево текущей реальности
Дерево текущей реальности (ДТР) — по сути, большая диаграмма, которая помогает взглянуть на проблемы комплексно, увидеть их взаимосвязи и найти корневую причину конкретной негативной ситуации. Для её построения нам и понадобятся собранные ранее НЖЯ.

В списках маст-рид литературы для владельцев бизнеса и управленцев вы наверняка встречали книги Элияху Голдратта. Его схема решения проблем рабочая и крутая, но требует много временного и человеческого ресурса — на сбор НЖЯ и построение дерева текущей реальности уйдёт N-цать часов вашей жизни (чем запущеннее процессы, тем больше времени вы на это потратите).
Владимир
CEO & Founder
До недавнего времени мне на глаза не попадались удобные инструменты, в которых можно было бы строить деревья текущей реальности. Делать это на бумаге, в xmind (обычно этим и заканчивалось), visio или в каком-нибудь draw. io — крайне неудобно.
Но всё-таки есть пара программ для построения ДТР, где думать над проблемой — удобно. Это Flying Logic Pro и Knowflow.io.
Как строить ДТР — инструкция
Шаг 1

Закидываем в одну из программ все наши НЖЯ — пока можно в произвольном порядке. Для адекватной диаграммы достаточно 5−10 нежелательных явлений.

Шаг 2

Далее нужно установить связи между НЖЯ: у каждого НЖЯ должна быть хотя бы одна причинно-следственная связь с другим нежелательным явлением. На этом же этапе стоит оценить причины каждого НЖЯ, задав простой вопрос «Почему?». Добавить в диаграмму, установить связи с конкретными нежелательными явлениями.

В нашем случае мы накопали несколько причин:

  • менеджер не провёл планинг;
  • при оценке задачи на интеграцию разработчик не вчитывался в постановки;
  • в протоколе интеграции промотали описание важного раздела (работа со скидками);
  • сам менеджер не разбирается в проекте на все 100%, так как получил его «по наследству» от другого менеджера;
  • менеджер не мог ответить на вопросы разработчика;
  • менеджер тянул с ответом разработчику в скайпе.

Шаг 3

Теория ограничений — концепция менеджмента организаций, выведенная Голдраттом в 80-е, а теперь ставшая целой философией для управленцев. И её главная суть — разложить по полочкам процесс мышления, чтобы ответить всего на три вопроса:

  1. Что менять?
  2. На что менять?
  3. Как менять?
С первым вопросом уже разобрались — собрали НЖЯ, поняли, как они связаны. Дальше продумываем и проверяем решения. Начинаем с потребности — ситуация не устраивает, думаем над тем, как должно быть, чтобы всё шло чётко (и отвечаем на второй фундаментальный вопрос ТОС).
В условиях нашей задачи условия должны быть такими:

1) разработчик должен продумывать вопросы по реализации заранее, а если уж что-то идет не по плану, приходить к менеджеру с решением проблемы (а не с заявлением «Ситуация хелп, ситуация SOS!» или «Шеф, всё пропало!»).

2) менеджер же должен знать свой проект, как облупленный, а если он всё-таки чего-то не знает — у него должен быть план В (и желательно ещё план C), чтобы быстро добыть ту информацию, которую он не знает.


Шаг 4

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

  1. Ясность (насколько ДТР понятно аудитории).
  2. Чёткие утверждения (причины и следствия верно сформулированы).
  3. Причины и следствия очевидны.
  4. Причины достаточны (не потеряны важные аспекты).
  5. Альтернативные причины проверены (ведет к такому же результату).
  6. Причины не подменяются следствиями.
  7. Указаны дополнительные результаты, имеющие в основании первоначальную причину.
  8. Нет зацикленной логики (причины явные, следствия достаточны).


Шаг 5


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

Шаг 6

Превращаем наши потребности в большие цели, которые приведут к выполнению основного желания (сдать проект) и устранят первопричину.

  1. для разработчика: подготовка вопросов до планинга для корректной оценки задач перед стартом, предложение решений при возникновении проблем — всё это ради 100%-ного качество работ.
  2. для менеджера: четкое формулирование задач с однозначной постановкой, понятная для разработчика декомпозиция задач, оперативные и достоверные ответы на вопросы (что в скайпе, что лично), высокая степень погружения менеджера в проект.
Получившаяся диаграмма — не конечный вариант ДТР, а лишь кусочек большого аналитического процесса
Что дальше?
Дерево текущей реальности не волшебная таблетка — готовых решений не предлагает. Оно обнажает проблемы и помогает ставить цели, которые требуют пересмотра процессов, введения дополнительных регламентов и прочих въедливых вдумчивых и продолжительных действий. В каждом случае — индивидуальных. И это — уже совсем другая история :)