Jak wybrać software house: pytania przed podpisaniem umowy

Jak wybrać software house? Nie po prezentacji i nie po najniższej cenie, tylko po odpowiedziach na kilka konkretnych pytań: kto naprawdę będzie pisał kod, jak wygląda proces i testy, do kogo należy kod po zakończeniu projektu i kto zajmie się systemem po wdrożeniu. Poniżej zebrałem pytania, które uważam za obowiązkowe przed podpisaniem umowy, oraz sygnały w ofercie, przy których sam bym się zatrzymał. Patrzę na to z perspektywy wykonawcy, więc wiem, w których miejscach oferty bywają najmniej konkretne.

Jak wybrać software house: od czego zacząć?

Zacznij od własnej strony stołu: zanim zapytasz wykonawców o cokolwiek, spisz cel projektu, główne procesy i ograniczenia, czyli budżet, termin i systemy, z którymi trzeba się zintegrować. Bez tego każda oferta odpowiada na inne pytanie i porównujesz rzeczy nieporównywalne. Wystarczą dwie, trzy strony konkretów, nie pełna specyfikacja.

Drugi krok to krótka lista. Zamiast rozsyłać zapytanie do kilkunastu firm, wybierz kilka, które mają doświadczenie w podobnej klasie systemów. Sklep z integracją ERP to inna praca niż aplikacja mobilna czy system do planowania produkcji. Z każdą firmą umów się na rozmowę, w której to Ty zadajesz pytania. Rozmowa powie Ci więcej niż portfolio, bo portfolio zawsze pokazuje najlepsze projekty.

Jeśli nie wiesz jeszcze, ile przeznaczyć na projekt, najpierw sprawdź, od czego zależy koszt systemu. Łatwiej wtedy ocenić, czy oferta jest realna, czy tylko atrakcyjna.

Kto realnie będzie pracował nad projektem?

Poproś o imiona, role i doświadczenie osób, które będą pracować przy Twoim projekcie, a nie o opis całej firmy. Na spotkaniu sprzedażowym często pojawiają się najbardziej doświadczeni ludzie, a kod piszą potem inni. To nie musi być nic złego, ale powinieneś wiedzieć o tym przed podpisaniem umowy.

Pytania, które zadałbym w tej części rozmowy:

• Kto będzie kierownikiem projektu i ile innych projektów prowadzi równolegle?
• Kto jest architektem lub głównym programistą i czy będzie obecny na spotkaniach?
• Czy część pracy trafi do podwykonawców lub freelancerów, a jeśli tak, to które zadania?
• Co się stanie, jeśli kluczowa osoba odejdzie z firmy w trakcie projektu?

Podwykonawca sam w sobie nie jest problemem. Problemem jest podwykonawca, o którym dowiadujesz się dopiero wtedy, gdy nikt nie potrafi wyjaśnić, dlaczego coś działa tak, a nie inaczej. Dobrze, gdy umowa wymaga zgody zamawiającego na zmianę kluczowych osób i na podwykonawstwo.

Jak wygląda proces: od wymagań do wdrożenia

Dobry wykonawca potrafi w kilku zdaniach opisać, jak pracuje: jak zbiera wymagania, jak często pokazuje postępy, kto po Twojej stronie akceptuje kolejne etapy i jak obsługuje zmiany zakresu. Jeśli odpowiedź brzmi „pracujemy zwinnie” i nic więcej, dopytaj.

• Jak często zobaczę działającą wersję systemu, a nie raport z postępów?
• Gdzie będę widzieć listę zadań i ich status?
• Jak wycenia się zmianę, którą zgłoszę w trakcie projektu?
• Kto po stronie wykonawcy podejmuje decyzje techniczne i jak je dokumentuje?

Regularne pokazy działającego oprogramowania to najlepsze zabezpieczenie zamawiającego. Po kilku tygodniach wiesz, czy projekt idzie w dobrą stronę, zamiast dowiadywać się o tym przy odbiorze końcowym. Więcej o tym rytmie pracy pisałem w tekście o zarządzaniu projektami IT metodą Agile.

