Сопоставимые предложения начинаются с чёткого описания задачи: 12 сведений, которые стоит предоставить

Актуальный британский Sourcing Playbook указывает, что ясная спецификация должна давать участникам достаточно информации, чтобы они могли осознанно решить, хотят ли подавать предложение. Документ также подчёркивает, что без общего понимания требований трудно связать предложенные цены с ожидаемыми затратами и результатами заказчика. [1]

Government Commercial Function формулирует это ещё прямее: хорошая спецификация должна содержать достаточно информации, чтобы поставщики могли корректно рассчитать стоимость, а заказчик мог сравнивать предложения на одинаковой основе. [2]

Одновременно британский Digital, Data and Technology Playbook предостерегает от чрезмерного определения решения. Он рекомендует сосредоточиться на пользователе, проблеме и ожидаемом результате, оставляя поставщикам пространство предложить эффективный способ реализации. [3]

Вывод не звучит как "опишите всё как можно подробнее". Более полезное правило:

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

Два профессиональных предложения никогда не будут одинаковыми, и к этому не нужно стремиться.

Сопоставимость означает, что специалисты отвечают на одну и ту же проблему при примерно одинаковых предположениях.

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

При этом могут отличаться подход, последовательность действий, метод, состав команды, инструменты, деление на этапы и способ снижения риска.

Именно эти различия часто имеют ценность и должны оставаться видимыми.

Начинайте с проблемы, а не со списка функций.

Вместо "Нужно приложение с панелью, уведомлениями и отчётами" лучше написать: "Сейчас пять человек ведут процесс в таблицах и электронной почте. Трудно увидеть текущий статус дела, ответственное лицо и следующий шаг. Хотим сократить ручное отслеживание и иметь одно место с актуальным состоянием."

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

Federal Acquisition Regulation для услуг, ориентированных на результат, рекомендует описывать работу прежде всего через требуемые результаты, а не через способ выполнения или количество часов. Минимальное описание целей включает цель, объём, контекст, требуемые результаты и операционные ограничения. [4]

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

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

Одна и та же конечная потребность может требовать разного объёма работы в зависимости от исходной ситуации.

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

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

Объём не должен заставлять специалистов гадать, какие части проблемы нужно оценить.

В объёме: анализ текущего решения, дизайн новых экранов, реализация, перенос определённой части данных.

Вне объёма: создание нового контента, покупка лицензий, поддержка после первого месяца, перестройка платёжной системы.

В образце Terms of Reference Всемирный банк подчёркивает, что требования и ожидания к услугам должны быть ясно сформулированы и адаптированы к конкретному проекту. [5]

Границы особенно важны, когда две задачи естественно связаны и легко предположить, что одна включает другую.

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

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

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

FAR прямо включает операционные ограничения в описание целей, а британский Digital, Data and Technology Playbook показывает, почему не следует навязывать решение, если реального ограничения нет. [4] [3]

Укажите то, что специалист не может изменить, но не придумывайте ограничение только потому, что привыкли к одному решению.

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

Если вы ещё не знаете, что сможете предоставить, скажите об этом. Отсутствие доступа к данным, материалам или людям может изменить метод, стоимость и сроки. Это часть условий, на которых строится предложение.

Различайте желаемую дату начала, жёсткий конечный срок, дату, связанную с внешним событием, ориентировочную дату и этапы, которые должны идти в определённой последовательности.

Если срок нельзя сдвинуть, объясните почему. Если он гибкий, тоже укажите это. Тогда специалист сможет предложить другой объём, порядок или поэтапную реализацию.

Нет единого правила, по которому клиент всегда должен раскрывать весь бюджет.

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

Для сравнения важно, чтобы стоимость была представлена одинаково. Например: "Укажите отдельно цену за анализ, дизайн, реализацию и ежемесячную поддержку. Также перечислите внешние расходы, которые не включены."

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

GAO подчёркивает важность явных предположений и анализа риска и неопределённости. [6]

Специалист сможет заложить резерв, предложить исследовательский этап, оценить варианты, назвать условия изменения цены и не изображать точность, которой пока невозможно честно достичь.

Явная неизвестность лучше скрытого предположения.

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

