cover
«Тут опять немножко все полностью нужно переделать»

Главный проджект-менеджер в Kyivstar о самом важном в разработке проектов.

author

Обозреватель в LABA

Многие болезненно реагируют на изменения. Но проектный менеджер устроен по-другому: он обожает разбираться в непонятном и новом.

Его главная задача — сделать так, чтобы проект дал бизнесу новое решение. А главная радость — видеть, как это решение помогает и компании, и клиенту.

У Павла Харикова более 10 лет опыта управления проектами в Kyivstar и «Альфа-Банке».

Он вел проекты с бюджетом $150 млн и вместе с командой увеличил долю успешных проектов в Kyivstar с 30% до 85%. Сейчас в этом телеком-гиганте он возглавляет новое бизнес-направление интернета вещей и «облаков».

Павел рассказал о своих ключевых кейсах, объяснил, почему софт-скиллы важнее хард-скиллов, описал жизненный цикл проекта и главные сложности работы с командой.

Кто такой проджект-менеджер

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

Хард-скиллы тоже нужны, но важно, как PM ими пользуется.

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

Проджект-менеджер не сможет сделать проект сам. Он организовывает команду и обеспечивает условия, в которых она реализовывает проект.

Главный проджект-менеджер в Kyivstar о самом важном в разработке проектов. 0

Когда PM занимается микроменеджментом, на нем и ответственность. Но проконтролировать все нереально.

Важнее иметь хард-скиллы в управлении проектами. Опыт тысяч PM-ов собран в PMBoK и похожих руководствах — и там объясняют, как управлять проектом, чтобы повысить его шансы на успех.

Задача проджект-менеджера — стоять на страже интересов компании. Если PM понимает, что проект будет убыточен, он должен первым сказать: «Пора его остановить».

Период адаптации PM из другой сферы

В 2018 году я перешел из телекома в «Альфа-банк» — директором по управлению проектами и процессами. Системы, базы данных, интерфейсы были по сути теми же, но чтобы разобраться в терминологии и сути финансовых процессов, понадобилось около полутора месяцев.

Даже когда PM из другой сферы, его адаптация не будет длительной и болезненной — если он открыт новой информации. Можно почитать о новой специфике в документах компании, пройти внутренние обучающие курсы.

Каким проектам нужен PM

Есть операционная деятельность — четкий понятный процесс, где действия выполняют по инструкции, чтобы получить гарантированный результат. И есть проекты — они создают изменения, новые продукты и процессы.

Проджект-менеджеры должны помнить, что деньги компании приносит операционная деятельность. Поэтому нужно как можно раньше вывести свое новое решение в «операционку». Только тогда оно начнет приносить пользу.

Проект — это всегда для результата, которого раньше не было.

Например, вы строите типовые 16-этажки. Визуально они одинаковые. Но каждая многоэтажка — проект. Ей нужно новое место, новая команда строителей и подрядчиков, новое подключение к городским коммуникациям. Дом типовой, но конкретно такой — первый.

Проектное управление начало формироваться в середине XX века в космической и военной отраслях.

Раньше, если в операционном процессе нельзя было получить нужный результат, каждый руководитель внедрял изменение у себя и передавал его дальше. Другие к нему что-то прибавляли — и в итоге собирался результат.

Но сложность задач растет. Уже нельзя обойтись без того, кто будет заниматься интеграцией — сбором результатов в одно целое. Любому проекту нужен РМ.

Kyivstar с точки зрения проджект-менеджмента

Пример проектных организаций — современные IT-компании. Там есть четко выделенные команды, которые реализуют проекты заказчика или развивают свои продукты.

Kyivstar — не проектная организация в классическом виде.

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

, иконка 1

Весь бизнес-контент в удобном формате. Интервью, кейсы, лайфхаки корп. мира — в нашем телеграм-канале. Присоединяйтесь!

За управление проектами отвечает проектный офис. Возглавлять его интересно, но всегда чешутся руки сделать большой проект и получить от него результаты.

По сути, мой проект сейчас — создание нового бизнес-подразделения интернета вещей и «облаков». Когда оно эффективно заработает и перейдет в операционку, возможно, буду искать что-то новое.

Кейсы, которыми гордитесь

