Деливери-менеджер (англ. Delivery Manager) – это ключевая роль в современной ИТ-среде, которая имеет большое значение для обеспечения бесперебойной работы процесса разработки ПО и доставки ценности для клиента. Деливери-менеджер постоянно общается с каждым членом большой команды на всех этапах реализации проекта.

В его функции входит:

• Создание процессов и процедур для организации успешного процесса доставки ценности.

• Координирование (или сопровождение) команды и помощь на разных этапах реализации проекта.

• Работа с дорожной картой совместно с владельцем продукта и руководителем проекта.

• Обеспечение оптимального процесса планирования и расходования ресурсов.

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

• Обеспечение непрерывного совершенствования команды и фасилитация[1] встреч.

Чтобы познакомить читателей с этой ролью поближе, руководитель отдела тестирования Центра продуктов управления доступом inRights Алена Зубкова беседует с деливери-менеджером Центра Ксенией Гырнец.

– Привет Ксюша, расскажи, пожалуйста, простыми словами, кто такой деливери-менеджер (ДМ)?

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

– А представь, что тебе досталась не столь самоорганизованная команда. Каких навыков от тебя потребовала бы организация таких ребят?

– Безусловно, тут очень важную роль играют софт-скиллы в первую очередь. Нужно уметь обеспечить коммуникации, уметь разрешать конфликты. И еще нужно уметь выстраивать процессы – быть довольно структурным человеком и уметь научить этому команду.

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

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

– А какова специфика проектов IdM со стороны ДМ?

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

– А за то время, которое ты выступаешь в качестве ДМ в команде IdM, удалось ли уже добиться каких-то внушительных результатов? Можно ли вообще каким-то образом оценивать эффективность работы ДМ?

– Когда я только пришла в команду, был некоторый пул задач: необходимо было выстроить процессы так, чтобы в условиях увеличивающегося количества проектов мы текущей командой смогли с ними справляться в сроки и с требуемым качеством. Было, на первый взгляд, очень простое решение, которое можно было бы применить, – так поступают некоторые команды: просто распределить людей по проектам, закрепить их за ними. Но мы таким путем не пошли, т. к. были масштабные задачи и некоторые ограничения. Почему мы так не сделали? В частности, хотелось «онбордить»[2] новых сотрудников, хотелось, чтобы сотрудники обменивались знаниями. Если бы они погружались только в один свой проект и в нем «варились», то, во-первых, это бы привело, скорее всего, к выгоранию, а во-вторых, у нас были узкоспециализированные специалисты по своим проектам. Это не очень хорошо для того, чтобы решать масштабные задачи. Первым делом мы пообщались со всеми представителями всех направлений: с линейными руководителями, с лидами, со специалистами. Выяснилось, что ключ к решению всех проблем – это повышение прозрачности. Были сложности с тем, что проекты длительные и сложные, как я уже говорила. И то, что делают разные команды на разных этапах, было непрозрачно. Возникали проблемы, потому что задачи решались долго и доходили до разных коллег в каком-то искаженном виде. Хотелось от этого избавиться.

Еще хотелось дополнить про онбординг, т. к. знаю, что эта тема – как погружать новых специалистов – болит у многих команд. Мы придумали несколько фишечек для себя. Первое – когда к нам приходит новый сотрудник, мы его отправляем проходить базовый регресс[3] по продукту. Вне зависимости от роли, проходя весь этот сквозной набор тестов, сотрудник погружается и на выходе уже отлично понимает специфику продукта и что от него ждать. Как побочные эффекты, мы получаем какие-то дефекты, которые, возможно, не выловили раньше по каким-либо причинам. Второе – мы закрепляем новых разработчиков за более опытными, и это помогает новичку быстрее влиться в проект. А уже опытный разработчик, благодаря тому, что ему приходится объяснять какие-то вещи, которые он уже знает, погружается в них еще глубже и узнает их еще лучше. То есть это и есть институт наставничества.

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

– А могут ли разные члены команды сформировать какой-то конкретный вопрос для этой архитектурной сессии? Допустим, интересна какая-то определенная часть архитектуры или конкретная функциональность и хочется получить не просто короткую консультацию, а всеобъемлющую лекцию?

