Порівнювані пропозиції починаються з чіткого опису завдання: 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
Відкрити джерело

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