Z procesem wiąże się model rozliczenia. Stała cena daje przewidywalność, ale wymaga dobrze opisanego zakresu. Rozliczenie za czas pracy daje elastyczność kosztem mniejszej kontroli nad budżetem. Zestawienie obu podejść i modelu mieszanego znajdziesz we wpisie fixed price czy time and materials.

Testy i jakość: o co pytać, jeśli nie jesteś programistą

Żeby dobrze wybrać software house, nie musisz czytać kodu, ale musisz ocenić podejście do jakości. Wystarczy zapytać, kto i kiedy testuje system, i poprosić o pokazanie, jak to wygląda w innym projekcie, oczywiście bez danych tamtego klienta.

Odpowiedzi, których szukam:

• czy w zespole jest tester, czy testują wyłącznie programiści,
• czy są testy automatyczne dla najważniejszych procesów, na przykład złożenia zamówienia albo wystawienia faktury,
• czy każda zmiana w kodzie przechodzi przegląd drugiej osoby,
• czy istnieje środowisko testowe, na którym sprawdzisz zmiany przed wdrożeniem na produkcję,
• jak zgłaszasz błąd i kiedy dostaniesz odpowiedź.

Zwróć uwagę, czy testy i poprawki są w ogóle w wycenie. Oferta, która pomija je w harmonogramie, nie jest tańsza. Przenosi koszt na okres po wdrożeniu, kiedy błędy znajdują Twoi klienci, a nie tester.

Własność kodu i prawa autorskie

Ustal przed podpisaniem umowy, czy przejmujesz autorskie prawa majątkowe do kodu, czy dostajesz licencję, i na jakich polach eksploatacji. Od tego zależy, czy za kilka lat zmienisz wykonawcę, rozwiniesz system samodzielnie albo sprzedasz go razem z firmą.

W umowie sprawdziłbym:

• przeniesienie praw albo licencję, z wymienionymi polami eksploatacji, takimi jak zwielokrotnianie, modyfikacja i rozpowszechnianie,
• dostęp do repozytorium z kodem źródłowym w trakcie projektu, a nie dopiero po ostatniej płatności,
• listę komponentów, do których wykonawca zachowuje prawa, na przykład własnych modułów, i warunki licencji na nie,
• listę bibliotek open source i ich licencji,
• dokumentację techniczną i instrukcję uruchomienia systemu jako część odbioru.

Liczy się też forma. Zgodnie z art. 53 ustawy o prawie autorskim i prawach pokrewnych umowa o przeniesienie autorskich praw majątkowych wymaga formy pisemnej pod rygorem nieważności. Mail z potwierdzeniem tego nie załatwi. Konkretne zapisy omów z prawnikiem, bo to on odpowiada za umowę, a nie software house.

Utrzymanie po wdrożeniu

System żyje dłużej niż projekt, więc o utrzymanie zapytaj, zanim zaczniesz budowę: kto będzie aktualizował oprogramowanie, monitorował serwery, robił kopie zapasowe i naprawiał błędy po okresie gwarancji. Brak odpowiedzi na te pytania to prosta droga do szukania nowego wykonawcy w pośpiechu.

Wybrany software house powinien pokazać przykładową umowę serwisową. Sprawdź w niej:

• czasy reakcji i naprawy dla różnych klas zgłoszeń, bo awaria krytyczna to co innego niż literówka na stronie,
• co jest w abonamencie, a co płatne osobno,
• jak wygląda aktualizacja bibliotek, frameworka i serwera,
• jak przekazać system innemu wykonawcy, gdy współpraca się skończy.

Ostatni punkt brzmi pesymistycznie, ale dobrze opisana procedura wyjścia chroni obie strony. Wykonawca, który jest pewny swojej pracy, nie ma problemu z tym, żeby ją spisać.