– Да, такая возможность, безусловно, есть. Более того, помимо этого, можно еще попросить донести информацию на определенном уровне. Например, аналитику и инженеру нужен разный уровень погружения, разный уровень объяснения. Поэтому каждый может прийти и сказать, что нужно, и мы с удовольствием ответим на все вопросы. Я увидела, как наш архитектор расцветает, когда эти лекции проводит. Мне самой они очень интересны.

– Да, потому что делиться знаниями – это не только полезно, но и важно, так как поднимает мотивацию людям.

– А какие инструменты использует ДМ в своей работе?

– Важно, чтобы инструменты помогали команде удобно и оперативно обмениваться информацией. В нашем случае команда распределенная, причем распределенная настолько, что у нас даже несколько разных часовых поясов. Поэтому из инструментов в первую очередь – это мессенджеры-звонилки. Также считаю инструментами все наши скрам-события: такие, например, как PBR[4] для обсуждения задач. Ретроспективы[5] – это, пожалуй, один из самых мощнейших инструментов, рекомендую его использовать всем командам, неважно, это разработчики или внедренцы. На ретроспективе можно всей команде обменяться в целом тем, что получилось, что не получилось, что стоит улучшить. Это такое событие, где атмосфера максимально безопасная, и одна из задач ДМ – как раз донести до команды, что тут действительно безопасно: можно сказать то, что у тебя болит, то, что ты чувствуешь, а иногда полезно просто всей командой посидеть чай попить с пирожками и обсудить, каким тяжелым был спринт и что следующий должен быть лучше. Также к инструментам можно отнести регулярные спринт-ревью, где все заинтересованные могут ознакомиться с тем, что сделала команда за определенный отрезок времени, например за спринт или за релиз.

– Ты упомянула про PBR’ы. Можешь раскрыть буквально в паре предложений, чем так ценны эти встречи и в чем их сутевая составляющая?

– Это такие встречи, куда наши аналитики приносят нам задачу. И неважно, продуктовая эта задача или проектная. Некоторые задачи, кстати, в процессе как раз этой встречи (PBR) становятся из проектных продуктовыми, если мы с командой понимаем, что да, нам это интересно и мы хотим внести это в продукт, чтобы это было доступно всем заказчикам. В чем ценность PBR’а – это в том, что туда не приходят конкретные исполнители, туда приходит бОльшая часть команды, т. е. все заинтересованные лица. Это открытая встреча. Там есть обязательные участники: аналитик, который принес задачу, тимлиды, архитектор может туда прийти, ну и непосредственно разработчик и его напарник (новый коллега, о котором я говорила, которого с первого дня прикрепили к наставнику). Также на эту встречу может прийти любой коллега, который считает, что он может внести какой-то вклад в эту встречу или дать полезную информацию. Вот всей этой большой компанией мы подробно обсуждаем задачу. Таким образом, мы имеем возможность не терять нить, создавать то самое ценное, что будет наиболее полезно заказчику, что будет наиболее полезно в нашем продукте, возможно, кто-то принесет какое-то технологическое новшество, что тоже часто бывает.

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

– Да, безусловно. Нам не нужно будет каждому по цепочке что-то объяснять. Мы избегаем эффекта испорченного телефона, когда на каждом последующем этапе передачи информации она трансформируется. У нас все заинтересованные лица сразу слышат, что нужно и как реализовать. Например, тестировщик, которому задача попадает практически в финале ее жизненного цикла, понимает, что нужно было в начале. Или, когда, например, разработчик слишком увлекается творчеством, мы можем помимо качества еще обеспечить контроль реализации, контроль соответствия постановке задачи, что мы реализовали именно то, что было нужно.

– А если вернуться к классическим инструментам, что из этого ты используешь в своей работе?

