Чёткий объём услуги без недосказанности: 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
Открыть источник

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