Коротка відповідь: так, варто! Хороше технічне завдання (ТЗ) може заощадити вам багато стресу, часу та коштів. Звучить як щось, що варто спробувати, чи не так? У цій статті ми розповімо про основи написання ефективного технічного завдання. Ми також розглянемо найважливіші переваги цього документа. Але спочатку давайте пояснимо, що таке ТЗ і яке місце воно займає в процесі управління проектом.
Посібник з управління проектами визначає Технічне завдання проекту як наративний опис продуктів, послуг або результатів, які мають бути досягнуті в рамках проєкту (Джерело: PMBOK® Guide - П'яте видання).
По суті, це документ, який описує різні аспекти проектув тому числі:
Технічне завдання має бути підписане всіма зацікавленими сторонами проекту і часто є частиною проектного контракту.
Ви можете запитати про різницю між технічним завданням та обсягом робіт. Перше - це назва документа, який зазвичай включає в себе обсяг проекту. Коли ми говоримо "обсяг робіт", ми зазвичай маємо на увазі роботу, яку необхідно виконати для реалізації проекту. Документування обсягу робіт є важливим елементом ефективного управління обсягом проекту. Ви можете зробити це, створивши так звану структуру розбиття робіт (WBS), яка дозволяє візуалізувати обсяг робіт. Також може бути гарною ідеєю додати WBS до вашого технічного завдання.
На початку цього блогу ми згадували про те, що правильний технічний завдання може заощадити вам багато нервів і грошей. Це особливо актуально, коли ви працюєте із зовнішніми стейкхолдерами, а ваш проект досить складний. Наявність єдиного джерела істини щодо роботи, яку ви повинні і не повинні виконувати, може врятувати вам життя. Завдяки технічному завданню ви можете це зробити:
[/vc_column_text]
Важливо зазначити, що проекти можуть бути дуже різними, тому, залежно від характеру проектів, які вони виконують, різні компанії можуть використовувати дуже різні технічні завдання. Однак є деякі елементи, які зазвичай включаються до вашого ТЗ. Давайте розглянемо їх по черзі:
Вступ до технічного завдання - це місце, де ви можете підсумувати проект та окреслити всі сторони, які беруть у ньому участь. Зазвичай в резюме проекту ви пояснюєте мету та бачення проекту. Про що цей проект? Яка бізнес-мета його реалізації? Яку проблему вирішить кінцевий продукт?
Пояснення цих елементів на початку вашого ТЗ допоможе вам задати тон усьому документу, а також надати обґрунтування для включення чи невключення певних результатів до обсягу робіт.
У цій частині технічного завдання ви намагаєтеся відповісти на два питання:
Зрозуміло, що цей розділ не може бути надто розпливчастим, оскільки це може призвести до непорозумінь. З іншого боку, можливо, ви не зможете, наприклад, окреслити всі завдання на цьому етапі. Якщо це так - нічого страшного. Головне, щоб ви точно відобразили обсяг, про який ви та інші зацікавлені сторони домовилися.
Ви можете перейти від більш загального огляду обсягу робіт до переліку конкретних кроків і завдань, які потрібно буде виконати проектній команді. Не забувайте про результати і будьте конкретними щодо них. Дуже важливо уникати двозначних фраз на кшталт того, що ви надасте те чи інше. Якщо ви хочете, щоб ваше технічне завдання було корисним у майбутніх переговорах з клієнтом, воно має бути максимально чітким.
Також може бути гарною ідеєю включити в технічне завдання негативний обсяг робіт. Йдеться про ті елементи проекту, які обговорювалися з клієнтом або присутні в продуктах конкурентів, але в кінцевому підсумку ви погодилися не включати їх до технічного завдання.
Описуючи різні етапи проекту, ви можете включити етапи проекту а також терміни виконання. Деякі проекти матимуть фіксовані дедлайни, інші - ні, тому ви не завжди зможете вказати точний період виконання. Проте, корисно принаймні вказати в технічному завданні різні етапи проекту та приблизну кількість часу, яку вони мають зайняти.
Ми вже наголошували на тому, що в технічному завданні потрібно використовувати точні формулювання і точно презентувати проект. Те ж саме стосується стандартів і критеріїв прийнятності, які також повинні міститися у вашому ТЗ.
Уявіть, що ваша команда працює над мобільним додатком для клієнта. Недостатньо просто описати функції додатку в технічному завданні. Що робити, якщо ваш додаток працює так, як зазначено, на більшості мобільних пристроїв, але не на всіх? Якщо ви з клієнтом не узгодили список платформ, на які орієнтований додаток, вам буде складно стверджувати, що робота виконана успішно. Ось чому так важливо враховувати деякі галузеві стандарти. Для проектів з розробки програмного забезпечення вони можуть включати детальну інформацію про:
Ви також можете згадати про обов'язки клієнта в документі SOW - наприклад, чи повинен він надати якісь активи?
Нарешті, запишіть визначення успіху проекту: яким клієнт очікує бачити успішний проект? Хто відповідатиме за визначення того, чи є проект успішним?
Інформація про бюджет є невід'ємною частиною вашого SOW. Якщо ви можете представити витрати на проект, запишіть їх. Якщо ви працюєте за принципом "час і матеріали" або у вас є інша домовленість, чітко поясніть її умови. Не забудьте про додаткові витрати на проект: ліцензійні платежі, обладнання, відрядження тощо.
Графік платежів також має бути зазначений у SOW. Коли слід очікувати оплату? Чи передбачена розстрочка? Як компанія, відповідальна за проект, у ваших інтересах не залишати місця для сумнівів у будь-якій частині ТЗ, і, зрозуміло, що цей розділ не є винятком.
Чи зібрали ви всю необхідну інформацію в технічному завданні? Переконайтеся, що всі залучені сторони ознайомлені з документом, і отримайте його підписи.
Тепер ви розумієте цінність добре складеного технічного завдання. Незалежно від того, чи керуєте ви бутиковою агенцією, чи працюєте у великій організації, це корисний елемент процесу управління проектами у вашій команді. Поділіться нашим посібником з проектними менеджерами у вашій компанії та заохочуйте їх створювати ТЗ для різних проектів, які вони ведуть.
Тут, у блозі Teamdeck, ми часто ділимося посібниками з управління проектами. Ось кілька статей, які можуть бути корисними для вас та ваших колег по команді:
Календар ресурсів (або календар управління проектами, або календар планування проектів, програмне забезпечення для планування ресурсів) дозволяє планувати, управляти і розподіляти ресурси більш ефективно і результативно - особливо якщо Microsoft Excel відігравав провідну роль у вашому...
Яка кінцева мета проектних менеджерів? Успішне завершення проектів. Самі керівники проектів визнають, що це трапляється не так вже й часто: згідно з останнім опитуванням Пульс Професії, менше 60% проектів завершуються...
Управління виробничими потужностями - це стратегія, що використовується підприємствами для найкращого використання ефективності виробництва з урахуванням попиту на послуги чи товари. Кінцевою метою управління виробничими потужностями є..: Визначити і...