Jak napisać zapytanie ofertowe na aplikację webową

Po co dobre zapytanie: porównywalne oferty

Jednozdaniowe zapytanie typu „potrzebuję aplikacji do zamówień” da ci tyle różnych odpowiedzi, ilu wykonawców zapytasz. Każdy zrozumie je inaczej, założy inny zakres i wyceni coś innego. Porównanie cen traci sens.

Zapytanie, które opisuje cel, użytkowników i ograniczenia, pozwala wykonawcy zadać trafniejsze pytania, a tobie ocenić, kto rozumie problem. Dobry wykonawca często odpowie pytaniami, a nie liczbą.

Krok 1: problem i cel w kilku zdaniach

Zacznij od problemu, nie od rozwiązania. Zamiast „potrzebuję aplikacji mobilnej z panelem administracyjnym” napisz, co dziś nie działa i co ma działać.

Odpowiedz na pytania:

• jaki proces chcesz usprawnić i jak wygląda dziś,
• ile osób i ile czasu angażuje,
• co będzie sygnałem, że aplikacja spełniła cel (na przykład „zamówienia nie są przepisywane ręcznie”),
• co jest poza zakresem tego projektu.

Nie podawaj liczb, których nie znasz. Lepiej napisać „brak pomiaru, szacunkowo biuro poświęca na to kilka godzin dziennie”, niż wpisać dokładną wartość z niczego.

Krok 2: kto będzie używać aplikacji

Opisz grupy użytkowników: kim są, ile ich jest w przybliżeniu, na jakich urządzeniach pracują i jakie mają uprawnienia.

Przykładowa lista (hipotetyczna): pracownik biura wprowadza zamówienia, kierownik zatwierdza, klient zewnętrzny widzi tylko swoje dane. Dla każdej grupy zapisz, co ma móc zrobić i czego nie może zobaczyć.

Zaznacz, czy aplikacja ma działać na telefonie, na komputerze, czy w obu środowiskach. Napisz, czy użytkownicy pracują w miejscach bez stabilnego internetu, bo to wpływa na projekt.

Krok 3: systemy, z którymi aplikacja ma działać

To zwykle największe źródło ukrytych kosztów. Wymień każdy system, z którym aplikacja ma wymieniać dane: sklep internetowy, ERP, CRM, poczta, system kurierski, bank, księgowość.

Dla każdego zapisz:

• nazwę i wersję systemu,
• kierunek wymiany (w jedną stronę, w obie strony),
• jakie dane przechodzą,
• czy system ma udokumentowany interfejs (API, SDK, import plików),
• kto jest administratorem po twojej stronie.

Jeśli czegoś nie wiesz, napisz to wprost. Wykonawca doceni uczciwą informację o niewiadomych.

Krok 4: dane, uprawnienia i bezpieczeństwo

Opisz, jakie dane aplikacja będzie przetwarzać i skąd się wezmą. Zaznacz, czy są wśród nich dane osobowe klientów lub pracowników. Jeśli tak, wykonawca ma do nich dostęp, więc zwykle potrzebna będzie umowa powierzenia przetwarzania danych. UODO zaznacza, że powierzenie przetwarzania trzeba udokumentować, a umowa powinna określać między innymi przedmiot, czas i cel przetwarzania, rodzaj danych, kategorie osób oraz zasady zwrotu lub usunięcia danych po zakończeniu. To nie jest porada prawna, więc umowę skonsultuj z prawnikiem.

Napisz też:

• kto ma mieć dostęp do jakich danych (role i uprawnienia),
• czy dane mają być przechowywane w konkretnym kraju lub u konkretnego dostawcy,
• jak długo mają być przechowywane,
• czy potrzebujesz kopii zapasowych i jak często,
• czy masz wymagania wewnętrzne dotyczące bezpieczeństwa.

Poproś wykonawcę o opis, jak zabezpiecza aplikację i dane.

Krok 5: etapy, termin i sposób odbioru

Podziel projekt na etapy, z których każdy daje coś, co można sprawdzić. Dobrą praktyką jest pierwszy mały etap: najważniejszy proces, uruchomiony na ograniczonej grupie użytkowników.

Ustal:

• co wchodzi w pierwszy etap, a co w kolejne,
• termin, który ma znaczenie dla firmy (sezon, zmiana przepisów, inwentaryzacja), i dlaczego,
• jak będzie wyglądał odbiór: kto i według jakich kryteriów sprawdza efekt,
• jak zgłaszane są poprawki po odbiorze i w jakim czasie,
• kto po stronie firmy podejmuje decyzje i odpowiada na pytania wykonawcy.

Zapytaj o prawa do kodu. Program komputerowy jest według ustawy o prawie autorskim chroniony jak utwór literacki, a prawa majątkowe obejmują między innymi zwielokrotnianie, zmiany i rozpowszechnianie. Zapytaj więc wprost, na jakich zasadach dostaniesz prawa do korzystania z kodu i jego rozwijania, czy dostaniesz kod źródłowy i dokumentację oraz co się stanie, jeśli zmienisz wykonawcę.