В 2016 году я возглавил проектный офис в Kyivstar. Без стандартизации процесса проектного управления только треть проектов достигали успеха. Моей задачей было выстроить процесс, чтобы новые решения внедрялись быстрее и эффективнее.

Мы смогли сделать так, что 85% проектов завершались успешно: на ранних стадиях отсекали все бесперспективное и не тратили ресурсы.

Моя главная гордость — 4G в Украине. Этим проектом я занимался 2,5 года. Решалось, как будут перераспределены частоты, как участвовать в тендере на них, где и в каких объемах строить новую сеть.

Kyivstar, на мой взгляд, вышел на этот тендер наиболее подготовленным. Мы проработали и просчитали тысячи сценариев.

Потратили на лицензии крупные бюджеты — но меньше, чем могли бы. И постарались, чтобы для конкурента обошлось не дешевле. Это было важно, потому что возможности для инвестиций не безграничны: чем дороже в итоге обойдется лицензия, тем меньше вложишь в сеть.

Главный проджект-менеджер в Kyivstar о самом важном в разработке проектов. 1

Тендер был очень серьезным. За бумажки формата А4 с надписью «Лицензия» операторы в общей сложности заплатили порядка 9 млрд гривен. Потом еще были значительные инвестиции в сеть.

На старте мы думали: «Будет ли у нас полмиллиона клиентов через год»? Сейчас, через 1,5 года после старта, 4G Kyivstar пользуются более 7 млн человек.

Еще мне дорог другой проект, который был почти провальным — проект оповещений для пользователей домашнего интернета Kyivstar.

Если с мобильными абонентами легче коммуницировать — им можно прислать СМС или позвонить, то к абонентам домашнего интернета достучаться сложно. В кабель ничего не пришлешь. Была задача придумать канал коммуникации.

Мы нашли технологическое решение: показывать клиенту сообщение (например, напомнить пополнить счет или проинформировать о плановых работах), когда тот работал в браузере.

Главный проджект-менеджер в Kyivstar о самом важном в разработке проектов. 2

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

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

Тем не менее, канал взаимодействия с клиентом появился, проработал около пяти лет и окупился. Этот опыт мне был дорог — научил фиксировать все договоренности на бумаге.

Вообще ошибки — это неплохо. Я бы больше доверял тому, кто запорол хотя бы один проект, чем тому, кто еще нет. Скорее всего, этот второй человек будет ошибаться и учиться на вашем проекте.

Жизненный цикл проекта

Чтобы понять, каким будет жизненный цикл проекта, нужно решить, как планируем его реализовывать.

Например, в строительстве не получится сделать проект итерационно — по agile. Там минимально жизнеспособный продукт — дом со всеми коммуникациями, не меньше.

Такая же ситуация с телекоммуникационными сервисами: должно работать все, иначе это никому не нужно.

В этих и похожих сферах нужен другой подход, каскадный. Его этапы:

Инициация. Фиксируем главную цель проекта, а из нее уже берем верхнеуровневые цели (охват, бюджет и сроки).

Планирование. Детально прорабатываем охват проекта, под него планируем бюджет и ресурсы, выстраиваем график работ и определяем сроки.

На этом этапе нужно пересмотреть бизнес-кейс и прийти к спонсору с решением: «Мы согласны на эти затраты ради этого результата».

Реализация. Она может идти итерационно или каскадно. Действия могут быть параллельными или последовательными, взаимозависимыми или нет.

PM контролирует прогресс, риски, изменения в охвате проекта. Решает, вносить ли изменения в проект.

Главный проджект-менеджер в Kyivstar о самом важном в разработке проектов. 3

Оценивает, сколько ресурсов нужно для реализации новой «фичи» и сколько она принесет в итоге. Еще PM-у важно вовремя доносить реальную картину мира до людей, принимающих решение.

В этап реализации входят и тестирования — технические и пользовательские.

Закрытие. После запуска решения в операционную деятельность нужно закрыть проект: сохранить все его артефакты. Их, скорее всего, можно будет использовать для похожих проектов в будущем.

Важно зафиксировать, что было хорошо в этом проекте, похвалить команду и осознать ошибки (это самое ценное). Еще нужно проверить, закрыто ли все по контрактам, со всеми ли поставщиками рассчитались.

Как внедрять инновации в текущий процесс

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

