Чіткий обсяг послуги без недомовок: 10 елементів, щоб клієнт розумів, що саме купує

Чинні американські Federal Acquisition Regulation для послуг, орієнтованих на результат, рекомендують описувати роботу насамперед через потрібні результати, а не через нав'язування способу виконання або лише кількості годин. Правила також посилаються на вимірювані стандарти виконання, а в описі цілей перелічують, зокрема, мету, обсяг, період і місце виконання, контекст, потрібні результати та операційні обмеження. [1]

Британський Digital, Data and Technology Playbook також підтримує чіткі специфікації, орієнтовані на результат. Він прямо рекомендує зосереджуватися на користувачеві та проблемі, яку потрібно вирішити, а не наперед нав'язувати технічне рішення. [2]

Актуальна британська настанова щодо розподілу ризиків і підходів до ціноутворення додатково підкреслює, що показники виконання мають бути вимірюваними й об'єктивними, а постачальник має відповідати за результати, на які він реально може впливати. [3]

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

Хороший опис має одночасно допомагати:

Клієнту - розуміти, що він отримає, чого не отримає і що буде потрібно від нього.

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

Обом сторонам - погодити, як можна розумно визначити, що узгоджена робота завершена.

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

Спочатку поясніть, навіщо потрібна послуга.

Не починайте зі списку інструментів або дій, якщо клієнт ще не розуміє мету.

Замість:

"Налаштування аналітики, звітів і подій."

краще:

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

Цей підхід відповідає принципу описувати потреби та результати, а не нав'язувати рішення, який застосовує британський Digital, Data and Technology Playbook. [2]

Мета відповідає на питання "чому?", а результат - на питання "що має існувати або бути правдою після завершення роботи?"

Результатом може бути, наприклад:

• готовий документ,
• працююча функція,
• впроваджене налаштування,
• завершене дослідження з висновками,
• підготовлений комплект матеріалів,
• проведена сесія з визначеним підсумком.

Для послуг, орієнтованих на результат, FAR описує вимоги насамперед через потрібні результати, а не лише через спосіб виконання. [1]

Це не означає, що кожна послуга має гарантувати бізнес-результат, який фахівець не контролює. Фахівець може зобов'язатися запустити кампанію в погодженому обсязі, але гарантоване зростання продажів на 30% може залежати від багатьох чинників поза його контролем.

Обсяг має називати конкретні частини роботи, які охоплює домовленість.

Наприклад, у проєкті сайту це можуть бути:

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

Мета не в тому, щоб зробити найдовший список. Мета - назвати основні елементи, які впливають на трудомісткість і очікування до початку роботи.

Обсяг описує роботу, а матеріали та результати описують що саме отримає клієнт.

Наприклад:

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

Якщо форма результату має значення, її потрібно назвати. "Звіт" може означати дві сторінки тексту або детальний документ з аналізом, пріоритетами та прикладами. Самої назви не завжди достатньо.

Критерії приймання відповідають на питання: за чим можна визначити, що погоджений результат доставлено відповідно до вимог?

Вони можуть стосуватися, наприклад:

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

FAR вимагає, щоб стандарти виконання в орієнтованих на результат договорах на послуги були вимірюваними й дозволяли оцінювати виконання. [1]

Британська настанова щодо ризику додатково зазначає, що показники мають бути об'єктивними та стосуватися результатів, на які постачальник може впливати. [3]

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

Послуга часто залежить від дій іншої сторони.

Варто вказати, чи має клієнт надати:

• доступ до систем,
• контент або матеріали,
• дані,
• інформацію про бренд,
• рішення та погодження,
• контактну особу,
• тестове середовище,
• відповіді у визначений строк.

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

Відповідальність за строки не слід описувати так, ніби фахівець контролює дії, яких він насправді не контролює.

Ціна і строк часто є правильними лише за певних припущень.

Приклади:

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

Посібник GAO з надійного оцінювання витрат вважає чітке визначення обсягу, технічних основ, правил і припущень, а також аналіз ризику та невизначеності важливими частинами якісного процесу оцінювання. [7]

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

Виключення не є ознакою слабкої пропозиції. Часто вони показують, що зобов'язання добре визначене.

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

Наприклад:

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

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

Строк має говорити більше, ніж "приблизно два тижні", якщо прогрес залежить від погоджень або матеріалів клієнта.

