Хабр, привет! Я Саша, Product Manager в Ozon. Хочу сегодня поговорить с вами об исследовании зависимостей между подсистемами проекта, в частности, и повышении прозрачности процессов в разработке в общем.

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

Почему?

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

Все эти варианты говорят нам о наличии рассинхрона команд, ожиданий и реальности, рассинхрона подсистем относительно общего процесса, вследствие этого команда(ы) делает «не то» «не так» или не делает вовсе.

Давайте разбираться — расскажу вам об инструменте, который поможет выявлять приводящие к подобным ситуациям серые зоны, нестыковки, зависимости между подсистемами проекта; поможет всё это дело визуализировать и анализировать. Инструмент я назвала картой зависимостей.

Содержание

Откуда взялась карта зависимостей
Шаг 0: зафиксируем ожидания
Техника безопасности
Подготовка: модель черного ящика
Идём в поля
Метод бумажной гармошки
Как пользоваться картой зависимостей
Ограничения, точки роста и финальные напутствия по карте зависимостей

Откуда взялась карта зависимостей

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

Исследование я проводила через общение с разными причастными людьми, результаты стала визуализировать как-то так:

Так появилась карта зависимостей.

С тех пор я регулярно пользуюсь этим инструментом; применила к 30+ командам в 3 разных доменах, провела несколько десятков сопутствующих интервью.

Кроме онбординга (откуда карта появилась изначально), я видела применимость инструмента ещё вот в таких ситуациях:

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

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

Давайте поделюсь с вами, как именно это работает.

Шаг 0: зафиксируем допущения

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

Система воспроизводит сама себя.

Или — новые процессы всегда опираются на старые. Даже если рассматриваем случай “полностью выбросили все старые процессы” и “будем работать совсем по-другому” — это означает, что новая система возникает не на пустом месте, а на противопоставлении старой; то есть формально всё-таки опирается на прежнюю конфигурацию, пусть и через отрицание. А уж если новые процессы в явном виде наследуются от старых — то и подавно.

Люди выбирают лучший из доступных для них вариантов.

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

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

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

Подготовка: техника безопасности

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

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

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

В технику безопасности входят:

Доверие

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

Режим «почемучка»

Убираем всё стеснение; даже очевидные вопросы — всё равно спрашиваем. Как можно чаще уточняем, почему происходит именно так.

Феноменологический подход

Или по-другому — всё есть феномен. Например, заказчик пришёл в продуктовую команду ругаться, что они не выполнили свои обязательства, не уложились в срок. Феномены: а) фича не запилена в ожидаемый срок; б) заказчик ожидал фичу именно к этой дате; в) фича настолько важна заказчику, что он не просто написал в почте, а пришёл лично, чтобы высказать своё недовольство; г) заказчик пришёл ругаться с продуктовой командой, не пошёл эскалировать на руководство.

Готовность к неидеальности мира

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

Установка на поиск несовершенства системы, а не виноватых

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

Готовность не делать резких телодвижений

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

Ещё подготовка: модель чёрного ящика

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

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

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

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

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

Какие границы у системы? Что мы в неё включаем? Какую конкретно часть всего процесса мы будем рассматривать?
Как среда влияет на систему? Как система влияет на среду?
Откуда поступают входящие сигналы? Как это происходит?
На выходе — кто пользователи продукта? Какие там есть сегменты?

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

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

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

Для моих карт зависимостей чаще всего требовались такие разрезы:

организационная структура,
KPI,
метрики,
архитектура.

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

Например, разрез организационной структуры. Тут речь о том, кто чей начальник официально. Как цели спускаются сверху вниз, как результаты репортятся наверх, какая система мотивации выстроена вокруг этого всего (KPI, OKR, премии, прочее).

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

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

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

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

Идём в поля

Наш ключевой инструмент для получения информации — разговор.

Договариваемся про интервью с такими людьми:

непосредственный руководитель — помимо того, что вытащим из человека нужную информацию, дополнительно уточним, с кем ещё можно пообщаться, чтобы лучше разобраться в процессах;
тимлид, продакт, проектный менеджер вашей команды;
все лиды и руководители внутри «чёрного ящика» (вообще все, да; по очереди).

Далее идем к коллегам, у кого есть экспертиза по интересующим нас разрезам: про метрики — к главному аналитику продукта; за архитектурой — к архитектору; за инсайтами про источник задач для бэклога — к заказчикам; за пользовательским опытом — к крайним за UX и Customer Success.

Структура разговора такая:

представиться,
рассказать, что делаете и зачем,
показать, что уже удалось выяснить к этому моменту (крайне полезный, но всё-таки опциональный пункт),
уточнить параметры системы, проверить гипотезы — перезадаём тут вопросы из модели «чёрного ящика”»(границы, взаимное влияние среды и системы, входящие/выходящие сигналы),
задать вопросы по разрезам — ключевое, ради чего всё затевалось.

Вопросы по разрезам могут звучать следующим образом.

Оргструктура

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

Архитектура

Какая архитектура у всего продукта? Какие зоны ответственности у каждой команды? Есть ли места пересечения зон ответственности? Как устроены релизы?

KPI

Какие KPI у продуктовых команд? А у лидов? Как KPI связаны с пользователями продукта? Как формируются KPI?

Метрики

