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

Собрали 11 диаграмм, которые рекомендуют опытные управленцы. Эти инструменты помогают:

• найти узкие места в процессах, 

• распределить ответственность между сотрудниками 

И предсказать проблемы до их появления.

Разделили статью на 2 части. В первой — эффективные инструменты, во второй — те, к которым нужно присмотреться, прежде чем использовать.

Статья написана для блога Minervasoft. Компания занимается комплексным внедрением менеджмента знаний для среднего и крупного бизнеса: помогает запустить процессы и культуру для обеспечения быстрого доступа сотрудников к важной информации и создать обновляемый источник знаний — фундамент для внедрения GenAI-агентов.

Часть 1. Диаграммы, которые работают

Иерархическая структура работ (WBS)

WBS разбивает проект на понятные части. Каждая часть — конкретный результат, который можно увидеть или представить. 

Например, нужно сделать веб-приложение. Нарисуем диаграмму:

.

Из диаграммы видно, что работу по приложению можно разделить на 3 крупных блока:

• Планирование.

• Разработка.

• Внедрение.

Каждый из этих блоков тоже можно разделить на составные части. Например, блок «Планирование» включает в себя анализ требований, проектирование и планирование. таким образом можно декомпозировать каждую задачу до нужной степени детализации.

«WBS показывает стоимость каждой части проекта. Легко понять, сколько потрачено на конкретную задачу.

Подрядчики получают деньги только после завершения блока работ. Не за время, а за результат. Это заставляет их работать быстрее и лучше.

Ещё WBS показывает связи между задачами — какие можно делать одновременно, какие зависят друг от друга. Проще планировать работу всех команд» (OG_TD с Reddit)

WBS нужен для проектов больше месяца с командой больше 5 человек, когда много неопределённости на старте или нужно чётко распределить ответственность между участниками. Не нужен для команды из 3 человек, которая делает простой процесс за неделю, или когда все задачи понятны и роли распределены.

Диаграмма сетевого планирования (PERT)

Например, нам нужно сделать веб-приложение. Для этого необходимо:

• проанализировать требования к нему;

• спланировать его архитектуру;

• разработать Backend API и прочее.

Для каждой задачи делаем три оценки времени:

• Оптимистичная (O) — если всё пойдёт идеально.

• Наиболее вероятная (M) — если пойдёт как обычно.

• Пессимистичная (P) — если будут задержки и проблемы.

Например, чтобы проанализировать требования, в худшем случае понадобится 4 недели, в «обычном» — 2 недели, в «лучшем» — 1 неделя.

Из этих трёх чисел рассчитывается среднее ожидаемое время. Здесь это будет примерно 2,5 недели.

Потом определяем зависимость между задачами. Рисуем схему.

«Удобнее всего описывать PERT на стикерах в переговорке, так вся команда увидит связи и сможет предложить улучшения» (SVAuspicious Reddit)

Здесь это цепочка Старт → Анализ требований → Планирование архитектуры → Разработка Bachend API → Интеграция компонентов → Тестирование → Релиз в сторы.

Задачи «по бокам» (выделены зелёным) могут задерживаться, но до тех пор, пока не начнут тормозить задачи на критическом пути. 

Здесь это разработка Backend API. Программирование мобильного клиента и интеграция платежей могут подождать в разработке, но не дольше окончания создания Backend API.

«Если начать использовать диаграмму сетевого планирования на этапе разработки проекта, можно найти возможные узкие места в нём ещё на этапе анализа данных, до их возникновения в реальном развитии» (Gr8AJ с Reddit)

Например, с помощью PERT можно:

• Понять, какие задачи реально критичны для сроков, где нужно поставить самых опытных людей.

• Объяснить клиенту, почему одни задачи важнее других: «Смотри, если задержим это, весь проект будет закончен позже». По той же схеме объяснить это сотрудникам.

• Провести переговоры: «Хотите добавить фичу? Вот как это повлияет на сроки проекта».

Диаграмма Исикавы 

Это инструмент для поиска причин проблемы. Выглядит как скелет рыбы: в голове — проблема, от позвоночника отходят основные категории проблемы, а от них — факторы, которые могли привести к проблеме.

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

Рисуем голову рыбы и пишем «Задержки релиза мобильного приложения». От головы проводим линию — позвоночник, а от него рисуем черты причин. Получается костяк рыбы.

Категории причин могут быть такими: 

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

