Декомпозиція від результатів роботи

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

Почни з іншого кінця: з результатів роботи — того, що проєкт передає і що хтось може перевірити. Для фізики їх дає список «входить» із брифу: програма, добірки задач, пул репетиторів, діагностичний тест, сторінка й запис за предметом, комунікації до старту. Задачі йдуть другими — як спосіб зробити кожен результат роботи.

Різниця видна одразу. Шістдесят рядків Danylo, список Vira і список Roman перетинаються на задачах для практики, і жоден не згадує, хто надсилає лист про запуск. Якщо дивитися від результатів роботи, обидві проблеми впадають в око: в одного результату два автори, в іншого — жодного. До того ж рамка результатів роботи стабільна, поки задачі змінюються щодня, тож вона може бути кістяком плану.

Результат роботи (deliverable) — те, що проєкт передає і що хтось може випробувати, а тоді прийняти чи повернути: діагностичний тест, який визначає рівень кожного учня, розділ програми з механіки, пул репетиторів, які пройшли демоурок. Задача — дія, що допомагає його створити: подзвонити п'ятьом кандидатам у вівторок, полагодити вибір предмета в бронюванні, зустрітися з Vira щодо розділу з механіки.

Зручна перевірка — граматика. Результати роботи — іменники: на них можна вказати й перевірити. Задачі — дієслова: те, що хтось робить. Дерево плану складається з іменників; дієслова живуть рівнем нижче, на власній дошці відповідального.

Чому це важливо: задачі важать лише через результат роботи, який вони створюють. Керівник, що відстежує дієслова, зрештою питає «ти подзвонив кандидатам?» замість «чи пул репетиторів іде за планом?» і бачить активність, а не прогрес.

Структура декомпозиції робіт (WBS) — це дерево. Нагорі — проєкт. Під ним — результати роботи. Кожен результат розпадається на частини, достатньо малі, щоб одна людина могла їх взяти й оцінити. Окремі задачі — ще нижче, на дошці власника, а не в дереві.

Для фізики одна гілка читається згори вниз: запуск фізики → пул репетиторів → демоуроки й оцінювання (один власник) → «надіслати кандидатові 7 час демоуроку» (задача на дошці цього власника). Інші гілки діляться так само: програма — на п'ять розділів від механіки до атомної фізики; пул репетиторів — на пошук і відбір (Roman), демоуроки (Vira) і введення в роботу (Roman); тест — на банк запитань від Vira і збирання на платформі від Danylo.

Кожен рівень відповідає на своє питання: що передаємо? (результати роботи), хто робить яку частину? (частини), як сьогодні? (задачі). Керівник проєкту стежить за частинами, а не за кожним повідомленням кандидатові.

Дерево корисне, лише якщо проходить правило 100 %: воно охоплює всю роботу проєкту, і кожна частина роботи є в ньому один раз. Правило має дві половини, і кожна ловить свою помилку.

Чогось бракує. Ніхто не вписав комунікації до старту, тож сторінка чекала б відвідувачів, які не прийдуть. А саме управління проєктом (план, щотижневий статус, список ризиків) — справжня робота зі справжньою трудомісткістю: пропусти її — і твої дні візьмуться нізвідки.

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

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

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

Шістдесят рядків Danylo лишаються на його дошці; у дереві написано «діагностичний тест на платформі, власник Danylo». Глибше розбиття не робить план точнішим. Воно робить його важчим в обслуговуванні, він змінюється щодня й забирає планування у власника. Керівник, що стежить за кожною годиною роботи Danylo, не дізнається нічого понад «збирання тесту йде за планом, зроблено близько 8 із 12 днів».

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

Коли дерево проходить правило 100 %, розгорни його в перелік результатів роботи: один рядок на частину, чотири стовпці.

1. Результат роботи (іменник, який хтось може перевірити).
2. Один власник.
3. Діапазон трудомісткості в людино-днях: оптимістично, найімовірніше й песимістично, бо одне число ховає, наскільки частина невизначена.
4. Що потрібно спершу: частини, які мають бути готові, перш ніж її почати.

Трудомісткість — це людино-дні, а не календарні тижні. Скільки роботи і коли вона може відбутися — різні питання: Roman працює на запуск два дні на тиждень, а демоуроки не можуть початися, поки немає програми. Календар з'явиться пізніше, у графіку, який використає стовпець «що потрібно спершу».

З цим переліком працює решта модуля: наступні уроки додадуть, що означає «готово» для кожного рядка, і вирішать, що урізати, якщо сума не вміщається в доступний час.

Кожен рядок переліку результатів роботи має рівно одного власника: людину, яка за нього відповідає, не обов'язково єдину, хто над ним працює. Рядок із двома власниками не має жодного, бо кожен цілком може вважати, що ним займається інший.

Демоуроки здаються спільною роботою: Roman записує кандидатів, Vira дивиться й оцінює. Написати «Vira і Roman» — зекономити рядок і створити прогалину. Натомість розділи рядок у точці передачі: «записи на демоуроки для 15 кандидатів, власник Roman» і «демоуроки оцінено, щонайменше 8 пройшли, власниця Vira». Тепер у кожної частини є людина, яка може сказати, чи все йде за планом.

Два інші скорочення провалюються так само. Записати власником усього керівника проєкту — сховати, хто робить роботу, і зробити керівника вузьким місцем. Лишити власника порожнім «до старту» — саме так частини зсуваються, і ніхто цього не помічає.

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

• Результат роботи в дереві: те, що проєкт передає і що хтось може перевірити, як-от діагностичний тест на платформі.
• Гілка управління проєктом: план, щотижневий статус і список ризиків. Правило 100 % вносить у дерево й роботу самого керівника.
• Задача на дошці власника: «написати запитання 14 до тесту» допомагає результату роботи, але керівник за нею не стежить.
• Список «не входить» у брифі: мобільного застосунку для фізики в проєкті взагалі немає. Чого немає в дереві, того немає в проєкті, доки Leo не вирішить інакше.

Якщо пункт ніби пасує у два місця, зазвичай він завеликий (розбий його) або ховає рішення (неси його спонсору).

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