Автор: Николай Мякишев, Project Manager в компании 05.ru @Quesyx

Всем привет! Зовут меня Николай, я Project manager в компании 05.ru. В этой статье я расскажу о своём опыте решения проблем в управлении задачами, о сложностях, с которыми столкнулся, и о том, какие вопросы возникали при внедрении нового подхода к учёту и измерению длительности выполнения задач.

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

Начнём с основного: что же такое тип задачи и зачем он нужен.

Тип задачи — это категоризация работ по источникам возникновения и особенностям реализации.

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

Этапы внедрения типов рабочих элементов

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

источник возникновения задачи;
особенности её реализации;
примерная интенсивность и длительность выполнения (если это известно).

На встрече расскажите про существующие базовые типы и договоритесь, какие будете использовать. Возможно, кто-нибудь предложит что-то новое.

Определение участников процесса

Решите, кто должен участвовать в обсуждении (источники возникновения задач). Вот основные роли:

Продукт-менеджер

Обычно предлагает тип задачи исходя из бизнес-ценности, срочности и стратегического фокуса. Например, это может быть **new feature, feature improvements или bug.

Тим/Техлид

Может предлагать типы задач с технической точки зрения, например, разделение на bug, refactoring, research

Тестировщик или другие участники команды

Могут предлагать типы задач, улучшающие качество продукта, такие как bug или testcase.

Базовые типы

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

1. New feature. Новая функциональность в системе или возможные изменения в архитектуре.

2. Feature improvements. Улучшения или исправления существующей функциональности без значительных архитектурных изменений.

3. Testcase. Задача, связанная с описанием конкретных сценариев в тестировании.

4. Bug. Дефекты, выявленные при тестировании.

Затем вспомните и определите интенсивность запросов по каждому типу и примерную длительность выполнения.

Допустим, у вас получилась вот такая таблица:

На текущий момент в моём продукте выявлено дополнительно:

Инфраструктура, Документация, Исследование, Техдолг, Cross-platform, Декомпозиция, Улучшение процессов.

По мере проработки этих типов у вас возникнет много вопросов, как корректно считать эти типы, какой процесс выстроить.

Cохранение целостности запроса и упрощение управления

Декомпозированные задачи лучше учитывать в рамках одного типа new feature.

1 in → 1 out

Пример:

Если у нас есть продуктовая задача, которая требует выполнения нескольких разных подзадач, то для её завершения разработчикам может понадобиться создать 2-4 отдельных подзапроса. Однако мы учитываем только один запрос, потому что для нас важно выполнение именно требований продуктовой задачи. То есть, независимо от количества задач, которые необходимо сделать разработчикам, запрос считается выполненным только тогда, когда все требования продуктовой задачи закрыты.

Важно понимать, что все типы работ взаимосвязаны. Например, мы не можем считать запрос завершённым, если выполнена только часть задач на бэкенде, но не реализован интерфейс (UI). Все части должны быть готовы, чтобы продуктовая задача была полностью закрыта.

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

Разделение классификации рабочих элементов на типы работ

Заказчик продукта должен понимать, работой какого типа можно выполнить задачу конкретного типа за n времени. Например, мы выводим три типа работ: front, Android и iOS, потому что они являются последним и ключевым звеном, когда пользователь может пощупать продукт. То есть мы считаем работу законченной, когда выполнены работы одного из этих типов.

Таким образом, мы считаем типы задач отдельно по каждой платформе, а не вместе.

Итого:

1. new feature с типами работ (backend, frontend);

2. new feature с типами работ (backend, iOS);

3. new feature с типами работ (backend, Android).

Кросс-платформенный запрос

Эта задача включает в себя три типа работ: backend, front и mobile. Она считается выполненной в том случае, если закрыты все три типа работ, чтобы можно было в целом посчитать, за какой период времени мы можем завершить такую задачу.

Я использую иерархию задач: одна родительская и три дочерние. Когда закрыты все три дочерние, закрывается и родительская, и после этого задача считается выполненной.

Объяснение типов на фигурах (пальцах)

Давайте представим, что типы задач — это квадрат с фигурными отверстиями, и когда все фигуры сложены, мы считаем элемент завершённым:

ромб — backend;
круг — frontend;
треугольник — mobile.

Разделим их на три квадрата.

Расчёт длительности

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

Управление потоками задач: от обязательства до закрытия в процессе доставки —

Теперь поговорим о том, как считать time-to-market и lead time в разных типах запросов. Пока на данный момент upstream не построен, мы считаем только Т2М и lead time разработки.

В команду доставки с продуктовой доски поступает три типа запросов, остальные типы создаются непосредственно в downstream. Каждый класс запросов хранит в себе разные типы работ:

Cross platform feature хранит mobile, backend и frontend.
New feature хранит backend и front или backend и mobile.
Feature improvements может хранить в себе разные типы.

Визуализация процесса:

В нашем случае, когда задача переходит в статус «Replenishment meet», мы передаем её разработчикам для ознакомления. Если у них возникают вопросы, они задают их на встрече. Если есть препятствия или нужно что-то уточнить в описании задачи, то обсуждение может проходить асинхронно, без проведения встречи. Когда все вопросы закрыты, задача переходит в статус «Ready for develop», после чего команда берёт на себя обязательство и мы создаём задачу с названием «delivery request» в downstream, выбираем тип и связываем с задачей на продуктовой доске и присваиваем статус «ToDo». Здесь я применяю паттерн разделение-слияние: когда все типы работ закрыты на продуктовой доске, мы переводим такую задачу в статус «closed».

По задаче с продуктовой доски мы считаем T2M, а по задаче в downstream — lead time.

Пилотный запуск

Всё это дело я запускал параллельно со стандартным процессом оценки задач. На сегодняшний день я прогнал на своём небольшом проекте пилот и получил такую статистику. Данные пока не совсем корректные, потому что через систему прошло не так много задач.

Масштабирование

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

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

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

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

Пользовательская точка зрения:

Это новая фича, так как ранее незарегистрированные пользователи не могли сохранять товары в корзине.

Техническая точка зрения:

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

В данном случае в нашей системе мы должны определить этот тип как «доработка фичи», потому что уже есть подобная функциональность, связанная с корзиной.

Полученный опыт позволил мне находить общий язык с командами, убедив их, что новые подходы не только помогут в текущих проектах, но и станут «базой» для более эффективной работы в долгосрочной перспективе.

Ну и также хочу добавить, что основным подспорьем в данном случае были проведённые митапы на эту тему, что развеяло у команды сомнения «а нужна ли нам эта штука?»

Литература

1. Алексей Пименов, Канбан метод.

2. Дэвид Дж. Андерсон, Канбан. Альтернативный путь в agile.

Классификация задач в проектах: Зачем и как внедрять типы рабочих элементов