Двадцать человек в команде — это уже не про «быстренько договорились», а про то, как не утонуть в операционке. Рассказываю, как мы с проджектом поделили руль и пересобрали процессы.
За плечами у меня больше десяти лет управления командами. Стартовала с нагрузочного тестирования в аутсорсе, где совмещала тимлида и проджекта. Продактом тоже довелось поработать и с крошечными коллективами, и с командами по 20 человек. В маленьких всё решается быстро, а вот на 15+ операционка начинает съедать прорву времени и вытеснять то, что я по-настоящему люблю. Ниже — про то, как мы адаптировали Scrumban под себя и разграничили зоны ответственности с проджектом.
Поначалу я тянула команду в одиночку, но годовая цель была амбициозной: не «сделать фичу», а «найти деньги». Это требовало уймы времени. Я перебрала несколько проджектов, пока не нашла ту самую — коллегу из соседней команды, недавно перешедшую в проджекты, но с огромной мотивацией. И главное — честную: она прямо говорила, чего не знает. Это заметно ускоряет переговоры и выстраивает доверие. Мы сели и начали думать.
Первым делом поделили ритуалы и зоны ответственности. Поскольку с бизнесом общаюсь я и знаю, чего хотят и заказчик, и пользователи, груминги и планирование остались за мной, а дейлики и ретро взяла на себя она. Команде чётко объяснили, к кому с чем идти: вопросы про бизнес, логику фичи, приоритеты — ко мне; организацию работы, синхронизацию и текущую операционку — к проджекту. Уже одно это сняло огромный пласт нагрузки.
Дальше взялись за дейлики. Слишком много людей, встречи затягиваются, а ребятам скучно слушать про чужие задачи. Разбили на три потока: отдельно DS (дата-аналитики, саентисты, data quality), отдельно delivery-разработка (фронты, бэки, тестировщики), отдельно discovery (дизайнер, бизнес-аналитик, системный аналитик — те, кто готовил ТЗ). Чтобы не было рассинхрона, тимлида разработки звали на дейлик DS и наоборот, а менеджеров по внедрению — везде, ведь к ним приходят пользователи. Стало легче, время освободилось, жалобы прекратились, все включены в процесс. Я уже могла не сидеть на каждом дейлике.
И наконец — доски и приоритеты. Раньше всё жило на одной доске: вроде удобно видеть статус по всем сразу, но по факту это была натяжка. Что такое этап «тестирование» для дизайнера? Когда я смотрю и отправляю на доработку? Плюс перегруженность и непонятные приоритеты. Мы разделили доски — ровно по дейликам. Как только требования к новой фиче полностью прописаны и задача уходит на последний этап в discovery, я переношу её в первый столбец delivery, на место согласно приоритету. Теперь разработчик, освободившийся раньше или ждущий чего-то от коллег, сам заходит на доску и берёт верхнюю задачу под свою компетенцию, никого не дожидаясь.
Ещё пара лайфхаков. На груминг discovery звать лида разработки и тестировщика: тестировщик — просто кладезь, столько нюансов подкидывал, что качество задач, уходящих в разработку, выросло кардинально. С дизайнером накидывать несколько вариантов и с ними бежать к фронту прикидывать трудозатраты. Логика везде одна: подключать нужных людей как можно раньше. Это работает и со смежниками — заранее прийти к финансистам и узнать их требования к защите, сделав соавторами; ещё на этапе идеи заглянуть в поддержку и понять, как им передавать; сбегать в маркетинг и выяснить их нюансы. Но это уже совсем другая история.
Загрузка...
