К команде дизайнеров в RoboFinance я присоединилась чуть больше 3 месяцев назад в роли pm. Только-только провела встречу по завершению испытательного срока. Хочу и с тобой, Хабр, поделиться результатами, трудностями и решениями, которые были приняты нашей командой. Приступим!

Как я попала в команду писала тут. Счастливая и заряженная на новый опыт, я приступила к знакомству с командой: тимлид, 5 продуктовых и 6 маркетинговых дизайнеров. С каждым провела встречу one-on-one, от 20 минут до 1,5 часов! Знакомились, шутили и плавно переходили к рабочим вопросам. Акцент сделала на следующих:

• Какие у тебя есть ожидания от роли pm? Как я смогу помочь конкретно тебе?

• Какие проблемы в процессах в команде существуют?

• Чего, по-твоему, не хватает в работе/команде?

Цель вопросов — выяснить, какие проблемы существуют, что больше всего беспокоит и как я могу помочь с этим справиться. После знакомства с командой и всеми заказчиками (а их около 20), у меня в голове было что-то типо этого ?.
Основные моменты, которые я выделила:

1. Команда дизайнеров — сервисная.
   Одна команда на все продукты, а их около 20. Работает недельными спринтами (5 дней) — наследие от работы с командой разработки, с которой была разъединена (правда зачем продолжают так работать — не понятно ?). Теперь команда находится в отдельном департаменте.

2. Боль команды — неточное планирование. Практически его отсутствие.
   Источник неудовлетворенности был очевиден, и он очень раздражал всю команду.

Именно с этими исходными данными и началась моя pm-ская работа. 

Революций совершать не стали: все, что нравится (спринты) — оставили, а то, что является болью — решили потихонечку менять).
Начали с

1. ограничения количества задач, которые берем в спринт
   Задачи оцениваются командой в story points (далее sp), максимальное количество на каждого — 16 sp.
   Теперь же можно было набирать себе задачек только на 13 sp, а остальное на буфер (увы, срочные задачи неизбежны в спринте).

Закон Литтла — среднее время ожидания обслуживания в системе равно отношению средней длины очереди к средней скорости обработки.

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

Далее, так как срочные задачи зачастую прилетают именно маркетинговым дизайнерам:

2. ввели свимлайн “firestripe”
   Чтобы не управлять людьми для решения asap задач, а дать команде общую визуализацию происходящего, мы решили выделить “отдельную полосу” под такие срочные задачи. Это отдельная полоса появилась только на доске маркетинга. Теперь, срочные задачи сразу видны и выделены! 

   

3. ввели дополнительные доски для продуктовых и маркетинговых дизайнеров
   Ранее ребята пользовались одной общей доской в Jira. Просто представьте: 11 человек, у каждого по 7-9 задач, и все это на одной доске! Да, были фильтры по именам дизайнеров, чтобы включить только свои задачи, но тогда не было видно, сколько задач внутри малой группы (продуктовой и маркетинговой).
   Дополнительные доски позволили нам лучше структурировать задачи, а также сделать общую доску более читаемой. Кроме того, так мы сместили акцент на командную работу. Вуаля)

4. настроили Structure в Jira
   Ранее не все задачи, которые ставились на команду дизайнеров, попадали в structure. Она заполнялась лишь в рамках PMP перед началом квартала и лежала без дела.
   Теперь же абсолютно все задачи на нашу команду попадают в structure. Даже если задача у заказчика в собственном эпике, по полю components, она подтягивается к нам в определенный  Epic (эпики названы по продуктам). 

   

   Работа с заказчиками тоже была проделана, как без этого) К каждому приходила и спрашивала: “Какие задачи планируются? А давайте внесем в структуру? И вам хорошо - время бронируем, и нам - планирование наше всё?”
   То есть теперь и исполнителям стало видно, какая работа планируется, что позволяет не только раньше и глубже погружаться в контекст задач, но и является пререквизитом для возможного участия сервисной команды в этом подготовительном "Discovery" этапе.

