# Получение задач
# Описание
Процесс, в результате которого у команды появляются задачи, над которыми она работает.
На чем делают фокус:
- Люди, которые ставят задачи команде
- Люди, ставящие задачи конечным исполнителям
- Необходимые условия для получения задачи в команду
- Процесс внутренней подготовки задачи к реализации
# Почему ветка важна?
Прозрачный для заказчиков и исполнителей процесс позволяет эффективно выполнять именно те задачи, которые решают проблему. Хорошо выстроенный процесс позволяет:
Тимлиду:
- Прогнозировать загрузку и сроки выполнения прилетающих задач
- Предоставить понятный интерфейс получения задач для заказчиков
- Уменьшить простой исполнителей
Исполнителям:
- Фокусироваться непосредственно на решении задач
# Что будет, если её не делать?
Непроработанный процесс получения задач приводит к:
- Дополнительным раундам уточнения цели задачи
- Исполнители неправильно понимают проблему заказчика. Результат не решает проблему
- У исполнителей появляется больше одного постановщика задач. Необходимо приоритезировать задачи не только внутри бэклога, но и между ними
- Начало реализации откладывается, так как не выполнены все предусловия
# На кого может быть делегирована?
На проектного менеджера, линейного тимлида
# Примеры поведения
# Примеры плохого поведения
- Конечный исполнитель переключается между несколькими бэклогами.
- Заказчик общается напрямую с разработчиками, продавливает сроки.
- Исполнители простаивают, потому что задачи в бэклоги не готовы.
- Заказчики не понимают когда будет сделана та, или иная задача.
- Появляются значительные переработки из-за многократного уточнения условий задачи.
- Излишний формализм в постановке задачи не позволяет понять цель её выполнения.
# Примеры хорошего поведения
- Роли чётко определены, всем участникам понятен процесс постановки задач в команду.
- Исполнители понимают не только что надо сделать, но и зачем.
- Простои и переработки минимальны.
# Способы прокачки
# Практика
Следующий алгоритм поможет настроить процесс получения задач в команду
- Необходимо понимать кто является заказчиками и стейкхолдерами задач, выполняемых командой. Необходимо прояснить ожидания от команды, а также её ответственности
- Надо сформулировать интерфейс взаимодействия заказчика с командой. Обеим сторонам должно быть понятно в каком виде прилетают требования заказчика. В некоторых случаях это общее описание проблемы с пользовательскими кейсами, сформированные при помощи лида или системного аналитика. В других – согласованное ТЗ с макетами. Аналогично происходит со сроками: или они гибкие и оценка команды согласуется с заказчиком, или дедлайны опускаются сверху.
- Формируется процесс изменения требований заказчиком. Возможны ли правки? Если возможны, то на каком этапе?
Эти пункты важны для выбора методологии разработки. Обычно она выбирается исходя из необходимости действовать гибко.
Проблемы, с которыми можно столкнуться, и возможные решения:
- Заказчик опускает скоуп и сроки
- Можно пожертвовать расширяемостью решения. Но надо понимать, что это локальная оптимизация времени, которая приведёт к большим срокам на дистанции
- Во время приёмки задачи становится ясно, что решение не закрывает проблему заказчика
- Потеря знания о проблеме происходит на одном из этапов: формулирования проблемы заказчиком или превращения требований в задачи исполнителей. Обычно ретроспективно удаётся локализовать потерю этих знаний