RFP checklist за разработка на софтуер

Една заявка за оферта за разработка на софтуер трябва предварително да опише проблема, функционалните и нефункционалните изисквания, сигурността, данните, търговските условия и метода за оценяване. Оценявайте претеглените критерии, проверявайте препоръките вместо да приемате case study и проведете кратък платен пилот, преди да поемете бюджетен ангажимент.

Какво трябва да съдържа един RFP?

Документът съществува, за да направи отговорите сравними. Доставчикът може да отговори само на написаното; RFP, който описва визия и иска цена, води до предложения, които звучат отлично, но не могат да се сравнят. Функционалното съдържание, ограниченията и правилото за оценяване трябва да са фиксирани преди първия отговор.

Има и важна последователност: RFP не е мястото, където откривате от какво имате нужда. Изискванията идват от вътрешна работа — собствениците на процеси описват как действително работи бизнесът, финансите казват какво трябва да се съгласува, а бъдещите ежедневни потребители посочват настоящата болка. Ако тази работа бъде оставена на първия доставчик, изискванията се написват на езика на неговия продукт и всички други предложения изглеждат неподходящи.

Разграничавайте 3 често обърквани документа. RFI пита пазара какво съществува; кратък е, предхожда изискванията и не ангажира никого. RFP иска предложение по определени изисквания и метод за оценяване. RFQ иска цена за определен обхват. RFQ преди да има обхват сравнява 3 числа, които означават 3 различни неща.

Пълният RFP прави 5 неща:

• Определя проблема, не решението. „Съкращаване на месечния консолидиран отчет от дни до определен брой часове“ е проблем; „изградете ни data warehouse“ е предположение за решение.


• Разделя изисквания от предпочитания. Задължителни условия за преминаване, желателни условия за класиране и удобства, които не променят резултата.


• Назовава ограниченията. Съществуващи системи за интеграция, данни за миграция, одитни и архивни задължения, прозорец за пускане и хората, които приемат резултата.


• Посочва метода предварително. Критерии и тежести, оценители, нужни доказателства и кога неуспешните участници получават обобщение на оценките.


• Определя датите. Срок за въпроси, период за уточнения, срок за подаване, оценяване и решение. Процес без дати привлича заети доставчици.

Структура на RFP

Функционални и нефункционални изисквания

Функционалните изисквания описват какво прави системата: процеси, роли и резултати. Нефункционалните описват колко добре го прави и често липсват, а после се налагат скъпо или изобщо не се налагат.

В повечето B2B проекти запишете изрично:

• Производителност. Време за отговор при определено натоварване за важните операции: въвеждане на поръчка, отчет и месечно приключване.


• Достъпност. Нужният uptime, прозорци за поддръжка и поведението при спиране. Цел без допустим престой не е изискване.


• Възстановяване. RTO и RPO на разбираем език: колко бързо се възобновява работата и колко работа може да бъде загубена.


• Одитна следа. Кой какво и кога е променил, колко дълго се пази, кой може да го извлече, особено при пари, стоки или лични данни.


• Достъпност и използваемост. Кой използва системата, на какви устройства и езици. Система, с която складът не може да работи, не е внедрена.


• Интеграция и данни. Кои системи се свързват, в каква посока вървят данните и кой притежава основния запис за всяка единица.

Въпроси за сигурност и compliance

Питайте за сигурността с въпроси и изисквани доказателства, не с ред „да/не“:

• ISO/IEC 27001. Има ли го доставчикът и какво покрива сертифицираният обхват? Сертификат само за търговската организация, без екипите за доставка, има конкретно значение.


• Сигурна разработка. Къде е сигурността при проектиране, code review и тестове и как се управляват зависимости и уязвимости.


• OWASP Top 10. Участва ли списъкът в прегледа на уеб компонентите? Това е конкретен въпрос, а не общо „сигурно ли е?“.


• Контрол на достъпа. Кой достига до среди и данни, как се предоставя и отнема достъпът и какво се записва.


• Задължения за данни. KVKK и GDPR, когато са приложими; кой е администратор, кой обработващ и как договорът урежда подизпълнители и уведомяване при нарушение.

Търговски условия и SLA

Искайте цена във формат за сравнение: какво включва, какво се таксува отделно и как се оценяват промените. Едно число без обхват не се сравнява с друго число; страницата за разходи и ценови модели разглежда често срещаните структури.

SLA заслужава същата точност като изискванията. Процентът за наличност има смисъл само с метод на измерване, изключения и компенсация. Времето за реакция има смисъл само с определения за тежест и работни часове. Помолете всеки доставчик да дефинира термините в SLA, вместо да приемате страница с проценти без определения.

Матрица за оценяване