Материалы Всемирного банка по Rated Criteria указывают, что неценовые критерии могут включать качество методики и плана работы, управление рисками, способность к выполнению и ключевой персонал. [7]

Для небольшой задачи не нужна формальная система баллов. Достаточно ответить: "Что, кроме цены, сделает одно предложение лучше для меня, чем другое?"

Если вы действительно хотите сравнивать предложения, попросите всех ответить на одинаковые вопросы:

1. Как вы понимаете проблему и ожидаемый результат?
2. Какой подход предлагаете?
3. Что именно входит в предложение?
4. Что исключено?
5. Какие предположения вы принимаете?
6. Каков график?
7. Что вам нужно от клиента?
8. Какие основные риски?
9. Какова цена и что в неё входит?
10. Какой похожий опыт или доказательства работы важны для этой задачи?

Government Commercial Function подчёркивает необходимость информации, позволяющей правильно рассчитывать стоимость и сравнивать предложения на одинаковой основе. [2]

Общий формат не должен стирать различия. Он должен делать их видимыми в одинаковых местах.

Это зависит от цели запроса. Бюджет полезно раскрыть, если объём можно адаптировать к средствам, нужен лучший вариант в заданном пределе или требуется быстро исключить финансово нереалистичные предложения.

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

Главное - объяснить какого типа ценовой ответ вы ожидаете: одну сумму, диапазон, варианты, цены по этапам или предположения для точной оценки.

Хорошее описание задачи может честно сказать: "Мы не знаем, можно ли безопасно расширять текущую систему", "Не знаем точного числа записей для переноса", "Не решили, входит ли второй язык в первый этап" или "Нам нужна помощь в выборе варианта".

Неопределённость должна влиять на способ подготовки предложения, а не исчезать из документа.

Иногда лучшей первой услугой будет короткий исследовательский этап, заканчивающийся решением, точным объёмом или более надёжной оценкой.

1. Отправлять каждому специалисту разный набор информации.

2. Перечислять функции без объяснения проблемы и цели.

3. Не описывать то, что уже существует.

4. Скрывать ограничения, которые позже меняют способ выполнения.

5. Просить одну конечную цену, не объясняя, что она должна включать.

6. Оценивать предложения по критериям, которые заранее не определены.

7. Путать подробное описание проблемы с подробным навязыванием решения.

1. Я описал проблему, а не только придуманное решение?
2. Понятен желаемый результат?
3. Специалист понимает текущее состояние?
4. Понятно, что нужно сохранить?
5. Ясны границы первого объёма?
6. Названы главные результаты для передачи?
7. Указаны реальные ограничения?
8. Понятно, что я обеспечу со своей стороны?
9. Описаны сроки и их гибкость?
10. Формат цены позволяет сравнить предложения?
11. Открыто названы главные неизвестные?
12. Я знаю, что оцениваю кроме цены?
13. Все отвечают на похожий набор вопросов?
14. Оставлено место для решения лучше моего собственного?

Хорошее описание должно быть достаточно конкретным, чтобы несколько специалистов оценивали одну проблему, и одновременно достаточно открытым, чтобы каждый мог предложить более сильный подход.

Полезная последовательность:

проблема -> результат -> текущее состояние -> объём -> результаты -> ограничения -> обязанности клиента -> сроки -> формат цены -> неизвестные и риски -> критерии выбора -> общий формат ответа.

Если один специалист оценил весь проект, другой только анализ, а третий предположил дополнительные интеграции, проблема может быть не в ценах.

Возможно, каждый получил другую задачу, хотя всем отправили один и тот же текст.

[1] UK Government - The Sourcing Playbook
Открыть источник

[2] Government Commercial Function - How to write a procurement specification
Открыть источник

[3] UK Government - The Digital, Data and Technology Playbook
Открыть источник

[4] U.S. Federal Acquisition Regulation - Subpart 37.6, Performance-Based Acquisition
Открыть источник

[5] World Bank - Sample Consultants Terms of Reference
Открыть источник

[6] U.S. Government Accountability Office - Cost Estimating and Assessment Guide, GAO-20-195G
Открыть источник

[7] World Bank - Rated Criteria
Открыть источник

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