Для удобства возьмём 4 категории. Рисуем их на рыбе.

Затем начинаем заполнять кость «команда». Здесь такая ситуация: два разработчика работают первый месяц, дизайнер уволился в середине проекта. Записываем.

По технологиям такие проблемы: старая версия фреймворка, проблемы совместимости программ.

По ресурсам — бюджет урезали, время сократили. По требованиям — заказчик постоянно хочет что-то новое, требования часто изменяются. 

Получается так: 

И теперь можно подумать, какая из проблем основная и как можно на неё повлиять. 

Получается, диаграмма Исикавы — это инструмент для сбора причин. Его нужно использовать, когда проблема есть и непонятно, как её решать. Показывает полную картину.

«Удобнее всего использовать диаграмму Исикавы во время мозгового штурма» (Austenite2 с Reddit)

А ещё диаграмма работает только при честном диалоге:

«Если команда боится называть реальные проблемы или атмосфера напряжённая, толку не будет» (удалённый пользователь с Reddit)

Таблица, где записываются риски, действия, проблемы и решения — RAID Log

RAID — это аббревиатура, которая включает в себя Risks (риски), Actions (действия), Issues (проблемы), Decisions (решения).

RAID-log используется, когда нужно отслеживать все важные элементы проекта в одном месте. Покажем, как можно использовать инструмент, на примере проекта в IT — разработка приложения. Здесь он может выглядеть так:

Risks (риски) — что может пойти не так. iOS разработчик Максим хочет уволиться. API платёжной системы может измениться без предупреждения.

Actions (действия) — кто, что должен сделать и когда. Настроить автотесты. Провести нагрузочное тестирование.

Issues (проблемы) — что уже идёт не так. App Store отклонил приложение. Бюджет превышен на 20%.

Decisions (решения) — какие важные решения приняты. Использовать React Native вместо нативной разработки. Перенести релиз на 2 недели.

Вести журнал можно в таск-трекерах или просто в Excel и Google таблицах.

Создаём таблицу в Google Sheets с четырьмя столбцами:

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

«Действия в RAID и задачи в таск-трекере сильно отличаются» (BraveDistrict4051 с Reddit) 

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

Карта потока ценностей (VSM)

Это схема процесса от идеи до готового продукта. На ней видно, какие этапы проходит задача, сколько времени тратится на каждый этап, где задачи зависают и кто за что отвечает.

Например, команда начинает разрабатывать приложение, и начинаются задержки. Нужно понять, где процесс тормозит. Для этого нужно нарисовать весь путь от идеи до релиза. 

Покажем инструмент на примере небольшого этапа работы:

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

На получившейся карте становится видно: между анализом требований и согласованным ТЗ документы лежат в ожидании два дня, команда в это время ничего делать не может. На разработку тратится 3 дня работы, но задача висит в бэклоге 5 дней. Понятно, почему появляется задержка.

VSM часто вскрывает проблемы, связанные с бюрократией, медленными согласованиями или нехваткой ресурсов в других отделах. 

«Чтобы построить VSM, нужно собрать всех в одной комнате. В моей компании плохо передавалась информация между командами. Когда они составили карту процесса, выяснилось: никто не видел полную картину — каждый знал только свой кусочек» (SeanvThompson с Reddit)

VSM показывает проблемы, но здесь начинается новая сложность. Карта составлена, узкие места найдены, план действий готов. И что дальше?

Построили диаграмму, проанализировали процессы — а дальше информация расползается по чатам, письмам и документам. Через месяц никто не помнит, какие выводы делали и что решили исправить.

В системе управления знаниями Minerva Knowledge работа с информацией по проектам ведётся сразу всей командой и в одном инструменте. Результаты анализа, планы действий, обновления статуса. Команда всегда видит актуальную картину, а менеджер не тратит время на поиски того самого документа с выводами.

А если нужно быстро получить ответ на вопрос, можно воспользоваться GenAI-агентом Minerva Copilot. Он встраивается в любые рабочие системы, за секунды находит нужную информацию в базе знаний и прикрепляет ссылки на источник. А если работа с информацией ведётся по методологии Minerva Result, корректность ответов ИИ-помощника достигает 94%.

Попробовать продукты Minervasoft

Часть 2. Спорные инструменты

Дальше расскажем про 6 спорных диаграмм. Они популярны и эффективны, но при определённых условиях будут работать плохо. 

Матрица компетенций

