IAMPM
65000
+38 (091) 481 01 38+7 (495) 128 58 05info@iampm.club

Как победить хаос в проектных задачах

8 декабря 2020

  • Автор: Павел Устинов

  • Сложность: легко

  • Время: 4 мин

Задач на проекте много: если их не структурировать, процесс превращается в «кашу» из тасок, подзадач и эпиков. Девелоперы работают сразу по нескольким направлениям, все задачи начаты, и ни одну не удается закончить вовремя. В итоге, разработчики 70% времени занимаются всем и ничем одновременно.

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

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

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

Структурируйте работуКак победить хаос 1

Для заказчиков и для технических специалистов нужны разные уровни объяснения задач. Если вы покажете бизнесу задачу по устройству API, вас вряд ли поймут. Поэтому разделяйте уровни задач бизнеса и команды. Удобный для этого инструмент, работающий в большинстве случаев — это user story.

Старайтесь не делать весь проект «одним пирогом», а сдавайте по кусочкам — итеративно. Направляйте усилия на получение рабочего продукта с каждой поставкой.

Проводите локальное планирование спринта-шага на основе технических задач. Если уже появилась «каша» из тасок, лучше перепланировать спринты и переделать задачи так, чтобы их можно было контролировать. 

И конечно, отдельная вещь, которая помогает справиться с процессами почти во всех проектах — это практики сортировки. 

Сортируйте задачи

Как победить хаос 3

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

Уточняем

Часто бывает, и думаю многие РМ-ы уже видели это на практике, что в процессе работы над проектом, задачи и потребности меняются. Люди могли думать одно, а потом додумали это глубже или посмотрели с другой стороны. 

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

Поэтому не факт, что требования, которые появились довольно давно — это то, что нужно. Если РМ систематически не уточняет задачи, позже можно столкнуться с ситуацией, когда заказчик говорит: «Я же хотел другое», — а вы объективно не в курсе и недоумеваете как такое получилось.

Делим/Объединяем

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

А бывают задачи непонятные, например, сделать систему тендеров. Половина сайта — система тендеров, и неясно, как такой запрос решать. Поэтому, такую работу нужно предварительно разделить на более мелкие кусочки.

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

Ранжируем

После уточнения и структурирования, остается только отранжировать. Для этого оцените каждую задачу по двум параметрам: «польза» и «количество усилий». Цель ранжирования — выразить в каких-то единицах измерения, какую пользу для проекта приносит задача и сколько усилий понадобится для выполнения. Не важно, какими единицами орудовать, будь то часы или story points,  также как и всем выражать приоритет от 1 до 5.

Затем расставляем поочередно:

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

Будет проще всего выстроить список по убыванию, если  «ценность-приоритет»  разделить на «оценку-трудоемкость». 

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

Если у вас живой scrum, и заказчик либо его product owner присутствует в спринтах, скорее всего, в задачах будет порядок, потому что в scrum заказчик обычно сам менеджерит проект. А бесконтрольные ситуации чаще случаются там, где есть какой-то Fixed Price и не очень значительные суммы. 

Не делайте лишнего

Как победить хаос 2

Задача РМ-а — навести порядок в проекте любым удобным способом. Если работа спланирована плохо и это приводит к потерям, лишним коммуникациям, остановкам, перезапускам, то наверное, стоило бы проект переделать.

Независимо от того, что говорит заказчик, и какое психологическое давление оказывают на менеджера и компанию подрядчика, всегда можно практически без последствий сделать несколько вещей:

  • Убрать пятую часть объема работы по проекту. Всегда есть задачи, которые на самом деле на нужны, а что-то можно сделать с меньшими усилиями или вернуться к задаче уже после MVP в первой версии.
  • Переформатировать весь проект: пересортировать этапы, итерации, майлстоуны, последовательности работ, особенно, если они не учтены. Возможно, такую процедуру бесполезно делать в Fixed Price проекте на 100 тысяч лет работы специалистов. В других случаях, надо попытаться навести порядок. 
  • Создать техдолг — временное решение для экономии времени, а позже его надо убрать. 
  • Если нужно что-то сделать срочно, можно переподелить задачи и выкинуть часть некритичных. Например, у вас есть система авторизации, а в ней — логин, пароль, права доступа, форм-валидатор. Систему прав доступа можно временно сократить и сэкономить время. 

Как это выглядит на реальном примере: 

Примерно раз в две недели product owner появляется в чате РМ-а и говорит: «Сегодня у нас есть новый бизнес и ему нужна новая фича. Накатить ее нужно до утра понедельника, потому что в понедельник в 9.00 у меня с ними встреча. Если фича будет готова — все хорошо, бизнес покупает, если нет — я буду недоволен». 

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

Далеко не все РМ-ы пользуются этими простыми манипуляциями, но, по моему опыту не стоит делать задачи с низкой ценностью. Если видите что-то лишнее, можно хотя бы попытаться это убрать или сократить. Или, как вариант, подтвердить, что делать конкретную задачу все равно придется, но можно не сейчас, а позже. 

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

Тема планирования и контроля не поместится в рамки одной статьи. Поэтому, если нужны системные знания — посмотрите программу по планированию и рискам или курс по внедрению изменений и контролю качества. 

 

 

Павел Устинов

Павел Устинов

Project Manager Officer в Solar Digital с 15-летним опытом работы в IT-сфере. Занимается разработкой мобильных приложений, сайтов, блокчейн систем. Имеет за спиной более 10 лет опыта преподавания в оффлайн и онлайн форматах.