Задач на проекте много: если их не структурировать, процесс превращается в «кашу» из тасок, подзадач и эпиков. Девелоперы работают сразу по нескольким направлениям, все задачи начаты, и ни одну не удается закончить вовремя. В итоге, разработчики 70% времени занимаются всем и ничем одновременно.
Чтобы не допустить хаоса, важно не только записывать, но и расставлять приоритеты. Тогда люди успевают работать, а РМ может контролировать выполнение и вообще понимать происходящее. А еще, важно избавляться от лишних задач с низким value.
Если вы этим не занимаетесь, то скорее всего, пятую часть работы ведете абсолютно зря, ее можно было не делать, и состояние проекта не всегда будет соответствовать тому, что вы видите в Jira и статусах задач.
Три важных пункта, которые помогут упорядочить ход проекта, — это структурирование, сортировка и удаление лишних задач.
Структурируйте работу
Для заказчиков и для технических специалистов нужны разные уровни объяснения задач. Если вы покажете бизнесу задачу по устройству API, вас вряд ли поймут. Поэтому разделяйте уровни задач бизнеса и команды. Удобный для этого инструмент, работающий в большинстве случаев — это user story.
Старайтесь не делать весь проект «одним пирогом», а сдавайте по кусочкам — итеративно. Направляйте усилия на получение рабочего продукта с каждой поставкой.
Проводите локальное планирование спринта-шага на основе технических задач. Если уже появилась «каша» из тасок, лучше перепланировать спринты и переделать задачи так, чтобы их можно было контролировать.
И конечно, отдельная вещь, которая помогает справиться с процессами почти во всех проектах — это практики сортировки.
Сортируйте задачи
Этот этап нужен, чтобы не заниматься лишней работой, всегда приносить максимальную ценность в проект. Для удобства работы с задачами и достижения измеримого результата, важны три фактора: уточнение задач, деление/объединение и ранжирование.
Уточняем
Часто бывает, и думаю многие РМ-ы уже видели это на практике, что в процессе работы над проектом, задачи и потребности меняются. Люди могли думать одно, а потом додумали это глубже или посмотрели с другой стороны.
Причем, иногда изменения задач происходят не тогда, когда вы обсуждаете требования, а через месяц после создания дизайн макета. Люди могли впервые по настоящему вникнуть в суть проекта только на этом этапе. Тут-то заказчику и приходят в голову дополнительные, по-настоящему важные мысли.
Поэтому не факт, что требования, которые появились довольно давно — это то, что нужно. Если РМ систематически не уточняет задачи, позже можно столкнуться с ситуацией, когда заказчик говорит: «Я же хотел другое», — а вы объективно не в курсе и недоумеваете как такое получилось.
Делим/Объединяем
Нелогично рассортированное всегда можно объединить, поделить, пересортировать. Есть понятные задачи, например, разработать страницу авторизации. Такую задачу просто разбить на технические и нетехнические составляющие, легко выполнить и закрыть.
А бывают задачи непонятные, например, сделать систему тендеров. Половина сайта — система тендеров, и неясно, как такой запрос решать. Поэтому, такую работу нужно предварительно разделить на более мелкие кусочки.
Вообще как показывает практика, поделить можно почти все. Важно только понимать зачем делим и что будем с этими частями делать.
Ранжируем
После уточнения и структурирования, остается только отранжировать. Для этого оцените каждую задачу по двум параметрам: «польза» и «количество усилий». Цель ранжирования — выразить в каких-то единицах измерения, какую пользу для проекта приносит задача и сколько усилий понадобится для выполнения. Не важно, какими единицами орудовать, будь то часы или story points, также как и всем выражать приоритет от 1 до 5.
Затем расставляем поочередно:
- нетрудоемкие задачи с самым большим value ставим вперед;
- посложнее, но с таким же value — чуть ниже;
- самые тяжелые, трудоемкие и наименее ценные задачи попадут в конец списка.
Будет проще всего выстроить список по убыванию, если «ценность-приоритет» разделить на «оценку-трудоемкость».
Приоритизацию лучше делать вместе с заказчиком: связались, предложили вариант, обсудили, согласовали.
Если у вас живой scrum, и заказчик либо его product owner присутствует в спринтах, скорее всего, в задачах будет порядок, потому что в scrum заказчик обычно сам менеджерит проект. А бесконтрольные ситуации чаще случаются там, где есть какой-то Fixed Price и не очень значительные суммы.
Не делайте лишнего
Задача РМ-а — навести порядок в проекте любым удобным способом. Если работа спланирована плохо и это приводит к потерям, лишним коммуникациям, остановкам, перезапускам, то наверное, стоило бы проект переделать.
Независимо от того, что говорит заказчик, и какое психологическое давление оказывают на менеджера и компанию подрядчика, всегда можно практически без последствий сделать несколько вещей:
- Убрать пятую часть объема работы по проекту. Всегда есть задачи, которые на самом деле на нужны, а что-то можно сделать с меньшими усилиями или вернуться к задаче уже после MVP в первой версии.
- Переформатировать весь проект: пересортировать этапы, итерации, майлстоуны, последовательности работ, особенно, если они не учтены. Возможно, такую процедуру бесполезно делать в Fixed Price проекте на 100 тысяч лет работы специалистов. В других случаях, надо попытаться навести порядок.
- Создать техдолг — временное решение для экономии времени, а позже его надо убрать.
- Если нужно что-то сделать срочно, можно переподелить задачи и выкинуть часть некритичных. Например, у вас есть система авторизации, а в ней — логин, пароль, права доступа, форм-валидатор. Систему прав доступа можно временно сократить и сэкономить время.
Как это выглядит на реальном примере:
Примерно раз в две недели product owner появляется в чате РМ-а и говорит: «Сегодня у нас есть новый бизнес и ему нужна новая фича. Накатить ее нужно до утра понедельника, потому что в понедельник в 9.00 у меня с ними встреча. Если фича будет готова — все хорошо, бизнес покупает, если нет — я буду недоволен».
РМ понимает, что задача займет 2 недели, а фича нужна уже в понедельник. В этом случае, можно создать технический долг: сделать косое-кривое решение, зато к понедельнику. Только не забудьте зарегистрировать техдолг в виде задачи и позже с ним разобраться.
Далеко не все РМ-ы пользуются этими простыми манипуляциями, но, по моему опыту не стоит делать задачи с низкой ценностью. Если видите что-то лишнее, можно хотя бы попытаться это убрать или сократить. Или, как вариант, подтвердить, что делать конкретную задачу все равно придется, но можно не сейчас, а позже.
В любом случае, регулярные сортировки и пересмотры задач улучшают процесс, убирают лишнюю деятельность с проекта и всем становится быстрее работать.
Тема планирования и контроля не поместится в рамки одной статьи. Поэтому, если нужны системные знания — посмотрите программу по планированию и рискам или курс по внедрению изменений и контролю качества.