Как пересобрать проектные процессы и сделать разработку эффективнее

Одно из золотых правил продуктовой разработки сформулировал Джефф Безос: «Эффективную команду можно накормить двумя пиццами». На практике это означает, что в ее составе должно быть 7-8 человек. Размер команды напрямую влияет на эффективность каждого участника и проекта в целом. Вышли за 10 человек – нужно создавать отдельную группу с отдельным управлением.

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

Что именно пошло не так

С ростом людей рос объем коммуникаций внутри команды. С одной стороны, логично – людей стало больше, значит, им нужно больше общаться. При подсчете временные затраты на коммуникации были в несколько раз больше, чем планировалось.

В True Engineering есть негласная метрика: минимум 85% времени сотрудники работают над неким продуктивным результатом, 15% могут посвятить чему-то проходному. Например, участвовать в планировании, митингах, ретроспективах, синхронизации. Пока управление проекта и прочие поддерживающие процессы укладываются в 15% рабочего времени, все в порядке. Как только этот показатель начинает расти, появляются вопросы.

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

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

Шаг №1: фокусировка на приоритетах

Когда в команде 10 человек, это одна емкость и количество задач в спринте. Когда в команде 30 человек, это совершенно другие объемы. Неделимый командный спринт содержал до 1,5 сотен задач. При этом задачи относились к разным потокам разработки со своей градацией приоритетов. Управлять таким бэклогом «визуально» очень трудно, и это приводит к потере управляемости.

Решение: мы разделили команду в TFS на 3 направления и по каждому в спринте получили свой двухнедельный бэклог с 20-50 задачами в каждой. Теперь в каждой «микрокоманде» визуально видны и локальные приоритеты, и динамика разработки, и проблемы. При этом процессы планирования и релизного менеджмента остались неделимыми.

Шаг №2: коммуникации в команде – убрать лишнее

Если на старте проекта, когда в команде было 10 человек, дейли занимало около 15 минут в день, то через пару лет в сумме по команде стало уходить до 30 рабочих часов в день.

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

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

А обсуждение некоторых тем по проекту перевели в формат целевых чатов Teams – об этом дальше. 

Шаг №3: каналы коммуникаций – оставляем только нужные

За годы развития проекта команда выстроила несколько параллельных каналов коммуникации: Slack, Skype, наш Teams, Teams заказчика, почта. Отовсюду на менеджера и команду сыпалась информация, а отделить важные вопросы от второстепенных становилось все сложнее.

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

Решение: свели внутренние коммуникации к двум основным каналам: Teams и почта, плюс фоном Teams заказчика.

Формализовали правила работы с этими каналами. Это позволяет каждому члену команды понимать, что пишут в конкретный канал и как на это реагировать. Параллельно ведем переговоры с заказчиком, чтобы привести коммуникации в его Teams к такому же формату: чаты должны быть конкретными, решать конечную задачу и содержать только нужных участников, а вот процессные активности обсуждать в нескольких формализованных каналах с участием нашего менеджера.

Главная идея изменений – любая коммуникация, внешняя или внутренняя, должна быть управляемой.

Шаг №4: общепроектная информация – доступная и единая для всех

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

Это приводило еще к одной проблеме – разные специалисты владели разной информацией, так что и единой неизменной картины не получалось. Это создавало дезориентацию и могло приводить к конфликтам.

Решение: создали единую систему координат на основе трекера TFS. Именно там теперь лежит вся (!) информация по проекту, емкость команды, отпуска и отгулы, оценки и статусы, база знаний проекта, спринты, релизы и проч. Заводить эксельки и прочие сторонние документы категорически нельзя. Даже выгрузки для заказчика в Excel делаются из OLAP-куба на данных TFS.

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

Что имеем в итоге

Изменения запущены два месяца назад, но уже сейчас есть ощутимые результаты.

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

2. Найти нужную информацию стало проще, и она гарантированно достоверна. Для этого мы используем как стандартные представления TFS, так и множество графиков процессного мониторинга. Не нужно назначать встречи держателям ценных знаний. Если нужно что-то актуализировать, обновлять приходится только один ресурс. Заказчик тоже может в любой момент увидеть актуальный статус проекта.

3. Команду не отвлекают десятки уведомлений по всем возможным темам, людям проще сосредоточиться, все работают исключительно с трекером и не думают, куда написать, чтобы разобраться с тем или иным вопросом.

Конечно, и в этих процессах иногда приходится созвониться и что-то уточнить. Но это разовые кейсы, и они не носят такого массового характера. Недостаток же личного общения планируем закрывать внедрением регулярных one-to-one встреч и командных ретроспектив.