— Ты говорил, что у тебя идеальная команда…
— Нет, я говорил, что у меня ЛУЧШИЕ специалисты. Лучшие PM из тех, кого смог найти.
© из диалога с руководством

Два года назад наш проектный офис в Professional Services был похож на пожарную команду: мы постоянно тушили пожары, сжигали людей (нет, не буквально) и не понимали, почему одни PM справляются, а другие выгорают за полгода. Сегодня текучка из-за выгорания снизилась на четверть, новички выходят на полную мощность вдвое быстрее, а понятие «зрелость» обрело понятные очертания. Это история о том, как мы перестали надеяться только на «чуйку» и начали строить работающую систему.

Меня зовут Виталий, я руковожу проектным офисом в компании, которая внедряет платформы виртуализации и VDI-решения. За 15+ лет в управлении проектами я видел десятки самых разных PM: блестящих технарей, которые не могли договориться с заказчиком, и харизматичных переговорщиков, которые не понимали инженеров и заваливали сроки.

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

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

Точка А: как выглядел наш PMO в 2023 году

Представьте типичную картину. Понедельник, 9 утра. В Telegram прилетает сообщение: «Заказчик в бешенстве, эскалировал напрямую гендиру». Или: «Я выгорел, сними с меня проект. Можно мне внеплановый отпуск?». Или «PM написал заявление, последний день в пятницу». Хорошее начало хорошей недели. А вот как это все выглядело в цифрах:

Самое болезненное: мы не понимали, почему так происходит. Один PM ведет пять проектов и справляется. Другой берет два и тонет. В чем разница? «Ну, он просто опытнее» — очевидный ответ. Но это не объяснение, это отговорка.

Три главных симптома незрелого PMO

Ответ на вопрос «что именно сломано» пришел не из теории. После того как мы разобрали несколько неприятных ситуаций подряд — эскалацию от заказчика, уход PM в середине проекта, конфликт внутри команды — я попросил каждого руководителя написать: «Что, по-твоему, было корневой причиной ситуации?» Ответы оказались разными по формулировкам, но похожими по сути. В каждом разборе всплывали три темы.

1. Синдром «незаменимого героя»
   У нас был PM, назовем ее Людмила. Заказчики ее обожали. Проблема: когда Людмила заболела на месяц, три проекта встали. Никто не знал, что происходит, где документация, какие договоренности. Вся информация была в голове одного человека.

   

2. «Интуитивный» найм
   Мы нанимали PM по ощущениям от собеседования. «Хороший парень, речь поставлена, опыт есть, структурный, вроде адекватный». Через три месяца выяснялось, что «хороший парень» не умеет говорить «нет» заказчику и соглашается на любые изменения скоупа. Бывало и наоборот: PM настолько жестко держит рамки, что клиент просит его сменить или уходит к конкурентам. Еще один пример: нормально работающий сотрудник в сложной ситуации оказывается слишком медленным, долго погружается в вопрос и протокол встречи с ЛПР высылает спустя три дня.

3. Развитие «по случаю»
   У нас были доки, база знаний, менторы, но погружение в специфику нашей работы происходило хаотично. Кто-то прошел курс по Agile, кто-то прочитал доку, кто-то «учился на проектах». Единой системы не было, как не было и четкого понимания, какие навыки критичны, какие — nice to have, а какие вообще не нужны для нашей специфики.

В какой-то момент я задумался о том, насколько наши проблемы уникальны, и поговорил с коллегами из других ИТ-компаний. Они дополнили мой список несколькими схожими проблемами, с которыми сталкиваются постоянно. Что интересно, все они так или иначе связаны именно с софт-скилами.

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

Делегирование «улетает в никуда». Задача поставлена, дедлайн обозначен — и тишина. PM не может понять, почему инженер не успел и не сказал о том, что не успевает, почему разработка не взяла фичу в релиз и сообщила об этом в последние недели. PM не задает вопросы, не эскалирует вовремя.

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

Рост «по желанию». Нет структуры — нет роста. PM годами сидит на одном уровне, потому что никто не сказал ему, что именно нужно прокачать и как это выглядит на следующем грейде. А сам он не спросил.

В принципе, все перечисленные проблемы мог бы решить осмысленный 1-on-1 или просто разговор по душам за чашкой пива. Но это было бы то самое тушение локальных пожаров, а я уже четко понимал необходимость системного подхода.

Переломный момент: когда стало понятно, что нужна система

В сентябре 2024 года мне пришлось расстаться с PMом, который не отвечал тем самым ощущаемым, но еще не оцифрованным стандартам качества. Проблема была в коммуникации. PM не смог вовремя эскалировать риск, заказчик узнал о задержке за день до дедлайна, разразился скандал. После разбора полетов я задал команде вопрос: «Как нам убедиться, что это не повторится?»

Ответы были предсказуемы:
«Нужно больше контроля» (= больше микроменеджмента).
«Нужно нанять больше самых опытных PM» (= дорого и долго).
«Нужно прописать регламенты» (= больше бюрократии).

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