Представим, что нужно распределить задачи в команде разработчиков. Для этого нужно понять уровень навыков каждого сотрудника. 

Создаём таблицу.

В ячейках указываем уровень: 1 — новичок, 2 — средний, 3 — эксперт. 

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

«Компания смотрит на матрицу навыков и видит, чего не хватает сотрудникам. Потом планирует обучение — кого отправить на курсы, кому дать наставника. Всё привязывают к целям компании» (Garuda с Reddit)

Матрица помогает принимать решения на основе данных, а не интуиции. Кого отправить на сложную задачу по оптимизации запросов? Кто может быть наставником для нового джуна? Нужно ли нанять ещё одного DevOps или проще обучить своего?

Важно договориться о системе баллов, прежде чем начать оценивать навыки команды. Чтобы оценки не были субъективными и можно было ориентироваться на общие правила. Если каждый понимает «уровень 2» по-своему, матрица превращается в поле для споров и обид.

Но есть проблемы:

• Матрица компетенций часто превращается в бюрократический инструмент: компании оценивают сотрудников по 50 навыкам, половина из которых не нужна для работы, проверяют раз в полгода и забывают до следующего раза. 

• Балльная система субъективна: один руководитель ставит 3 балла за React, другой за те же знания — 2. 

• Дизайнеры нервничают, что не умеют делать 3D, хотя рисуют интерфейсы, а разработчики не понимают, как изучать DevOps, если работают только с фронтендом. Т.е. в таблице могут быть ненужные для работы специалиста навыки, а за них всё равно оценивают.

• Количественные показатели вроде «нарисовал 100 экранов» не показывают качество работы. В итоге сотрудник видит, что не добрал полбалла до сеньора, расстраивается и теряет мотивацию, а матрица не помогает отследить реальный рост навыков (из тг-канала DesignOps с ?)

А ещё:

«Прежде чем кого-то уволить, руководители любят составлять матрицу компетенций. Если что — это не мы захотели, это сотрудник чего-то не умел, вот таблица» (huancuneo с Reddit)

Оценка перспектив продукта — SWOT-анализ 

SWOT — это матрица из четырёх квадратов: Strengths (сильные стороны), Weaknesses (слабые стороны), Opportunities (возможности) и Threats (угрозы). Помогает разложить проект или бизнес по полочкам.

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

Рисуем матрицу 2x2 и заполняем квадраты:

После заполнения ищем связи между квадратами. Как использовать опыт e-commerce разработки для выхода на растущий рынок? Как преодолеть незнание ресторанного бизнеса?

SWOT удобен при планировании на долгий срок — полгода, год, и когда нужно принять большое решение: запускать ли новый продукт, переходить ли на другую технологию.

Нюансы:

«SWOT-анализ редко выявлял самую главную проблему, с которой сталкивалась организация, и не даёт понять, как её решить» (verybassline с Reddit)

Без должной подготовки SWOT-анализ будет бесполезным.

«Сначала нужно изучить рынок, поговорить с клиентами, проанализировать конкурентов — собрать реальные данные. А уже потом использовать SWOT для сведения всех фактов в одну картину» (RabiiOutamha с  Reddit)

Матрица анализа заинтересованных сторон

Помогает понять, как взаимодействовать с руководителями и отделами. 

Например, компания занимается разработкой ПО. В ней есть менеджмент, юристы, безопасники, команды разработчиков и много кто ещё. Нужно понять, кто может помочь, а кто — навредить. Для этого нужно проанализировать влияние и интерес каждого участника. 

Матрица строится по такому принципу: 

Рисуем квадрат 2x2 и выписываем всех участников проекта:

• СТО и техлид могут заблокировать релиз и очень заинтересованы — попадают в «вовлекать». С ними нужно тесно сотрудничать, регулярно встречаться, согласовывать решения.

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

• Тестировщиков и дизайнеров — в «информировать»: они хотят знать каждое изменение, но повлиять не могут. Стоит держать в курсе, отвечать на вопросы, но не тратить много времени.

• HR и поддержку — в «наблюдать»: пока приложение не запустилось, им особо делать нечего. Достаточно общей рассылки.

«Когда проект постоянно менялся, матрица помогала отслеживать, как разные люди влияют на ход работ. Команда безопасности ИТ, к примеру, могла заблокировать внедрение — матрица показала, как с ними лучше работать, чтобы их влияние не тормозило проект» (predatorypineapple с Reddit)

