Jak zlecić oprogramowanie: brief, umowa i etapy współpracy

Najdroższe projekty IT to nie te z największym budżetem, tylko te źle zlecone. Niejasny zakres, brak praw do kodu, komunikacja raz na miesiąc — to z tego biorą się przekroczenia, opóźnienia i systemy, które trzeba przepisać. Dobra wiadomość: zlecenie oprogramowania da się ułożyć tak, żeby ryzyko spadło do minimum. Oto jak.

Zacznij od problemu, nie od rozwiązania

Najczęstszy błąd to przyjść do wykonawcy z gotową listą funkcji. „Chcę aplikację, która ma A, B i C." Problem w tym, że ta lista to już Twoja interpretacja rozwiązania, a niekoniecznie najlepsza.

Zamiast tego opisz problem i cel: co dziś nie działa, ile to kosztuje, co chcesz osiągnąć. Dobry wykonawca, mając jasny cel, często zaproponuje prostsze i tańsze rozwiązanie niż to, które przyniosłeś. Gotowa specyfikacja bywa kotwicą, która blokuje lepsze pomysły.

Jak napisać brief

Brief nie musi być grubym dokumentem. Wystarczy, że odpowie na kilka pytań:

• Po co? Jaki problem biznesowy rozwiązujemy i jak poznamy, że się udało.
• Dla kogo? Kto będzie korzystał z systemu i w jakim kontekście.
• Co musi obsłużyć? Główne procesy, nie ekran po ekranie.
• Z czym się łączy? Istniejące systemy, ERP, płatności, fakturowanie.
• Budżet i termin? Choćby widełki. To nie tajemnica, to informacja, która pozwala dobrać zakres.

Tyle wystarczy, żeby zacząć rozmowę. Resztę doprecyzujecie wspólnie na warsztacie.

Co musi być w umowie

Tu rozstrzyga się większość późniejszych kłopotów. Pilnuj czterech rzeczy:

• Zakres i kamienie milowe. Co dokładnie powstaje i w jakich etapach. Bez tego „skończone" znaczy co innego dla każdej strony.
• Przeniesienie praw autorskich do kodu. Kod i prawa muszą przejść na Ciebie. To absolutna podstawa — bez tego budujesz na cudzym i każda zmiana wykonawcy oznacza start od zera. Wagę własności praw dobrze tłumaczy WIPO, światowa organizacja ds. własności intelektualnej.
• Model i terminy płatności. Powiązane z kamieniami milowymi, a nie „z góry za całość".
• Zasady zmian zakresu. Bo zakres się zmieni. Ważne, żeby było jasne, jak się to wycenia i zatwierdza.

Dorzuć też zasady utrzymania po wdrożeniu, żeby nie okazało się, że po odbiorze zostajesz sam.

Jak wygląda zdrowa współpraca

Dobry proces jest przewidywalny i przejrzysty:

1. Warsztat i zakres. Wspólnie układacie, co i po co powstaje.
2. Wycena. Konkretna, oparta na ustalonym zakresie.
3. Budowa iteracyjna. Krótkie cykle, działające wersje co kilka tygodni, feedback na bieżąco. To podejście opisuje m.in. przewodnik po agile firmy Atlassian — pracujesz przyrostowo, zamiast czekać na wielki finał.
4. Testy i wdrożenie. QA, poprawki, uruchomienie produkcyjne.
5. Wsparcie i rozwój. Monitoring i kolejne funkcje wedle potrzeb.

Jeśli wykonawca pokazuje postęp dopiero na końcu, to czerwona flaga.

Najczęstsze błędy

• Wybór po najniższej cenie. Najtańsza oferta bywa najdroższa, gdy projekt trzeba przepisać.
• Brak jednego decydenta po Twojej stronie. Gdy każdy w firmie mówi co innego, zakres się rozjeżdża.
• Zlecenie wszystkiego naraz. Lepiej zacząć od MVP i rozbudowywać, niż zamrażać duży budżet na założeniach.
• Pominięcie tematu utrzymania. System bez opieki po wdrożeniu zacznie się sypać.

Firma, freelancer czy zespół na zlecenie

To, komu zlecić, zależy od skali. Cały projekt pod klucz najlepiej oddać firmie z zespołem — opisujemy to na stronie firma programistyczna Gdańsk. Gdy potrzebujesz tylko rąk albo konkretnej kompetencji do istniejącego zespołu, sprawdza się model programistów na zlecenie. A jeśli budujesz coś od podstaw pod swój proces, zacznij od dedykowanego oprogramowania.

Podsumowanie

Zlecenie oprogramowania nie musi być loterią. Zacznij od problemu, nie od listy funkcji. Napisz prosty brief. Zadbaj o umowę z przeniesieniem praw i jasnymi etapami. Wybierz wykonawcę za proces i komunikację, nie za najniższą cenę. Tyle wystarczy, żeby projekt nie skończył się przepisywaniem od nowa.

Masz temat do zlecenia? Napisz do nas — pierwsza konsultacja jest bezpłatna, a wstępną wycenę policzysz w kalkulatorze.