Замкнутый круг: как найти скрытые зависимости в проекте с помощью DSM

Копирайтер не может закончить текст, пока не увидит дизайн. Дизайнер ждёт окончательный текст, чтобы собрать макет. Разработчик ожидает утверждённую страницу, а маркетолог собирается проверить предложение только после того, как увидит готовый лендинг. Формально у каждой задачи есть исполнитель и срок, но проект постоянно возвращается к уже пройденным этапам. Такие зависимости можно обнаружить до начала производства с помощью матрицы DSM. Разберём, как построить её в обычной таблице, найти замкнутые циклы и определить, какие договорённости нужно изменить.

Шесть задач, из которых получилась бесконечная работа

Представим, что небольшая digital-команда готовит посадочную страницу для нового продукта. Проект разбит на шесть основных задач: утвердить оффер, написать текст, подготовить дизайн, сверстать страницу, настроить аналитику и проверить готовый лендинг.

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

Но реальные условия оказываются немного сложнее.

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

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

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

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

Для подобных ситуаций существует метод Design Structure Matrix — DSM, или матрица структуры зависимостей.

Матрица, которая показывает то, чего нет в списке задач

DSM появилась в инженерном проектировании как способ анализировать взаимосвязи между элементами сложных систем. Один из вариантов метода — Task DSM — рассматривает зависимости между отдельными работами.

Исследователи Роберт Смит и Стивен Эппингер использовали такие матрицы для анализа последовательных, параллельных и взаимозависимых проектных задач. В их работах показано, что некоторые процессы невозможно представить простой линейной цепочкой: отдельные работы требуют повторных итераций и обмена информацией.

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

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

Возьмём наш пример с лендингом и обозначим задачи буквами:

A — утвердить оффер. Это отправная точка, для которой в нашей упрощённой модели нет входящих зависимостей.

B — согласовать окончательный текст. Требуются утверждённый оффер A и результаты работы над дизайном C.

C — согласовать дизайн. Необходим результат работы над текстом B.

D — сверстать страницу. Нужен утверждённый дизайн C.

E — настроить аналитику. Для завершения этой работы требуется результат вёрстки D.

F — проверить готовый лендинг. Необходимы готовая вёрстка D и настроенная аналитика E.

Теперь попробуем расположить работы в логическом порядке. Большинство связей не вызывает вопросов: оффер нужен для текста, дизайн — для вёрстки, а готовая страница — для итогового тестирования.

Но между задачами B и C возникает противоречие. Согласование текста требует готового дизайна, а согласование дизайна — готового текста.

Получается двусторонняя зависимость B ↔ C. Переставить эти задачи местами в плане не получится: при любом порядке одна всё равно будет ожидать результат другой.

Вот он — замкнутый круг.

Это и есть взаимная зависимость, которую DSM помогает сделать видимой. Причём матрица обнаруживает её ещё на этапе планирования, когда команда только договаривается о последовательности работ.

Как построить собственную DSM в Google Таблицах

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

Шаг 1. Выпишите результаты работ.

Лучше использовать конкретные результаты, а не названия отделов или слишком крупные этапы. Например, «Согласовать текст лендинга» подходит лучше, чем «Работа копирайтера».

Если задача сформулирована слишком широко, внутри неё могут скрываться несколько разных зависимостей.

Шаг 2. Продублируйте перечень по горизонтали и вертикали.

В Google Таблицах можно разместить названия задач в диапазоне A2 и повторить их в B1. Получится квадратная матрица 6 × 6.

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

Шаг 3. Для каждой строки проверьте, какие результаты нужны на входе.

Возьмём задачу «Сверстать страницу». Спросите разработчика, какие результаты других работ необходимы, чтобы выполнить её без возврата к исходным материалам.

Если нужен утверждённый макет, поставьте крестик на пересечении строки «Вёрстка» и столбца «Дизайн».

Правило чтения здесь одно: крестик означает, что задача в строке зависит от задачи в столбце.

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

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

Шаг 4. Найдите отметки выше диагонали.

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

