Куда можно пойти поработать, если вы – Руководитель проектов? Есть много сладких названий: Яндекс, Тинькоф, Сбер, Авито, ВК. Есть еще Газ-Нефть-Полиметал-Тех-сырье компании, есть просто ИТ подразделения не ИТ компаний типа Магнита или Технониколь. Есть еще системные интеграторы Т1, IBS, Softline и так далее. Есть ли среди всей этой карусели отличия, и что вы получите, работая в каждой, кроме того что сможете сказать «Я работал в /Name/?

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

Это очередная статья о том, чего не рассказывают на курсах РП: о навыках, которые потребуются Руководителю проектов с самого первого дня работы. Если вам интересны такие истории, читайте другие мои статьи на Хабре и подписывайтесь на мой ТГ канал "Морковка спереди, морковка сзади".

Статья не претендует на 100% знание истины (опыт у каждого свой), но основана на личном опыте автора, который поработал во многих компаниях, прошел больше сотни собеседований сам и прособеседовал не менее нескольких сотен Руководителей проектов из разных компаний.

Небольшая предыстория

Изначально я стал РП в большой продуктовой компании, которая сама внедряла свои продукты. Внедрение было настолько сложным, что отдел Solution delivery был полноценным системным интегратором: горели дедлайны, работа по выходным, и ночами -  короче, все, как у всех.

А потом я пришел для интереса во внутреннее ИТ. То есть в ИТ департамент внутри компании. Где я столкнулся с новыми для себя функциями: надо было выбирать подрядчиков на работы, а не самому выполнять. А еще я столкнулся с тем, что я был «слишком быстрый и резкий» для такой компании. Я же, в свою очередь, очень удивился, почему в 18-00 команда перестает работать и идет играть в настолки, когда можно поколбасить еще часок-другой (тем более, что раньше 10 на работу никто не приходил и обедали не менее часа). «А вот так», - сказали мне – «у нас work-life balance, а ты слишком негативный и не умеешь работать с людьми».

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

Этими закономерностями я и хочу поделиться.

Какие виды РП есть

С точки зрения ГОСТ все РП одинаковые. Но никто в реальной жизни не живет по ГОСТ и в зависимости от организации роли РП могут быть разные. Я постарался их обобщить на картинке ниже:

Важно: это общая классификация. Ясно, что могут быть причудливые девиации вида «РП, который должен закупить рекламу и привести лидов, потом снимать видео и выкладывать в мой ТГ канал» до чистых релиз-менеджеров, но общий подход везде прослеживается: базовые роли именно такие, а все остальное – их микс в разной степени.

 Если попробовать систематизировать, получается следующее.

1. РП в продуктовой компании.
   Основные компании: Яндекс, Авито, Мейлру, ИТ крупных банков.
   Функции: выполнение задач от продакта (продактов) в срок. У такого РП есть беклог с задачами и дата релиза, его главная задача – дотащить задачи до релиза. Часто может быть кросс-командным РП, который синхронизирует реализацию нескольких задач в нескольких беклогах, параллельно разбираясь со сторонними компаниями, с которыми интегрируется продукт. В крайних проявлениях функции не особо отличаются от Релиз-менеджера.
   Команда: Проектной команды нет, есть независимые команды, в беклоге у которых стоят его задачи, которые надо сделать к сроку.
   Заказчик: продакт или продакты.
   Общие черты: фактически – технические менеджеры, отвечающие за релизы фичей и не имеющие выход на заказчика.
   Краткое описание: не успели сделать тикет в спринте — это только твоя проблема, проект у тебя а не у команды, которая просто фигачит по беклогу.

2. РП внутреннего ИТ или шире – внутренний РП.

   Основные компании: Сбертех (и любые Банки в части цифровизации услуг), весь ГосТех, и вообще -любая крупная компания со своим ИТ отделом более 30 человек (примерно), где появляется необходимость вести ИТ проекты по внедрению новых систем, замене старых и цифровизации внутри самой компании.
   Функции (здесь речь будет только про ИТ, не касаемся РП, которые синхронизируют работы по потокам кроме ИТ – стройка, маркетинг и так далее): оказание ИТ услуг всей компании – цифровизация всех процессов компании от бухгалтерии до производства, замена устаревающих систем, внедрение новых. Сложность систем и процессов обусловлена размерами компании: чем комания больше, тем сложнее инфраструктура, процессы, и тем сложнее ИТ системы.
   Команда: часто работает без команды по принципу: сделали ФЭО-защитили его на инвесткомитете-играем конкурс 44ФЗ или 223ФЗ-трахаем подрядчика-получаем результат. Иногда бывает микс, когда выполняет работы и inhouse команда и подрядчики.
   Заказчик: все бизнес подразделения компании. В больших компаниях (банках, к примеру) может экранироваться внутренними сейлзами или аккаунтами – по сути экранирующими РП от бизнеса.
   Общие черты: иногда ты отвечаешь за все, а у тебя нет почти никаких рычагов, кроме мольбы ?.  Крайне много политики внутри компании, политики с подрядчиками. Помимо этого, у вас будет еще сотня внутренних регламентов компании, которые нарушать вы не имеете права даже ради вашего проекта.
   Краткое описание: «обосрался подрядчик, а чпокнули тебя»

