Инструкция: как строить дерево текущей реальности для решения бизнес-проблем

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

Можно, конечно, просто вызвать подчинённых на ковёр и наорать, но это не решит проблему. А можно — взять и разобраться. Долго, нудно, подчас — неприятно и больно.

И кусочек за кусочком, восстанавливая картину и все причинно-следственные связи, построить дерево текущей реальности — диаграмму, которая нравится прошаренным управленцам за её наглядность и результативность.

В этом материале мы пошагово покажем на реальном примере, как это сделать.

Задачка со звёздочкой

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

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

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

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

Решение

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

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

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

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

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

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

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

— НЖЯ — постоянная проблема, которая мешает достичь лучших результатов.

— НЖЯ объективно и не содержит оценочных суждений.

— НЖЯ никого не обвиняет.

— НЖЯ описывает состояние, а не разовую ситуацию.

— НЖЯ устранимо (в его отношении можно что-то предпринять).

— НЖЯ не может быть предполагаемой причиной проблемы.

— НЖЯ не может быть завуалированным решением проблемы.

— НЖЯ не требует объяснений своего негативного эффекта.

— НЖЯ не содержит причинно-следственных связей.

— НЖЯ находится в вашей, как руководителя, области ответственности.

Подробнее об этом можно почитать в книге Одеда Коуэна и Елены Федурко «Основы Теории Ограничений».

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

Нет

«Низкая удовлетворенность потребителей».

«Напряженная атмосфера в коллективе».


Да

«Потребителям не нравится продукт».

«Сотрудники конфликтуют».

Решение задачи — дерево текущей реальности

Дерево текущей реальности (ДТР) — большая диаграмма, которая помогает взглянуть на проблемы комплексно, увидеть их взаимосвязи и найти корневую причину конкретной негативной ситуации. Для её построения нам и понадобятся собранные ранее НЖЯ.

В списках маст-рид литературы для владельцев бизнеса и управленцев вы наверняка встречали книги Элияху Голдратта. Его схема решения проблем рабочая и крутая, но требует много временного и человеческого ресурса — на сбор НЖЯ и построение дерева текущей реальности уйдёт N-цать часов вашей жизни (чем запущеннее процессы, тем больше времени вы на это потратите).

До недавнего времени мне на глаза не попадались удобные инструменты, в которых можно было бы строить деревья текущей реальности. Делать это на бумаге, в Xmind (обычно этим и заканчивалось), Visio или в каком-нибудь draw.io — крайне неудобно.

Владимир, руководитель студии

Но всё-таки есть пара программ для построения ДТР, где думать над проблемой — удобно. Это Flying Logic Pro и Knowflow.io.

Flying Logic Pro
Knowflow.io

Как строить ДТР — инструкция

Шаг 1

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

Шаг 2

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

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

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

Шаг 3

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

  1. Что менять?
  2. На что менять?
  3. Как менять?

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

В условиях нашей задачи условия должны быть такими:

  1. Разработчик должен продумывать вопросы по реализации заранее, а если уж что-то идет не по плану, приходить к менеджеру с решением проблемы (а не с заявлением «Ситуация хелп, ситуация SOS!» или «Шеф, всё пропало!»).
  2. Менеджер же должен знать свой проект, как облупленный, а если он всё-таки чего-то не знает — у него должен быть план В (и желательно ещё план C), чтобы быстро добыть ту информацию, которую он не знает.

Шаг 4

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

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

Шаг 5

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

Шаг 6

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

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

Что дальше

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

0
34 комментария
Написать комментарий...
Алексей Ш.

Крайне смутном могу себе представить руководителя, который будет тратить время на построение таких схем

Ответить
Развернуть ветку
Евгений Яровой

крайне смутно представляю себе руководителя, который строит современный бизнес, читает статьи на VC  и не пользуется инструментами планирования/майнд-картами/таблицами, иначе я не понимаю чем он занимается, если не структурирует/формулирует свои знания и опыт вокруг себя. Как можно без этого строить управление, если не ситуативно и коридорно, представить трудно, но в таком случае это и руководитель так себе

Ответить
Развернуть ветку
Сибирикс
Автор

Тем не менее — по этой технике в свое время на западе все машиностроение и металлообработку переосмыслили. В push на pull.

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

Решение проблемы очевидно из её условий. У вас на одного разработчика всего один менеджер, надо нанять еще шестерых, и все сразу прекрасно заработает! :)

Ответить
Развернуть ветку
Сибирикс
Автор

У семи нянек — четырнадцать сисек?

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Amadeus

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

Ответить
Развернуть ветку
Сибирикс
Автор

Не надо из пушки по воробьям стрелять, вам разве мама не рассказывала?

Ответить
Развернуть ветку
Alexandre Svergoun

Лучше один раз разобраться с источником проблемы чем каждый раз устронять её последствия.

Ответить
Развернуть ветку
Артём А.

Это скорее всего очередная попытка формализовать творческий процесс. Обычно вы не думаете над проблемами так, а просто собираете инфу в голове, хуяк хуяк и решение озарило вашу светлую голову. и скорее всего в процессе сбора инфы и обсуждения проблем уже даже реализовано. А это для тех, кто не знает что делать если что-то идет не так. Берете методичку и делаете все по инструкции:) если повезет, результат будет хорошим)

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

Ответить
Развернуть ветку
Фахреддин Мирзоев

бред какой-то :D

Ответить
Развернуть ветку
Сибирикс
Автор