Това е шаблон за копиране. Тежестите са пример: определете свои според приоритетите и запазете общо 100. Дефинирайте какво означават 1, 3 и 5 преди оценяването.

Оценявайте независимо преди обсъждане, за да не зададе първият уверен глас посоката. Записвайте по един ред обосновка на оценка. Третата дисциплина е съставът на панела: включете собственик на процеса, отговорника за данните и човек от сигурност или финанси, когато има такъв. Един технически човек с право да каже „това няма да работи със сегашните ни системи“ спестява повече разход от отстъпка.

Тежестите са публично изявление за приоритети. Ако сигурността е 5%, а цената 30%, сериозните доставчици ще го видят, както и вашият екип при подписване. Определете тежестите с вземащите решения и ги променяйте само чрез същата формалност.

Проверка на препоръки и пилот

Case study е маркетинг; проверката на препоръка е доказателство. Краткият разговор пита какво е станало: завърши ли проектът, какво се промени в обхвата, кой реално е бил в екипа, какво биха направили различно и биха ли започнали отново с този доставчик. Конкретните отговори в минало време са сигналът.

Искайте препоръка от проект със сходен размер и сложност, не от най-голямата гордост на доставчика. Реалният контакт трябва да бъде проверен от вас; човек, предварително инструктиран от доставчика, е testimonial, не независима препоръка.

Кратък платен пилот проверява как екипът работи с вашите хора при непълни изисквания. Използвайте реална работа, писмени критерии за приемане, една промяна по средата и предварително правило за решение. Страницата за IT аутсорсинг разглежда пилота по-подробно.

Договорни клаузи за проверка

• Прехвърляне на IP. Правата върху код, документация и производни резултати преминават към вас от създаването, не само при последното плащане.
• Собственост върху данните. Вашите данни остават ваши; правата на доставчика са само нужните за изпълнение.
• Приемане. Какво означава приемане, кой го обявява и какво става при непреминаване.
• Контрол на промените. Как промените се заявяват, ценообразуват и одобряват.
• Изход и преход. Изходен код, достъп, документация, помощ и прехвърляне на знанията.
• Escrow. Как се пази непрекъсваемостта, ако доставчикът не може да продължи.
• Отговорност. Лимити, изключения и незастраховани рискове.
• Прекратяване. Срокове за предизвестие, задължения след прекратяване и връщане или изтриване на данните.

Често задавани въпроси

Да изпратим ли първо RFI или RFP?

RFI е подходящ, когато пазарът или проблемът са неясни и питате какво съществува и какво струва. RFP е подходящ, когато изискванията и методът за оценяване са определени. Ако изпратите RFP по-рано, всеки доставчик ще напише липсващите изисквания на своя език.

Колко доставчици да поканим?

Толкова малко, че да прочетете всяко предложение и да се обадите на всяка препоръка. След определен брой качеството пада. Кратък списък от RFI, скрининг разговор и една сходна препоръка обикновено е по-полезен от дълъг списък с известни имена.

Как се определят тежестите?

Според вашите приоритети, преди да видите предложенията, и с agreement между хората, които ще живеят с резултата. Еднакви тежести за всичко често означават, че нищо не е по-важно. Ако цената или рискът доминират, тежестите трябва да го покажат.

Трябва ли да оценяваме цената?

Да, но като един претеглен критерий с фиксиран обхват, не като цялата оценка. Цена без описан обхват награждава доставчика, който е предположил най-малко работа. Първо фиксирайте изискванията, после сравнявайте общите суми за едно и също.

Как да оценим отговорите за сигурност?

По доказателства, не по тон. Работят 3 нива: няма позиция (1), описани политики (3), проверен обхват на сертификата плюс описана сигурна разработка и доказателства (5). Честно „нямаме сертификат“, подкрепено с писмени контроли, е по-добро от непроверимо „да“.

Можем ли да променим изискванията след RFP?

Преди подаването — да, ако промяната се съобщи на всички. След подаването — само чрез официално уточнение до всички участници. След договора това е задача на change control. Тихата промяна за един доставчик унищожава сравнимостта.

Източници и стандарти

• ISO публикува ISO/IEC 27001 за управление на информационната сигурност; потвърдете актуалното издание и обхвата на сертификата.
• OWASP публикува списъка Top 10 за рисковете при уеб приложенията.
• Принципите на матрицата следват практиката при RFP шаблони; посочените тежести са пример за редактиране, не препоръка. Страницата е насока за procurement, не правен съвет, и не твърди сертификат или одит за WorldwideTradeX.

Свързани страници

Разработка на софтуер · IT аутсорсинг от Türkiye · Разходи и ценови модели · IT одит и консултации · Поискайте оферта