Wzór struktury zapytania

Poniższą listę nagłówków możesz skopiować do e-maila lub dokumentu i wypełnić własnymi danymi.

1. Firma i osoba kontaktowa
2. Problem i cel projektu
3. Obecny sposób pracy
4. Użytkownicy i role
5. Funkcje najważniejsze (do pierwszego etapu)
6. Funkcje dodatkowe (na później)
7. Systemy i integracje
8. Dane, uprawnienia, bezpieczeństwo
9. Etapy i terminy
10. Sposób odbioru i poprawek
11. Prawa do kodu, dokumentacja, utrzymanie
12. Pytania do wykonawcy: co jeszcze potrzebujesz wiedzieć, żeby przygotować wycenę?
13. Termin odpowiedzi i forma oferty

Do każdego punktu napisz po kilka zdań. Dwustronicowe zapytanie jest zwykle wystarczające. Poproś też wykonawców, aby w ofercie osobno wskazali założenia, ryzyka i elementy, których nie wycenili.

Co dołączyć do zapytania

Opis słowny ułatwiają materiały, które masz pod ręką:

• zrzuty ekranu lub nagranie obecnego sposobu pracy, na przykład arkusza, w którym dziś prowadzisz zamówienia (usuń z nich dane osobowe),
• przykładowy plik wymiany danych z innym systemem, bez prawdziwych danych klientów,
• lista raportów lub dokumentów, które aplikacja ma generować, z wyglądem, jeśli go masz,
• opis uprawnień w formie tabeli: rola, co widzi, co może zmienić.

Nie wysyłaj prawdziwych danych osobowych ani haseł do systemów. Do oceny zakresu wystarczą dane przykładowe.

Najczęstsze błędy w zapytaniach

• Opis rozwiązania zamiast problemu. „Potrzebuję aplikacji z trzema ekranami” zamyka wykonawcę na lepszy pomysł.
• Brak informacji o integracjach. To one najczęściej zmieniają wycenę, a zostają opisane dopiero w trakcie projektu.
• Brak informacji o tym, kto decyduje. Gdy zakres zatwierdza kilka osób, a nikt nie ma ostatniego słowa, projekt się wydłuża.
• Wszystko jest priorytetem. Oddziel to, co potrzebne w pierwszym etapie, od tego, co poczeka.
• Pytanie wyłącznie o cenę. Dwa podobne zapytania mogą dać wyceny różniące się mocno, jeśli wykonawcy przyjęli inne założenia. Poproś o ich opisanie.
• Zapytanie wysłane do zbyt wielu firm. Kilku wykonawców wystarczy do porównania, a każdemu trzeba odpowiedzieć na pytania.

Jak porównać odpowiedzi

Zestaw oferty w tabeli według tych samych punktów: zakres, założenia, etapy, termin, koszty utrzymania, prawa do kodu, sposób odbioru. Różnica w cenie często wynika z różnych założeń, a nie z lepszej lub gorszej oferty. Zapytaj o każdą istotną różnicę.

Po wysłaniu zapytania

Ustal z góry, w jakim terminie oczekujesz odpowiedzi i czy odpowiadasz na pytania wykonawców zbiorczo, żeby wszyscy mieli te same informacje. Rozmowę z wykonawcą warto zacząć od jego pytań: ich jakość często mówi więcej niż sama wycena. Zapisz odpowiedzi na pytania wykonawców, bo to właśnie one uzupełniają zapytanie o brakujące założenia, które potem trafią do umowy.

Jak długo powinno być zapytanie

Nie ma idealnej długości. Dla małej aplikacji wystarczy strona lub dwie, dla złożonego systemu kilka stron z załącznikami. Pilnuj proporcji: im mniej wiesz, tym więcej pytań zadaj wykonawcy, zamiast zgadywać. Lepiej napisać wprost „ten element wymaga ustalenia w pierwszym etapie”, niż udawać, że wszystko jest ustalone. Taki zapis pozwala zaproponować etap analizy przed budową, co często obniża ryzyko całego projektu.

Przykład opisu jednego wymagania

Zamiast „system ma obsługiwać zamówienia” napisz: „pracownik biura wpisuje zamówienie od klienta, wybiera produkty z listy, widzi cenę dla tego klienta i stan magazynowy, a po zapisaniu zamówienie trafia do programu magazynowego”. Takie zdanie można wycenić, przetestować i odebrać, bo wskazuje kto, co i z jakim skutkiem robi. Przykład jest hipotetyczny, ale pokazuje poziom szczegółowości, który wystarcza do porównywalnych ofert.

Podsumowanie

Dobre zapytanie ofertowe zaczyna się od problemu, opisuje użytkowników, systemy i dane, dzieli pracę na etapy i określa sposób odbioru. Dzięki temu dostajesz wyceny, które da się porównać, i widzisz, kto rozumie twoją potrzebę. Jeśli chcesz wysłać zapytanie do M8T, przejdź do opisu współpracy, a zakres realizowanych prac znajdziesz w usługach.