Роли и как они объединяются для развития продукта

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Вообще эта статья была написана еще в 2020 году во время активной фазы пандемии, когда мы еще не знали что нас ждет. Но мы понимали что масштабирование продукта, разработки, нагрузки уже вот начинается сейчас и процессы должны были все это пережить. Они должны были перестать мешать.

Необходимо думать о функционале, общаться с пользователями, проверять гипотезы, работать над техническим долгом и улучшать архитектуру продукта, выстраивать процессы, работать индивидуально с людьми и помогать им развиваться. Запихнуть все это в голову одного Product Owner’а (PO) можно лишь в очень маленьком продукте и когда у него есть глубокие технические компетенции. С ростом продукта растет ответственность и сложность, а задачи все более фрагментируются.

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

  • продуктовую, проверка гипотез, общение с пользователями и т.д.

  • техническую, работать с нефункциональными требованиями, архитектурой, кодом

  • выстраивать процессы так, чтобы они помогали продукту

  • работать индивидуально с людьми и растить их, решать их проблемы

Это приводит к 4м ролям.

Кто за что отвечает
Кто за что отвечает

Product Owner

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

Владелец продукта хорошо справляется со своей работой, если бизнес показатели продукта имеют позитивный тренд.

Тут ровно ничего нового и необычного. Откройте поиск и увидите там плюс-минус одинаковое понимание, кто такой PO.

Technical Lead

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

Роль Техлида Продукта схожа с ролью Component Owner/Technical Owner, с единственным отличием что Техлид Продукта действует и несет ответственность на уровне Продукта целиком, а Component Owner действует на уровне конкретного компонента.

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

Техлид хорошо справляется со своей работой, если Сервисы продукта имеют высокий SLA, они хорошо тестируемы, легко поддерживаемы и позволяют быстро вносить изменения.

Техлид хорошо справляется со своей работой, если он научил команду самостоятельно принимать грамотные технические решения.

Process Lead

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

Мы это изменили названием — Process Lead.

Process Lead отвечает за создание среды для эффективной работы команд продукта и устранение препятствий как внешних так и внутренних. Process Lead помогает PO, Техлиду и командам разработки в организации их работы для достижения целей продукта. Не важно, будет это Scrum, Kanban, LeSS, да что угодно. Его задача — эффективный процесс, который помогает разработке продукта.

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

People Lead

People Lead отвечает за развитие людей, их эмоциональное состояние и решение их проблем (устал, выгорел, не нравятся задачи, зарплата, опционы, чувствую что перестал расти, помоги собрать обратную связь и т.д.), которые не решаются на уровне продукта, отвечает за разбор, разруливание конфликтных ситуаций. Любит людей и верит, что они действуют из лучших побуждений.

People Lead хорошо справляется со своей работой, если каждый в команде растет и развивается, конфликтов нет и каждый разработчик может реализовать в команде свой потенциал.

Объединять, а не разделять

А интересность в необычных сочетания. Есть такая хорошая книжка “От хорошего к великому”. Там есть глава, рассказывающая о силе союза “И”, когда ты начинаешь сочетать несочетаемое и получать невероятные результаты. Все что я описывал выше — это роли и это не значит что у нас в команде есть выделенные люди на каждую роль. Мы используем сочетания ролей в одном человеке.

В одной команде один человек взял роль PO и People Lead. В другой сочетают роль Tech Lead и People Lead, в третьей Process Lead и People Lead, в четвертой Tech Lead и Process Lead. Возможностей разных сочетаний много и это приводит к гибкости построения командной работы. Все люди разные, есть ребята с сильным эмоциональным интеллектом, умеют читать и понимать эмоции людей, но при этом не дружат с процессами. Есть те кто наоборот — любит процессы и шарит в технике. Команды получаются очень разными и гибкими, они сами выстраивают что им нужно.

Разные конфигурации ролей
Разные конфигурации ролей

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

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

Источник: https://habr.com/ru/articles/764992/


Интересные статьи

Интересные статьи

Привет, Хабр! Я – Илья Усов, техлид из команды сервиса SunkeyToolkit для удаленного тестирования мобильных приложений. В этой статье расскажу о том, как мы попытались исследовать некоторые вероятностн...
«Однажды темным-темным вечером в темной-темной комнате», — так должна начинаться любая по-настоящему страшная история. Однако история, от которой шевелятся волосы на голове DevOps-инженера, звучит сов...
Перед вами первая часть из трёх частей общего труда, вводная часть цикла статей о проектировании процессов разработки IT-продукта. Данная вводная статья носит философский характер, некий взгляд на ве...
Современные цифровые технологии постепенно, незаметно, но кардинально трансформируют мир вокруг нас, все глубже проникая в нашу повседневную жизнь. Меняются способы общения, ведения бизнеса, самореали...
Первый квартал внутренний критик и синдром самозванца были моими двумя лучшими друзьями. Я с ними общалась каждый день. Систематически. И просто не могла расслабиться. Считала, что недостаточ...