Zapytanie ofertowe (RFP) na tworzenie oprogramowania działa wtedy, gdy opisuje Twój problem, użytkowników, wolumeny, ograniczenia i widełki budżetowe — a rozwiązanie zostawia wykonawcom. Większość słabych ofert ma wspólne źródło: RFP, które narzuca rozwiązanie, pomija liczby albo ukrywa budżet. Poniżej: darmowy szablon RFP i uczciwy przewodnik, jak z niego korzystać.
Szablon to dokument, który sami chcielibyśmy dostawać od każdego potencjalnego klienta. Jest celowo neutralny wobec wykonawców — jedenaście sekcji z podpowiedziami do wypełnienia i notką, dlaczego każda z nich ma znaczenie — i darmowy, bez zostawiania maila: pobierz szablon RFP na tworzenie oprogramowania (PDF, po angielsku). Reszta tego artykułu to widok z drugiej strony stołu: odpowiadanie na RFP to nasza codzienna praca, więc dokładnie wiemy, nad którymi wykonawca naprawdę myśli, a które zbywa wyceną skopiowaną z szablonu. Co dzieje się po przyjęciu oferty, to osobna historia — opisaliśmy ją na stronie Jak pracujemy.
Dlaczego większość RFP dostaje słabe oferty
Za większość szkód odpowiadają trzy błędy — i każdy z nich, w momencie popełniania, do złudzenia przypomina rzetelność.
Narzucanie rozwiązania. RFP w stylu „zbudujcie nam aplikację w React z backendem na mikroserwisach” dostaje wyceny właśnie tej hipotezy — także od wykonawców, którzy widzą prostszą i tańszą drogę, ale wyceniają to, o co poproszono, bo tak wygrywa się przetargi. Uczciwy wykonawca zaoponuje; słaby z przyjemnością zbuduje niewłaściwą rzecz dokładnie według specyfikacji. Opisz problem, a każda oferta stanie się darmową próbką tego, jak dany wykonawca myśli.
Pomijanie liczb. „Portal dla naszych klientów” może służyć pięćdziesięciu użytkownikom albo pięćdziesięciu tysiącom — to różne systemy w bardzo różnych cenach. Gdy brakuje wolumenów, ostrożni wykonawcy dokładają do wyceny margines na niewiadome, a niedbali zaniżają cenę systemu, który wywróci się w drugim miesiącu. Tak czy inaczej liczba w ofercie przestaje cokolwiek znaczyć.
Ukrywanie budżetu. Firmy nie podają budżetu w obawie, że wykonawcy podciągną cenę pod jego górną granicę. W praktyce wykonawcy dopasowują do niego zakres: niemal każdy problem, który rozwiązuje się oprogramowaniem, ma wersję za 30 tys. i wersję za 300 tys. dolarów, a bez widełek dostajesz oferty rozrzucone po całym tym spektrum — nieporównywalne ze sobą i w większości rozwiązujące problem innego kalibru niż Twój.
| Objaw słabego RFP | Co napisać zamiast tego |
|---|---|
| „Zbudujcie nam aplikację mobilną z funkcjami AI” | Problem: „Nasi dyspozytorzy tracą ok. 3 godziny dziennie na przepisywanie zamówień między dwoma systemami” — a rozwiązanie niech zaproponują wykonawcy |
| Brak danych o liczbie użytkowników i wolumenach | Role, liczba osób i transakcji dziennie lub miesięcznie — dziś i za dwa lata; wartości przybliżone wystarczą |
| „Budżet: do uzgodnienia” | Widełki z dolną i górną granicą — wykonawcy dopasują do nich zakres, a niedopasowani sami się wycofają |
| Czterdzieści funkcji, wszystkie równie ważne | Bezlitośnie krótka lista must-have, osobna lista nice-to-have i wyraźna pozycja „poza zakresem” |
| „Musi się integrować z naszym ERP” | Każdy system z nazwy, ze statusem API i właścicielem po Twojej stronie |
| Brak kryteriów oceny | Jak zamierzasz ważyć oferty, plus ten sam zestaw trudnych pytań dla każdego wykonawcy |
Co zawiera dobre RFP: 11 sekcji
Szablon prowadzi przez jedenaście sekcji; każda ma podpowiedzi do wypełnienia i krótką notkę, po co wykonawcom te informacje. W skrócie:
- Firma i kontekst — kim jest Twoja firma i dlaczego rusza z tym właśnie teraz; do tego wykonawcy kalibrują całą resztę.
- Problem, nie rozwiązanie — sekcja o największej dźwigni w całym dokumencie.
- Obecny proces i systemy — łącznie z ręcznymi krokami i obejściami, z których nikt nie jest dumny.
- Zakres: must-have vs nice-to-have — żeby nie płacić cen must-have za pozycje nice-to-have.
- Użytkownicy i wolumeny — role, liczby, częstotliwość, wzrost; lepsze liczby przybliżone niż żadne.
- Integracje i ograniczenia — klasyczny cichy winowajca rosnącego budżetu, spisany system po systemie.
- Kryteria sukcesu i metryki — rozmowa o odbiorze projektu, przeniesiona na jego początek, gdzie jest jeszcze tania.
- Harmonogram i ramy budżetowe — uczciwie podane widełki oraz to, co sprawia, że dany termin jest naprawdę nieprzesuwalny.
- Zespół i proces decyzyjny — Twój product owner i to, kto zatwierdza decyzje; tempo decyzji to prawdziwe ryzyko dla harmonogramu.
- Kryteria oceny — w tym pytania, które obnażają słabych wykonawców (więcej niżej).
- Logistyka składania ofert — terminy, format i okno na pytania, które znaczy więcej, niż się wydaje.
Sekcja 10 zasługuje na osobne omówienie. Szablon zawiera pięć pytań, które warto zadać każdemu wykonawcy: kto dokładnie wykona pracę — nazwiska i doświadczenie, a nie „nasz 200-osobowy zespół”; co dzieje się po wdrożeniu — zapisane w umowie, a nie w prezentacji handlowej; jak wyceniane są zmiany w trakcie projektu; jak wygląda zwykły tydzień współpracy; oraz — pytanie, które filtruje najszybciej — o podobny projekt, w którym coś poszło nie tak. Każdy doświadczony wykonawca ma taką historię. Wykonawca, który jej nie ma, to nie wykonawca bez porażek — to wykonawca, któremu brakuje uczciwości, żeby o nich mówić.
Jak wykonawcy naprawdę czytają Twoje RFP
Kilka rzeczy, których nikt nie wpisuje do materiałów marketingowych — dzielimy się nimi, bo dzięki nim Twoje RFP będzie lepsze:
- Sekcję o budżecie czyta się jako pierwszą. Nie z chciwości — to triaż. W dziesięć sekund odpowiada na pytanie, czy na stole leży wersja Twojego problemu za 30, czy za 300 tys. dolarów — i czy ten wykonawca w ogóle powinien składać ofertę.
- Brakująca informacja nigdy nie znika — zostaje wyceniona. Każda luka zamienia się albo w margines ryzyka w wycenie, albo w change request po podpisaniu umowy. Za nieprecyzyjność płacisz tak czy inaczej; RFP decyduje tylko o tym, kiedy.
- Precyzja przyciąga uwagę doświadczonych ludzi. RFP z realnymi wolumenami, systemami wymienionymi z nazwy i podanymi widełkami sygnalizuje klienta, z którym będzie się dobrze pracować — i po cichu wędruje na górę stosu, tam gdzie zakres wyceniają najbardziej doświadczeni. Ogólnikowe zapytanie rozesłane do piętnastu agencji dostaje szablonową odpowiedź ze skrzynki działu sprzedaży.
- Pytania przed złożeniem oferty to właściwa rozmowa kwalifikacyjna. Wykonawcy, na których Ci zależy, wrócą z pytaniami, zanim cokolwiek wycenią. Zostaw okno na pytania, odpowiadaj wyczerpująco i notuj, kto o co pytał — wykonawca, który nie pyta o nic, zamierza wycenić Twój projekt w ciemno.
Pobierz szablon
Pobierz szablon RFP na tworzenie oprogramowania (PDF, po angielsku) — darmowy, neutralny wobec wykonawców, bez zostawiania maila. Wypełnij go, wyślij do trzech–pięciu wykonawców, których naprawdę bierzesz pod uwagę, a dostaniesz oferty, które faktycznie da się porównać. Jeśli jednym z tych wykonawców będziemy my — tym lepiej: nasze usługi tworzenia oprogramowania obejmują platformy webowe, chatboty, AI i automatyzację, a nasz proces opisaliśmy krok po kroku na stronie Jak pracujemy.
FAQ: najczęstsze pytania
Czy do małego projektu potrzebne jest pełne RFP?
Nie. Przy małym projekcie wystarczą sekcje 2, 4, 5 i 8 — problem, podział zakresu, wolumeny, widełki budżetowe — spisane na jednej stronie; reszta szablonu działa wtedy jak checklista, dzięki której nic ważnego nie umknie. W wielu małych projektach całe RFP zastępuje zwykła rozmowa discovery — i każdy wykonawca powinien ją zaproponować, zanim poprosi Cię o papierologię.
Czy naprawdę warto podawać widełki budżetowe?
Tak — widełki, nie pojedynczą kwotę. Wykonawcy dopasowują zakres do widełek: to one decydują, którą wersję rozwiązania zaproponują, i odsiewają niedopasowanych, zanim ktokolwiek spędzi tydzień nad ofertą. Ukrywanie budżetu nie chroni przed zawyżonymi cenami — odbiera za to ofertom porównywalność.
Do ilu wykonawców wysłać RFP?
Do trzech–pięciu, których naprawdę bierzesz pod uwagę. Przy mniejszej liczbie nie masz porównania; przy większej sama ocena ofert urasta do osobnego projektu — a doświadczeni wykonawcy, wyczuwając loterię, odpowiadają szablonem zamiast myśleniem.
Co, jeśli jeszcze nie znamy swoich wymagań?
Napisz to w RFP wprost — „jeszcze nie wiemy” to pełnoprawna odpowiedź, a to, jak wykonawca ją potraktuje, samo w sobie jest sygnałem. Mocni zaproponują etap discovery: zmapowanie procesu i określenie zakresu, zanim wycenią cały projekt. Dokładnie tak powinny zaczynać się projekty oprogramowania na zamówienie — i tak właśnie prowadzimy nasze.
