Самое сложное в нашей работе — общение между командами.
Трой Магиннис
2.3
ВЫЯВИТЬ ЗАВИСИМОСТИ
Сан-Франциско, 2012 год
Крупная организация запускает третью аgile-трансформацию. Приезжает группа консультантов. Новые аgile-команды делят на подгруппы по пять-девять человек. Они поглощают неимоверное количество пиццы. (Помните ?) Они слышали, какого успеха добился Google с помощью небольших команд, которым хватает всего двух пицц, поэтому крупная организация решила, что в ее случае этот метод тоже сработает. Такая разветвленность повлияла и на другие группы. Они назвали это «выездной проблемой», потому что для решения любой задачи приходилось обращаться к коллегам. В таком режиме работали примерно 92% команд. И многие сотрудники «выезжали» часто.
Расхититель времени по имени «Невидимые зависимости» (или «Неизвестные зависимости»), словно самолет-невидимка, неслышно подкрался к командам. Он олицетворяет вот какую фразу: «К тому времени, как обнаружишь, что ничего не получается, ничего не получается уже очень давно». Точно так же к тому времени, когда невидимые зависимости будут выявлены, вы уже увязнете в неприятностях. Вред причинен. Но не отчаивайтесь, всегда есть надежда. Этот расхититель времени процветает, как вы понимаете, если множество групп работают над разными частями единой большой системы. Чем больше команд, тем выше вероятность, что многие сотрудники занимаются определенными функциями продукта одновременно, а это благодатная почва для огромного количества зависимостей.
Вы поймете, что неизвестные зависимости расхищают ваше время, когда услышите: «Кстати, он внес изменения/сделал что-то новое» — и от шока потеряете дар речи. Или хуже того, совершенно неожиданно (можно сказать, исподтишка) на вас обрушивается срочное сообщение от другой команды, которое указывает на катастрофическую ситуацию. Самое сложное в нашей работе — общение между группами. Что же теперь делать? Даже все пиццы в мире не сумеют усмирить этого расхитителя времени.
Когда кризис охватывает одну команду, занятые на других проектах обязаны бросить свои дела и помочь. Это приводит к так называемым высоким издержкам координации. Если это происходит, сотрудники недоступны, когда они вам нужны, — а ведь согласование работы поручают проект-менеджеру.
Крупная организация на третьем витке аgile-трансформации попыталась решить проблему координации с помощью электронных таблиц. Схемы зависимостей появились в некоторых командах. То есть некоторые группы знали о них, а некоторые нет. Больше всего пострадали группы общего обслуживания, которые поддерживали сразу несколько отделов.
Консультанты решили свести этот риск к минимуму. Подумав, они сформулировали идеи, призванные выявить все зависимости и эффективно выстроить работу.
- Проводить кросс-функциональные стендапы команд, чтобы обозначить зависимости.
- Определить зависимости с помощью матрицы зависимостей.
- Внедрить общие правила распределения работы между командами с помощью канбан-досок.
- Ввести должность скаута по выявлению зависимостей — системного архитектора, который знает структуру в совершенстве.
Идею о кросс-функциональных стендапах команд быстро отбраковали, потому что она непрактична (или, лучше сказать, невыполнима): взаимозависимые группы физически не могут посещать столько ежедневных встреч. Издержки координации слишком высоки, и в итоге сотрудники тратили бы все рабочее время на стендапы.
А вот матрица зависимостей оказалась более плодотворной инициативой. Один умный консультант сформировал ее во всю стену, и выглядела она примерно так, как на рис. 11, только намного больше.
Рис. 11. Физическая матрица зависимостей
Когда вся нужная информация была записана, люди увидели, наконец, какие проблемы создают эти зависимости. Чтобы выполнить все задачи, требовалось слишком много времени, но только потому, что специалисты, способные решить проблемы, оказались постоянно заняты.
Сколько времени тратится на координацию, если несколько небольших групп связаны огромным количеством зависимостей? Да, действительно, мы любим малые команды, потому что они быстрые и гибкие. Но помните: если вы быстро продвигаетесь вперед как отдельная группа, на уровне всей организации процесс идет гораздо медленнее из-за трудностей управления, вызванных многочисленными зависимостями. Что же делать с зависимостями? Если они стали проблемой для вас или если программа не дает необходимой прозрачности и наглядности, нужно найти способ визуализировать их между командами.
Существуют роскошные автоматизированные программы управления зависимостями, но ими пользуются немногие. Если у вас есть такая программа и она хорошо справляется со своей задачей (ваши зависимости от узких специалистов или сильносвязанной архитектуры не доставляют мучений), все прекрасно. Все равно полезно четко понимать другие методы визуального отображения зависимостей.
Иногда, чтобы обозначить зависимости, придется воспользоваться старым проверенным способом — нарисовать. Это одна из прелестей визуализации: можно задействовать давно забытые навыки работы с бумагой и фломастерами, которые были актуальны на школьных уроках рисования.
Обратите внимание на последнюю колонку схемы на рис. 12 — «АРХ»; имеется в виду обзор архитектуры. Его цель — получить рекомендации и поддержку эксперта для эффективного функционирования организации. Это не должно быть формальным одобрением.
Рис. 12. Рисуем схему зависимостей
Если подобные методы не отвечают вашим вкусам или неприменимы в вашем случае, то взгляните на рис. 13, который предлагает другой способ визуализации зависимостей на канбан-доске — в отдельной дорожке.
Рис. 13. Дорожка зависимостей на канбан-доске
Спроектируйте свои доски так, чтобы неизвестные зависимости даже носа не показывали (рис. 14).
Рис. 14. Метки зависимостей на канбан-доске
Или визуально обозначьте зависимости между командами (рис. 15), чтобы продемонстрировать их всей организации и избавить себя от дорогостоящих последствий.
Рис. 15. Зависимости между командами
Команды редко работают в изоляции. Если понадобятся навыки и умения другой группы, то между ними должен произойти обмен. Чтобы избежать проблемы «с глаз долой — из сердца вон», визуализируйте поток работы между отделами. Это поможет прогнозировать работу и избегать ситуаций «кстати, сегодня нужно сделать еще вот это». Это также дает представление о возможных трудностях и проблемах, которые могут обрушиться на коллективы, а это обычно высоко ценится. Визуализация важной межкомандной информации помогает группам общаться.
Небольшие аgile-группы доминируют в IT-отрасли, и это разумно. Ничто не сравнится с талантливой, мотивированной и сплоченной командой, которая быстро принимает решения и может выдать удивительные результаты. Если коллектив обеспечен всем, чтобы разработать, создать и развернуть продукт, можно только позавидовать — неизвестные зависимости ему не страшны.
Однако крупным организациям с большим количеством отделов везет в этом отношении куда меньше. В какой-то момент компания достигает таких масштабов, что множеству сотрудников, работающих над большим количеством разных проектов, не требуется знать о каждом решении, которое на них влияет (например, изменения в архитектуре и интеграция третьей стороны). Чем больше команд, тем выше вероятность того, что новые зависимости повлияют на ваш рабочий день, проект, задачу и т. д. Чем активнее WIP, тем значительнее шансы у неизвестных зависимостей загнать вас в угол.
Вот почему нужно выявлять все зависимости — чтобы команды по незнанию не нарушали существующего алгоритма работы. Спросите любую группу, чей код сломала другая команда из-за того, что не знала о созданной ею зависимости, — совсем невесело устранять ошибки в продакшен-среде, пока клиенты жалуются на вашу компанию в Twitter. Будьте в курсе и информируйте других; используйте любые методы, эффективные в вашей ситуации, и помните, что лучше начать с простого, чем не начинать вообще. Хорошая видимость помогает перебраться на следующий уровень. И возможно, даже получить поддержку начальства для организации работы по группам продукта, а не проектным командам, — а об этом стоит задуматься, если ваша организационная структура не справляется со своей задачей.
Проблема в том, что проектные команды недолговечны. Их распускают после того, как они свалят свой проект на группу сопровождения или эксплуатации и займутся другим делом. Эта передача обходится дорого и отнимает немало времени. Пока проектная команда торопится успеть в срок, многое упускается из виду, например информация по зависимостям. А это увеличивает объем WIP, потому что отдел-получатель должен прервать действия отправителя, чтобы получить необходимую информацию для корректной работы. Так экспертные знания проектной команды превращаются в зависимость от предметных знаний. Текущие задачи накапливаются, потому что к тому времени, как операционная группа отвлекает людей из проектной, те уже давно занимаются чем-то совершенно иным и им приходится переключаться с одного на другое, пока старый проект не обретет стабильность или пока не будут обучены новые «опекуны», — видите, сколько зависимостей.
Если организовать команду вокруг продукта, то сотрудники, которые разработали и протестировали функции, остаются на месте. Нет нужды в сложной, запутанной передаче проекта из одних рук в другие. Напротив, сокращается количество зависимостей во время его передачи в операционную поддержку.
Отличие проекта и продукта довольно существенно по многим причинам, так что обсудим их в двух словах, чтобы не путать понятия, учитывая, что одно из них намного продуктивнее другого. Проект — это одна масштабная, монолитная задача, и координация работы в рамках крупного релиза — непростой и длительный процесс. Проекты создают большой объем работы, которую в итоге нужно передавать отделам выполнения и сопровождения. Проекты приходят и уходят и требуют дополнительной синхронизации и коммуникации, чтобы управлять действиями временных команд. В ходе этих громоздких проектных процессов может возникнуть множество проблем.
Напротив, организация и управление вокруг продукта создают условия, чтобы одна и та же группа сотрудников с необходимыми экспертными знаниями постоянно участвовала в процессе. Разработчики функций продукта не уходят; они остаются до конца — чтобы внести изменения и обеспечить поддержку. Проектные группы оцениваются по статистическим параметрам (например, тестировщики — по количеству багов в программе), в то время как команды продукта рассматриваются по итоговой бизнес-ценности. Старший технический директор Pivotal Корнелия Дэвис отметила в обсуждении на форуме DOES 2017: «Архитектура неотъемлемо связана с тем, как мы работаем. Предпочтительная архитектура представляет собой слабосвязанные компоненты, отдельные микросервисы, разработанные конкретными группами — автономными командами продукта, а не проектными» .
УПРАЖНЕНИЕ
Матрица зависимости «Кстати, надо сделать еще и это»
Цель: визуализировать зависимости между командами, помочь сотрудникам прогнозировать ситуацию и предотвратить задержки из-за неизвестных или невидимых зависимостей.
Время: 60–90 минут (или дольше, если команды очень большие).
Материалы:
- крупная доска, или большой лист бумаги, или место на стене,
- стикеры,
- маркеры,
- пицца (абсолютно необходимо).
Инструкции: вам нужны сыщики в командах. Их задача, если они, конечно, готовы взвалить это на себя, — выискивать и визуально отмечать зависимости между всеми группами, которые могут негативно повлиять на их работу.
Рис. 16. Пример упражнения
Нарисуйте большой квадратный график со столбцами и строками. Прикрепите стикеры с названием вашей команды на заголовки столбцов и строк.
Строки показывают команды, на которые оказывается влияние. Столбцы показывают команды, влияющие на других.
Определите результаты каждой команды, которая создает работу для другой группы, и напишите это число в ячейке на пересечении двух команд.
Например, чтобы обеспечить клиентам контент по тренингу самообслуживания, нужно задействовать маркетинг и продажи, потому что для продвижения и поддержки предпродаж нужна информированность. Продажи требуют мониторинга клиентского опыта и сбора данных по клиентам — для персонализированных предложений и промоакций, что влияет на команду 1, так как придется вносить изменения в сайт и сбор данных. Команда 1, в свою очередь, воздействует на IT-операции из-за требований к информационной безопасности и хранению данных.
Ваша задача — выявить зависимости между группами по важным функциям или проектам и пометить крестиком соответствующий квадрат. Каждая ячейка матрицы представляет одну или несколько зависимостей между двумя пересекающимися командами. Отметьте сами зависимости в матрице.
Когда все межкомандные зависимости будут указаны, обсудите, какие действия можно предпринять, чтобы сократить риск негативного влияния на работу другой группы.
Вариант 1. Помимо зависимостей, укажите в матрице предстоящие риски.
Вариант 2. Вместо команд внесите в матрицу компоненты софта.
КЛЮЧЕВЫЕ ВЫВОДЫ
- Небольшие команды работают быстро, но, если между ними существуют зависимости, придется смириться с тем, что работа компании как единого организма будет тормозиться.
- Составьте канбан-доску таким образом, чтобы отметить на ней зависимости и избежать сюрпризов.
- Визуально обозначьте зависимости, чтобы показать всем сотрудникам и избежать дополнительных бизнес-затрат.
- Визуализируйте зависимости между канбан-досками разных команд.
- Опирайтесь на команды продукта, чтобы сократить количество проблем, связанных с проектными группами.
