К команде дизайнеров в RoboFinance я присоединилась чуть больше 3 месяцев назад в роли pm. Только-только провела встречу по завершению испытательного срока. Хочу и с тобой, Хабр, поделиться результатами, трудностями и решениями, которые были приняты нашей командой. Приступим!
Как я попала в команду писала тут. Счастливая и заряженная на новый опыт, я приступила к знакомству с командой: тимлид, 5 продуктовых и 6 маркетинговых дизайнеров. С каждым провела встречу one-on-one, от 20 минут до 1,5 часов! Знакомились, шутили и плавно переходили к рабочим вопросам. Акцент сделала на следующих:
Какие у тебя есть ожидания от роли pm? Как я смогу помочь конкретно тебе?
Какие проблемы в процессах в команде существуют?
Чего, по-твоему, не хватает в работе/команде?
Цель вопросов — выяснить, какие проблемы существуют, что больше всего беспокоит и как я могу помочь с этим справиться. После знакомства с командой и всеми заказчиками (а их около 20), у меня в голове было что-то типо этого 🤯.
Основные моменты, которые я выделила:
Команда дизайнеров — сервисная.
Одна команда на все продукты, а их около 20. Работает недельными спринтами (5 дней) — наследие от работы с командой разработки, с которой была разъединена (правда зачем продолжают так работать — не понятно ?). Теперь команда находится в отдельном департаменте.Боль команды — неточное планирование. Практически его отсутствие.
Источник неудовлетворенности был очевиден, и он очень раздражал всю команду.
Именно с этими исходными данными и началась моя pm-ская работа.
Революций совершать не стали: все, что нравится (спринты) — оставили, а то, что является болью — решили потихонечку менять).
Начали с
ограничения количества задач, которые берем в спринт
Задачи оцениваются командой в story points (далее sp), максимальное количество на каждого — 16 sp.
Теперь же можно было набирать себе задачек только на 13 sp, а остальное на буфер (увы, срочные задачи неизбежны в спринте).
Закон Литтла — среднее время ожидания обслуживания в системе равно отношению средней длины очереди к средней скорости обработки.
Иначе говоря, чем больше у нас задач в процессе, тем дольше будет каждая задача находиться в работе и тем хуже будет пропускная способность.
Уменьшив количество задач, мы нацелились на увеличение производительности
Далее, так как срочные задачи зачастую прилетают именно маркетинговым дизайнерам:
ввели свимлайн “firestripe”
Чтобы не управлять людьми для решения asap задач, а дать команде общую визуализацию происходящего, мы решили выделить “отдельную полосу” под такие срочные задачи. Это отдельная полоса появилась только на доске маркетинга. Теперь, срочные задачи сразу видны и выделены!
свимлайн “firestripe” ввели дополнительные доски для продуктовых и маркетинговых дизайнеров
Ранее ребята пользовались одной общей доской в Jira. Просто представьте: 11 человек, у каждого по 7-9 задач, и все это на одной доске! Да, были фильтры по именам дизайнеров, чтобы включить только свои задачи, но тогда не было видно, сколько задач внутри малой группы (продуктовой и маркетинговой).
Дополнительные доски позволили нам лучше структурировать задачи, а также сделать общую доску более читаемой. Кроме того, так мы сместили акцент на командную работу. Вуаля)настроили Structure в Jira
Ранее не все задачи, которые ставились на команду дизайнеров, попадали в structure. Она заполнялась лишь в рамках PMP перед началом квартала и лежала без дела.
Теперь же абсолютно все задачи на нашу команду попадают в structure. Даже если задача у заказчика в собственном эпике, по полю components, она подтягивается к нам в определенный Epic (эпики названы по продуктам).
Structure в Jira Работа с заказчиками тоже была проделана, как без этого) К каждому приходила и спрашивала: “Какие задачи планируются? А давайте внесем в структуру? И вам хорошо - время бронируем, и нам - планирование наше всё🤝”
То есть теперь и исполнителям стало видно, какая работа планируется, что позволяет не только раньше и глубже погружаться в контекст задач, но и является пререквизитом для возможного участия сервисной команды в этом подготовительном "Discovery" этапе.создали дашборд аналитики команды.
Я, как человек с инженерным образованием, нуждалась в цифрах и данных. Как без этого!? И мы создали его!
Например, тимлид ежемесячно заполняла таблицу по продуктам аллокации и каждому дизайнеру в %, чисто по списку задач в Jira было довольно сложно сделать. Теперь же на платформе Power Вi у нас целых два отчета, которые помогают это сделать в 2 клика.
отчет в Power Вi Согласитесь, работа часто является чёрным ящиком на каком-то этапе, т.к. хз какой именно системе правил она подчиняется. И для того чтобы постоянно сокращать эту неопределённость, всю работу и её результаты стоит циклически классифицировать и замерять в разрезе выявленных категорий. Это много полезного приносит. Например, чётко вычленив определённый тип работ, затем замерив его и наложив ограничение на количество выполняемой работы (стабилизировав систему) такого типа, можно выявить период в какой выполняется значительная часть такого плана работы. В этот момент можно начать отказываться от оценок такого рода задач, потому что опираться уже будем на достоверную статистику. Звучит амбициозно! Но реализуемо, будем работать над этим)
2 отчет в Power Вi В планах еще Диаграмму управления с Jira перетащить в Power Вi, добавив возможность фильтрации по продуктам. Тогда и Cycle Time соберем по каждому продукту, и попробуем отследить закономерности, которые пока не замечаем. В общем, потенциал велик! А так как отчеты - это рабочий инструмент и даже не pm, а скорее уже Delivery Manager, то я за них борюсь и пока побеждаю🙃
И, наконец, последнее изменение, которое касается не только команды дизайна, но и заказчиков:
введен новый статус и настроены оповещения в Slack
Было 5 статусов: это new, analytics, in progress, in review и done.
было Тут была выявлена проблема - заказчики (т.е. авторы задач) зачастую не приходили до конца спринта за задачами или приходили уже в пятницу с большими правками по задачам, и команда просто не успевала в рамках спринта их отработать. То ли потому что оповещения приходили на почту, а она в основном у всех переполнена, или потому что не очень нужна была сама задача ?? Поэтому было принято решение ввести дополнительный статус “ready” между статусами “in review” и “done”, а также настроить оповещение авторам задач в Slack о том, что задача выполнена и ждет проверки.
стало Таким образом мы постарались уменьшить риск невозврата заказчика. И это сработало!
Ниже на Диаграмме управления видно, что задачи стали закрываться в рамках спринта (не превышает 5 дней) после введения изменения (19 марта).
результаты 6 изменения Наглядно? Точно да! Круто ли? Судя по обратной связи от команды - тоже да. Теперь не нужно приходить к каждому заказчику в личку и просить проверить, а после закрыть задачу. Теперь это происходит автоматически.
Сейчас, когда все изменения уже введены и получены результаты, кажется, что они были такими очевидными. Они лежали на поверхности!...Но нет, каждое давалось нелегко, над каждым приходилось покорпеть: нагенерить решения, выбрать подходящие, взвесить все за и против, предложить команде, получить одобрение (иногда очень неуверенное) и сделать это. Примерно такой путь был проделан с каждым, абсолютно каждым нововведением.
А теперь, предлагаю приступить к финалу - результатам. Чего же мы достигли и к чему пришли?
Здесь барабанная дробь….
Все это привело к росту производительности! И к какому: + 43%!
Ниже на графике пропускной способности видно, что после введения изменений (красная черта) пропускная способность выросла. Если в начале года она составляла в среднем 31 задачу, то после введения изменений выросла до 44 задач!
Для удобства над каждым столбцом (спринтом) подписано количество задач, выполненных в спринт
И производительность стала более прогнозируемой, отмечен тренд на уменьшение. Смотрите сами.
Всё та же Диаграмма управления, только теперь обратите внимание на красную линию - среднюю продолжительность выполнения задач и синюю - скользящую среднюю. В начале года последняя находится выше красной в пределах 2 дней, но в итоге опускается ниже средней основной (красной).
Тренд на уменьшение очевидный. Остается только привести этот показатель (средняя продолжительность выполнения задачи) к более точному - по каждому продукту. Так как продукты в компании разные, задачи разной сложности и единого ответа просто не может быть. Но я, конечно, очень скромно назвала что, только это осталось😬
Вот такие у нас получились результаты. Дружной и слаженной команды!
Мы не собираемся останавливаться, будем продолжать собирать аналитику. Ведь работа сама себя не сделает еще более комфортной)
Жду ваших комментариев по теме =)
P.S. Спасибо за мудрые советы и поддержку моей старшей сестре - Крестине Анохиной (senior, PMM) и наставнику с getmentor - Станиславу Мельникову. Они не просто мне помогли разобраться во всем и не потонуть в этом объеме информации, но и достичь этих результатов вместе с командой.
