Грейды проектных менеджеров KT.Team: уровни, оценка и ИПР

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

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

Если проектов несколько, оценок тоже несколько: по одной на проект. Все сомнения трактуются в меньшую сторону — сомневаетесь между двойкой и тройкой, ставьте двойку.

Клиент может передать команде состояние уровня L30, но это ещё не делает проект проектом уровня L30. Уровень считается удержанным, только если команда сама формулирует кейсы, критерии готовности и проверки и сама доводит состояние до реального использования.

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

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

Нормально начинать сотрудничество с уровня рук. Ненормально долго на нём оставаться: задача менеджера — растить доверие и повышать уровень нашей ценности в проекте.

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

Всё остальное — запас. Незавершённая работа это не актив, а замороженные деньги клиента и отложенное понимание того, было ли решение вообще правильным. Поэтому оценка смотрит на максимальный объём такого запаса: сколько ценности лежит невостребованной и как давно.

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

Это два разных контура, и они расходятся чаще, чем кажется. Команда может быть в прекрасных отношениях с ИТ-департаментом и при этом ни разу не увидеть человека, который отвечает за бизнес-результат. Обратное тоже встречается.

Поэтому в оценке два вопроса с одной и той же шкалой. Растить нужно оба: без бизнеса не будет понимания ценности, без ИТ не будет доступа к контуру, данным и продуктиву.

Требования меняются даже в enterprise-проектах, даже при миграциях, даже при точном ТЗ и даже в регуляторных задачах. Это не отклонение, а нормальное свойство программных систем. Предсказуемость при этом достигается не тяжёлым предварительным планированием и не многоуровневыми согласованиями, а короткими циклами обратной связи, автономией команды и поставкой маленьких проверяемых инкрементов.

DORA изучает современные продуктовые команды с 2013 года, QSM моделирует индустриальные данные с 1978-го, и по ключевым выводам они совпадают: большие партии вредны, поздняя обратная связь дорога, фазовое мышление удлиняет проект, а успех не зависит от определённости на старте. Попытка заморозить требования увеличивает и длительность, и стоимость.

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

Мы не можем менять оргструктуру клиента и не собираемся спорить о терминах. Но мы всегда различаем формально назначенного Product Owner и владельца бизнес-результата, и никогда не подменяем одно другим, даже если у клиента это называется одинаково.

Менеджер обязан обеспечить минимальный прямой контур между командой и владельцем результата. Рабочих форматов три: регулярные бизнес-сессии раз в две-четыре недели, где команда показывает инкремент на живых данных; демо с метриками, наблюдениями и реальными кейсами использования, где вопросы адресуются владельцу результата напрямую; асинхронный канал с короткими записями экрана и конкретными вопросами, если встречи невозможны.

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

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

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