Варто визначити:

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

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

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

Практичний механізм може бути дуже простим:

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

Також варто чітко вказати:

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

Це не усуває зміни. Це робить зміну свідомим рішенням, а не прихованим розширенням початкового зобов'язання.

Чіткий обсяг не означає необхідність контролювати кожен крок роботи фахівця.

Британський Digital, Data and Technology Playbook застерігає від надмірного визначення рішення та зазначає, що специфікації, орієнтовані на результат, можуть залишати постачальнику простір запропонувати ефективніший спосіб розв'язання проблеми. [2]

FAR так само віддає перевагу опису потрібних результатів, а не точному нав'язуванню того, як має виконуватися робота. [1]

Тому:

"сайт має коректно підтримувати погоджені сценарії на зазначених пристроях"

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

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

Під час визначення обсягу важливо розрізняти:

безпосередній результат роботи фахівця і бізнес-результат, який залежить також від інших чинників.

Фахівець може зобов'язатися:

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

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

Актуальна британська настанова щодо розподілу ризиків прямо говорить, що постачальники мають відповідати за результати, на які можуть впливати. [3]

Хороший опис не послаблює відповідальність. Він розміщує її там, де реально існує контроль.

Не кожна послуга потребує багатосторінкового документа.

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

Зразок Terms of Reference, опублікований Світовим банком, зазначає, що такий документ має чітко викладати вимоги до консультаційних послуг і очікування замовника та бути адаптований до конкретного проєкту й місцевих умов. [4]

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

Опис послуги на сайті або в профілі може бути лише одним елементом процесу укладення договору. Конкретні правові обов'язки залежать від країни, типу транзакції, статусу сторін і способу продажу.

У відносинах між підприємцем і споживачем у ЄС офіційний портал Your Europe називає серед переддоговірної інформації основні характеристики послуги, загальну ціну з платежами, умови оплати та виконання і, якщо застосовується, строк дії договору. [5]

Матеріали ЄС для бізнесу також зазначають, що стандартні умови споживчих договорів мають бути справедливими та написаними простою і зрозумілою мовою, щоб споживач міг розуміти їхні економічні наслідки. [6]

Ці вимоги стосуються визначених споживчих відносин у ЄС. Їх не слід автоматично переносити на всі транзакції між компаніями або на інші юрисдикції.

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

1. Чи розуміє клієнт проблему або мету, яку вирішує послуга?
2. Чи названо фінальний результат?
3. Чи зрозуміло, що входить до обсягу?
4. Чи знає клієнт, які конкретні матеріали або результати отримає?
5. Чи є розумний спосіб оцінити завершення роботи?
6. Чи зрозуміло, що клієнт має надати або забезпечити?
7. Чи видимі найважливіші припущення?
8. Чи описані очевидні виключення, які можуть спричинити непорозуміння?
9. Чи враховують строки та етапи залежності обох сторін?
10. Чи зрозуміло, що відбувається при зміні обсягу?
11. Чи подано ціну, модель розрахунку та додаткові витрати на відповідному етапі?
12. Чи не обіцяє опис результату, який фахівець не контролює?

Найкращий тест хорошого опису дуже простий.

Після його прочитання клієнт і фахівець мають дати подібні відповіді на такі питання:

Чого потрібно досягти? Що буде зроблено? Що отримає клієнт? Що не входить? Що має зробити клієнт? Як ми зрозуміємо, що робота завершена? Що станеться, якщо обсяг зміниться?

Якщо відповіді збігаються, ціна і строк мають значно кращий контекст.

Якщо відповіді різняться, проблема часто починається не під час виконання. Вона починається вже в описі послуги.

[1] U.S. Federal Acquisition Regulation - Subpart 37.6, Performance-Based Acquisition
Відкрити джерело

[2] UK Government - The Digital, Data and Technology Playbook
Відкрити джерело

[3] UK Government - Risk Allocation and Pricing Approaches Guidance Note
Відкрити джерело

[4] World Bank - Sample Consultants Terms of Reference
Відкрити джерело

[5] Your Europe - Contract information: what you should know before buying
Відкрити джерело

[6] Your Europe - Contracts with consumers
Відкрити джерело

[7] U.S. Government Accountability Office - Cost Estimating and Assessment Guide, GAO-20-195G
Відкрити джерело

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