Compos mentis
Сейчас все экономят. Считается нормальным совмещать прожекта и аналитика, особенно на небольшом проекте. Более отмороженные директора пытаются совмещать продактов и прожектов. В этой небольшой статье разберёмся с совсем уж диким примером — роли скраммастера (далее SM) и продуктовнера (далее PO), исполняемые одним и тем же человеком.
Для того, чтобы понять, что это очень плохая идея, давайте рассмотрим пример пиратского корабля.
Работу капитана пиратского корабля можно разделить на две большие категории:
- Драйвовые задачи. Продумывать маршрут следования корабля, принимать решения, вступать или не вступать в схватку с очередным испанским галеоном, командовать персоналом во время боя, вести переговоры с захваченными или ещё не захваченными капитанами. Короче, драйв.
- Операционка. Управление запасами провизии, организация медицинской службы, распределение добычи, конфликт-менеджмент, текущий ремонт судна.
Основная проблема заключается в том, что очень мало существует людей, способных эти задачи эффективно совмещать. Драйвовый лидер будет с отвращением составлять список капусты и брюквы, администратор не сможет вести команду в бой. Вторая проблема заключается в том, что люди склонны больше времени уделять задачам, которые им нравятся и забивать на оставшиеся, что порождает риски.
Пираты решили проблему, разделив роли капитана и заместителя по операционке, избирая на них двух разных людей. Один занимается стратегией и рубкой конечностей, второй — смолением корпуса и закупкой солонины.
Разберём четыре причины, по которым такой же подход хорошо бы реализовывать и в айти.
У SM и PO разные задачи
У них реально разные задачи и зоны ответственности, которые требуют разных навыков. PO в большей степени занимается определением стратегии и видения, SM должен сосредоточиться на снятии ограничений с работы команды и максимальном ограждении от отвлекающих факторов, улучшении взаимодействия между членами команды, повышению фокусировки.
То есть, PO определяет, чем команда будет заниматься, SM помогает ей лучше работать сообща.
Это как разделение роли разработчика и тестировщика. Да, разраб отвечает за качество своего продукта и должен уметь тестировать. Хороший QA должен уметь программировать, но они делают разные вещи. Первый — как бы так сделать, чтобы это работало? Второй — как бы так сделать, чтобы это сломать? Я утрирую, QA при нормальной схеме рабочего процесса принимают участие в проектировании и тоже думают в первом ключе, но вы уловили смысл.
Каждая роль соответствует полноценной работе на полный день
Это реально работа на полный день, что у PO, что у SM. Зачастую SM выполняет свои функции на несколько команд, но это полноценная работа. Пытаться совмещать — совершенно точно забить на часть обязанностей, обычно тех, которые меньше нравятся.
Разница в характерах
Работа SM и PO требует разных складов характера и разного мышления. Люди, в принципе, неспособны сочетать эти типы мышления, это противоречит принципам психологии и организации личности.
Некоторый антагонизм между этими ролями
PO хочет поставить на рынок как можно больше ценности, чтобы улучшить метрики продукта и доказать руководству компании свою эффективность.
SM тоже хочет примерно этого же, но его в большей степени волнует сохранность команды и психическое здоровье её членов. Почитайте, почему я не люблю термин «работа на результат». Выпустить десять фич за месяц, а потом разбежаться и забросить продукт — плохая идея. Намного лучше работать год и выпустить сто. PO тоже это понимают, но выпуск ценности для них всё же важнее.
Устраиваясь на работу, я всегда говорю своему продакту: «Моя основная задача — добиться того, чтобы твои цели достигались, но при этом команде было комфортно работать. Без перекоса в ту или иную сторону».
Бывают ли исключения?
Поговорим о казуистических случаях, когда совмещение возможно. Прежде всего, речь о маленьких компаниях, для которых экономия — вынужденное решение. Продукты в них тоже, как правило, скромные.
В такой компании возможна диковинная роль — техникал продакт менеджер. Человек и «наружу», и «внутрь».
Другое исключение — SM, глубоко погружённый в бизнес. Такое бывает, если PO находится на «территории» заказчика, а в компании-разработчике PO нет. SM может в такой ситуации взять на себя часть функций PO и по возможности их выполнять.
Наконец, видел пару случаев, когда человек был настоящим ниндзя скрама и совмещал роли во вполне полноценной разработке. Но остаётся лишь гадать, насколько он был бы эффективен, если бы выбрал одну роль.
Но в целом, такое совмещение больше вредит.
Итак, SM и PO — разные роли и выполнять их должны разные люди.