5. создали дашборд аналитики команды.
   Я, как человек с инженерным образованием, нуждалась в цифрах и данных. Как без этого!? И мы создали его!
   Например, тимлид ежемесячно заполняла таблицу по продуктам аллокации и каждому дизайнеру в %, чисто по списку задач в Jira было довольно сложно сделать. Теперь же на платформе Power Вi у нас целых два отчета, которые помогают это сделать в 2 клика.

   

   Согласитесь, работа часто является чёрным ящиком на каком-то этапе, т.к. хз какой именно системе правил она подчиняется. И для того чтобы постоянно сокращать эту неопределённость, всю работу и её результаты стоит циклически классифицировать и замерять в разрезе выявленных категорий. Это много полезного приносит. Например, чётко вычленив определённый тип работ, затем замерив его и наложив ограничение на количество выполняемой работы (стабилизировав систему) такого типа, можно выявить период в какой выполняется значительная часть такого плана работы. В этот момент можно начать отказываться от оценок такого рода задач, потому что опираться уже будем на достоверную статистику. Звучит амбициозно! Но реализуемо, будем работать над этим)

   

   В планах еще Диаграмму управления с Jira перетащить в Power Вi, добавив возможность фильтрации по продуктам. Тогда и Cycle Time соберем по каждому продукту, и попробуем отследить закономерности, которые пока не замечаем. В общем, потенциал велик! А так как отчеты - это рабочий инструмент и даже не pm, а скорее уже Delivery Manager, то я за них борюсь и пока побеждаю?

И, наконец, последнее изменение, которое касается не только команды дизайна, но и заказчиков:

6. введен новый статус и настроены оповещения в Slack

   Было 5 статусов: это new, analytics, in progress, in review и done.

   

   Тут была выявлена проблема - заказчики (т.е. авторы задач) зачастую не приходили до конца спринта за задачами или приходили уже в пятницу с большими правками по задачам, и команда просто не успевала в рамках спринта их отработать. То ли потому что оповещения приходили на почту, а она в основном у всех переполнена, или потому что не очень нужна была сама задача ?? Поэтому было принято решение ввести дополнительный статус “ready” между статусами “in review” и “done”, а также настроить оповещение авторам задач в Slack о том, что задача выполнена и ждет проверки.

   

   Таким образом мы постарались уменьшить риск невозврата заказчика. И это сработало!
   Ниже на Диаграмме управления видно, что задачи стали закрываться в рамках спринта (не превышает 5 дней) после введения изменения (19 марта).

   

   Наглядно? Точно да! Круто ли? Судя по обратной связи от команды - тоже да. Теперь не нужно приходить к каждому заказчику в личку и просить проверить, а после закрыть задачу. Теперь это происходит автоматически.

Сейчас, когда все изменения уже введены и получены результаты, кажется, что они были такими очевидными. Они лежали на поверхности!...Но нет, каждое давалось нелегко, над каждым приходилось покорпеть: нагенерить решения, выбрать подходящие, взвесить все за и против, предложить команде, получить одобрение (иногда очень неуверенное) и сделать это. Примерно такой путь был проделан с каждым, абсолютно каждым нововведением.

А теперь, предлагаю приступить к финалу - результатам. Чего же мы достигли и к чему пришли?

Здесь барабанная дробь….

Все это привело к росту производительности! И к какому: + 43%!

Ниже на графике пропускной способности видно, что после введения изменений (красная черта) пропускная способность выросла. Если в начале года она составляла в среднем 31 задачу, то после введения изменений выросла до 44 задач!

Для удобства над каждым столбцом (спринтом) подписано количество задач, выполненных в спринт

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

Тренд на уменьшение очевидный. Остается только привести этот показатель (средняя продолжительность выполнения задачи) к более точному - по каждому продукту. Так как продукты в компании разные, задачи разной сложности и единого ответа просто не может быть. Но я, конечно, очень скромно назвала что, только это осталось?.

Вот такие у нас получились результаты. Дружной и слаженной команды!
Мы не собираемся останавливаться, будем продолжать собирать аналитику. Ведь работа сама себя не сделает еще более комфортной?

Жду ваших комментариев по теме :-)

P.S. Спасибо за мудрые советы и поддержку моей старшей сестре - Крестине Анохиной (senior, PMM) и наставнику с getmentor - Станиславу Мельникову. Они не просто мне помогли разобраться во всем и не потонуть в этом объеме информации, но и достичь этих результатов вместе с командой.