Дерево метрик (OKR)

Дерево метрик показывает, как связаны все задачи в компании. С помощью него сотрудники понимают, как их работа помогает общему делу. Ещё оно позволяет быстро находить проблемы и перераспределять ресурсы туда, где они будут более эффективны. 

Например, нужно запустить мобильное приложение и привлечь новых пользователей. Для этого — разработать MVP (от англ. minimum viable product, «минимально жизнеспособный продукт» — тестовую версия товара, услуги с минимальным набором функций), привлечь пользователей и обеспечить стабильность. Заполним дерево метрик. 

Сверху ставим главную цель: «Запустить мобильное приложение и привлечь первых пользователей». Ниже — цели, которые нужно выполнить, чтобы закрыть главную цель. Их тоже можно разбить на подкатегории.

После её составления каждый из специалистов знает, что конкретно от кого зависит. Главная цель создания диаграммы OKR — перестать делать работу «в стол». Когда специалист видит, как маленькая задача влияет на большой результат, это придаёт работе смысл.

«Для того, чтобы OKR-система заработала, требуется время, после её внедрения проходит от шести до девяти месяцев, пока сотрудники без напоминания начнут ею пользоваться» (Correct_prize70 с Reddit)

OKR система бесполезна, если руководство не живёт по тем же правилам, что и команда. Сотрудники не понимают связь своих задач с общими целями компании, приоритеты меняются непредсказуемо без объяснений, создаются двойные стандарты — от команды требуют прозрачности, а топ-менеджмент принимает решения за закрытыми дверями. В итоге падает мотивация, люди понимают, что их OKR — формальность, а настоящие решения принимаются наверху по неизвестным критериям, и система превращается в бюрократическую отчётность.

Накопительная диаграмма потока (CFD)

График помогает найти узкие места и понять, где процесс тормозит.

Вот так выглядит «здоровая» CFD. Все линии идут параллельно — полосы не расширяются и не сужаются, рабочий процесс стабилен.

А вот на этом графике есть проблема:

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

Зелёная область (готовые задачи) растёт медленно. Разработчики простаивают, тестировщик работает на износ, а проект тормозит.

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

Диаграмма Ганта 

Показывает сроки всех задач проекта и их связи друг с другом.

Например, нужно сделать редизайн сайта. Для этого — проанализировать текущий сайт, написать ТЗ, создать дизайн, сверстать, протестировать и запустить. 

Выписываем все задачи проекта и определяем зависимости между ними:

Дизайн нельзя начинать без анализа. Вёрстку — без дизайна. Тестирование — без готового кода. Получается схема: Анализ → ТЗ → Wireframes → Дизайн → Вёрстка → Тестирование → Запуск

Оцениваем время на каждую задачу, считаем количество недель, сколько займёт проект. В нашем случае: 35 дней = 7 недель.

Рисуем диаграмму:

Диаграмма Ганта будет удобной для проектов с предсказуемым результатом и без форс-мажоров. Но таких проектов не бывает.

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

«Диаграмма Ганта подходит для презентаций руководству, когда оно хочет знать, над чем будет работать команда следующие 2–6 месяцев, — показывает весь проект на одном экране с датами и зависимостями» (watsyurface с Reddit)

Итог

Из 11 рассмотренных инструментов 5 работают стабильно:

• WBS разбивает проект на конкретные результаты и подходит для любого проекта длительностью дольше двух недель.

• PERT показывает зависимости между задачами и критический путь — полезен при планировании. 

• Диаграмма Исикавы собирает все причины проблемы в одном месте. 

• RAID Log отслеживает риски и управленческие мелочи. 

• VSM находит этапы в повторяющихся процессах, где процесс тормозит.

И 6 требуют особых условий — честности команды, долгого внедрения, предварительных исследований. Без этого превращаются в бюрократию или создают новые проблемы:

• Матрица навыков может превратиться в демотивирующую бюрократию. 

• SWOT-анализ без предварительных исследований становится пустыми размышлениями. 

• Матрица заинтересованных сторон при неправильном использовании ведёт к манипуляциям. 

• OKR Tree требует долгого времени внедрения. 

• CFD работает только при честном ведении истории задач. 

• Диаграмма Ганта создаёт иллюзию контроля и требует постоянных переделок.

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

Больше статей про спорные вопросы в найме, менеджменте и планировании читайте в Telegram. Подпишитесь, чтобы не пропустить.