– Здесь все просто и довольно стандартно. Как трекер мы используем Jira[6], как базу знаний – Confluence[7], для ретроспектив мы используем Miro[8]. И хочется поделиться таким фан-фактом про ДМ нашей команды, то есть про меня: когда у меня выдается тяжелый день, когда очень тяжело переключиться на какую-то сложную задачу, я открываю Miro и делаю шаблончик для следующего ретро. Люблю всякие прикольные штуки, например с супергероями, с какими-то мультяшками, с чем-то еще. Это помогает команде на самой ретроспективе настроиться на безопасную среду, про которую я ранее говорила.

– Получается, что ты отдыхаешь и переключаешься с работы тоже на работу?

– Получается, что так. Совмещаю приятное с полезным.

– Ксюша, а каким опытом и навыками, на твой взгляд, должен обладать ДМ?

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

– Должен ли ДМ находиться в контакте с заказчиком, с клиентом? Если да, то зачем ему это может понадобиться?

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

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

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

– А если вдруг не удалось найти подход к каждому участнику команды и, например, призошел конфликт. Бывает такое?

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

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

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

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

– Да, это как будто такая легализация, то есть место, где так можно сделать. Если в обычной жизни не каждый человек способен сказать, что ему что-то не нравится, что ему где-то некомфортно, что какие-то задачи для него слишком сложные или слишком простые. Вот ретроспектива и есть то место, где разрешается так сделать. И команда учится это говорить чаще.

– Ксюша, скажи, удается ли тебе соблюдать баланс рабочего и личного?

– Хочется сказать, что я в целом за work balance. При этом я бы даже переформулировала: я за гармонию в жизни в целом. Я имею в виду вот что: когда ты с удовольствием идешь на работу, а потом с удовольствием возвращаешься домой или к своим личным делам. Как я уже говорила, наша команда территориально распределенная и распределенная по часовым поясам, и это была отдельная задача – настроить наши графики так, чтобы мы пересекались, при этом никому из нас не приходилось бы критично жертвовать личной жизнью, работая по 15 часов в сутки. Или приходить на работу в 5 утра, или уходить с работы в 12 ночи. Нам это удалось урегулировать. Мы договорились о некотором расписании. Например, PBR’ы, о которых мы говорили ранее, могут приходить в определенные часы каждый день. Возвращаясь к ответу на твой вопрос, очень важно хорошо отдыхать, с удовольствием работать и в целом соблюдать гармонию между сферами нашей жизни.

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

А как ты отдыхаешь? Может, у тебя есть хобби? И связаны ли твои увлечения каким-то образом с твоей работой?

– Я довольно творческий человек, несомненно, я отдыхаю даже на работе. Я уже говорила про лайфхак с приключением на подготовку к ретроспективе или к другим встречам. Также во внерабочее время я занимаюсь творчеством – декоративно-прикладным искусством. А еще я делаю косметику.

– А теперь несколько блиц-вопросов:

– Что для тебя является драйвером?

– Результаты моей команды.

– Чего тебе не хватает в работе?

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

– Как ты отдыхаешь или переключаешься?

– А мы уже с тобой про это говорили, я делаю шаблончики для ретро.

– Где учат на деливери-менеджера?

– Я думаю, что ДМ – это призвание, а не профессия. Поэтому, пожалуй, нигде не учат. Важно не бояться и пробовать.

– Чем ты гордишься?

– Ведением архитектурных сессий.

– Какими тремя качествами, на твой взгляд, обязательно должен обладать каждый ДМ?

— Это должен быть инициативный человек, ориентированный на результат и умеющий слушать!

[1] Фасилитация (англ. «facilitate» – помогать, направлять) – профессиональная организация работы, общения в группе, между разными людьми или командами, чтобы все пришли к единой цели.

[2] Онбординг (англ. Onboarding) – процесс адаптации новых сотрудников.

[3] Регресс – проверка ранее протестированной программы, позволяющая убедиться, что при внесении каких-либо изменений в ПО не появилось новых дефектов.

[4] PBR (Product Backlog Refinement) – процесс обсуждения, уточнения, добавления деталей и оценок для новых, еще невыполненных задач.

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

[6] Jira – инструмент управления рабочим процессом для команд разработки ПО.

[7] Confluence – база знаний с возможностями совместной работы, вики-система, написанная на Java.

[8] Miro – визуальная платформа (online-доска) для совместной работы распределенной команды.