Referencje: jak je sprawdzać, żeby coś z nich wynikało

Referencje mają sens wtedy, gdy rozmawiasz z klientem wykonawcy, a nie czytasz list polecający. Poproś o kontakt do jednej lub dwóch firm z podobnym projektem i zadzwoń.

• Czy projekt skończył się w założonym terminie i budżecie, a jeśli nie, to dlaczego?
• Jak wykonawca reagował na problemy i zmiany zakresu?
• Czy nadal z nim pracujecie przy utrzymaniu?
• Co zrobilibyście inaczej przy wyborze wykonawcy?

Ostatnie pytanie daje najwięcej. Nawet zadowolony klient powie, na co zwrócić uwagę, a to jest dokładnie ta wiedza, której szukasz.

Sygnały ostrzegawcze w ofercie software house’u

Niektóre oferty da się odłożyć po pierwszej lekturze. Oto sygnały, przy których sam bym się zatrzymał:

• Wycena bez pytań. Firma podaje cenę po jednym mailu, nie dopytując o procesy, integracje i dane.
• Brak testów, wdrożenia i dokumentacji w harmonogramie. Same funkcje, nic o tym, jak system trafi na produkcję.
• Termin, który nie zależy od zakresu. Ta sama data niezależnie od tego, co dopiszesz do wymagań.
• Niejasna własność kodu. Kod zostaje na serwerze wykonawcy, a repozytorium dostaniesz kiedyś, po zakończeniu projektu.
• Obietnica, że wszystko się da. Dobry wykonawca mówi też, czego nie robić i co jest ryzykowne.
• Brak nazwisk. Oferta opisuje firmę, ale nie zespół, który będzie przy projekcie.

Sama niska cena nie jest sygnałem ostrzegawczym. Jest nim niska cena, której wykonawca nie potrafi rozłożyć na etapy i godziny. Poproś o taki rozkład i porównaj oferty pozycja po pozycji, a nie tylko kwotą na końcu.

Jak porównać oferty i podjąć decyzję

Żeby wybrać software house na podstawie faktów, zbuduj tabelę z tymi samymi kryteriami dla każdej firmy i oceniaj odpowiedzi, a nie wrażenie ze spotkania. Przykładowy zestaw kryteriów wygląda tak:

Kryterium	Na co patrzeć
Zespół	konkretne osoby, ich doświadczenie, zasady zmiany składu
Proces	częstotliwość pokazów, obsługa zmian, osoba decyzyjna
Jakość	testy, przeglądy kodu, środowisko testowe
Prawa do kodu	przeniesienie lub licencja, pola eksploatacji, dostęp do repozytorium
Utrzymanie	czasy reakcji, zakres abonamentu, procedura wyjścia
Cena	rozbicie na etapy, lista rzeczy poza wyceną

Jeśli dwie firmy wypadają podobnie, rozważ krótki, płatny etap wstępny: warsztat analityczny albo prototyp jednego procesu. Po kilku tygodniach wspólnej pracy wiesz więcej niż po kilku rundach negocjacji, a ryzyko jest małe. Taki etap pomaga też odpowiedzieć na pytanie, czy w ogóle oddawać projekt na zewnątrz, o czym pisałem przy temacie outsourcingu IT w firmie.

Na koniec sprawdź, jak się Wam rozmawiało. Projekt potrwa miesiące, a utrzymanie lata. Wykonawca, który zadaje niewygodne pytania już na etapie oferty, zwykle robi to samo w trakcie projektu, i to jest zaleta, nie wada.

Jak wybrać software house w praktyce? Spisz cel i procesy, zaproś kilka firm na rozmowę, zadaj każdej te same pytania o zespół, proces, testy, prawa do kodu i utrzymanie, a potem porównaj odpowiedzi w jednej tabeli. Jeśli chcesz przejść przez te pytania z kimś, kto zna stronę wykonawcy, zobacz, jak wygląda współpraca przy projektach IT.