[Перевод] Что не так с управлением поставками?
Меня не покидают размышления — что на самом деле значит быть Delivery Manager-ом? И почему мой опыт в этой роли часто расходится с опытом и ожиданиями других?
В 2021 году в какой-то период я замечал, что других Delivery Manager-ов (DM) просят брать на себя всё больше обязанностей по управлению проектами. В то время я работал с двумя отличными командами, которые развивались с повышенной автономией и зрелым продуктом, с некоторыми основами agile и инвестициями в подход DevOps. Меня огорчало, когда я слышал, как другие DM определяли для своих команд фиксированный объём работ и сроки выполнения. Ещё больше я расстраивался, когда старшие менеджеры ругали DM за то, что они не могут составить диаграмму Ганта с полным перечнем этапов, ориентированных на конкретные фичи.
Я смог избежать такой практики и сосредоточил свои усилия на создании подходящей среды для команд, которые я поддерживал. Не у всех была такая роскошь.
В июне я вкратце поделился своими мыслями в X (бывший Twitter). «Читая и слушая о трудностях работы Delivery Manager-а в государственном секторе, я осознал, что эта роль несёт в себе много ответственности… К сожалению, этот багаж может встать на пути развития потенциально высокоэффективных команд». Я чаще использую X, чем пишу блоги, и поэтому решил поделиться этим там, чтобы узнать мнение других людей. Это вызвало положительное обсуждение, но показало, что единого мнения о том, что такое управление поставками — нет; даже в государственном секторе, где эта роль уже устоялась.
В интернете можно найти много интересных мнений о Delivery менеджменте («управлении поставками»). Лично мне больше всего нравится высказывание Джейсона Найта: «Delivery Manager возрождается, когда побеждают менеджеров проектов в финальной битве». Лично я считаю, что Delivery Manager сталкивается с множеством проблем и в конечном итоге, вероятно, не всегда является оптимальной для выполнения задач.
Названия должностей могут быть проблематичными в лучшие времена, так как они создают предположения и усиливают иерархию. Ни то, ни другое не способствует созданию гибкой или бережливой среды, а также не способствует психологической безопасности. Как отметил Марк Далгарно недавно, иногда работать без чёткого названия должности может быть проще. Разбор названия Delivery Manager помогает выявить проблемные моменты, связанные с этой ролью.
Понятие «Delivery» может вызывать затруднения. Я лично начал сомневаться в его использовании в различных контекстах. Часто слово «Delivery» используется для обозначения поставки «чего-то». В большинстве организаций это означает завершение проекта с конкретными результатами. В agile-среде это может интерпретироваться как достижение определённых этапов на пути к цели. Однако, мой опыт показывает, что поставка «чего-то» не всегда является правильным решением. Как только мы распознаем плохую идею (или плохую цель), доставка должна изменить направление или даже прекратиться. Когда мы осознаем недостатки идеи (или цели), поставка должна измениться или быть отменена. В случае фиксированного объёма работ это может означать, что ничего не было доставлено в рамках этого объёма. Как Delivery Manager, как вы оцениваете такие ситуации, особенно если вашу работу оценивают по результатам?
Чтобы избежать неудачных идей, команды часто разделяют процесс обдумывания и выполнения, а также проектирования и поставки. Фазе поставки предшествует фаза исследования. Определение поставки как отдельной сущности возвращает нас в кроличью нору жизненного цикла «спроектируй, реализуй, выброси». Джон Катлер недавно сказал: «Я вижу рекламу того, что называется Delivery менеджметом. Кто позаботится о программном обеспечении после его создания?». Понятие «поставка» часто используется для обозначения «реализации заранее определённых идей», но если рассматривать поставку как цель (или стратегию), мы можем легко уйти в режим «фабрики фичей», поставляя множество «идей», которые не приносят пользы и в конечном итоге оказываются заброшенными из-за отсутствия дальнейшего планирования.
Чтобы найти решение этой проблемы с «поставкой», нужно ответить на два вопроса: «Что поставлять?» и «Зачем это поставлять?». Для меня на оба этих вопроса отвечает одно слово — ценность. То, как мы определяем ценность, — это отдельная и сложная тема, но она является важным уточнением для части управления поставкой. Мы должны поставлять ценность, потому что она будет ценной. Однако это очень сильно пересекается с другими ролями в успешной многопрофильной команде. Может ли DM действительно рассматриваться как «менеджер по поставке ценности»? Это больше похоже на управление продуктом в общих чертах.
Из этого следует еще один аспект проблемы названия роли. Менеджер Аллен Холуб уже затрагивал эту тему: «Слово «менеджер», похоже, всё больше и больше описывает две совершенно несовместимые профессии. В каскадной модели разработки менеджер отвечает за выполнение работы в срок и в рамках бюджета. В случае Agile чаще всего речь идет о тренерах или коучах, но их называют «менеджерами». Лично я считаю, что использование одного и того же термина для двух разных профессий неэффективно и вводит в заблуждение. Если они не управляют чем-то, то они не являются «менеджерами». Команды сами управляют своей работой. Коучи лишь помогают им в этом. Называйте их коучами, если они таковыми являются».
Работа в качестве «менеджера» ограничивает способности команд, которым я оказывал непосредственную поддержку, быть автономными и самоуправляемыми. Это проявляется в запросах от членов команды о подписании отпусков или увольнении кого-то. Управление порождает иерархию, а иерархия противоречит принципу равенства. Команды не могут эффективно функционировать в условиях ложной навязанной иерархии. Мне пришлось много работать в командах, чтобы соответствовать управленческому аспекту моей должности в качестве DM и быть способным управлять средой, в которой мы все работали, а также препятствиями, которые неизбежно появлялись на нашем пути. Тем не менее, когда старшие коллеги ожидали, что я буду представлять команду на общих собраниях или руководить работой инженеров, это активно работало против идеи, что команде не нужен «менеджер» из мира каскадной модели управления. Мы стремились сохранить старые методы работы, пытаясь при этом применить новые способы мышления.
Мой личный опыт сформировался благодаря попытке не быть руководителем команды. Я никогда не представлял себя лидером, вместо этого я был там для того, чтобы дать всем возможность поставлять ценность и чувствовать себя при этом ценным. Однако я регулярно слышу, как DM заявляют, что они недовольны тем, что «их» инженеры недостаточно продуктивны, или что они здесь для того, чтобы руководить командой. Роль Delivery Manager-а создаёт пространство для выполнения людьми автократических функций. Командование и контроль могут процветать в командах, где DM мыслит как менеджер проекта или вынужден занимать позицию, в которой его собственная безопасность на работе зависит от поставки продукта или услуги. DM не должен никого подгонять, но название должности оставляет возможность для этого.
По сути, Delivery Manager — это проблематичная должность, потому что один человек не может отвечать за поставку. Как сказал Аллен Холуб: «В последнее время я встречаю название «Agile Delivery Lead». Такого не существует. Поставка — это работа всей команды». Поставка — это командный вид спорта. Я регулярно слышу от старших коллег «Ну, ты же отвечаешь за поставку», и мне всегда хочется сказать:»…нет, не я, мы все отвечаем». Если кто-то сомневается в этом, я бы с удовольствием посмотрел, какой продукт или услугу сможет предоставить комната, полная DM, в одиночку. Вероятно, он и близко не будет таким же хорошим, как тот, что создаёт многопрофильная команда.
Однако если заглянуть в госсектор, где работают многие DM, можно найти краткое определение. «Delivery Manager отвечает за поставку продуктов и услуг». Стоит ли удивляться тому, что многие ожидают от DM управления проектами команды? Сколько антипаттернов это закрепляет? Если вы не занимаетесь непосредственно поставкой, зачем вы здесь? Кроме того, действительно ли мы хотим создать в госсекторе культуру, в которой DM отвечает за поставку ценности, а не команды отвечают за это вместе? Это предполагает стремление к единой точке вины или к одному человеку, которого руководители могут использовать, чтобы избежать общения с командой для достижения результатов. Это не хочу быть частью такой культуры.
К счастью, в управлении государственным сектором всё более тщательно прорабатывается и выходит за рамки простой ответственности за результаты. Интересно, что на странице GOV.UK слово «коуч» употребляется тринадцать раз. Это говорит о том, что первоначальное понимание роли не совсем точно. Хотя слово «коуч» не подчёркивается, возможно, к этой роли следует применить рекомендации Аллена Холуба. Должен ли в каждой команде быть Delivery коуч вместо менеджера?
Руководство по определению роли каждого сотрудника в сервисной команде поддерживает этот аргумент. В документе говорится о том, что DM существует для поддержки команды: создание среды, устранение препятствий, обеспечение автономии, поддержание доступности.
Это также согласуется с часто обсуждаемым определением управления поставкой Эмили Веббер: «Delivery Manager — это человек в квалифицированной многопрофильной команде, который заботится о том, чтобы эта команда могла поставлять ценности. Для этого он создаёт правильную среду для успешной работы команды, помогает ей самоорганизоваться и создает культуру обучения и прозрачности». Быть помощником, который помогает команде самоорганизоваться и обрести автономию, не очень-то сочетается с ответственностью за результат или с идеей управления.
Совсем недавно Эмили Веббер написала о планах развития для многопрофильных организаций. В ней есть несколько замечательных идей о том, как не допустить того, чтобы роли стали существовать в отрыве друг от друга. Это позволяет признать ценность T-, P- и прочих ролей, в памках которых люди используют смешанный набор навыков. (Эту тему я регулярно обсуждаю с Гималом Мандалией, что привело к признанию «glue work», когда люди выполняют несколько функций, чтобы помочь командам). В посте Эмили приводится очень простое определение Delivery Manager-а: это тот, кто обеспечивает «последовательный, плавный темп поставки».
Это менее конкретное определение полезно, поскольку оно не ограничивает человека каким-то одним подходом или стилем, а в гораздо большей степени ориентировано на результаты. То, как мы помогаем командам создавать ценности, — вопрос открытый. Однако, по моему опыту, для бесперебойной и последовательной работы требуется команда, которая чувствует себя в психологической безопасности, получает поддержку и имеет все необходимое для успешной работы. Если Delivery Manager не в состоянии создать такие условия, то они не смогут достичь желаемого результата. Кроме того, этот результат редко совпадает с теми результатами, которые старшие менеджеры ожидают от DM. Сколько времени тратится на просмотр планов, отчёты, журналы и статусы, вместо того чтобы понять, какими возможностями DM обладает для реальной поддержки команды.
Для того чтобы подготовить Delivery Manager-ов к обеспечению последовательного и плавного темпа выполнения работ, многие DM изучают и применяют специальные фреймворки и методологии. Скрам особенно распространён в госсекторе (и, что примечательно, не особенно распространён в известных технологических компаниях). DM часто пытаются взять на себя ответственность скрам-мастера. В Scrum Guide сказано, что скрам-мастер выполняет функции коуча, фасилитатора, тренера и специалиста — в командах и организации. Я помню, как Дэн Браун сказал мне, что нет причин, по которым Delivery Manager не может полностью взять на себя ответственность скрам-мастера. Лично мне такая позиция показалась невероятно полезной. Мой успех в качестве DM был достигнут в первую очередь благодаря работе в качестве скрам-мастера, особенно в качестве коуча. Но действительно ли это совместимо с тем, что старшие люди требуют от DM в большинстве сред? Если нет, то почему мы поощряем людей брать на себя ответственность, которую они не в состоянии нести?
Похоже, что Delivery Manager-ы обременены ролью, которую многие плохо понимают и на которую возлагают неправильные надежды. Один комментарий Джо Кроссика привлек моё внимание: «В роли Delivery Manager-а я обычно выступаю в незрелых agile-средах. Я выполняю обязанности скрам-мастера плюс осуществляю линейное руководство, провожу agile-коучинг для других менеджеров, делаю более широкий анализ процессов, поддержку продукта, провожу много фасилитации и защищаю команду от негативных факторов. Это настоящая роль полиглота agile+tech+product. Моя цель — всегда делать себя лишним». Мы так много ожидаем от DM и так мало предлагаем поддержки, что никто не может по-настоящему понять, что такое хорошо. В конечном итоге это приводит к тому, что по-настоящему эффективная команда должна быть в состоянии поддерживать себя без Delivery Manager-а.
Что приводит к финальнмоу вопросу: нужны ли нам вообще Delivery Manager-ы? Если они создают условия для возникновения так многих антипаттернов, для укрепления старых методов работы и для того, чтобы коучинг проводился скрытно как случайное дополнение к результатам, которые должны быть доставлены — не стоило бы нам начать с чего-то нового? С чего-то, что не обременено ожиданиями и наследием. Роль, где одному человеку не говорят, что он обязан поставлять весь продукт или услугу? Перемены не придут легко, но, на мой взгляд, нам лучше быть открытыми в отношении наших потребностей. Если организации, включая государственные учреждения, нуждаются в менеджерах проектов, то нанимайте менеджеров проектов, а если им нужны agile-коучи, то приглашайте agile-коучей!
Что не так с управлением поставками? Оно не поставляет.
Разбираться с управлением поставками продолжим на открытых уроках:
11 марта: поговорим о жизненном цикле задач и релизов; планировании и контроле поставок, а также об этапах CI/CD. Записаться
18 марта: постараемся понять, какие есть особенности и «подводные камни» позиции DM, кому подходит эта роль, а кому — категорически нет. Записаться