Нужно продумывать все, что связано с непрерывностью сервиса. Любое изменение при его внедрении не должно ударить по пользователю.

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

PM должен знать, кто его стейкхолдеры, какие у них их интересы. Информировать их о статусе, результатах, проблемах. Если просто принести инновацию, они ответят: «У нас обед, приходи завтра».

Самые частые риски

Основные риски — не выдержать сроки, не уложиться в бюджет. Потом уже — нехватка ресурсов на реализацию. Например, не сможем набрать нужных специалистов на проект (они окажутся дороже, чем нужно). Или люди разбегутся в ходе работы. Или их перекупят.

Самое важное — определить все риски и знать, как на них реагировать.

Главный проджект-менеджер в Kyivstar о самом важном в разработке проектов. 4

Понять, что часть команды может уйти, например, из-за невысокой зарплаты — и быть готовым искать новых (зная, что это повлияет на сроки). Или мотивировать их нематериально — хвалить, поднимать профессиональный уровень.

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

Если проект ведется правильно (охват, стейкхолдеры и их ожидания известны), все риски можно выявить.

Их вписывают в реестр рисков с оценкой вероятности и стоимости в случае наступления. Там же указывают владельца риска — того, кто подключится и начнет действовать по плану, когда риск проявится.

Самое сложное в работе с командой

Самое сложное — формирование команды. Люди разные, у всех свои взгляды на хардовые вещи. Здесь важно уважать и модерировать всех членов команды.

PM должен быть доверенным лицом, с которым можно поделиться опасениями. Уже на старте какой-то скромный сотрудник может понимать, что все не сработает. Но не скажет — это же не его задача. Важно, чтобы ему было комфортно высказать свои мысли.

Еще важно резервировать экспертизу. В 2015 году мы планировали партнерство с одним из крупнейших брендов-производителей мобильных телефонов. Это была новая и сложная бизнес-модель взаимодействия.

У нас работала девушка с экспертизой в девайсном бизнесе и контактом с партнером. Но она ушла. Мне пришлось разбираться в тонкостях самому, поэтому реализация затянулась.

PM может выступать как дополнительный резерв для многих ролей в команде. Это неправильно с точки зрения проектного управления, но на практике спасает и добавляет «очков в карму» — по некоторым вопросам я могу выручить, если возникают перегрузки.

Ваш стиль работы в команде

Не люблю микроменеджмент. У людей должна быть возможность думать самим. Если вы будете говорить, что делать — они будут делать только то, что вы говорите.

Контролировать надо. PM может вникать в каждую задачу, но его должны интересовать только эти вопросы:

, иконка 1

- все ли выполняется в срок

есть ли проблемы

как можно помочь

Команда должна сама решать, что, как и когда делать для достижения результата.

БЛИЦ

Что посмотреть и почитать PM-у?

, иконка 1

Фильм «Человек, который изменил все» — о том, как правильно работать с командой.

Книга «Тонкое искусство пофигизма» — о том, как расставлять приоритеты. Одна из немногих бизнес-книг, которую я прочитал на одном дыхании.

Три главных страха PM-а

, иконка 1

#1. Не понимать, что от тебя хотят. Тебе говорят: «Занимайся проектом по разработке сиреневых металлоконструкций из оптоволокна». Почему сиреневых? Почему металлоконструкций? Кому это надо, к кому бежать?

#2. Нарушить дедлайны.

#3. Не быть готовым отчитаться перед спонсором.

Три любимых фразы проджекта?

, иконка 1

#1. «План — ничто, планирование — все».

#2. «Это баг или фича?»

#3. «Тут опять немножко все полностью нужно переделать».

Главный совет, который вам дали?

, иконка 1

Не ошибается только тот, кто ничего не делает — пробуйте.

Последние материалы
Ближайшие курсы
image Проджект-менеджмент в IT
Стратегия ведения проектов
image Проджект-менеджмент
основы управления проектами
image Проджект-менеджмент 2.0
практика управления проектами
mail
Подпишитесь и получайте лучшие материалы от LABA
photo
Павел Хариков
Курс
Проджект-менеджмент 2.0
19 мая - 25 июня
  • группы процессов в проекте
  • команда и коммуникации
  • управление рисками
  • мониторинг и контроль
записаться