Документування якості проєкту

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

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

Одразу хочу зауважити, що управління якістю – це довгостроковий, повторюваний процес. Через тимчасовість існування проєкту, ми не зможемо забезпечити ідеальну якість роботи команди і якість продукту проєкту. Ба більше, якість – це одне з обмежень проєкту, тому, якщо концентруватися здебільшого на ній, то і бюджет перевищимо, і дедлайн перетнемо, і обсяги робіт не виконаємо.

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

Зрозумій, що необхідно і достатньо

У статті про документування обсягів робіт я описав, як з’ясувати й оформити вимоги. Окремим випадком вимог є вимоги до якості виконання проєкту і до якості продукту проєкту. Називається це “метрики якості”. Тобі потрібно визначити параметри проєкту і результату проєкту. Потім для кожного з цих параметрів визначити й описати спосіб вимірювання, одиницю вимірювання, бажану величину цього параметра, а також допуск, тобто діапазон значень, у якому величині кожного параметра дозволено змінюватися.

З метриками якості результатів проєкту (тобто продуктів) усе більш-менш зрозуміло – стіни під час будівництва мають бути рівними, а додатки під час програмування мають бути без глюків. А ось із якістю виконання проєкту не все одразу зрозуміло. Давай розберемо на прикладі.

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

1. Частота нарад за проєктом має бути не частіше ніж 1 раз на тиждень, але не рідше ніж 1 раз на 3 тижні. Тривалість наради не може бути більше 1 години. А кількість учасників наради має бути не більше чотирьох.
2. Звіт має виходити щочетверга о 16:00 +/- 2 години.

Таким чином збираємо всі потрібні нам параметри з характеристиками і все це акуратненько заносимо в таблицю “Метрик якості”.

Але метрики якості – це так, для розминки. Тепер найцікавіше.

Напиши, як будеш робити

Будь-який підхід до управління якістю зводиться до трьох “простих” дій:

1. Напиши, як будеш робити (планування якості)
2. Роби, як написав (забезпечення якості)
3. Щоб незалежний фахівець міг звірити те, що робиться і написане (контроль якості)

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

План управління якістю – це багатосторінковий документ, на кшталт “процедура”, у якій якраз і описується те, що описано в цій статті, тільки трохи ширше. До складу плану управління якістю входять такі розділи:

1. Метрики якості
2. Забезпечення якості
3. Контроль якості
4. Постійне вдосконалення процесів
5. Шаблон чеклиста

Метрику якості я описав вище. Забезпечення якості – це перелік заходів, які потрібно виконувати, щоб робота і продукт відповідали зазначеним вище метрикам. Контроль якості – це перелік перевірок і відповідних “папірців”, які проводять і підписують виконавець і перевіряльник.

Постійне вдосконалення процесів – це те, що команді проєкту дістається в навантаження від ОУП або від системи управління проєктами в компанії. Одиничному проєкту цей розділ нічого корисного не несе, а ось якщо проєкти йдуть на потоці, то якість від проєкту до проєкту можна вдосконалювати. Кожен виконавець проєкту може покращувати якість на своєму рівні. Тому, якщо він виявив потенціал для поліпшення якості процесів та інструментів, з якими він працює, потрібно дати йому механізм передання його ідеї до ОУП або Відділу Якості.

Роби, як написав

Найважливішим моментом у забезпеченні якості проєкту є передача цього “забезпечення” безпосередньому виконавцю робіт. Тому, друже мій, пиши чеклісти! Причому скільки в проєкті типів робіт, стільки має бути і чеклистів, а може й більше (якщо врахувати підтипи робіт).

Чеклист – це список самоперевірки виконавцем своєї роботи. Коли виконавець виконує роботу він може захоплюватися або, навпаки, халтурити. Тому потрібно дати йому список характеристик його роботи або продукту, за якими він сам себе може перевірити ще до того, як він передасть результати своєї роботи ПМ-у або своєму керівникові.

Приклад. Планувальник завершив свою роботу. Перш ніж вивалити на керівника проєкту свій графік, з усіма його роботами, зв’язками, ресурсами та іншими віхами, він має перевірити себе за такими параметрами:

1. На верхньому рівні графік проєкту повністю відповідає WBS проєкту.
2. Усі завдання пов’язані зв’язками. У всіх завдань (крім першої та останньої) є попередник і послідовник. Жодне завдання не прив’язане жорстко до певних дат.
3. Для завдань, яким потрібні конкретні дати за контрактом або статутом, встановлено параметри “дедлайну”.
4. У графіку немає завдань із тривалістю, що перевищує управлінський (або звітний) період проєкту.
5. На сумарні завдання призначено резерви.
6. Ресурси вирівняні й не перевантажені.
7. S-крива, що вивантажується з графіка, нагадує букву S.

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

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