Такие отметки сигнализируют о возможной обратной передаче информации. Но сама по себе отметка ещё не означает замкнутый цикл: возможно, достаточно просто изменить порядок задач.

Если же обнаружена взаимная зависимость B ↔ C, перестановка уже не поможет.

Шаг 5. Подсветите взаимные связи.

Для небольшой таблицы достаточно визуальной проверки. Найдите крестик на пересечении двух задач и проверьте симметричную ячейку.

Например, если B зависит от C, посмотрите, зависит ли C от B. Когда обе связи существуют, выделите соответствующие ячейки красным.

С более сложными циклами ситуация интереснее. Зависимости могут образовывать цепочку A → B → C → A, даже если ни одна пара задач не зависит друг от друга напрямую в обе стороны.

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

Для первого эксперимента с шестью-восемью задачами ручной проверки вполне достаточно.

Нашли цикл. Теперь нужно понять, почему он существует

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

Вернёмся к копирайтеру и дизайнеру.

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

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

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

Можно изменить последовательность следующим образом.

Было: согласовать окончательный текст, согласовать дизайн, вернуться к тексту, исправить дизайн, повторить согласование.

Станет: сначала утвердить оффер и основные смысловые блоки, затем подготовить черновой текст с ориентировочным объёмом. На его основе дизайнер собирает предварительный макет. После этого копирайтер и дизайнер совместно проверяют содержание и композицию, согласовывают окончательную версию и только тогда передают её в разработку.

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

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

Это один из возможных способов работы с циклическими зависимостями — организовать необходимые итерации внутри согласованного блока.

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

Универсального способа убрать все циклы не существует. Некоторые взаимные зависимости возникают из самой природы работы.

Не все зависимости нужно устранять

Здесь есть риск увлечься идеей идеального линейного процесса.

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

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

Сотрудничество между специалистами само по себе не является проблемой. Иногда именно совместные итерации позволяют найти лучшее решение.

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

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

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

Ответы зависят от конкретного проекта, а не от красоты получившейся матрицы.

Как перенести новую последовательность в Канбано

После анализа DSM у команды появляется более точное представление о порядке работ. Но сама матрица не предназначена для ежедневного управления задачами. Она помогает спроектировать процесс, который затем нужно где-то реализовать.

Для нашего примера можно собрать в Канбано доску производства лендинга с колонками «Запланировано», «Подготовка», «Совместная проверка», «В работе» и «Готово».

При этом ключевой результат анализа — не количество колонок, а изменение самих задач.

Вместо двух взаимно заблокированных карточек «Утвердить финальный текст» и «Утвердить дизайн» команда создаёт новую последовательность.

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

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

Карточка «Согласовать текст и дизайн вместе». К карточке прикрепляются актуальный макет и текст. В чек-листе фиксируются конкретные проверки: формулировка оффера, читаемость основных сообщений, соответствие визуальной композиции содержанию, наличие обязательных элементов.

И только после выполнения последней карточки согласованную версию можно передавать в вёрстку.

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

Самостоятельно рассчитывать матрицу или находить циклы Канбано не будет — это отдельный аналитический этап, который мы проводим в таблице.

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

Собрать такую доску можно в Канбано.

Проверяем, изменилась ли работа на самом деле

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

Поэтому стоит провести небольшой эксперимент на нескольких сопоставимых задачах.

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

Количество возвратов. Сколько раз готовый результат передавали назад на доработку. Например, сколько раз текст пришлось переписывать после проверки дизайна.

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

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

После изменения процесса повторите наблюдение и сравните результаты.

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

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

Смысл эксперимента — проверить, действительно ли найденная зависимость была существенной и помогло ли её изменение.

Матрица не исправляет процесс за команду

DSM полезна тем, что заставляет посмотреть на задачи не как на отдельные поручения, а как на систему обмена результатами. Она показывает, где работу можно выполнять последовательно, где допустима параллельная подготовка, а где участникам придётся возвращаться друг к другу.

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

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

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

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