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

Начнем с ярлыков. Можем ли мы говорить, что проджект без доменной экспертизы — дорогой секретарь? Человек, который собирает встречи, передаёт статусы и фиксирует договорённости, но не удерживает контекст и не влияет на качество решений? Да, можем.

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

Простой пример. Команда оценила задачу в две недели. У проджекта есть тимлид, казалось бы, этого достаточно. Но проджект всё равно должен уметь проверить не “правильность” оценки в инженерном смысле, а полноту контекста в оценке. Учтены ли зависимости от другой команды? Заложены ли интеграционные проверки? Попали ли в срок миграция данных? Если этого понимания нет, то проджект не управляет сроком. Он просто пересылает чужую оценку дальше по цепочке 🤡

На эту тему есть отличный анекдот

То же самое видно на примере внутреннего продукта. Допустим, это сервис управления доступами или внутренний портал для сотрудников. Проджекту здесь недостаточно «знать терминологию». Он должен понимать, кто пользователь, какие подразделения зависят от продукта, какие есть ограничения со стороны безопасности, прав доступа, интеграций и сопровождения. Он должен видеть, что именно в этой системе дорого менять, где узкое место процесса, а где локальная просьба одной команды, которая не влияет на общую картину.

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

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

Собрал для вас несколько материалов по теме, т.к в этот пост уже не лезет

“A project manager does not need intense technical training.” Где заканчивается полезное техническое понимание и начинается ложное требование к роли.

“Engineers hate being micromanaged on the technical side...” Технический микроменеджмент.

Проблема не в самой экспертизе, а в её уровне и в том, как именно она используется в роли.

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

Всех обнял 💜