Инструкция: как строить дерево текущей реальности для решения бизнес-проблем
Вы владелец бизнеса или управленец. И у вас на каком-то проекте или управленческом контуре творится неведомая херня: конфликт между сотрудниками, проблемы с клиентом и его проектом, нарушенные договоренности или всё это вместе.
Можно, конечно, просто вызвать подчинённых на ковёр и наорать, но это не решит проблему. А можно — взять и разобраться. Долго, нудно, подчас — неприятно и больно.
И кусочек за кусочком, восстанавливая картину и все причинно-следственные связи, построить дерево текущей реальности — диаграмму, которая нравится прошаренным управленцам за её наглядность и результативность.
В этом материале мы пошагово покажем на реальном примере, как это сделать.
Задачка со звёздочкой
Можно долго писать про деревья текущей реальности и теорию ограничений систем теоретически (если что, мы подробно рассказали об этом вот тут), но куда круче разобрать на реальном примере.
Дано: проект со сложной интеграцией — 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, что лично), высокая степень погружения менеджера в проект.
Что дальше
Дерево текущей реальности не волшебная таблетка — готовых решений не предлагает. Оно обнажает проблемы и помогает ставить цели, которые требуют пересмотра процессов, введения дополнительных регламентов и прочих въедливых вдумчивых и продолжительных действий. В каждом случае — индивидуальных. И это — уже совсем другая история :)
В начале этой недели рынок акций продолжил рост, однако довольно быстро развернулся вниз и упал более чем на 200 пунктов по индексу ММВБ к концу недели. Это уже приличная и продолжительная коррекция, которую ранее рынку не давал реализовать безумный поток позитивных новостей. И нельзя сказать, что этот поток прекратился, но он теперь уже не такой п…
Создание резерва поспособствует развитию «критически важной индустрии».
Дополнено в 20:37 мск. Курс BTC вырос до $93,6 тысячи за монету.
Я долго искал похожие истории в интернете, надеясь найти советы от тех, кто пережил нечто подобное. Но так ничего и не нашёл. Возможно, моя история — редкость. Возможно, просто никто не хочет делиться такими провалами.
Масспостинг — один из самых спорных инструментов работы на Авито. Одни видят в нем эффективный способ увеличения продаж, другие — нарушение правил и прямой путь к блокировке. Рассмотрим в статье как этот механизм работает, каковы его последствия и можно ли использовать его легально.
Тренд текущего времени - впарить себя через чат с ником похожим на собачью кличку и оплатой криптой. Оплата конечно же вперед и 100%.
И посоветовал сотрудникам приходить в офис «хотя бы» в будни, чтобы выиграть гонку за AGI.
В этом кейсе мы расскажем, как платформа Millennium, которая занимается организацией командировок и деловых поездок за короткий промежуток времени заняла топы поисковых систем.
Февраль закончился, акции скорректировались после второго Трамп-ралли. Вместе с зимой закончился и бюджет на покупки акций, которые я продолжаю покупать в свой портфель. Посмотрел, как идут успехи с приведением его к целевым значениям. Размер портфеля составляет 2,357 млн рублей.
Крайне смутном могу себе представить руководителя, который будет тратить время на построение таких схем
крайне смутно представляю себе руководителя, который строит современный бизнес, читает статьи на VC и не пользуется инструментами планирования/майнд-картами/таблицами, иначе я не понимаю чем он занимается, если не структурирует/формулирует свои знания и опыт вокруг себя. Как можно без этого строить управление, если не ситуативно и коридорно, представить трудно, но в таком случае это и руководитель так себе
Тем не менее — по этой технике в свое время на западе все машиностроение и металлообработку переосмыслили. В push на pull.
Дано: проект со сложной интеграцией — 1 штука. Менеджер проекта — 1. Разработчик, занимающийся интеграцией, — 1.
Решение проблемы очевидно из её условий. У вас на одного разработчика всего один менеджер, надо нанять еще шестерых, и все сразу прекрасно заработает! :)
У семи нянек — четырнадцать сисек?
Комментарий недоступен
Пока я буду строить это дерево, я уже сто раз придумаю решение проблемы. Если вы очень много времени тратите на оптимизацию своих процессов, значит вы тупо ленитесь делать основную работу и утешаете себя мыслями, что вот я сейчас найду нужную программу/планировщик/календарь и каааак попрет!!!