Куда можно пойти поработать, если вы – Руководитель проектов? Есть много сладких названий: Яндекс, Тинькоф, Сбер, Авито, ВК. Есть еще Газ-Нефть-Полиметал-Тех-сырье компании, есть просто ИТ подразделения не ИТ компаний типа Магнита или Технониколь. Есть еще системные интеграторы Т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. Часто умеет достигать результата ценой нарушения правил. Если в интеграторе так иногда можно (все-таки деньги зарабатываем), то в процессной компании такое не прощается.

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

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

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

Итого

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

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

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

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