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