Cделали +300% по задачам за 2 года в ecom-проекте — кейс о менеджменте и Notion

Привет! Меня зовут Даша Суппес, я аккаунт-директор в ДАЛЕЕ, веду проекты для Haier. Расскажу, как за 2 года улучшили качество управления процессом, выросли с 1500 до 5000 часов по задачам, увеличили команду с 14 до 40 человек. Во многом благодаря выстраиванию процессов в Notion. В конце отдаю шаблон планера для проекта в Notion.

В статье будет об:

• особенностях организации работы с проектами Haier и почему было сложно использовать Jira для планирования спринтов;
• чего хотели добиться и почему выбрали Notion как дополнительный инструмент в работе;
  
• к чему это все привело.
  

С Haier мы работаем с 2020 года и на данный момент поддерживаем 6 e-com проектов. Начали сотрудничество, когда был один небольшой сайт с каталогом, затем развили его в полноценный интернет-магазин. К 2024 году команда выросла до 40 человек, которые вырабатывают около 5000 часов в месяц.

Изначальной сложностью проекта были две трекинговые системы — Jira и Redmine, которые нужно было подружить между собой, плюс увязать дополнительные инструменты управления. Процесс строился следующим образом: из клиентского Redmine забирали задачи, работа команды была в Jira. При этом в Google таблицы использовали для планирования спринтов.

Приготовьтесь, сейчас будет длинно.

• Трекинговых систем две, но прямой перелинковки между тасками не было. Из-за этого небольшой процент задач терялся и не доходил до стадии планирования. Клиенту отсутствие ссылки на наш трекер мешало понять, заведена задача в работу или еще нет. В Jira каждый раз нужно было искать таск через поисковую строку.
• Менеджеры использовали индивидуальные инструменты для заметок по текущим задачам и не всегда заносили данные в оба трекера. Часто это были личные документы, ежедневники. Процесс по обработке задач был не прозрачный для руководителя, адекватно оценить загрузку менеджера было сложно.
  

• Ни один трекер не позволял в необходимом виде создать спринт, поэтому приходилось планировать задачи в Excel, то есть создавать третью систему с ручным управлением.

• Не было единого процесса обработки и регулярного контроля задач, приоритизации, отсутствовало SLA.

Очевидно, что подобные решения приводили к потере информации в задачах, частичным срывам сроков и соответствующей обратной связи от клиента. В команде тоже были сложности: менеджеры жаловались на высокую загрузку, так как также не всегда понимали объем и актуализировали задачи по принципу «что ярче горит».

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

Из-за нынешних условий и ограничений рынка, у нас не самая новая версия Jira. К тому же проект имеет ряд требований для ретроспективы, которые Jira не может обеспечить. Усугубляется проблема тем, что наши спринты достаточно «подвижны» из-за специфики e-com проекта, SLA и срочности логистических или промо-задач. Это не классический 2х-недельный спринт.

• На борде 11 статусов, задачи перетекают из одного в другой, по мере чего меняется положение карточки на борде. Отслеживать порядок задач по дедлайнам в таком формате сложно для исполнителя.

• «Подвижности» спринту добавляют внеплановые задачи по SLA: до 20% еженедельно. Поэтому сформировать и закрепить спринт без возможности редактирования мы не могли.

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

• У Haier несколько проектов в JIRA, соответственно несколько бордов, а спринт требовалось в формировать в режиме «одного окна» для клиента.

• Когда на борде 100+ задач невозможно быстро понять, что в приоритете, оценить актуальность без детального погружения в задачу.

На тот момент для планирования спринта и проведения ретроспективы оптимальным решением было использовать Google Таблицы, где мы могли гибко настроить необходимые для проекта поля.

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

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

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

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

Затем был проработан регламент обработки задач, а также мы начали «дружить» два трекера между собой через дополнительные свойства.

Задачи из Redmine на менеджеров распределяет руководитель, после PM проходятся по ним согласно регламенту:

• отписываются клиенту статус о принятии в работу;

• фиксируют задачу и дальнейшие шаги по ней в Notion;

• линкуют трекеры и приоритеты между системами;

• формируют задачу во внутреннем трекере;

• регулярно раз в неделю проходят по всем задачам и актуализируют статус.

Линковка между двумя трекерами и фиксация ссылок в Notion позволяет находить задачу в два клика из любого рабочего инструмента. Наличие ссылки в Redmine помогает клиенту понять, что задача точно находится в работе и не потеряна.

После мы внедрили SLA и приоритеты совместно с клиентом. Такой подход помог в том числе:

• структурировать процесс и сроки обработки задач по разным направлениям;

• дополнительно акцентировать внимание на более высоких приоритетах;

• адекватно оценивать объем задач в разных приоритетах и планировать их в спринты;

• регулярно проводить актуализацию статусов задач.

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

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

Когда мы таким образом собрали в Notion все задачи проекта, стало очевидно, что планирование спринтов тоже удобно будет перенести туда. Раньше у каждого менеджера в Google Docs на это уходило до полутора часов: нужно было собрать план из ста с лишним строк в экселе.

Теперь менеджер тратит около 30 минут на сбор спринта. Привязать задачу к спринту можно в один клик: она автоматически подгрузится в нужную вкладку. На странице спринта можно быстро увидеть следующие показатели:

• объем спринта

• исполнителей

• план/факт,

• дедлайны

• прогресс
• приоритеты и порядок реализации для исполнителя в рамках спринта.

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

Самое важное и полезное для нас в Notion

1. Простота и удобство контроля. Менеджеры видят все свои задачи в едином окне с актуальными статусами, дальнейшими шагами, приоритетом, прогрессом выполнения, исполнителями, оценками. Оттуда же можно перейти в клиентский Redmine или Jira, если нужна дополнительная информация или коммуникация с исполнителем/клиентом.

2. Notion позволяет соединить все наши 6 e-com проектов и задачи по ним в одном инструменте, и при этом быстро управлять фильтрацией и видеть нужную информацию.
   

3. Руководитель всегда видит нагрузку каждого специалиста и в случае перегруза может перераспределить ее за 5 минут.

4. Таски из бэклога в отдельным разделе, мы их не теряем, всегда учитываем при планировании.

5. Планировать спринт теперь можно очень быстро: в нужном столбце проставляем желаемый спринт и задачи появляются в нужной вкладке.

6. Внеплановые задачи по SLA тоже фиксируются. Их мы учитываем в общей статистике в ретроспективе, что очень важно для понимания нагрузки спринта.

7. Разработчики используют вкладки спринтов и быстро фильтруют задачи по себе, приоритетам, датам.

8. В несколько кликов задачи можно вывести в новые форматы отображения по необходимым параметрам: канбан доску по приоритетам, график Ганта по срокам, отдельные доски по разным проектам и тд. Настройки Notion максимально гибкие, подходят практически для любых целей.

Нам удалось настроить Notion под себя, под свои бизнес-процессы. А не пытаться адаптироваться к готовому жесткому инструменту, доработки которого требуют времени и денег.

• Процесс стал понятным и прозрачным для всех: видны комментарии по задачам, даты следующего шага или просто плана, ответственного.

• Если что-то не обработано вовремя, мы обращаем внимание на это благодаря статусам и комментариям, а не потому что клиент напомнил.

• Клиента устраивает система работы, обратная связь и отношения улучшились.

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

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

Наш тг-канал: @daleedigital. Тут бывают новости, полезности для работы, вакансии и другой диджитал-движ.

Сайт: dalee.ru