МенеджментПідрозділ
Декомпозиція
Як перетворити щось надто велике, щоб почати, на частини, достатньо малі, щоб завершити, — і не загубити дорогою причину кожної частини. Чотири теми про дві традиції, що рідко зустрічаються: декомпозиція робіт із проєктного менеджменту й користувацькі історії з продуктового. Вони відповідають на різні питання, і розуміння, у якій ви зараз, знімає більшість суперечок про потрібну деталізацію плану.
Що всередині
Усі сторінки цієї групи — і про що кожна з них.
- Work Breakdown StructureРезультати, а не задачі: словник, контрольні рахунки, пакети планування й хвильове планування.РезультатиПравило 100%
- User StoriesНавіщо потрібна історія, формати критеріїв приймання, story mapping, спайки й що насправді міряють поінти.INVESTНарізання
- Епіки, фічі, задачіІєрархія, яку кожен трекер називає по-своєму: Jira, Azure DevOps і SAFe, зіставлені один з одним.ІєрархіяІнструменти
- OKRЦілі, що не є списком задач: зобовʼязані проти амбітних, каденція, запобіжники й OKR проти KPI.РезультатиЩокварталу
З чого почати
- Пишете беклогСпершу історії, потім епіки й фічі: ієрархія стає значно зрозумілішою, коли знаєш, що лежить у її основі.
- Плануєте проєкт із фіксованим обсягомСтруктура декомпозиції робіт. Вона ділить результати, а не роботу, — і саме ця відмінність тримає оцінки.
- Ваші цілі — це список задачOKR, а саме поділ на зобовʼязані й амбітні: зазвичай саме цієї частини й бракує.
Інше в цьому розділі
- МенеджментУправління IT-проєктом — це набір рішень, які перетворюють намір на випущений продукт: що будувати, як розрізати це на роботу, яку справді можна завершити, як команда організовує себе тиждень за тижнем і як результат доходить до користувачів. У розділі 21 тема у пʼяти групах — продуктовий менеджмент, декомпозиція, методології, реліз-процес і формальні фреймворки, — і кожна сторінка дає компроміс за вибором, а не переказ для сертифікаційного іспиту.
- МетодологіїЯк команда вирішує, що будувати далі, у якому порядку і звідки знає, що щось завершено. Девʼять методологій — від двох, за якими більшість справді працює, до чотирьох, що існують, бо однієї команди стало замало. Кожна сторінка описує те, що фреймворк справді визначає — кожну церемонію, роль і артефакт, — а не переказує його, і прямо каже, де він перестає працювати.
- Продуктовий менеджментЯк вирішити, що взагалі варто будувати, і як потім зрозуміти, чи спрацювало. Три теми, що йдуть одна за одною: зʼясувати, що людям потрібно; обрати, що з цим робити, у порядку, який можна захистити; і виміряти результат, не обманюючи себе. Найважче в усіх трьох — відмовляти, тому кожна сторінка охоплює і те, як казати «ні», а не лише як обирати.
Було корисно?
Поділіться з тим, хто працює над тією ж задачею.