Когда проектным или продуктовым организациям имеет смысл выделять delivery в отдельную организационную единицу? Как управлять такой структурой, какие цели перед ней имеет смысл ставить? Как сделать так, чтобы она приносила пользу, а не усложняла всем работу? Об этого говорим с Ильёй Тегмарком, ex-BCG, ex-Accenture, Head of Delivery в “Math, Code & Growth”.
Delivery менеджмент
Как компании приходят к необходимости выделить delivery в отдельное направление проектного менеджмента? Это следование тренду или реальные ограничения предыдущей организационной модели?
Компании дорастают до того, что различия в управлении разработкой и управлении внедрением становятся чувствительными. Если разработка решения может занимать от нескольких месяцев до нескольких кварталов, то внедрение может занимать от нескольких кварталов до более чем 1 года. Разработка ИТ или цифрового решения практически целиком ведётся силами разработчиков подрядчика, в то время как внедрение – это процесс в который непрерывно вовлечены несколько подразделений как со стороны заказчика, так и со стороны подрядчика. Соответственно внедрение – это такой масштабный по времени и усилиям блок работ, что разработка порой меркнет по сравнению с ним.
Проектный менеджер, конечно, может вести весь проект от разработки до внедрения, но как правило, это разные по характеру люди и хотят они разного. Типичный проектный менеджер больше фокусируется на новых начинаниях, в то время как типичный менеджер по внедрению – это человек, который любит доводить до конца, которого не пугают опытно-промышленные испытания, ввод в эксплуатацию, обслуживание и сотни мелких доработок, которые возникают после разработки – такая рутинная, но при этом не менее стрессовая работа, чем проектный менеджмент.
Помимо этого, проектные менеджеры и менджеры по внедрению по-разному относятся к командировкам, удалённой работе и взаимодействию с заказчиком. Поскольку характер этих работ настолько сильно отличаются, то логично разделить их менеджеров на отдельные группы, между которыми передаётся проект.
С delivery менеджерами понятно, но есть ли смысл выделять их из проектной организации в собственную структуру?
Выделять их в отдельную структуру или нет компании решают сами. Обычно какое-то подобие delivery организации начинает формироваться, если существуют структурные различия структурные различия между процессами разработки и внедрения: например, не все проекты из стадии разработки переходят на стадию внедрения, или если проект разрабатывается однажды, а внедряется с доработками разным клиентам. Эти различия, впрочем, имеются далеко не в каждой проектной организации.
Delivery Director – это просто модное название или реально новая роль?
Ну если вопрос в том, как перевести delivery на русский язык чтобы не пользоваться англицизмом, то есть простое русское слово внедрение. Это в меньшей степени дань моде, скорее желание дать оформленное краткое наименование роли, которая всегда существовала – директору портфеля проектов с акцентом на внедрение.
Структура и роль delivery центра
Расскажите о delivery центре, сколько человек, какая структура, как распределяются роли, насколько эффективна его структура?
У центра внедрения проектов или delivery-центра, как правило, достаточно плоская структура: основной состав – это менеджеры по внедрению с грейдом аналогичным проектным менеджерам, а также инженеры, которые задействуются при опытно-промышленных испытаниях и при эксплуатации, когда требуется быть на связи с клиентом. В отличие от этапа разработки, этап внедрения может потребовать круглосуточного наблюдения.
В delivery-центр может наниматься дополнительный состав, например аналитики, сотрудники техподдержки, необходимость в этом становится понятной в ходе развития проектной практики. Разработчики, как правило, остаются в организации техдиректора (CTO) и привлекаются только на последнем уровне поддержки, а также в случае необходимых доработок. Надо понимать, что на этапе внедрения одного проекта, разработчики уже заняты на других проектах, и их отвлечение должно закладываться в ресурсный план и не превышать заданных квот.
Расскажите о взаимодействии между Delivery центром и смежными подразделениями, с проектным офисом, с CTO, с CPO. Возникают ли конфликты на почве распределения зон ответственности?
Надо понимать, что delivery-центр – это те люди, благодаря которым усилия десятков человек в конечном итоге обретут финансовый результат. Соответственно, если delivery-центр вынужден бороться с другими подразделениями за ресурсы – то это рецепт провала. Вообще, конфликт на почве распределения зон ответственности – это признак того, что в компании ещё многое предстоит поменять и развить. Конфликт в рабочем контексте само по себе явление скорее положительное, если не принимает затяжной характер. Например, если у delivery-центра систематически не хватает ресурсов, которые закреплены за другими подразделениями, то это приведёт к фрустрации клиента.
Если проект прошёл по пайплайну от гипотезы через продажу и разработку к внедрению, при этом на каждом из этих этапов значительная часть проектов отсеивается, то к команде delivery проект поступает с наивысшими шансами на успех и на финансовый результат, поэтому не помогать delivery команде могут только те люди, которым не важен результат.
Какие методологии и инструменты используютя в работе Delivery центра?
В общем случае, группа внедрения может работать не по тем методологиям, по которым работает группа разработки. Например, разработка может работать по agile со спринтами и канбаном, а внедрение по waterfall с Gantt-чартами. Но будет неплохо, если в системе управления проектами в организации они интегрированы, поскольку передача проекта из разработки во внедрение – это не всегда простая веха, а часто итеративный процесс, когда мяч переходит от разработки во внедрение и обратно. Говоря упрощённо, если разработка управляется, например в Яндекс Трекере, а знания хранятся в Яндекс Вики, то возможно имеет смысл и внедрение вести в этих же инструментах.
Подбор персонала
Почему компании ищут Delivery директора не из числа проектных менеджеров компании, а на рынке труда?
Потому что директору по внедрению важно иметь опыт внедрения, для приобретения которого требуется значительно больше времени, чем зачастую есть у проектных менеджеров, по той причине, что внедрение одного проекта это значительно более длительная история, чем просто его разработка. Поэтому, директор по внедрению, вероятнее всего, воспитывался за пределами одной компании.
По каким критериям имеет смысл подбирать delivery менеджеров? Есть ли риск набрать людей, которые просто хорошо говорят, но не умеют реально деливерить?
Деливерить – это особый набор суперспособностей, это люди, у которых исполнительность, внимание к деталям и способность гасить конфликтные ситуации на первом месте. Есть тесты, которые непросто обмануть, например BASE Ассессмент. Риск взять не того человека всегда есть, равно как и риск для человека попасть не в такую компанию, о которой ему/ей рассказывали на собеседованиях.
Как обеспечить профессиональное развитие Delivery менеджеров? Какие программы обучения и повышения квалификации существуют?
Внедрение проектов по цифровизации и ИТ – это прекрасный социальный лифт и отличное резюме. Люди получают опыт, сравнимый с топовыми компаниями, такими как IBM и Accenture. Не думаю, что кого-то должно пугать, что в перспективе отличные сотрудники занимают крутые позиции у клиентов. Что касается обучения, сейчас в этом нет недостатка и delivery менеджеры могут развиваться как в предметной области ИТ и цифровизации, так и в индустриях клиентов, и конечно же в мягких навыках.
Результаты и эффективность
Какие KPI стоят перед delivery директором, насколько они реалистичны? По каким результатам судят о том, насколько эта структура действительно полезна?
Основная цель delivery центра – довести проект до финансового результата. Чтобы этого достичь нужно чтобы клиент был счастлив. Чтобы этого достичь, нужно чтобы все трудности с которыми сталкивается разработанный софт на этапе испытаний и эксплуатации были устранены. Чтобы этого достичь требуется либо физически быть там, где софт используется, либо быть на связи 24х7. Успешность директора по внедрению измеряется тем, насколько бесшовно происходит внедрение и насколько счастливы клиенты, а это в свою очередь прямое следствие того, насколько хорошо укомплектован delivery-центр и насколько хорошо отлажены внутренние процессы. Таким образом, delivery директор по стилю управления – это больше внутренний предприниматель или операционный директор, а не директор портфеля проектов или руководитель проектного офиса.
С какими проблемами приходится сталкиваться при осуществлении деятельности центра?
Уровень проблем и задач, которые решает директор по внедрению сильно зависит от стадии зрелости, на которой находится delivery-центр. Вначале это неналаженные процессы, недоукомплектованность, взаимодействие со смежными подразделениями, затем – повышение эффективности и качества работ, трудности роста – масштабирование.
Перспективы и стратегия
Какие перспективы у это новой роли? Не считаете, что она не пройдёт тест временем и просто схлопнется, перестанет существовать?
Она уже не схлопнулась: должности delivery-менеджеров и директоров существуют в глобальных компаниях уже более 10 лет. Многие проектные компании рано или поздно приходят к разделению между проектным управлением и управлением внедрением, просто потому что различия между ними становятся критическими. Но как и любая деятельность – эта может трансформироваться во что-то, что мы пока ещё не очень хорошо представляем. За последние 10-15 лет появились продуктовые менеджеры, agile методологии – я думаю, что возникнут и изменения, специфичные конкретно для проектного delivery.
Что бы вы порекомендовали организации, которой только предстоит выделить delivery функционал в отдельную структуру? Какие подводные камни?
Я бы рекомендовал двигаться в этом направлении теми же шагами, которые делают стартапы, когда внедряют какие бы то ни было изменения: начать с формулирования гипотез, протестировать отделение функции внедрения от функции управления проектами, сделать MVP центра внедрения, и на любом этапе быть готовыми сделать шаг назад и исправить недочёты.