3. РП системного интегратора/консультанта.
   Основные игроки: T1, Softline, I-Teco, Инфосистемы Джет, IBS и огромное количество других. Системный интегратор – это непродуктовая компания, которая оказывает ИТ услуги компаниям из раздела 2 выше.
   Функции: зарабатывать бабки для своей компании, выполяя проекты для клиентов в срок и с прогнозной маржой.
   Команда: линейно не подчиняется, но, как правило, тут самая сильная связь РП и команды. Если РП интегратора хочет хорошей скорости и качества, он должен много коммуницировать с командой и эффективно выстраивать ее работу. Это приводит к тому, что функциональное руководство гораздо сильнее линейного (линейный менеджер в интеграторах, как правило, только согласовывает отпуска и согласует вопросы зп).
   Заказчик: компании из пункта 2 выше.
   Общие черты: «Не пускают в дверь – залезь через окно». Ты или зарабатываешь деньги компании или ты неэффективный.
   Его боль: Все хотят быстро, качественно и недорого, а так не бывает.

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

В чем отличия этих РП друг от друга по знаниям (повторюсь, это мои наблюдения «в целом» по выборке. Ситуация у вас может быть иной из-за требуемых функций в компании).

1. Продуктовые РП

   1. Знает:

      1. Как собирать требования, как ставить задачи;

      2. Правила формирования беклога и приоритизации;

      3. Как работать с несколькими командами разработки, для которых ты никто;

      4. Шарит в технике на уровне аналитика.

   2. Не знает: 

      1. Проектной документации от инициации проекта до его завершения – во внутренних продуктовых компаниях свои методологии и подходы к документированию. Про ГОСТ34 вообще молчу.

      2. Не умеет быть гибким. «Как сделать быстро, не двигая сроки вправо» знает хуже других, потому что обычно, ему проще их перенести (как сказала как-то продуктовый менеджер из Яндекса: «наш best practice – это вообще не говорить сроки готовности заказчику» ? ? ?).

      3. Не знает слова «маржа проекта» и как правило не сильно следит за перерасходованием времени в тикетах своих проектов.

2. Внутренние РП

   1. Знает:

      1. ЖЦ проекта от инициации до завершения, может даже знать, что при внедрении системы ложится на CAPEX, а что на OPEX.

      2. ФЗ-223 или ФЗ-44 или проприетарные правила отбора поставщиков-подрядчиков.

      3. Спокойно относится к бюрократии (данность любой крупной компании) и сам бюрократ.

      4. Умеет контролировать подрядчика или подрядчиков.

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

      6. Как правило, не шарит в технических деталях на уровне аналитика – у него часто нет на это времени: подрядчик сделал, заказчик принял – акт подписан.

   2. Не знает:

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

      2. Часто не шарит в технических деталях, выступая, как администратор (и от этого страдает)

3. РП интегратора

   1. Знает:

      1. Жизненный цикл проекта от идеи до сдачи в поддержку.

      2. Как делается контрактовка.

      3. Гибкий в отношениях с заказчиком (не будешь понимающим – не заработаешь).

      4. С высокой технической экспертизой в своих проектах (иначе команда может и без него, он только мешает).

      5. Умеет работать с командой разработки, мотивируя ее (другие долго не живут).

      6. Умеет зарабатывать бабки.

      7. Понимает, что такое маржа и знает, как ее увеличивать.

   2. Не знает:

      1. Что такое серьезная бюрократия и документооборот.

      2. Часто умеет достигать результата ценой нарушения правил. Если в интеграторе так иногда можно (все-таки деньги зарабатываем), то в процессной компании такое не прощается.

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

В системной интеграции Руководитель проектов - и есть бизнес. Он приносит деньги компании и ради этого ему многое можно простить.

Во внутреннем ИТ Руководитель проектов расходует деньги. А значит, его деятельность надо максимально нормировать и контролировать, чтобы не потратил лишнего. Как говорится - почувствуйте разницу.

Итого

Хотите научиться скорости, нахождению самых быстрых решений в режиме ограниченных ресурсов – вам в системную интеграцию.

Хотите научиться настоящей бюрократии и дипломатии – вам во внутреннее ИТ (и ваши сложные отношения с сейлзом в системном интеграторе вам покажутся игрушками).

Хотите играть в настолки, сидеть в красивом офисе, чувствовать причастность к чему-то большому и отвечать за небольшие релизы, выполняя часто просто техническую роль – вам в продукт.

Ну и надо помнить – мир небинарен и написанное выше иногда очень интересно переплетается в реальной жизни: есть РП, которые и продакты, и аналитики, и даже маркетологи. Вот именно это и рекомендую выяснять у работодателя на собеседовании, чтобы понимать заранее, что вас ждет, и чтобы ваша работа и ваш опыт соответствовали вашим ожиданиям.