Продакт + Проджект на 20 человек: как мы разделили руль

Опыт управления командами у меня больше 10 лет. Начинала с нагрузочного тестирования в аутсорсе и там исполняла роль тимлида+проджекта. И в роли продакта я работала как с совсем маленькими, так и с командами по 20 человек. В маленьких командах получается быстро договориться, а вот в командах 15+ операционка может перетаскивать на себя огромный временной ресурс и отжирать то, чем я люблю заниматься. В этой статье расскажу, как я подхожу к управлению большими командами, как мы делили обязанности с проджектом и адаптировали Scrumban под наши потребности.

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

Мы сели и начали думать. Первое, что мы решили поделить - ритуалы и зоны ответственности. Так как я общаюсь с бизнесом, знаю чего хочет он, чего хотят пользователи, и так далее - то решили, что мне останутся груминги и планирование, а она будет вести - дейлики и ретро. Чётко разделили для команды к кому с какими вопросами после появления проджекта они могут обращаться: если вопрос про бизнес, как будет работать фича, какой приоритет и так далее - ко мне, а если вопрос про организацию работы, синхронизацию и текущую операционку — к проджекту. Это уже сняло огромную нагрузку.

Следующим шагом было - решить проблему с дейликами. На них слишком много народу, они затягиваются, ребятам скучно когда обсуждают задачи, которые к ним не относятся. Разделили дейлики: отдельно DS (дата-аналитики, саентисты, data quality и тд), отдельно разработка delivery (фронты, бэки, тестировщики), отдельно discovery (дизайнер, бизнес аналитик, системный аналитик - эта часть команды, которая делала ТЗ). Чтобы у ребят не возникло рассинхрона, то мы звали тимлида разработки на дейлик DS и наоборот, менеджеров по внедрению - на всё, так как к ним приходят пользователи с вопросами. Ребятам стало проще, время освободилось, они перестали скучать и жаловаться, все включены во встречу - это круто. А я уже в целом могла не присутствовать на каждом дейлике.

Ну и, наконец, - доска и приоритеты. У нас было всё на одной доске. Идея была простая - в одном месте видеть статус по всем, но по факту это было натягивание совы на глобус. Например, что такое этап “тестирование” для дизайнера? Это когда я смотрю и возвращаю на доработку? Во-вторых она была перегружена и слишком много тасков и ребятам был совсем не ясен приоритет! Мы решили разделить доски. Прямо по дейликам. Когда требования были полностью прописаны к новой фиче и задача переходила на последний этап на доске discovery, то я её переносила в первый столбец delivery на место согласно приоритету. Так, если, например, у разработчика появилось свободное время (он закончил раньше, или ждёт чего-то от кого-то), он сам мог зайти на доску и взять первую задачу сверху из тех, что подходят под его компетенции, никого не дожидаясь.

Ещё крутые лайфхаки: 

1. На груминг команды discovery звать лида разработки и тестировщика. Тестировщик - это вообще кладезь! Он столько нюансов накидывал, что качество задач, отдаваемых в разработку, повысилось кардинально. 

2. С дизайнером накидывать несколько вариантов и с ними сбегать к фронту и прикинуть трудозатраты.

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