Jak napisać brief projektu IT, by dostać porównywalne oferty

Brief istnieje po to, by odpowiedzi dało się porównać

Brief projektu ma jedno zadanie: pozwolić kilku partnerom zrozumieć problem na tyle dobrze, by zaproponowali sposób jego rozwiązania z wyceną, której można zaufać. Jeśli każdy partner wypełnia luki własnymi założeniami, oferty różnią się zakresem, a nie jakością, a najtańsza jest często ta, która założyła najmniej.

Dlatego brief powinien być precyzyjny w opisie problemu i skromny w kwestii rozwiązania. Należy opisać, co musi być prawdą po zakończeniu projektu, a partnerom zostawić wyjaśnienie, jak do tego dojdą. Ich odpowiedzi na tę otwartą część to najcenniejsza lektura.

Najpierw problem biznesowy i sposób oceny sukcesu

Na początku warto wyjaśnić, po co projekt istnieje: co dziś nie działa, kogo to dotyczy i ile kosztuje pozostawienie tego bez zmian. Informacja, że dział operacyjny przepisuje każde zamówienie z e-maila do ERP, mówi partnerowi znacznie więcej niż prośba o portal do zarządzania zamówieniami.

Następnie trzeba określić, jak będzie oceniany sukces. Warto wybrać kilka obserwowalnych efektów, takich jak czas zaoszczędzony na każdym zamówieniu, błędy, które przestały docierać do klientów, albo data, od której można wyłączyć stary system. Te kryteria stają się później kryteriami odbioru kamieni milowych, więc należy je zapisać tak, by ktoś mógł je sprawdzić.

Użytkownicy, systemy i dane przed listą funkcji

Pracę integracyjną i związaną z danymi łatwo niedoszacować, gdy partner jej nie widzi. Przed wypisaniem funkcji warto opisać, kto będzie korzystał z oprogramowania, z jakimi systemami musi współpracować i jakie dane przetwarza. Luki w tej części wracają później jako zgłoszenia zmian.

• Użytkownicy: kim są, mniej więcej ilu ich jest, gdzie i na jakich urządzeniach pracują.
• Istniejące systemy: jakie to systemy, kto jest ich właścicielem i czy mają udokumentowane API, czy tylko bazę danych i eksport plików.
• Dane: które są osobowe, poufne lub regulowane, gdzie znajdują się dziś i ile z nich trzeba zmigrować.
• Utrzymanie: kto będzie obsługiwał oprogramowanie po uruchomieniu i jakie zasady dotyczące hostingu lub chmury firma już ma.
• Ograniczenia: języki, wymagania dostępności, standardy bezpieczeństwa i każdy nieprzesuwalny termin, wraz z jego powodem.

Widełki budżetu i termin, który naprawdę się liczy

Wielu kupujących zatrzymuje budżet dla siebie, aby zobaczyć, co zaproponują partnerzy. W efekcie dostają oferty na różne projekty: jeden partner projektuje minimum, inny wszystko, co zostało wspomniane. Widełki, nawet szerokie, pozwalają każdemu partnerowi zaproponować najlepszy projekt, który się w nich mieści, i otwarcie powiedzieć, jeśli się nie da.

Tak samo jest z czasem. Warto napisać, która data jest stała i dlaczego, na przykład kończąca się umowa lub termin regulacyjny, a które daty są tylko preferencjami. Partner może planować wokół twardego terminu tylko wtedy, gdy wie, który to termin.

Co jest ustalone, a co pozostaje otwarte

Każde wymaganie warto oznaczyć jako ustalone, preferowane lub otwarte. Ustalone oznacza, że oferta bez niego jest nieważna, na przykład hosting w UE albo logowanie przez istniejącego dostawcę tożsamości. Preferowane oznacza, że jest powód, ale alternatywa wchodzi w grę. Otwarte oznacza, że oczekuje się rekomendacji partnera.

Technologię lepiej zostawić otwartą, chyba że istnieje realny powód, by ją ustalić, na przykład wewnętrzny zespół, który będzie utrzymywał kod, albo platforma, na której firma się ustandaryzowała. Jeśli jakiś wybór zostaje ustalony, warto napisać dlaczego, aby partnerzy nie poświęcali oferty na argumentowanie przeciw niemu.

Na koniec należy poprosić każdego partnera o odpowiedź w tej samej strukturze: zrozumienie problemu, podejście, fazy i kamienie milowe, założenia, ryzyka, zespół i model rozliczeń. Wspólna struktura to warunek, by oferty dało się w praktyce porównać.

Błędy, przez które ofert nie da się porównać

Wiele bezużytecznych ofert to odpowiedzi na brief, który sam je sprowokował. Przed wysłaniem własnego warto usunąć z niego poniższe wzorce.

• Lista funkcji bez opisu problemu, przez co każdy partner zgaduje priorytety.
• Długa specyfikacja, która ustala rozwiązanie, zanim ktokolwiek przeanalizował problem.
• Brak wzmianki o istniejących systemach czy migracji danych, które potem wracają jako zgłoszenia zmian.
• Dodatkowe informacje przekazane niektórym partnerom podczas rozmów, przez co ich oferty odpowiadają na inne pytania.
• Słowa takie jak „prosty”, „standardowy” czy „jak znana aplikacja”, które każdy czytelnik rozumie inaczej.
• Brak terminu na pytania albo odpowiedzi przekazane tylko partnerowi, który zapytał.

Pytania partnerów jako część oceny

Partnerzy powinni mieć określony czas na zadawanie pytań, a odpowiedzi warto udzielać na piśmie i wysyłać każdą z nich wszystkim. Same pytania wiele mówią: partner, który pyta o dane, użytkowników i kryteria odbioru, już myśli o realizacji.

Jeśli problem jest jeszcze zbyt niepewny, by go dobrze opisać, warto to powiedzieć i zamiast pełnej oferty poprosić o krótką, płatną fazę rozpoznania (discovery). Stała cena zbudowana na domysłach ukrywa niewiadome w marży na ryzyko; faza rozpoznania zastępuje domysły faktami. Jeśli chcą Państwo, by inżynierowie przeczytali brief lub na niego odpowiedzieli, można go przesłać przez nasz formularz „Rozpocznij projekt”.

FAQ