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

Тут важно небольшое пояснение. Везде, где мы говорим о ролях РП, тимлида, иногда архитектора в компаниях в сфере ИТ, мы заранее понимаем, что в каждой компании своё представление о роли. Вот где-то даже СТО обязан писать код. А где-то (мои личные знакомые) тимлид вообще не прикасается к коду, а занимается только people-management и немного project-management.

Итак, руководитель проектов. Проект в нашем случае реализуется посредством ИТ-решений и силами ИТ-команды. Но главная цель такой реализации - обеспечить конкретную потребность бизнеса. Поэтому если тимлид сфокусирован больше на грамотном использовании ресурса ИТ-команды, то РП - на результате и пользе для компании.

Да, я считаю, что РП должен уметь думать про пользу. Где-то есть чёткое разделение: руководитель продукта про сам продукт и пользу, которую он приносит юзерам, акционерам и всем-всем-всем, а руководитель проектов только про исполнение задумок.

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

И всё же, где экспертиза со стороны РП по поводу пользы? - Всё просто. Работая в inhouse-командах, я всегда удивлялся, что почти всегда у нас, а также по многочисленным свидетельствам из других компаний, бизнес очень редко считает непосредственную эффективность доработок или устранения неисправностей.

Бывает, забегают в пятницу вечером: всё, капут, выводи всех своих завтра на overtime, даже заплатим по ТК РФ, нужно срочно добавить вон ту плашку на сайт! Аккуратно интересуешься, а зачем, а сколько народу ей будет пользоваться, а что это за категория посетителей, а какой средний чек она обеспечивает, а есть ли репутационные потери? Всем вдруг становится очевидно, что overtime стоимостью условно 100 тысяч рублей принесёт компании условные 5 тысяч, и то с вероятностью 0,7.

Ещё хуже с фичами. Готов повторять много раз: до сих пор ещё много где ИТ воспринимают как волшебников, которые могут всё сделать быстро и сделать буквально всё. Это мнение рождается из нематериальной сущности нашего производства: сложность, в отличие от постройки домов и прокладки дорог, не выражена в громоздких материальных объектах, а значит, не видна.

Далеко не за каждым проектом стоит элементарное экономическое обоснование: что это нам даст, каких целей достигаем, какой срок окупаемости, какие риски. Понятное дело, РП не обязан быть, как та тётя Циля из анекдота, старшим экономистом. Однако он должен дать заказчику достаточно полное понимание реальной стоимости проекта: непосредственно разработка, трудозатраты, умноженные на часовую ставку. Также взаимовлияние на другие части продукта и/или проекты. Также риски и их стоимость. Также приоритетность отвлечения команды: если мы делаем это, то значит, не делаем вот это - как вам, меняем важность запросов внутри компании?

Последнее особенно важно. Часто в inhouse-разработке у ИТ-команд всегда больше запросов на изменения, чем она сможет выполнить. Поэтому приоритезация запросов бизнеса падает на РП. Если, будучи тимлидом, я ждал, что бизнес сам между собой договорится, что ему важнее, то на роли РП этой работы ожидают непосредственно от меня. А для этого нужно подбирать инструменты: экономическое обоснование, опора на авторитетность того или иного лидера бизнес-направления, "всем понемногу", прямые указания от директора и так далее, так далее.