Ви управляєте Backlog'ом, чи він вами?

Що в проєктному, що в продуктовому менеджменті - одну з найголовніших речей грає відповідь на питання, "що лежить в нашому беклогу?"

• Таска в беклогу
• Делівері на продакшн
• Можливе велью для користувачів
• Покращення метрик / Більше грошей

Якщо ми не контролюємо наш план робот — як ми контролюємо делівері велью для наших користувачів чи стейкхолдерів?

Беклог — це список задач, які ми ПЛАНУЄМО зробити, а не список ідей та хотілок всіх стейкхолдерів. Якщо ми з самого початку не розуміємо коли та яким чином задача буде реалізована, ми її просто не приймаємо.

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

Одна з перших речей на яку я дивлюся під час консалтингу проєктних команд:

• Що в беклогу?
• Як і чому воно там з'явилося?
• Чому пріоритети самі таки?

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

Найпопулярніші проблеми які я бачу наступні:

🟠 Все однаково важливо

Пріоритетність - це важливість задачі у порівнянні з іншими задачами. А не важливість її для того чи іншого стейкхолдера. Якщо для вас важливо все — для вас нічого не важливо.

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

🟠 Беклог перетворюється на смітник та задачі живуть вічно.

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

Найкращий спосіб позбавитися цієї проблеми, превентивно видаляти ( backlog grooming ), або не додавати нові задачі взагалі.

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

🟠 Супердетальний опис задач

Не повірите, але це теж проблема у деяких командах. Чим більше команда розбирається в бізнес-задачах та кодбейсі проєкту, тим менше опису їм мало.

70-90% беклогу повинні бути готові до того, що їх у будь-який момент візьмуть у роботу. Інші 30-10% повинні бути описані впродовж наступних 1-2 спринтів.