Тогда я сформулировал вопрос иначе: «Как измерить способность PM принимать правильные решения без постоянного контроля?» На него уже сложнее дать простой (и неправильный) ответ. Это был поворотный момент. Мы перестали искать абстрактных «правильных людей» и начали строить систему, которая еще на испытательном сроке помогает нам определить, насколько развиты те или иные качества руководителя.

Культурный код

Прежде чем строить систему оценки и развития, нам нужно было начать с качеств PMа: какие для нас критичны, а какие — опциональны? Оказалось, что внутри команды нет согласия в том, чего мы ждем от PM. Более того, у каждого руководителя был свой образ «хорошего PM». У меня — один, у директора департамента — другой, у заказчика — третий. Люди не могут соответствовать ожиданиям, которые нигде не записаны.

Мы сели вместе и сформулировали четыре принципа. Не для HR или сайта с вакансиями — для себя. Чтобы когда на очередном 1-on-1 PM спрашивает «как я работаю?», у меня был конкретный ответ, а не «ну, в целом нормально».

Так получился культурный код Professional Services:

Далее на основании этих верхнеуровневых принципов мы сформулировали, чего ждем от сотрудников, в том числе от PM:

• Способность принимать решения. Действовать без лишних согласований, но с полной ответственностью.

• Ориентация на клиента. Понимать, что клиент покупает результат, а не часы работы.

• Командный дух. Результат у нас общий, и работаем над его достижением мы вместе.

• Готовность экспериментировать. Если нет готового решения — создаем его. Ошибки — это данные для роста.

• Скорость и дисциплина. Клиент не ждет. Работаем быстро, стараясь не терять в качестве.

• Стремление к развитию. Учимся и учим. Каждый сотрудник — и ментор, и ученик.

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

Поэтапная трансформация

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

Диагностика (Q4 2024)

Когда я первый раз попросил команду самостоятельно оценить свой уровень, получил неожиданный результат: почти все поставили себе 7–8 из 10. При том, что на проектах картина была другая, не настолько оптимистичная.

Идею подсмотрел у руководителя нашего Professional Services. Он давно использовал похожую самооценку для инженеров, когда ему нужно было быстро понять, кто из команды знает продукт, а кто «знает, что не знает». Мы адаптировали подход для PM — добавили шесть направлений для оценки: инструменты, процессы, софт-скилы, управление проектом, техническая база, сертификация. В файле самооценки зрелости эти направления раскрывались как несколько вопросов с вариантами ответов. «Баллы-попугаи» из примера методики мы перевели в проценты уровня владения, где можно было достичь и 100% (идеальный уровень владения навыком/инструментом), и даже 120% (уровень overhead, говорит о том, что сотрудник перерос пределы своей роли). Каждому варианту ответа зафиксировали субъективный % зрелости, соответствующий, по нашим меркам, данному направлению. Каждое направление зрелости имело свой вес в оценке, помноженный на % уровня владения.

Пример расчета:

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

Определение приоритетов (Q1 2025)

После диагностики встал вопрос: хорошо, у нас есть метрики. С чего начинать? Нельзя развивать все сразу — люди перегорят, а ресурс руководителя конечен. Мы провели серию интервью с руководством и заказчиками, честно спросили: «Назовите трех PM, которые работают лучше всего. Что их отличает?» А потом: «Назовите трех, с которыми было сложнее всего. Почему?» Паттерны совпали у всех опрошенных — независимо от того, кто именно называл имена.

Выкристаллизовались четыре качества. Я назвал их НРАВ: Надежность, Результативность, Автономность, Вовлеченность. Не потому что хотел красивую аббревиатуру — просто именно эти четыре навыка объясняли, почему один PM ведет пять проектов и не теряется, а другой тонет на двух.

Сильный PM, увлеченный и настроенный на результат, может тянуть одновременно несколько сложных проектов. Это похоже на драйв индивидуального предпринимателя — «никто, если не я!». Руководитель проектов, у которого сложно с той же автономностью, буксует даже на простых активностях, постоянно ждет совета и перекладывает ответственность на всех вокруг, ожидая от них решения: «Ну, я ведь неделю назад говорил вам на дейлике, что у заказчика задержка в настройке инфраструктуры». Такое поведение напоминает тот анекдот про сисадмина на стрельбище: «Пули вылетели, проблемы на той стороне».

Перестройка онбординга (Q3 2025)

Раньше онбординг у нас выглядел примерно так: «Вот регламент, пара инструкций и несколько видео, вот Jira/Confluence, вот твой первый клиент — разберешься». Аттестация перед выходом «в поля» была, но не было четких принципов и этапов, опознавания «свой/чужой». К концу трехмесячного испытательного срока PM либо начинал работать нормально, либо мы понимали, что что-то не так. Но три месяца — это дорого: и деньгами, и нервами заказчика, и временем коллег, которые тащат его на себе. Иногда мы видели, что человек «не наш», уже после окончания испытательного срока, и это была боль для обеих сторон.

