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