Привет! Меня зовут Катя. Я — менеджер проектов в компании Constanta и сегодня хочу с вами поделиться, как важно выстраивать новые процессы постепенно, не разрушая их до основания.

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

Я отвечаю за мобильные платформы одной из крупнейших букмекерских компаний в России, а именно за мобильные приложения — iOS (iPhone, iPad, Apple Watch), Android (смартфоны и планшеты) и мобильный сайт. А также еще за пару дополнительных приложений, косвенно относящихся к основному продукту.

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

Дополнительная особенность в том, что приложение ориентировано не только на российский рынок, но и на рынки стран СНГ: общее количество, где мы присутствуем — 9 стран. По этой причине у нас много заказчиков и задач, связанных с законами других государств. Например, отдельные предупреждения об окончании срока действия документов, отображение и расчёт налогов на выигрыш, разная логика и уровни идентификации пользователей и много других мелочей, которые отличаются от страны к стране.

Впечатляет? Меня лично да.

А сейчас давайте попробуем решить задачу как на уроке математики.

Дано: большая команда, состоящая из дизайнеров, разработчиков трех платформ (Frontend, Android и iOS) и QA. До моего прихода эту команду вела ПМ, она же QA лид, она же единственный SA. У каждой команды разработки свой проект в джире (это 3 проекта). У дизайнеров — свой проект (+1), у команды тестирования и менеджера — свой (+1).

Итого: 5 проектов в джире. В проектах разработки были спринты и менеджер каждые 2 недели перетаскивал задачи из одного спринта в другой по причине появления более срочных задач на постоянной основе.

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

В конце вас ожидает квест — понять, все ли баги поправили, что пойдет в релиз и прошла ли задача дизайн-ревью, так как линковка между задачами осуществлялась в основном менеджером.

Бонус 1: В проекте около 10-13 внешних заказчиков (на период моего прихода): менеджеры стран, backend, акционеры, букмекеры, маркетинг, СЕО, команда саппорта, внутренние задачи и многие другие.

Бонус 2: Backend реализуется другой дочерней компанией, с которой мы плотно коммуницируем, но у них своя команда, устои и процессы.

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

Найти: слабые места

Дано мы рассмотрели, каким же будет решение? Что нам нужно сделать, чтобы для команды наши действия были безболезненными?

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

И получается, что команду оставлять без менеджера нельзя. Ни в отпуск сходить, ни заболеть, ни глазом моргнуть. А ещё менеджер всех тормозит, потому что в сутках всего 24 часа.

Вводных данных нам хватает, перейдем к решению:

1. Наводим порядок в джире
   

   1. Избавляемся от спринтов и переходим к канбан методологии. Если приходится постоянно перетягивать задачи из спринта в спринт, значит что-то идёт не так. Поскольку в проекте много внешних заказчиков и приоритет может поменяться по щелчку, то спринты нам не подходят. Нужна более гибкая схема.

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

   3. Вводим поле “Приоритет”. Тут важно понимать свой продукт и срочность задач от всех стейкхолдеров, чтобы принимать решения по тому, какие именно задачи пойдут в следующий релиз.

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

   5. Схлопываем все проекты в один. В пяти проектах работать и не запутаться — очень сложно. Давайте не усложнять себе жизнь? :)

   6. Вводим поле “Компонент”. Раз все задачи в одном проекте, то как определить, к какой платформе задача или бага? Вводим компонент и завязываемся на него. Дополнительно, у задач в начале названия прописываем краткую аббревиатуру платформы.

   7. Четкий флоу задач. Команда должна понимать, как движется задача и куда её передавать после реализации своей работы. Таким образом, задачи не будут застревать и теряться, а менеджеру не придётся следить за каждой таской и пинговать на каждом этапе.

2. Структурируем каналы в слаке. Необходимо структурировать коммуникации, чтобы это не было одним большим полотном обсуждений всех задач подряд. Особенно важно, если коммуникации в Telegram, а не в Slack с тредами. Распределяем по направлениям - платформы (MobSite, IOS, Android), команды (SA, Design, QA), страны (Россия, Греция, Кипр), отделы (маркетинг, контент и т. д.), объёмные продуктовые фичи (навигация, поиск).

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

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

5. Ретро и постоянная обратная связь. Нужны встречи по докрутке процессов, где команда будет обсуждать, предлагать и аргументировать те или иные подходы. Это помогает сплотить команду и процессы, которые будут выстраиваться — решения всех, а не тоталитарного менеджера с девизом “Я знаю, как вам лучше”.

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

Базовые постулаты, которые всегда будут в почёте:

1. Слушать и слышать команду. Если команда жалуется на слишком большое количество встреч, попробуйте совместно прийти к тому варианту, который будет устраивать всех. Если они просят выделить время на важный им рефакторинг — пойдите им навстречу.

2. Помощь. Нужно всегда устранять преграды и проблемы на пути реализации задач. Стоит повторять и спрашивать “Всё ли в порядке и нет ли трудностей или вопросов? Если они возникнут, пингуй, разберёмся”. Тем самым менеджер даёт понять команде, что всегда поможет и разрулит любые вопросы.

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

4. Свобода. Без доверия друг к другу очень сложно построить гармоничную команду. ПМу нужно уметь отпускать микроменеджмент и доверять своей команде. Порой будут ошибки, но мы на них учимся! Намного приятнее работать в коллективе, где не требуют ежедневных отчетов, а ценят результат.

5. Честность. Не нужно врать своей команде. Порой реальность жестока и хочется уберечь их от бюрократических решений, на которые вы повлиять не в силах. Наберитесь смелости и скажите правду.

Теперь давайте посмотрим, что же по итогу получилось у меня с процессами и общими нашими результатами за год?

1. Количество минусов, озвученных на первом ретро, уменьшилось на 55%

2. Количество плюсов увеличилось на 46%

3. Основали отдел системного анализа и начали работать над документацией проекта

4. Команда выросла на 6 человек

5. За год мы выпустили 260 релизов (общее количество со всех моб.платформ)

6. Успешно запустились в 4х странах

7. Завели 4520 задач, из которых 3834 - реализовали (84%)

8. Вышли в 2 магазина приложений Android

За второй год работы:

1. Команда выросла еще на 8 человек

2. За год мы запустили 246 релизов (общее количество со всех моб.платформ)

3. Успешно запустились еще в 3х странах

4. Завели 4875 задач, из которых 4337 - реализовали (89%)

5. Вышли еще в 4 магазина приложений Android

А самое главное достижение — команда стала автономной без участия менеджера на каждом шагу.

На этом у меня всё, надеюсь, моя статья будет полезна и поможет кому-то улучшить процессы в команде. Традиционно желаю всем классных проектов!