Как звучат индикаторы успеха нашего продукта? Метрики «счастья» пользователя? Метрика North Star? Есть ли дерево метрик (в любом виде)? Какие гипотезы по влиянию метрик друг на друга нам уже известны, а какие ещё только предстоит проверить?

Обратная связь.

Как команда получает фидбэк по продукту? Как фидбэк влияет на бэклог? Кто и как обрабатывает обратную связь? Как принимается решение, в какую именно команду будет направлен запрос?

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

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

На выходе после серии интервью получается что-то такое:

Метод бумажной гармошки

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

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

Допустим, карта зависимостей у нас какая-то такая:

Давайте схлопнем карту — на время спрячем блоки «Архитектура» и «Метрики»; посмотрим на «Бэклог (вход)», «Оргструктуру», KPI и «Пользователей (выход)».

Точно ли в бэклоге у команды задачи — про счастье целевой категории пользователей? KPI руководителей и команды стыкуются с финальными пользователями?

Проделываем это упражнение со всеми блоками и всей картой в целом.

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

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

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

Это упражнение по сопоставлению можно проделать со всей картой и всеми разрезами. Новые идеи и гипотезы могут появиться на любом из уровней «схлопывания».

Как пользоваться картой зависимостей

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

Для разных вариантов причин можем иметь разные последствия:

вместо суперзадачи команда занимается какой-то ерундой — перестанем доверять команде, начнём думать что-то из серии «давайте там всех уволим»;
команда не поняла, что фича принесёт реальные деньги и насколько это важно — ставим серию «разъяснительных» встреч;
недостаточно описаны требования — уходим писать супердетализированное техническое задание («чтобы вообще не нужно было думать, просто сделайте»);
задача потерялась в недрах бэклога — увольняем продакта.

Карта зависимостей может помочь обнаружить, что причины ситуации могут быть иные. Возможно, мы пришли не в ту команду. Если у них совсем другие KPI, то, какой бы перспективной ни звучала наша фича, она не попадает в область их интереса; с любой степенью детализации. Или KPI те, что нужно, но у команды нет доступа к нужному куску архитектуры (например, там у нас монолит и очередь на релизы). Или очередью задач управляет не продакт, а тимлид.

Вот несколько примеров результатов, которые мне помогала получить карта зависимостей.

Пример 1: отказались от внедрения LeSS

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

Пример 2: выявили разницу в целеполагании между продуктовой веткой и инженерной

До построения карты зависимостей мы там пользовались OKR; в целом всё выглядело хорошо. Но Key Results оказались принципиально разные у продактов и инженерных лидов — их фокус был направлен на разное. Попутно выявили, что по факту отслеживание OKR происходит несистемно, а в рандомные моменты случайными людьми.

Пример 3: увидели проблему — нет цельной иерархии метрик

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

Пример 4: нашли узкое горлышко для всего входящего потока задач

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

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

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

Например, в случае с разницей в целеполагании между инженерной и продуктовой веткой — именно это расхождение давало возможность технически совершенствовать систему, постепенно уменьшать технический долг, благодаря тому, что лид инженеров настаивал на таких задачах (ведь у него такие KPI!).

Так что эти кейсы — не про чёрное и белое, не «было плохо, стало хорошо», но про эволюцию системы, комплексную работу с точками роста.

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

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

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

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

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

Если прямо сейчас вокруг вас нет стабильной оргструктуры, устоявшейся системы целеполагания, метрик, то использование карты может оказаться преждевременным. Этот инструмент — для стадии масштабирования. Если компания только ищет свой Product/Market Fit — кажется, у вас есть более срочные и важные дела, чем визуализировать зависимости между подсистемами.

Не могу поручиться, как всё это сработает в не IT-компаниях — тут мне сложно судить о локальной специфике, до этого момента не доводилось применять карту в таком контексте.

Есть ненулевая вероятность, что в рамках исследования вы придёте к выводу, что некоторая подсистема не помогает, а мешает работе всей системы. Это ок, так бывает. Что делать с такой ситуацией — не будет принципиально отличаться от большинства других кейсов — о найденном есть смысл поговорить с причастными коллегами, руководством. В конце концов, это только лишь ваша гипотеза, которая опирается на слова коллег.

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

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

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

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

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

Из идей, что можно ещё интересного поделать с картой зависимостей:

добавить Definition of Ready / Done для входного и выходного потока;
интегрировать с процессом Discovery;
уточнить, какие цели (OKR, KPI) у основных заказчиков/стейкхолдеров;
расширить на контекст эксплуатации, работы с багами и запросами;
масштабировать иерархию метрик — за пределы исследуемого изначально продукта вплоть до метрик всей компаний.

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

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

Успехов вам с повышением прозрачности в процессах; надеюсь, визуализация будет вам в этом полезна!

Что ещё посмотреть по теме

«Адаптироваться необязательно. Выживание — дело добровольное», Евгений Пешков (ЦИАН)
«Что делать с командными проблемами, которые не удаётся решить никакими способами», Илья Любимов (Nexters)
«Ваши процессы попахивают. Как это понять и что делать?», Филипп Дельгядо (OpenWay Group)
«Ускоряем Cycle Time и растим счастье в команде», Никита Дубко (Яндекс)

Создание карты зависимостей: как увидеть системный уровень в процессах