Урок 3 з 4
WBS і робочі пакети
Розбиваємо проєкт на частини
«Зробити гру» — завелике завдання, щоб його оцінити чи комусь доручити. Тому проєкт ділять на менші частини, ті — ще на менші, поки кожна не стане зрозумілою і керованою.
Таку покрокову декомпозицію називають WBS (Work Breakdown Structure), українською — ІСР, ієрархічна структура робіт. Це головний інструмент домену «Зміст»: усе, що не потрапило у WBS, команда робити не буде.
Розбивати проєкт можна п'ятьма способами:
- За результатами — за продуктами чи їхніми частинами: застосунок гри, сервер, сторінка в магазині.
- За етапами життєвого циклу — за фазами в часі: концепція, розробка, реліз.
- Організаційно — між підрозділами чи людьми: програмістом, дизайнером, маркетологом.
- Територіально — за місцем, де виконують роботу: Київ, Львів, Одеса.
- Функціонально — між проєктною командою і звичайною, щоденною роботою компанії.
Часто їх поєднують: перший рівень, наприклад, за етапами, а другий — за результатами.
П'ять способів розбити проєкт
Один проєкт, п'ять різних структур робіт.
Ділимо за тим, що отримаємо в кінці: за продуктами чи їхніми частинами.
Застосунок гри
- Механіка
- 20 рівнів
- Персонажі
Сервер
- Акаунти гравців
- Таблиця рекордів
Сторінка в магазині
- Опис
- Скриншоти
- Трейлер
П'ять кроків декомпозиції
- Визначити результати. Які кінцеві та проміжні продукти мають бути: гра, сервер, сторінки в магазинах.
- Обрати структуру. За яким із п'яти способів групувати.
- Розбити верхні рівні. Великі блоки ділимо на дрібніші: Мобільна гра → Застосунок гри → Ігрова механіка.
- Присвоїти коди. Кожен елемент отримує свій номер (1.2, 1.2.1, 1.3.1). Так зручно вести облік і прив'язувати кошторис.
- Перевірити глибину. Чи достатньо деталізовано? Про це нижче.
Найнижчий рівень WBS — робочий пакет (work package). Саме для робочих пакетів оцінюють тривалість і вартість і призначають відповідальних.
WBS гри з кодами
Кожен елемент має свій код, а робочі пакети — відповідального й оцінку.
| Код | Елемент | Відповідальний | Оцінка |
|---|---|---|---|
| 1 | Мобільна гра | ||
| 1.1 | Управління проєктом | ||
| 1.1.1 | Концепція і планпроєктний менеджер | проєктний менеджер | 2 тижні |
| 1.2 | Застосунок гри | ||
| 1.2.1 | Дизайн персонажів і світудизайнер | дизайнер | 4 тижні |
| 1.2.2 | Ігрова механікапрограміст | програміст | 5 тижнів |
| 1.2.3 | 20 рівнівдизайнер | дизайнер | 3 тижні |
| 1.3 | Сервер | ||
| 1.3.1 | Акаунти й таблиця рекордівпрограміст | програміст | 3 тижні |
| 1.4 | Запуск | ||
| 1.4.1 | Тестування на телефонахтестувальник | тестувальник | 2 тижні |
| 1.4.2 | Сторінка в магазинахмаркетолог | маркетолог | 2 тижні |
| 1.4.3 | Релізпрограміст | програміст | 1 тиждень |
Наскільки дрібно розбивати
Якщо розбити гру на завдання по годині, менеджер витрачатиме на контроль більше часу, ніж команда на роботу. А завдання «Зробити гру за п'ять місяців» проконтролювати неможливо: до кінця строку не видно, чи все йде за планом.
На практиці часто користуються правилом 8/80: робочий пакет займає не менше 8 годин (один робочий день) і не більше 80 годин (два робочі тижні). Коротші роботи краще об'єднати, довші — розбити ще раз.
А коли команда розписує вже щоденні задачі (наприклад, на спринт), популярний орієнтир — одна задача на один день. Таку задачу легко оцінити, і вже наступного ранку видно, чи вона готова.
Обидва правила — практичні орієнтири, а не вимога стандарту. У нашому прикладі роботи крупніші, 2–5 тижнів, щоб схеми вміщалися на екран. У справжньому плані «ігрову механіку» розбили б ще на кілька робіт.
Базовий план змісту
Опис змісту, WBS і словник WBS (опис кожного елемента: що саме зробити, хто відповідає, як перевірити) разом утворюють базовий план змісту (scope baseline). Його затверджують, і з ним порівнюють усе, що відбувається в проєкті далі.
В адаптивному проєкті WBS теж є, але верхні рівні визначають на старті, а нижні з'являються поступово, з беклогу.