Як перемогти хаос в проєктних задачах

Як перемогти хаос в проєктних задачах

8 December 2020

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

  • Складність: легко

  • Час: 4 хв

Задач в проєкті багато: якщо їх не структурувати, процес перетвориться в “кашу” із тасок, підзадач і епіків. Девелопери працюють одразу в декількох напрямках, всі задачі розпочаті і жодну не вдається завершити вчасно. В результаті, розробники 70% часу займаються всім і нічим водночас.

Щоб не допускати хаос, важливо не тільки записувати, а й розставляти пріоритети. Тоді люди встигають працювати, а РМ може контролювати виконання і взагалі розуміти, що відбувається. А ще, важливо позбавлятися від зайвих завдань з низьким value.

Якщо ви цим не займаєтеся, то швидше за все, п’яту частину роботи ведете абсолютно даремно, її можна було не робити, і стан проєкту не завжди буде відповідати тому, що ви бачите в Jira і статусах завдань.

Три важливі пункти, які допоможуть упорядкувати хід проєкту, це структурування, сортування та видалення зайвих завдань.

СТРУКТУРУЙТЕ РОБОТУКак победить хаос 1

Для замовників і для технічних фахівців потрібні різні рівні пояснення завдань. Якщо ви покажете бізнесу задачу по влаштуванню API, вас навряд чи зрозуміють. Тому розділяйте рівні завдань бізнесу і команди. Зручний для цього інструмент, який працює в більшості випадків — це user story.

Намагайтеся не виконувати весь проєкт “одним пирогом”, а здавайте по шматочках — ітеративно. Спрямовуйте зусилля на отримання робочого продукту з кожної поставки.

Проводьте локальне планування спринт-кроку на основі технічних завдань. Якщо вже з’явилася “каша” з тасок, краще перепланувати спринти і переробити завдання так, щоб їх можна було контролювати.

І звичайно, окрема річ, яка допомагає впоратися з процесами майже у всіх проєктах — це практики сортування.

СОРТУЙТЕ ЗАДАЧІ

Цей етап потрібен, щоб не займатися зайвою роботою, завжди приносити максимальну цінність в проєкт. Для зручності роботи з завданнями і досягнення вимірюваного результату, важливі три чинники: уточнення завдань, розподіл/об’єднання і ранжування.

УТОЧНЮЄМО

Часто буває, і думаю багато РМ-ів вже бачили це на практиці, що в процесі роботи над проєктом, завдання і потреби змінюються. Люди могли думати одне, а потім продумати це глибше або поглянути з іншої сторони.

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

Тому не факт, що вимоги, які з’явилися досить давно — це те, що потрібно. Якщо РМ не уточнює завдання систематично, пізніше можна зіткнутися з ситуацією, коли замовник каже: “Я ж хотів інше”, — а ви об’єктивно не в курсі і дивуєтесь, як так сталося.

ДІЛИМО/ОБ’ЄДНУЄМО

Нелогічно розсортоване завжди можна об’єднати, поділити, пересортувати. Є зрозумілі завдання, наприклад, розробити сторінку авторизації. Таке завдання просто розбити на технічні та нетехнічні складові, легко виконати і закрити.

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

Взагалі, як показує практика, розділити можна майже все. Важливо тільки розуміти навіщо ділимо і що будемо з цими частинами робити.

РАНЖУЄМО

Після уточнення і структурування, залишається тільки відранжирувати. Для цього оцініть кожну задачу за двома параметрами: “користь” і “кількість зусиль”. Мета ранжирування — висловити в певних одиницях виміру, яку користь для проєкту приносить завдання і скільки зусиль знадобиться для виконання. Не важливо, якими одиницями орудувати, будь то годинник або 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 років досвіду викладання в оффлайн і онлайн форматах.