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

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

В закладки
Аудио

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

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

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

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

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

Дано: проект со сложной интеграцией — 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, что лично), высокая степень погружения менеджера в проект.
Получившаяся диаграмма — не конечный вариант ДТР, а лишь кусочек большого аналитического процесса

Что дальше

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

Материал опубликован пользователем.
Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.

Написать
{ "author_name": "СИБИРИКС // scrum", "author_type": "self", "tags": ["\u043c\u0435\u043d\u0435\u0434\u0436\u043c\u0435\u043d\u0442","\u0438\u043d\u0441\u0442\u0440\u0443\u043a\u0446\u0438\u0438"], "comments": 34, "likes": 37, "favorites": 186, "is_advertisement": false, "subsite_label": "hr", "id": 81710, "is_wide": true, "is_ugc": true, "date": "Wed, 04 Sep 2019 10:05:52 +0300", "is_special": false }
0
{ "id": 81710, "author_id": 57675, "diff_limit": 1000, "urls": {"diff":"\/comments\/81710\/get","add":"\/comments\/81710\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/81710"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 199121, "last_count_and_date": null }
34 комментария
Популярные
По порядку
Написать комментарий...
7

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

Ответить
4

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

Ответить
3

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

Ответить
4

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

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

Ответить
7

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

Ответить
4

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

Ответить
3

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

Ответить
2

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

Ответить
0

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

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

Ответить
2

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

Ответить
4

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

Ответить
3

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

Ответить
1

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

Ответить
0

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

Ответить
1

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

Ответить
2

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

Ответить
1

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

Ответить
1

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

Ответить
1

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

Ответить
0

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

Ответить
0

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

Ответить
0

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

Ответить
0

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

Ответить
1

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

Ответить
0

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

Ответить
0

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

Ответить
0

СJM вид сбоку

Ответить
0

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

Ответить
0

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

Ответить
0

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

Ответить
0

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

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

Ответить
0

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

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

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

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

Ответить

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

{ "page_type": "article" }

Прямой эфир

[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox_method": "createAdaptive", "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fizc" } } }, { "id": 4, "label": "Article Branding", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "cfovx", "p2": "glug" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "bscsh", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "createAdaptive", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-223676-0", "render_to": "inpage_VI-223676-0-1104503429", "adfox_url": "//ads.adfox.ru/228129/getCode?pp=h&ps=bugf&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid10=&puid21=&puid22=&puid31=&puid32=&puid33=&fmt=1&dl={REFERER}&pr=" } }, { "id": 15, "label": "Баннер в ленте на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byudx", "p2": "ftjf" } } }, { "id": 16, "label": "Кнопка в шапке мобайл", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byzqf", "p2": "ftwx" } } }, { "id": 17, "label": "Stratum Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvb" } } }, { "id": 18, "label": "Stratum Mobile", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvc" } } }, { "id": 19, "disable": true, "label": "Тизер на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "p1": "cbltd", "p2": "gazs" } } } ] { "page_type": "default" }