RFP на розробку програмного забезпечення працює тоді, коли описує вашу проблему, користувачів, обсяги, обмеження та бюджетний діапазон — а рішення залишає підрядникам. Слід більшості слабких пропозицій веде до RFP, які приписують рішення, замовчують цифри або приховують бюджет. Нижче — безкоштовний шаблон RFP і чесний гайд, як ним користуватися.
Цей шаблон — документ, який ми хотіли б отримувати від кожного потенційного клієнта. Він свідомо нейтральний до підрядників — одинадцять розділів із підказками для заповнення й коротким поясненням, навіщо кожен потрібен, — і безкоштовний, без обміну на email: завантажте шаблон RFP на розробку програмного забезпечення (PDF, англійською). Решта цієї статті — погляд з іншого боку столу: відповідати на RFP — частина нашої щоденної роботи, тож ми точно знаємо, які з них отримують від підрядника найкращі ідеї, а які — шаблонний цінник, скопійований з минулого проєкту. Що відбувається після того, як пропозицію прийнято, — окрема історія; вона описана на сторінці «Як ми працюємо».
Чому більшість RFP отримують погані пропозиції
Більшість шкоди спричиняють три помилки — і всі три в момент написання здаються ретельністю.
Приписане рішення. RFP, у якому написано «збудуйте нам React-застосунок із мікросервісним бекендом», отримує цінові пропозиції саме на цей здогад — зокрема від підрядників, які бачать простіший і дешевший шлях, але рахують те, що просили, бо саме так виграють тендери. Чесний підрядник заперечить; слабкий охоче збудує неправильну річ точно за специфікацією. Опишіть проблему — і кожна пропозиція стане безкоштовним зразком того, як цей підрядник думає.
Пропущені цифри. «Портал для наших клієнтів» може обслуговувати пʼятдесят користувачів або пʼятдесят тисяч — це різні системи за дуже різні гроші. Коли обсягів немає, обережні підрядники закладають в оцінку запас на невідоме, а недбалі занижують ціну системи, яка впаде на другому місяці. У будь-якому разі число в пропозиції перестає щось означати.
Прихований бюджет. Компанії не називають бюджет, боячись, що підрядники піднімуть ціну до його межі. На практиці підрядники підганяють під нього обсяг: майже кожна софтверна задача має версію за $30 000 і версію за $300 000, і без діапазону ви отримуєте пропозиції, розкидані по всьому спектру, — жодна не зіставна з іншими, і більшість розвʼязує задачу іншого масштабу, ніж ваша.
| Симптом слабкого RFP | Що писати натомість |
|---|---|
| «Збудуйте нам мобільний застосунок з AI-функціями» | Проблема: «Наші диспетчери втрачають ~3 години на день, перебиваючи замовлення між двома системами» — нехай підрядники запропонують, як це виправити |
| Жодних цифр про користувачів чи обсяги | Ролі, кількість людей і транзакції на день чи місяць — сьогодні й через два роки; приблизно — цілком достатньо |
| «Бюджет: обговоримо» | Діапазон із нижньою та верхньою межею — підрядники підганяють під нього обсяг, а невідповідні відсіюються самі |
| Сорок функцій, усі однаково важливі | Безжально короткий список must-have, окремий список nice-to-have і явний рядок «поза обсягом» |
| «Має інтегруватися з нашою ERP» | Кожна система поіменно, зі статусом API та відповідальним із вашого боку |
| Жодних критеріїв оцінювання | Як ви зважуватимете пропозиції, плюс однакові жорсткі запитання кожному підряднику |
Що містить хороший RFP: 11 розділів
Шаблон проводить через одинадцять розділів; кожен супроводжується підказками для заповнення й коротким поясненням, навіщо він підрядникам. Стисло:
- Компанія та контекст — хто ви і чому саме зараз; під це підрядники калібрують усе інше.
- Проблема, а не рішення — розділ з найвищою віддачею в усьому документі.
- Поточний процес і системи — включно з ручними кроками й обхідними шляхами, якими ніхто не пишається.
- Обсяг: must-have vs nice-to-have — щоб не платити ціну must-have за nice-to-have.
- Користувачі та обсяги — ролі, кількість, частота, зростання; приблизні цифри кращі за жодних.
- Інтеграції та обмеження — класичне місце, де бюджет непомітно зсувається; кожна система поіменно.
- Критерії успіху та метрики — розмова про приймання, перенесена в дешевий кінець проєкту.
- Терміни та бюджетні рамки — чесно названий діапазон і те, що робить ваш дедлайн жорстким.
- Команда та процес ухвалення рішень — хто у вас власник продукту і хто підписує; швидкість рішень — справжній ризик для графіка.
- Критерії оцінювання — включно із запитаннями, що викривають слабких підрядників (про них нижче).
- Логістика подання — дедлайни, формат і вікно для запитань, яке важить більше, ніж здається.
Розділ 10 заслуговує окремої згадки. Шаблон містить пʼять запитань до кожного підрядника: хто саме робитиме роботу — імена та рівень, а не «наша команда з 200 людей»; що відбувається після запуску — в контракті, а не в пітчі; як розраховується вартість змін посеред проєкту; який вигляд має звичайний тиждень співпраці; і — запитання, що фільтрує найшвидше, — схожий проєкт, де щось пішло не так. У кожного досвідченого підрядника така історія є. Підрядник без такої історії — не підрядник без провалів; це підрядник без чесності щодо них.
Як підрядники насправді читають ваш RFP
Кілька речей, яких ніхто не пише у своєму маркетингу, — тут вони тому, що зроблять ваш RFP кращим:
- Розділ про бюджет читають першим. Не з жадібності — для швидкого сортування: він за десять секунд відповідає, про яку версію вашої проблеми йдеться — за $30 000 чи за $300 000 — і чи варто цьому підряднику взагалі подаватися.
- Відсутня інформація не залишається відсутньою — вона отримує ціну. Кожна прогалина стає або запасом на ризик у ціновій пропозиції, або change request-ом після підписання. За розмитість ви платите в будь-якому разі; RFP лише вирішує, коли саме.
- Точність притягує сеньйорну увагу. RFP зі справжніми обсягами, назвами систем і названим діапазоном сигналізує про клієнта, з яким буде добре працювати, — і непомітно опиняється на верхівці стосу, де його оцінюють досвідчені люди. Розмита розсилка на пʼятнадцять агенцій отримує шаблонну відповідь зі скриньки відділу продажів.
- Запитання перед пропозицією — і є справжня співбесіда. Підрядники, яких ви хочете, повернуться із запитаннями ще до цінової пропозиції. Залиште вікно для запитань, відповідайте щедро й нотуйте, хто про що питав: підрядник, який не питає нічого, збирається оцінювати ваш проєкт наосліп.
Завантажте шаблон
Завантажте шаблон RFP на розробку програмного забезпечення (PDF, англійською) — безкоштовний, нейтральний до підрядників, без email. Заповніть його, надішліть трьом-пʼятьом підрядникам, яких ви справді розглядаєте, — і отримаєте пропозиції, які можна порівнювати між собою. Якщо один із цих підрядників — ми, тим краще: наші послуги розробки охоплюють веб-платформи, чат-боти, AI та автоматизацію, а наш процес крок за кроком описано на сторінці «Як ми працюємо».
Поширені запитання
Чи потрібен повний RFP для малого проєкту?
Ні. Для невеликої розробки достатньо розділів 2, 4, 5 і 8 — проблема, поділ на must-have і nice-to-have, обсяги, бюджетний діапазон — на одній сторінці; решта шаблону працює як чекліст, щоб не пропустити нічого важливого. Для багатьох малих проєктів звичайний discovery-дзвінок замінює RFP повністю — і будь-який підрядник має запропонувати його ще до того, як просити у вас папери.
Чи справді варто називати бюджетний діапазон?
Так — діапазон, а не одне число. Підрядники підганяють обсяг під діапазон: він вирішує, яку версію рішення вам запропонують, і відсіює невідповідних підрядників до того, як хтось витратить тиждень на пропозицію. Приховування бюджету не рятує від завищених цін — воно лише робить пропозиції непорівнюваними.
Скільком підрядникам надсилати RFP?
Трьом-пʼятьом, яких ви справді розглядаєте. Менше — і вам нема з чим порівнювати; більше — і оцінювання стає окремим проєктом, а досвідчені підрядники, відчувши лотерею, відповідають шаблонами замість того, щоб думати.
А якщо ми ще не знаємо своїх вимог?
Так і напишіть в RFP — «ми ще не знаємо» цілком легітимна відповідь, і те, як підрядник до неї поставиться, — саме по собі сигнал. Сильні запропонують фазу discovery, щоб дослідити процес і визначити обсяг розробки, перш ніж оцінювати весь проєкт; саме так мають починатися кастомні софтверні проєкти — і саме так ми ведемо свої.