А ты клёвый!

Ответить
Развернуть ветку
Фахреддин Мирзоев

интересно, что следует из пунктов в правом верхнем углу? :D Женя должен вчитываться в постановки, а разраб не сидеть без дела, пока нет задач? )) планинг?! ))

Ответить
Развернуть ветку
Андрей Браиловский

Дано: проблема взаимопонимания менеджера и разработчика на которого повесили всех собак(не сделал это, это и вот это, пока менеджер занимался хрен знает чем)
Решение: а давайте строить графики, схемки и усложнять проблему в 10 раз
И не забыть упомянуть токсичность, это же так модно!

Ответить
Развернуть ветку
Сибирикс
Автор

Схемки никогда не заменят живого, человеческого общения по SMS!

Ответить
Развернуть ветку
Alexandre Svergoun

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

Ответить
Развернуть ветку
Nikolay Vavilov

Оч много текста, проще наорать. Ну или консультантов пригласить со стороны - модно ж.

Ответить
Развернуть ветку
Юрий Козинцев

"И потому безвестным будешь ты..." (из к/ф "Троя")

Ответить
Развернуть ветку
Сибирикс
Автор

хозяин-барин :)

Ответить
Развернуть ветку
Павел

"Мысью" по древу :)

Ответить
Развернуть ветку
Alexandre Svergoun

Автору спасибо. Статья полезная. Пример то же хороший, достаточно часто встречающийся в компаниях. Любой руководитель должен несколько раз сделать это на бумаге/в софте а затем он сможет это делать в голове. А не орать не разобравшись как делают большая половина руководителей.

Ответить
Развернуть ветку
Виктор Юдаев

Половина большей не бывает

Ответить
Развернуть ветку
Alexandre Svergoun

В. И. Ленин: «Этого мало, потому что перед нами сейчас стоит вторая, большая половина задачи, большая по трудности»; «Тем самым, что мы сбросили власть эксплуататоров, мы сделали уже большую половину работы» (Полн. собр. соч., т. 42, стр. 5). Ср. в художественной литературе: Большая половина фабрики… была в огне (Б. Полевой)

Ответить
Развернуть ветку
Виктор Юдаев

Забавно)
Говорят, что если хочешь обидеть человека напиши: грамматика и пунктуация сохранены))
Ну хоть не деревня Большая Половина в Юрлинском районе Пермского края на реке Сылва.
Конечно, это расстрельный грамматический список устоявшихся оборотов, но т.к. Ульянов и Полевой гуманитарии, то они могли так ошибаться.
Анекдот в тему:
— Нету такой вещи, как бо́льшая половина, — говорит учительница классу. — Половины одинаковые, равные. Если одна из них больше, то значит уже не половина. Это элементарно. Почему же бо́льшая половина класса этого не понимает?

Ответить
Развернуть ветку
Alexandre Svergoun

А как вы считаете, какого рода должно быть слово КОФЕ?

Ответить
Развернуть ветку
Анастасия Романова

Отличная метода - пользовались ею скорее умозрительно, на пальцах, попробуем рекомендуемые программы - спасибо!

Ответить
Развернуть ветку
Владимир Дикусар

что за НЖЯ, ну назвали бы НЖП, хотя тоже звучит так себе.

Ответить
Развернуть ветку
Sergey Orlov

Я бы перерисовал схему в формате IDEF.

Ответить
Развернуть ветку
Nikolay Kapustin

СJM вид сбоку

Ответить
Развернуть ветку
Иван Пилецкий

Не корневая причина, а коренная, или первопричина.
Я считаю, что все же стоит отделять дерево коренных причин (root cause tree) от решений. Во-первых, причин может быть дофига - схемка станет весьма объемной, во-вторых, до разработки решений обязательно проводить тесты первопричин, об этом часто забывают.
Самое интересное не описали - на основании чего формулировать решения и как их декомпозировать в отдельные проекты.

Ответить
Развернуть ветку
Сибирикс
Автор

Иван, предмет для отдельной статьи :)

Ответить
Развернуть ветку
Indigo

На эту тему есть пару книг в форме бизнес-романов, Элияху Моше Голдратт создатель теории ограничений.

Ответить
Развернуть ветку
Антон Лазовский

Эм... а почему корневая причина это отсутствие планирования, которая по вашей же схеме приводит только к тому, что разраб сидел без задач? Если основная проблема - это то, что был провален спринт..

В общем все достаточно сумбурно и больше высосано из пальца, возможно, неудачный пример

Ответить
Развернуть ветку
Руслан Зиганшин

"НЖЯ никого не обвиняют"

При этом в НЖЯ присутствуют "Разработчик сидел без задач ожидая ответа, менеджер не вникал в задачи клиента и согласовал недостаточный функционал" (косяки менеджера) и "Оценил на глаз, не вчитывался в формулировки" (косяки разработчика).

Тут же у проблем есть конкретные имена и фамилии?

НЖЯ "Разраб приходит не с решением, а с проблемой" это вполне себе рабочий процесс, на правах ИМХО. Некоторым надо подумать об кого-то, кто-то боится расширить зону ответственности. Менеджер для того и нужен, чтобы такие ситуации разруливать. Я никогда не встречал разработчика, который придя с проблемой не может ответить на вопрос "А что мы можем сделать?". Просто ответ ему не нравится, да и меня как менеджера не устроит. Садимся и ищем другое решение

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
31 комментарий
Раскрывать всегда