Автор статті – Олексій Просніцький, PgMP, PMP, Prince2, MVP

Ця історія випадково попала в нашу сонячну систему. Звісно це звучить дуже дивно, проте телескоп Блабла зафіксував довгий сигнал який йшов з сузір’я Ки-Їва.

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

Публікується вперше і саме як було розшифровано

Факапі (ймовірно, ім’я, бо часто згадується у тексті – прим. астрономів), слухай, давно хочу запитати тебе про одну ситуацію.

Я давно працюю в проєктах і мене турбує поточна звітність. Для різних стейкхолдерів потрібна різна звітність, що займає багато часу. Наприклад, основний замовник не хоче занурюватися в деталі, для нього треба упакувати інформацію в один слайд. Але цей one page має містити: Що зроблено, Що в процесі, Що наступне, Що критичне, Проблеми, Де ми на таймлайні. Часто проблема в тому, що замовник хоче бачити все, але не має часу на занурення. Тому треба щоб на цій one page було достатньо інформації, але не перевантажено🤪 Або взагалі не хоче бачити «нічого зайвого», окрім позитивного прогнозу.

Для керівництва ж потрібна вся ця інформація, але з деталями про ризики та їх мітігації. Хочеться мати універсальний (але це нереально) шаблон або дашборд звітності, який можна як конструктор змінювати для різних стейкхолдерів.

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

«Звісно, ситуація доволі знайома» – невимушена сказала тихенько Факапі. «Мар Іча, мені сумно, що навіть у такому розвиненому суспільстві ти стикаєшся з такими труднощами. Це справді проблема. Так як, керівник проєкту, або будь хто інший, замість того, щоб виконувати роботу і зосереджуватися на результаті, повинен витрачати свій час на створення звітів.

Ти мені нагадуєш офіціантку, яка обслуговує вибагливих відвідувачів ресторану і намагається відгадати, що їм потрібно: «Вам звіт з зеленим відтінком? Чи варто додати трохи аріальчика чи все ж таки зробити на таймсі[1]?Можливо ви би хотіли відчути від погляду на звіт нотки далекої Мадейри?».

Добре. Розповім тобі, що я думаю з цього приводу.

Одного літнього вечора я мандрувала скупченням у Малій Магеллановій Хмарі й завітала на планету Тральфамадор. Там якраз проходила вечірка з покращення роботи зі звітами.

Виявилося, що Тральфамадор була заселена кіптами, які покинули якусь планету біля якоїсь жовтої зірки. Вони привезли з собою не лише пісні далекої Землі, а й пам’ять про управління проєктами за методом PRINCE2. Цікаво, що цей самий метод використовують і на Землі! І в ньому є всього два типи звітів:

• Періодичні звіти (time-driven),
• Звіти по подіям (event-driven).

Чому тільки два? Бо коли розробників просили звітувати про створення PRINCE2, вони вирішили, що якось не добре, що вони постійно відволікаються на запити, тому і придумали ці два типи звітів. Звісно, спочатку з’їшви тих, хто попросив ці звіти їх зробити.

Звіти по подіям

Це звіти, які команда або керівник проєкту готують у разі випадку настання певних подій:

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

Звіти по подіям складаються з:

• Звіт про завершення стадії/проєкту
• Звіт про інцидент
• Звіт про вихід за затвердженні показники.

Періодичні звіти

Їх готують із заздалегідь визначеною періодичністю (раз на тиждень, місяць тощо). Періодичні звіти бувають двох типів:

• Звіт по основним моментам (Highlight Report) – короткий огляд статусу проєкту від керівника проєкту (ідеально, щоб вміщувався на одну сторінку).
• Звіт по основним подіям (Checkpoint Report) – деталізований звіт від Керівника команди (Team Lead) для керівника проєкту з метою проінформувати про статус виконаних завдань (план/факт/прогрес).

Більше звітів немає. Тобто, якщо до керівника проєкту хтось випадково прибігає з запитом «А що у нас там з проєктом?», керівник проєкту повинен надати «Звіт по основним моментам».

Автоматизація та ручна робота

Важливо зазначити, що в великих компаніях, можливо, і я саме наголошую на цьому слові, можливо мати єдиний шаблон звіту по основним моментам або «One Page Project Report» на всі типи проєктів. Проте, якщо в компанії ведуться різні типи проєктів – будівельні проєкти, проєкти розробки програмного забезпечення, інвестиційні проєкти, R&D проєкти, бізнес проєкти, то нюанси різних типів будуть вимагати різної інформації та різного наповнення.

