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