В мае в компании Godel Technologies с головным офисом в Манчестере и центрами разработки в Беларуси произошла маленькая революция. Несколько десятков проектных менеджеров узнали, что отныне их должность называется Agile Delivery Coordinator. Инициатором изменений была Елена Огнева, Head of Agile Delivery Division (отдел тоже был переименован).
dev.by поговорил с главным ADC компании о причинах изменений и бизнесе в стиле agile.
«Почему Project Manager? Разве мы работаем не по Agile?»
По образованию я переводчик. В ИТ попала случайно, как раз благодаря знанию иностранных языков: стартап с клиентом из Германии искал человека с идеальным немецким. Сначала занималась составлением юзергайда приложения. В процессе работы вникала в детали рабочих процессов. Выяснилось, что я неплохо разбираюсь в требованиях заказчика к приложению и могу донести их до разработчиков на понятном им языке. Менеджер сказал мне: «У тебя так классно получается, попробуй себя в бизнес-анализе!». Так я попала в другую компанию, где три года проработала бизнес-аналитиком. Когда проект подошел к своему логическому завершению, большая часть моей прежней команды уже работала в Godel. И я решила пройти собеседование. Это было 8,5 лет назад.
На какую позицию вас брали в Godel?
Это интересная история, потому что тогда в Godel не было отдела бизнес-анализа. Позиция называлась PM/BA и подразумевала совмещение функций менеджера проектов и бизнес-аналитика. На собеседовании сказали: «С аналитикой у тебя всё здорово, а менеджменту научим». Дали пару небольших проектов. Было сложно, но у меня была маленькая команда и к тому же я работала с уже знакомой мне технологией. Это сильно помогло на начальном этапе. Через пять лет я стала заниматься чистым менеджментом проектов, а два года назад выросла в Head of Project Management Division.
Почему в компании решили переименовать позицию проектного менеджера и когда это произошло?
Это произошло в мае текущего года. Я и сама интуитивно ощущала, что не занимаюсь менеджментом проектов в чистом виде. Мне как командному игроку всегда было важно создать благоприятные условия для самостоятельной работы команды, а не выступать в роли начальника.
В последнее время очень популярна тема agile и гибких методологий. Но в agile роли Project Manager по сути и нет. И вот все наши клиенты говорят об agile, хотят гибких подходов и продуктовый майндсет, а у нас Project Manager… Естественно, они спрашивали: «Почему Project Manager? Разве мы работаем не по agile?».
Приходилось объяснять, что так уж исторически сложилось на белорусском рынке. Что на самом деле мы знаем, как работать в духе agile, знаем, что такое гибкость, командная работа и фасилитация, умеем применять scrum и оперативно реагировать на изменения. Вопросы клиентов и сложности sales-команды в головном офисе Godel в Манчестере привели меня к мысли, что мы не совсем корректно называем данную роль.
Последней каплей стал апрельский визит нового крупного клиента. Представители компании приехали к нам знакомиться. Среди белорусских разработчиков выбирали между Godel и Epam. На этой встрече мне нужно было описать стиль нашей работы. И когда я опять начала рассказывать всю эту историю про проектных менеджеров, заметила удивление на лице клиента. Он спросил: «Мы можем называть эту роль по-другому?». До этого у нас уже были примеры сотрудничества с компаниями, где менеджерские роли назывались иначе. И мы сказали: «Да, конечно. Мы же agile».
Как же так: были менеджерами, а стали всего лишь координаторами!
Я пришла к руководству и рассказала об идее изменить название позиции и отдела. Меня поддержали. Начали думать о вариантах, набрейнстормили большой список. Искали существующие на мировом рынке примеры. В конце концов, выбирали между Agile Delivery Coordinator и Agile Delivery Manager.
У нас в отделе работает больше 50 человек. Несмотря на то, что изменения коснулись только самого тайтла (список обязанностей остался прежним), некоторые почувствовали себя задетыми. Как же так: были менеджерами, а стали всего лишь координаторами!
Но всё-таки я остановилась именно на тайтле Agile Delivery Coordinator, потому что то, чем мы занимаемся, это всё-таки координация деливери. Наши клиенты — крупные компании с собственными ИТ-департаментами, которые знают, что они разрабатывают и куда хотят двигаться. Мы не управляем процессами — мы приходим к клиенту, понимаем его бизнес и задачи, настраиваем взаимодействие и коммуникацию и создаём фреймворк, который позволит вместе работать над развитием продукта и над эффективностью процессов в соответствии с потребностями команды, клиента и продукта.
Сложно было убедить сотрудников в полезности таких перемен?
Я написала большое письмо и разослала сотрудникам компании, включая Манчестерский офис. Объяснила, что пугаться не стоит — будем работать, как и раньше. Разве что теперь ответственности станет ещё больше, потому что мы громко заявляем, что знаем и практикуем agile, и прикрываться тем, что «я же Project Manager, а все эти ваши „гибкие“, командные истории со scrum не про меня» не получится.
То есть функции у бывших проектных менеджеров всё-таки изменились?
Скорее окончательно оформились. И изменения в компании — это изменение тайтла в первую очередь. Agile Delivery Coordinator — это шире, чем scrum-master, который занимается фасилитацией в команде и устранением «блокеров». Это человек, который недирективными методами строит эффективную работу в ней. Я объяснила команде, что то, как мы реагируем на потребности рынка, это очень круто. Плюс сильно облегчит жизнь нашим сейлам и позволит говорить с клиентом на одном языке практически со старта. В ответ из головного офиса в Манчестере пришло множество восторженных комментариев.
Многие, кто переименовал свою должность на LinkedIn, получили поздравления от сообщества. Люди восприняли это как повышение: раньше был олдскул в лице менеджера проектов, а теперь Agile Delivery Coordinator. Вау! Клиенты тоже восприняли изменение как шаг вперед. Они всё же гораздо более agile, чем мы. А один заказчик даже переименовал эти позиции в своей компании.
Чем в таком случае работа Agile Delivery координатора отличается от работы «классического» менеджера проектов в ИТ-компании?
Классический менеджер проектов — это таймлайн, ресурсы, скоуп, бюджет. Директивная манера управления. ADC же больше фокусируется на людях: фасилитации и коммуникации, развитии потенциала команды и построении командных процессов.
Мы создаём такие условия работы, чтобы каждый участник команды понимал суть и цель поставленных перед ним задач. Более того, команда сама решает, что и как ей делать. Командой в широком смысле можно назвать как коллектив Godel, так и людей на стороне заказчика. Речь идёт о том, чтобы создать наиболее комфортные условия для работы обеих команд, создать атмосферу доверия, чтобы команды не боялись критиковать друг друга и предлагать наиболее выгодные решения.
Опять же, это не работа scrum-мастера в чистом виде, потому что невозможно направлять и фасилитировать команду, если ты не понимаешь процесс разработки и не видишь общую картинку, куда и зачем движется разрабатываемый продукт. Координатор должен найти разумный баланс между клиентом, командой и менеджментом. Понять интересы каждого и привести всех к общему успеху.
«Координатору не нужно контролировать написание кода»
Насколько координатор должен быть подкован в техническом плане?
Мне нравятся примеры, когда на позицию Agile Delivery координатора приходит человек с опытом в другой области. Не обязательно специалист с техническим образованием, кстати. Он прибавляет к своим профессиональным навыкам другие: не боится общаться с командой и клиентами, где-то берёт на себя ответственность за ключевые решения, может вывести команду из затруднительной ситуации.
С другой стороны, у нас есть примеры координаторов, которые ранее не работали ни аналитиками, ни QA, ни разработчиками. Это просто люди с хорошими коммуникационными и фасилитационными навыками и желанием учиться новому.
Вполне достаточно, когда координатор на приемлемом уровне понимает жизненный цикл всех этапов разработки программного продукта. Копать глубже только плюс. Но нужно найти здоровый баланс между погружением в детали и предоставлением свободы команде.
Могу судить по себе: за восемь с половиной лет в Godel начинаешь понимать все процессы. Всё, что требуется — иметь пытливый ум и не бояться обращаться за советом к команде.
В Godel мы периодически приглашаем людей из других департаментов рассказывать ADC доступным языком о важных нюансах процесса разработки и отвечать на их актуальные вопросы. Например, как работает business intelligence, или как настроить DevOps на проекте, или как встраивать автоматизацию в текущий процесс.
Насколько глубоко вы как ведущий Agile Delivery координатор компании понимаете технические вещи? Например, вы владеете языками программирования?
Нет. Я доверяю команде разработчиков. Координатору не нужно контролировать написание кода. Ошибки и качество кода могут отслеживаться в ходе код-ревью (когда члены команды проверяют код друг друга), а также при помощи других технических практик.
Полезно, когда прежде чем отдать что-то в код-ревью и потом в тестирование, разработчик показывает написанное бизнес-аналитику — так можно быстро убедиться, что оно соответствует функциональным требованиям продукта и сэкономить время ревьювера и QA. Опять же, в конце цикла разработки есть демо продакт-оунеру.
Ещё один прекрасный инструмент синхронизации команды друг с другом — daily scrums.
Это всё — составные части той работы, которая позволяет убедиться, что команда движется в правильном направлении. Это не контроль, а командная работа, где координатор выступает в роли дирижёра. Во всех командах, где я работала, мне удавалось применять именно такой подход.
Сколько человек в компании сейчас работает на позиции Agile Delivery координатора?
В отделе Agile Delivery 60 человек. Кроме того, в компании есть сотрудники других отделов, которые также совмещают функции Agile Delivery Coordinator со своей основной специализацией. Это, как правило, бизнес-аналитики и QA, есть даже один человек из отдела JavaScript. Обычно ребята из смежных департаментов переходят в отдел Agile Delivery, если им нравится это направление. Итого около 70 человек.
«ИТ-сообщество уже готово к тому, что компании могут экспериментировать с тайтлами или функционалом позиций»
Не возникнет ли проблема с наймом людей в Беларуси, ведь придётся всем объяснять, кто такой Agile Delivery Coordinator?
Когда ещё не было официального анонса о переименовании тайтла, я уже начала «обкатывать» новинку на собеседованиях. Стала рассказывать кандидатам, что в наших условиях мы под проектным менеджером подразумеваем Agile Delivery Coordinator. Реакция была очень доброжелательной. Не встретила ни одного кандидата (а я стараюсь большую часть собеседований проводить сама), который засомневался бы в своём выборе. Думаю, наше ИТ-сообщество уже готово к тому, что компании могут экспериментировать с тайтлами или функционалом позиций. Agile — это всё же про гибкость. Если человек приходит на собеседование в Godel и его смущает смена названия позиций, значит, он не готов подстраиваться и под изменения рынка, среды или проекта.
А какие вообще требования предъявляете к кандидату на эту должность?
Самое важное — это фокус на людях, а не на собственных амбициях. Команда должна стоять на первом месте. Каким бы классным ни был проектный менеджер, он не напишет код и не сделает работающее приложение без людей. Он должен обладать очень хорошими коммуникационными и фасилитационными скилами — уметь доносить до команды свои идеи. Не всегда ребята, сильные в техническом плане, хороши в коммуникации. Иногда очень умелые разработчики воспринимаются клиентами при встрече хуже, чем ребята послабее, исключительно из-за разницы в умении вести переговоры. Ещё очень важно иметь продуктовый mindset — для нас важен работающий продукт и понимание того, зачем мы его создаём.
Это всё больше soft skills. Наверняка, есть и более конкретные навыки, которые вы требуете от кандидата?
Soft skills в данном случае необходимы. Также важно понимать, как устроен процесс разработки программного продукта, и в этом очень помогает опыт в смежных областях — бизнес-анализе, QA, девелопменте. Помимо этого, кандидату нужно не просто знать о гибких методологиях, но и искренне разделять ключевые ценности agile.
Я скептически отношусь к сертификатам — мы все учились в университетах и знаем цену документальным свидетельствам знаний. Не думаю, что наличие сертификата о пройденном тренинге доказывает владение гибкими методологиями. Важно иметь ещё практический опыт и критическое системное мышление.
Согласно исследованию dev.by, особенностью белорусского ИТ-рынка является небольшая разница между зарплатами менеджеров и разработчиков. Эта тенденция сохраняется в Godel?
Честно, не знаю. В нашей компании не принято обсуждать зарплаты сотрудников. Могу только предполагать. Каждая роль в команде имеет одинаковый вес. Думаю, что зарплаты в команде на каждой позиции примерно сопоставимы, будь то координатор, бизнес-аналитик, QA или разработчик.
Кто клиенты Godel, с которыми работают Agile Delivery координаторы?
Как правило, крупный бизнес. Много работаем с финансовыми и страховыми компаниями. Есть клиенты из ритейл-сферы, трэвела, машиностроения, коммунального хозяйства. Это всегда решения для бизнеса: написание нового продукта с нуля или доработка и расширение старого — как с точки зрения функциональных, так и нефункциональных требований, например распил монолитного приложения на микросервисы.
Agile-консалтинг?
В чистом виде такой услуги у нас нет. Но можно сказать, что Agile-консалтинг — это часть нашей работы. Как я уже говорила, мы работаем с компаниями той или иной agile-зрелости. Один наш клиент, крупная английская компания, наняла agile-коуча и перестроила офис правильным образом. Коуч сам собеседовал ключевых участников команды на проект, хотел видеть горящие глаза и passion for scrum. В таких ситуациях мы должны соответствовать ожиданиям клиента.
Есть и компании поменьше, которые только хотят стать на путь agile и внедрить, например, scrum. Они не считают, что им нужен специальный коуч, поэтому, работая с ними, мы сами занимаемся выстраиванием гибких процессов и обучением команды.
«Крайне важно, чтобы во главе команды стоял живой позитивный человек»
Тема agile до сих пор окружена массой споров и спекуляций. Частые комментарии на специализированных сайтах вроде «Хабра» под статьями об agile: «agile всё больше и больше и больше походит на извращение», «agile начал обрастать новыми ролями, «это начало конца agile» и прочее. Насколько сегодня подход себя оправдывает?
Всё зависит от направления бизнеса. Если мы говорим о бизнесе, где среда не предполагает быстрого реагирования на пользователей, на потребности продукта и рынка, то традиционные подходы могут работать вполне эффективно. Например, в банковской сфере, в которой всё жёстко регламентировано и расписано на год вперёд, agile-подход вряд ли оправдан. Там нужна строгая отчётность и структурированные процессы.
Agile больше подходит ИТ-сфере с изменчивым рынком и высокой конкуренцией, где нужно быстро показывать результаты и плотно взаимодействовать с пользователями, чтобы понимать реакцию на продукт. У нас бывают ситуации, когда разработать новую фичу для клиента надо за неделю. Да, за такой срок она не будет написана идеально, но это позволит клиенту потратить минимум времени и средств, чтобы проверить отклик рынка, а затем уже вкладываться в более серьёзную разработку и архитектуру.
Мне agile нравится тем, что в этой методологии каждый участник команды несёт ответственность за результат. Мы строим команду, которая понимает цели разработки продукта и может повлиять если не на выбор технологии, то на выбор того или иного инструмента в рамках этой технологии. Agile позволяет вовлекать каждого члена команды во все этапы создания продукта.
В Godel начинали активно развивать agile-подходы с 2013 года. Достаточно поздно по сравнению с другими компаниями. Признаться, до этого момента мы довольно скептически относились к теме agile. Нам казалось, что модный подход — это всего лишь способ замаскировать неспособность завершать проекты в срок и показывать достойный результат. Тогда мы пригласили тренера из scrum.org — с горящими глазами он рассказал нам про scrum и его инструменты с элементами геймификации.
Крайне важно, чтобы во главе команды стоял живой позитивный человек, умеющий заряжать настроением окружающих. Команда часто склонна к пессимизму, когда появляются сложности в работе над проектом. Тренер нас воодушевил, и появилось желание перестроить работу в компании по принципам гибких методологий.
В это же время мы стали сотрудничать с клиентом, который работал в стиле true agile, — он тратил минимальное количество времени на разработку и не занимался глубоким стратегическим планированием каждой фичи. Мы увидели на конкретном примере, что подход работает, научились применять технические практики, без которых agile невозможен: серьёзная автоматизация, парное программирование, код-ревью, CI/CD — практики, позволяющие сделать процесс разработки постоянным и максимально предсказуемым. Не так давно мы снова обратились в scrum.org уже за курсом «Professional Scrum Developer». Зарядились новой порцией энтузиазма. Регулярно проводим внутренние тренинги на базе накопленного опыта в сфере agile.
Какой карьерный рост возможен для Agile Delivery Coordinator в ИТ-компании?
В agile уже ушли от привычных градаций: senior, lead и прочее. Но в Godel мы пока их сохраняем. Поэтому сотрудник может вырасти, скажем, с mid-позиции до senior. Также успешному координатору могут доверить более крупную команду. Возможен рост вне проектных активностей. Недавно мы стали развивать consultancy-направление: это когда группа специалистов из разных подразделений может подключиться на любой из проектов по запросу — если нужна помощь в каком-то аспекте разработки.
Рост возможен и в talent management. К каждому человеку в Godel прикреплён Talent Manager — человек, который помогает специалисту развиваться, отвечает на вопросы, предоставляет фидбэк. Приветствуем активное участие в образовательных ивентах — как в качестве регулярных тренеров, так и хэдлайнеров на внутренних Open Space конференциях. Дорасти до топ-менеджерских позиций, думаю, тоже возможно — компания динамично развивается, появляются новые роли, которые сможет занять и Agile Delivery Coordinator.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.