Про продуктовые команды 🤝
(Часть 4 - Teach-Lead и Project Manager)

Scrum Guide декларирует равноправие членов команды. Нет руководителей, ответственность только коллективная. На практике "самоорганизующиеся команды” - скорее миф. Как я уже описал выше, роль руководителя возлагается на продакта, как ответственного за результат в терминах достижения целевых метрик.

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

Но за пределами бизнесовых вопросов есть ещё огромный пласт технической реализации и предсказуемого delivery.

Чтобы мозг продакта не взорвался окончательно от необходимости вникать и в эти аспекты, и Сбер, и Яндекс вводят в командах роль teach lead. Получается довольно гармоничное разделение: продакт решает “что делать”, а Tech-Lead - “как делать” и "кому делать”. (Sporify Tribes, прообраз Сберовских трайбов, существуют по схожей логике. И да, это очень похоже на обычную матричную структуру.)

Предполагается, что Tech-Lead обычно отвечает за:
✦ классический people management: мотивация, 1-1, найм…
✦ delivery: предсказуемость и скорость, оптимизация процессов…
✦ унификацию технических аспектов в рамках компании: технологический стек, правила работы с репозиторием…

Но я чаще встречал ситуации, когда это работает не полностью. Tech-Lead чаще обладает глубокой экспертизой, чем скиллами типичного менеджера (или стоит очень много). Поэтому продакту, наверняка, придётся разбираться в том, как выстраивать эффективный процесс разработки. Потому что, если delivery хромает, количеством кастдева/аналитики эту проблему не решить.

Приходя в новую команду, я склонен врываться в оптимизацию процессов, пока не "обучу нейронки" команды действовать с понятной мне логикой. Когда статусы задач в таск-трекере начинают отражать реальную картину, и становятся достаточно прозрачными, чтобы не выяснять каждый раз “а это мы зачем делаем?", я постепенно перестаю участвовать в Daily. Planning и Retrospective остаются в календаре продакта насовсем - без них потеряешь связь с реальностью. (Если опыта в построении эффективных процессов пока немного, рекомендую “Цель” Голдратта - ставит мозги на место, послужит неплохим базисом.)


В вопросам требующих сложной координации появляются и Project Manager’ы. Они могут быть быть как частью конкретной команды, если у неё много завязок с окружающими, так и координировать большие проекты, вовлекающие множество команд и подразумевающие жёсткие deadline. (В Яндекс.Браузере, судя по рассказу Галины Митричевой, всё ещё интереснее.)

Обычно роль проджекта, заключается в следующем:
✦ осознать все составляющие проекта и взаимные зависимости - собрать их в общий план, ничего не забыть
✦ убедиться, что составляющие отражены в планах команд в нужное время - в бэклоге с нужным приоритетом
✦ отслеживать, что всё будет доставлено во время - про задачи не забыли, все справляются
✦ если что-то идёт не по плану, предпринять корректирующие мероприятия (например, перераспределить ресурсы) или экскалировать
✦ координировать всех участников проекта, не являющихся членами продуктовых команды (закупки, инфраструктура, маркетологи, логисты и т.д.)


Продакту не обязательно знать все детали технической реализации фичей или быть гением в оптимизации процессов разработки. Но наличие этих скиллов позволит двигаться быстрее и доставлять фичи эффективнее. ☝️

#product_teams #product_management #tech_lead #project_management