Мы решили сделать первые 90 дней более управляемыми. Начали с подробного плана обучения и онбординга. Но план не равно оценка, а оценку софт-скилов сделать объективной казалось невозможным. Руководитель Professional services предложил оцифровать наши ощущения в «попугаях», прогнать на известных успешных новичках и тех, кто «под вопросом». Назвали этот метод «ВПП» — взлетно-посадочная полоса, поскольку без нее невозможен успешный вылет, это чек-лист и индикаторы на каждом этапе перед долгим полетом. Двенадцать недель, четыре блока: процессы, инструменты, продукты, взаимодействие с командой. На каждой неделе — конкретные задачи и контрольные точки с обратной связью от руководителя и бадди-сотрудника.

Эффект превзошел ожидания: уже на второй-третьей неделе стало видно, кто точно приживется, а кому нужна помощь в конкретном месте. Время принятия решения «наш человек / не наш» сократилось вдвое.

Самый банальный пример: либо сотрудник ставит сам встречи с наставником, либо ждет и молчит. Без системы вы можете это заметить, но, скорее всего, нигде не отложится этот звоночек. «Взлетно-посадочная полоса» — это своего рода чек-лист по неделям, в том числе для фиксации того, как новичок формирует вопросы, оформляет встречи, интересуется продуктом, насколько пунктуален и прочее. Те самые софт-скилы.

Система развития (Q4 2025)

Первые тренинги (еще в доковидные времена) мы делали «для всех». Брали тему, например переговоры с заказчиком, и проводили общую сессию с лучшими практиками. После курсов предлагали инструменты, в частности топ вопросов для оценки позиции оппонента и шаблон для подготовки к сложным переговорам. Был опыт с наймом внешнего ментора и переговорными поединками. Быстро поняли, что это не работает: если оценивать текущими метриками, PM со зрелостью 50% и PM со 100%-ной оценкой коммуникативных навыков находятся в совершенно разных точках. Для одного базовая техника — откровение, для другого — скука и ощущение потери времени. Поединки тоже давали субъективную оценку от присутствующих и не развивали слабых.

Переделали обучение под уровни НРАВ. Для каждого уровня — свой набор: упражнения, разборы кейсов, shadowing с более опытным коллегой. Отдельно разработали техники развития и методики для аккуратного развития сотрудников на один на один. Разница оказалась заметной: средний рост автономности за квартал вырос с 0,1 до 0,3 пункта. Звучит как небольшое число — но на горизонте года это разница между PM, который работает под постоянным контролем, и PM, которому можно доверять сложный проект без ежедневной «сверки часов».

Карьерный путь (Q1 2026)

К началу 2026 года у нас была оценка, была система развития. Однако оставался незакрытым вопрос, который мне задавали на каждом 1-on-1: «Когда меня повысят? Что для этого нужно?» Ответ у меня был, но только у меня и только в голове — нигде не записанный и непрозрачный для команды.

Это было нечестно. Человек работает, старается — и не понимает, по каким правилам оценивается его прогресс. Мы формализовали грейды: три уровня (A, B, C), каждый разбит на три подуровня. Для перехода с уровня A на B — конкретный порог зрелости, конкретные достижения. Никакого «ну, посмотрим».

Результат: желающим PM составили индивидуальный план развития на год. Не потому, что мы заставили, — просто стало понятно, куда идти.

Автоматизация и масштабирование (Q2 2026)

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

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

Во многом поэтому я написал эту статью и хочу превратить ее в серию. Хочу выйти из ручного режима не только технически, но и методически — зафиксировать то, что работает, пока оно еще свежо. Объяснить в понятной системе логику всех инструментов и их взаимодействие, перенести фантазии на работающую систему.

Вместо заключения

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

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

Бонус-трек. Типичные ошибки на старте

Ошибка 1: «Сначала найму хороших людей, потом выстрою систему»

Хорошие люди уйдут, пока вы выстраиваете систему. Система — это то, что удерживает хороших людей.
Я сам был уверен: вот найду правильных людей — и все наладится. Не наладилось. Хорошие люди уходят туда, где есть система.

Ошибка 2: «У нас все и так работает — зачем формализовывать?»

Работает на текущем масштабе. При удвоении команды «и так» превращается в хаос быстрее, чем вы думаете.
До 2023 года у нас все «работало». Потом команда выросла с 5 до 10–15–20+ человек — и я понял, что масштабируется только то, что формализовано.

Ошибка 3: «Мы внедрим лучший фреймворк из книги»

Фреймворки — это карты. Ваша команда — территория. Карта и территория всегда отличаются друг от друга. Берите инструменты, адаптируйте под свой контекст.
Мы потратили три месяца на адаптацию популярного фреймворка оценки компетенций. Выбросили почти все и сделали свое. Сожалений нет.

Ошибка 4: «Сначала обучу всех, потом введу оценку»

Оценка без обучения — стресс. Обучение без оценки — деньги на ветер. Внедряйте параллельно.
Без оценки с самого начала нам было очень сложно найти «отправную точку» в середине пути. Как проходили онбординг и адаптацию те, на кого мы равняемся? А это исключение или правило? Оценивать лучше сразу, поэтапно и в моменте.
Это как с подсчетом калорий — вечером можно «забыть» о лишнем сырнике с утра, а если не взвешивать еду, то кажется, что «я ем совсем немного, точно укладываюсь в норму».