Якщо ж узагальнити, то можна виділи загальні риси:

• Назва;
• Керівник проєкту;
• Спонсор проєкту;
• Замовник проєкту;
• Тривалість;
• Початок;
• Закінчення проєкту;
• Дата поставки продукту;
• Відхилення від завершення;
• Віхи минулого місяця;
• Віхи майбутнього місяці;
• Ризики майбутнього місяця;
• Інциденти минулого місяця.

А далі стільки різних нюансів, що бажано на кожний окремий тип все ж таки мати свій варіант звіту. Тому досягнути в великих компаніях, одноманітності дуже складно і скоріше за все, майже неможливо.

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

«Ох, Мар Іча» – обізвався Факапі. «Ми саме тут з моїми знайомими, паном Сірим Гусом та Морс Мусом[2] говорили про ручну працю керівників проєктів і прийшли до наступних висновків. Всі звіти ми розділили на два типи. Звісно, Сірий Гус виступав за тип звітів «Один Гус наліво», Морс Мус за «Один Мус направо», але я їх відмовив, тому пропоную тобі наступні два типи:

• Автоматичні звіти,
• Ручні звіти.

І якщо ми повернемося до попередньої кваліфікації, то автоматичні звіти це:

• Звіти по подіям (Highlight Report та Checkpoint Report),
• Звіти про інцидент/ризики/зміни,
• Звіту про вихід за затвердженні показники.

А ручні звіти це:

• Звіту про закінчення стадії,
• Звіту про закінчення проєкту.

На думку пана Гуса та пана Муса всі автоматичні звіти повинні бути створені в спеціальних ІТ системах з побудови звітності.

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

Проте у автоматичних звітів є один суттєвий недолік. Річ в тому, що вони показують момент у часі. Так, навіть з динамікою, трендами, але момент у часі. Ти на цей звіт дивишся, як на фото, проте чого тобі бракує? Правильно. Історії! Історії про те, як ми тут опинилися, що передувало стану речей, завдяки яким компанія саме і опинилася в проєкті. Не вистачає думок керівника проєкту, команди, рефлексії, висновків.

Саме тому звіти про закінчення стадії і, особливо проєкту, повинні бути написані рукою керівника проєкту. Звісно, не треба як Містер Нетописець писати пером та руками. Для цього можна і різні ІТ інструменти використовувати.

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

• Подивитися на фото (звіт в ІТ системі),
• Сісти у вогнища і почати розповідати байки про те, як ви раніше жили на іншій планеті. І хто цьому повірить?
• Дати почитати звіт по проєкту.

Уяви, в тебе звільнився керівник проєкту після завершення проєкту. Що він після себе залишить? Є наступні варіанти:

• Звіти в ВІ системі.
• Легенди про проєкти.
• Ручні звіти.

«І останнє, після чого я вважатиму, що моя місія виконана і ти зможеш рухатися далі» – тихенько сказала Факапі. – «Важливо розуміти, хто в компанії відповідальний за процес розробки звітів і їх підтримки. Сподіваюся, ти пам’ятаєш з чудової книжки однієї людини, здається, вона називається «Як не пропити проєкт», що бажано в компаніях мати офіс управління проєктами (РМО), і саме він відповідає за створення, підтримку і розвиток всього того, що стосується управління проєктами, а саме за процес «Врядування».

Тому відповідаючи на запитання, хто повинен створити шаблони всіх звітів, комунікувати з різними стейкхолдерами стосовно даних по всім звітам, відповідь одна, проста і складається з трьох літер – РМО.

Резюмуючи, шановна Мар Іча, вимагай від РМО створення шаблонів, автоматизуйте систему звітності та залишай після себе історію в ручних звітах».

[1] Arial та Times New Roman мабуть найрозповсюджені звіти в корпоративному світі

[2] Сірий Гус (Grey Goose) та Mорс Мус (Morse Moose) відомі організатори проєктних прольотів по грошам у великих розмірах без зайвої відповідальності. Останній раз були помічені в прольоті в проєкті «Дільский міст Віта-Ко» та в пісні Пола Маккартні “Morse Moose And The Grey Goose”