Jak wybrać software house? 12 pytań przed podpisaniem umowy

Wybór software house'u często zaczyna się niewinnie. Wysyłasz opis projektu do kilku firm, odbywasz parę spotkań i po dwóch tygodniach otrzymujesz oferty.

Pierwsza firma proponuje realizację za 180 tysięcy złotych. Druga chce 320 tysięcy. Trzecia nie podaje ceny końcowej, ale przedstawia zespół rozliczany godzinowo.

Każdy dostawca zapewnia, że rozumie projekt, pracuje zwinnie i stawia na partnerską komunikację. Każdy pokazuje portfolio, logotypy klientów oraz listę technologii. Wszystkie prezentacje wyglądają profesjonalnie, ale nadal nie wiesz, która firma rzeczywiście dowiezie projekt.

To normalne. Na etapie sprzedaży oceniasz dostawcę w momencie, w którym masz najmniej informacji, a on ma największą kontrolę nad tym, co Ci pokaże.

Dlatego nie warto wybierać software house'u wyłącznie na podstawie ceny, portfolio ani dobrego wrażenia po spotkaniu. Potrzebujesz pytań, które pozwolą zajrzeć za prezentację sprzedażową i sprawdzić, jak będzie wyglądała codzienna współpraca.

Zanim zaczniesz: upewnij się, że wszyscy wyceniają ten sam projekt

Największy błąd pojawia się często jeszcze przed pierwszym spotkaniem z dostawcami.

Klient wysyła bardzo ogólny opis pomysłu, na przykład:

Na tej podstawie każda firma buduje własną interpretację.

Jeden wykonawca zakłada konfigurację gotowego systemu. Drugi planuje stworzenie dedykowanej aplikacji. Trzeci uwzględnia integrację z księgowością i pocztą, a czwarty traktuje integracje jako osobny etap.

W efekcie otrzymujesz cztery różne ceny, ale nie są to cztery wyceny tego samego projektu.

Przed rozpoczęciem wyboru wykonawcy powinieneś mieć przynajmniej:

• jasno opisany problem biznesowy;
• listę głównych użytkowników systemu;
• najważniejsze procesy, które mają zostać obsłużone;
• zakres pierwszej wersji;
• wymagane integracje;
• podstawowe wymagania dotyczące danych i bezpieczeństwa;
• oczekiwany termin;
• informacje o odpowiedzialności po stronie klienta;
• kryteria, według których porównasz oferty.

Nie musi to być kilkusetstronicowa specyfikacja. Materiał musi być jednak wystarczająco konkretny, aby dostawcy odpowiadali na podobne pytanie — dokładnie do tego służy specyfikacja projektu IT.

Dopiero wtedy można zacząć oceniać wykonawców.

1. Czy realizowaliście projekt podobny do naszego — i za co dokładnie odpowiadaliście?

Pytanie o podobne realizacje jest oczywiste. Problem polega na tym, że samo portfolio niewiele wyjaśnia.

Firma może pokazywać duży system e-commerce, mimo że odpowiadała wyłącznie za jeden moduł. Może przedstawiać projekt zrealizowany kilka lat temu przez zespół, którego już nie zatrudnia. Może także prezentować znaną markę, nie ujawniając, że współpraca zakończyła się po krótkim etapie analitycznym.

Dlatego nie pytaj jedynie, czy dostawca ma doświadczenie w Twojej branży.

Zapytaj:

• jaki był rzeczywisty zakres odpowiedzialności firmy;
• co zostało wykonane od podstaw;
• jakie elementy dostarczały inne podmioty;
• jak długo trwał projekt;
• jakie problemy pojawiły się podczas realizacji;
• czy obecny zespół uczestniczył w tamtym projekcie;
• czy rozwiązanie nadal jest rozwijane i utrzymywane.

Podobieństwo branżowe może być pomocne, ale nie zawsze jest najważniejsze. Często większe znaczenie ma doświadczenie w podobnym rodzaju problemu: integracji wielu systemów, migracji danych, obsłudze złożonych uprawnień albo pracy z kilkoma spółkami.

2. Kto konkretnie będzie pracował przy naszym projekcie?

Na etapie sprzedaży często spotykasz najbardziej doświadczone osoby w firmie. W spotkaniu uczestniczy dyrektor technologiczny, senior architekt i doświadczony kierownik projektu.

Po podpisaniu umowy może się jednak okazać, że codzienną realizacją zajmuje się zupełnie inny zespół.

Poproś o przedstawienie osób, które rzeczywiście mają pracować przy projekcie:

• kierownika projektu;
• analityka;
• projektanta UX;
• architekta;
• głównych programistów;
• testera;
• osoby odpowiedzialnej za wdrożenie i utrzymanie.

Nie chodzi o to, aby prowadzić rekrutację za dostawcę. Powinieneś jednak wiedzieć, jakie kompetencje kupujesz i czy przedstawiony zespół będzie dostępny w planowanym terminie.

Warto zapytać także:

• ile czasu poszczególne osoby przeznaczą na projekt;
• w ilu innych projektach równolegle uczestniczą;
• kto może je zastąpić;
• jak będzie wyglądało przekazanie wiedzy;
• czy zmiana kluczowej osoby zostanie wcześniej uzgodniona.

CV firmy nie realizuje projektu. Realizują go konkretni ludzie.

3. Jakie założenia przyjęliście podczas przygotowania wyceny?

Każda wycena zawiera założenia. Część z nich jest zapisana w ofercie, a część istnieje tylko w głowach osób przygotowujących estymację.

Dostawca może zakładać, że:

• dane do migracji będą uporządkowane;
• istniejące systemy posiadają aktualne API;
• klient dostarczy kompletne treści i materiały;
• użytkownicy będą dostępni podczas analizy i testów;
• nie są potrzebne testy wydajnościowe;
• wersja mobilna oznacza responsywną stronę, a nie osobną aplikację;
• klient zaakceptuje standardowe mechanizmy platformy;
• wymagania bezpieczeństwa nie wykraczają poza podstawowy poziom;
• projekt będzie realizowany bez większych zmian zakresu.

Każde z tych założeń może znacząco wpłynąć na cenę.

Poproś dostawcę o osobną listę:

• przyjętych założeń;
• elementów nieuwzględnionych w wycenie;
• obowiązków klienta;
• zależności od zewnętrznych dostawców;
• obszarów wymagających dalszej analizy.

Dobra oferta nie udaje, że wszystkie niewiadome zostały rozwiązane. Pokazuje, gdzie występuje niepewność i jak można ją ograniczyć.

4. W jaki sposób przygotowaliście estymację?

Cena może być atrakcyjna, ale powinieneś wiedzieć, skąd się wzięła.

Zapytaj, czy wycena została przygotowana:

• na podstawie analizy zakresu;
• przez zespół techniczny;
• poprzez porównanie z podobnymi projektami;
• jako suma estymacji poszczególnych elementów;
• z uwzględnieniem testów, zarządzania i wdrożenia;
• z wykorzystaniem określonego bufora ryzyka.

Warto także sprawdzić, czy podana liczba godzin obejmuje wszystkie role. Oferta może wyglądać tanio, ponieważ pokazuje jedynie czas programistów, pomijając analizę, zarządzanie projektem, projektowanie, testy i wdrożenie.

Nie oczekuj absolutnej precyzji. Im wcześniej powstaje wycena, tym więcej zawiera niepewności. Dostawca powinien jednak umieć pokazać logikę estymacji i wskazać elementy, które mogą najmocniej wpłynąć na końcowy koszt. Jeśli masz już taką wycenę na stole i chcesz sprawdzić, czy trzyma się kupy, audyt wyceny i ofert IT właśnie do tego służy.

5. Co może spowodować wzrost kosztu projektu?

To pytanie warto zadać wprost, zanim pojawi się pierwsza dodatkowa faktura.

Poproś dostawcę o wskazanie sytuacji, które mogą wymagać dodatkowego budżetu. Mogą to być:

• zmiany wymagań;
• nowe integracje;
• nieprzewidziana jakość danych;
• brak dokumentacji istniejących systemów;
• dodatkowe wymagania bezpieczeństwa;
• zmiana technologii;
• opóźnienia po stronie klienta;
• konieczność ponownego wykonania zaakceptowanych prac;
• zwiększenie liczby użytkowników lub wolumenu danych;
• rozszerzenie testów.

Następnie ustal, jak dodatkowe koszty będą zgłaszane i zatwierdzane.

Dostawca nie powinien rozpoczynać płatnych prac dodatkowych wyłącznie na podstawie luźnej rozmowy podczas spotkania. Każda zmiana powinna mieć opis, uzasadnienie, wycenę i wskazanie wpływu na termin.

6. Jak zarządzacie zmianami zakresu?

Zmiany w projekcie IT są normalne. W trakcie realizacji użytkownicy lepiej rozumieją swoje potrzeby, pojawiają się nowe informacje, a część wcześniejszych założeń okazuje się błędna.

Problemem nie jest sama zmiana. Problemem jest zmiana, której konsekwencji nikt świadomie nie ocenił.

Zapytaj, czy dostawca prowadzi:

• rejestr zmian;
• opis uzasadnienia biznesowego;
• ocenę wpływu na koszt;
• ocenę wpływu na harmonogram;
• informację o wpływie na pozostały zakres;
• formalną decyzję klienta;
• historię zaakceptowanych i odrzuconych zmian.

W projekcie ze stałym budżetem warto także ustalić zasadę zamiany zakresu. Nowa funkcja może zostać dodana bez zwiększenia ceny, jeżeli w zamian usuniecie element o podobnej pracochłonności.

Dzięki temu projekt pozostaje elastyczny, ale nie rośnie bez końca.

7. Jak będziemy sprawdzać rzeczywisty postęp?

Liczba przepracowanych godzin nie mówi, ile produktu powstało.

Podobnie niewiele mówi informacja, że zespół „pracuje nad modułem” albo ukończył 80 procent zadań. Zadania mogą mieć różną wielkość, a element oznaczony jako ukończony może nadal wymagać integracji, testów i poprawek.

Zapytaj dostawcę:

• jak często odbywają się demonstracje;
• kiedy otrzymasz dostęp do środowiska testowego;
• jakie elementy będą możliwe do odebrania po każdym etapie;
• jak definiowane jest ukończenie zadania;
• jak raportowane są opóźnienia;
• czy raport zawiera prognozę kosztu i terminu zakończenia;
• czy klient będzie miał dostęp do backlogu i dokumentacji.

Postęp powinien być potwierdzany działającymi rezultatami, a nie wyłącznie raportami o aktywności zespołu. Jeżeli wolisz, żeby ktoś pilnował tego za Ciebie na bieżąco, to dokładnie robi nadzór projektu IT.

8. Jak wygląda kontrola jakości i kto odpowiada za testy?

Sformułowanie „system zostanie przetestowany” jest zbyt ogólne.

Zapytaj:

• jakie rodzaje testów zostaną wykonane;
• kto je przeprowadzi;
• kiedy rozpoczną się testy;
• jak dokumentowane są wyniki;
• jak klasyfikowane są błędy;
• które testy nie są objęte ofertą;
• kto przygotuje dane testowe;
• jak klient zostanie włączony w testy akceptacyjne;
• jakie warunki muszą zostać spełnione przed uruchomieniem produkcyjnym.

Warto rozdzielić odpowiedzialność wykonawcy od odpowiedzialności klienta.

Dostawca powinien sprawdzić techniczną poprawność rozwiązania. Klient powinien zweryfikować, czy system rzeczywiście pozwala wykonać proces biznesowy zgodnie z oczekiwaniami. Testy użytkowników nie powinny zastępować kontroli jakości po stronie software house'u — o tym, jak dobrze zorganizować własne testy akceptacyjne, piszemy przy okazji odbioru aplikacji i testów UAT.

9. Co robicie, gdy projekt zaczyna się opóźniać?

Nie pytaj, czy projekt może się opóźnić. Oczywiście, że może.

Zapytaj, co dostawca robi, gdy pojawia się pierwsze istotne odchylenie od planu.

Interesuje Cię:

• kiedy problem zostanie zgłoszony;
• kto przygotuje analizę przyczyn;
• jak zostanie zaktualizowana prognoza;
• jakie warianty rozwiązania otrzymasz;
• czy możliwe będzie ograniczenie zakresu;
• kto podejmie decyzję;
• jak będzie monitorowany plan naprawczy.

Dojrzały wykonawca nie obiecuje świata bez problemów. Pokazuje, że potrafi problemy szybko zauważać, otwarcie komunikować i metodycznie rozwiązywać.

Najbardziej kosztowne opóźnienia często nie zaczynają się od poważnej awarii. Zaczynają się od kilku drobnych przesunięć, które przez wiele tygodni nie wpływają na oficjalną datę końcową.

10. Jak chronicie nasze dane i kto będzie miał do nich dostęp?

Wymagania bezpieczeństwa powinny zależeć od rodzaju systemu i przetwarzanych informacji. Inaczej ocenia się prostą stronę informacyjną, a inaczej system zawierający dane klientów, pracowników, płatności lub informacje medyczne.

Zapytaj między innymi:

• gdzie będą przechowywane dane;
• kto uzyska dostęp do środowisk;
• czy dostawca korzysta z podwykonawców;
• jak nadawane i odbierane są uprawnienia;
• czy środowiska testowe zawierają rzeczywiste dane;
• jak tworzone są kopie zapasowe;
• jak firma reaguje na incydenty;
• jak zarządza podatnościami;
• jakie narzędzia zewnętrzne wykorzystuje;
• czy kod lub dane mogą trafiać do narzędzi generatywnej AI;
• co stanie się z danymi po zakończeniu umowy.

Nie wystarczy zapewnienie, że firma „działa zgodnie z RODO”. Potrzebujesz informacji o konkretnych praktykach i odpowiedzialności.

11. Co dokładnie otrzymamy po zakończeniu projektu?

System nie kończy się na ekranach widocznych dla użytkownika.

Po zakończeniu współpracy możesz potrzebować:

• kodu źródłowego;
• historii zmian;
• dokumentacji technicznej;
• dokumentacji użytkowej;
• konfiguracji;
• dostępów administracyjnych;
• danych i ich eksportu;
• informacji o licencjach;
• listy użytych komponentów;
• instrukcji wdrożenia;
• procedur utrzymania;
• dokumentacji integracji;
• wykazu znanych ograniczeń.

Nie każdy element musi stać się Twoją własnością. System może wykorzystywać biblioteki open source, komponenty dostawcy, licencjonowane produkty albo usługi chmurowe.

Musisz jednak wiedzieć, jakie prawa otrzymujesz i czy będziesz mógł:

• korzystać z rozwiązania po zakończeniu umowy;
• rozwijać je z innym wykonawcą;
• przenieść dane;
• odtworzyć środowisko;
• utrzymać system bez stałej zależności od obecnego dostawcy.

Te kwestie należy uzgodnić przed podpisaniem umowy, a nie w momencie, gdy współpraca zaczyna się psuć.

12. Jak wygląda utrzymanie systemu i zakończenie współpracy?

Uruchomienie produkcyjne nie oznacza końca kosztów ani odpowiedzialności.

Zapytaj:

• kto będzie usuwał błędy po wdrożeniu;
• co obejmuje gwarancja;
• jaki jest czas reakcji na awarie;
• jak rozliczane są zmiany i rozwój;
• czy potrzebny jest minimalny miesięczny pakiet godzin;
• jak aktualizowane będą biblioteki i infrastruktura;
• kto odpowiada za monitoring;
• co stanie się po wypowiedzeniu umowy;
• ile potrwa przekazanie projektu;
• czy dostawca pomoże wdrożyć następcę;
• jakie opłaty mogą pojawić się podczas migracji.

Procedura zakończenia współpracy nie jest wyrazem braku zaufania. Jest elementem odpowiedzialnego zarządzania ryzykiem.

Dobra relacja biznesowa nie wymaga, aby klient był technicznie uwięziony u dostawcy.

Jak porównać odpowiedzi software house'ów?

Same rozmowy nie wystarczą. Po kilku spotkaniach odpowiedzi zaczną się mieszać, a decyzja ponownie zostanie oparta na ogólnym wrażeniu.

Przed rozpoczęciem procesu przygotuj kartę oceny.

Możesz uwzględnić w niej:

• zrozumienie problemu biznesowego;
• kompletność proponowanego zakresu;
• doświadczenie zespołu;
• przejrzystość wyceny;
• sposób zarządzania zmianami;
• raportowanie postępu;
• jakość i testy;
• bezpieczeństwo;
• warunki utrzymania;
• prawa do kodu i danych;
• możliwość zmiany dostawcy;
• całkowity koszt w okresie kilku lat.

Każdemu kryterium przypisz wagę. Inne priorytety będzie miał system obsługujący dane medyczne, inne sklep internetowy, a jeszcze inne proste narzędzie wewnętrzne.

Ważne jest również, aby kryteria ustalić przed podjęciem decyzji. Jeżeli zbudujesz je dopiero po spotkaniach, łatwo dopasujesz ocenę do firmy, która zrobiła najlepsze wrażenie — a jeśli oferty i tak trudno sprowadzić do wspólnego mianownika, to typowy przypadek na porównanie ofert software house'ów.

Najczęstsze błędy podczas wyboru software house'u

Wybór wyłącznie na podstawie ceny

Najtańsza oferta może być najlepsza, ale najpierw trzeba sprawdzić, czy obejmuje cały potrzebny zakres. Niska cena może wynikać z przewagi technologicznej i doświadczenia. Może również wynikać z pominięcia analizy, testów, migracji, dokumentacji albo utrzymania.

Nadmierne znaczenie portfolio

Duża liczba znanych klientów nie gwarantuje, że przy Twoim projekcie będzie pracował równie doświadczony zespół.

Brak rozmowy z zespołem technicznym

Handlowiec może bardzo dobrze rozumieć proces sprzedaży, ale nie będzie podejmował codziennych decyzji projektowych.

Niejasne kryteria wyboru

Bez wcześniej ustalonych zasad proces łatwo zamienia się w konkurs prezentacji.

Brak planu wyjścia

Klient analizuje sposób rozpoczęcia współpracy, ale nie sprawdza, co wydarzy się po jej zakończeniu.

Podpisanie umowy przed doprecyzowaniem rozbieżności

Ustne zapewnienie, że „na pewno się dogadamy”, rzadko jest dobrym zamiennikiem jasnego zakresu i zasad rozliczeń.

Czy dobry software house zawsze odpowie idealnie?

Nie.

Mniejsza firma może nie posiadać rozbudowanych procedur, a mimo to pracować bardzo dobrze. Duży dostawca może mieć doskonałe procesy, ale przeznaczyć do Twojego projektu niewłaściwy zespół.

Nie chodzi o szukanie jednej poprawnej odpowiedzi.

Chodzi o sprawdzenie, czy sposób pracy wykonawcy pasuje do:

• skali projektu;
• poziomu ryzyka;
• kompetencji Twojej organizacji;
• oczekiwanego modelu współpracy;
• wymagań dotyczących bezpieczeństwa;
• dostępnego budżetu;
• planów dalszego rozwoju.

Dostawca powinien nie tylko umieć zbudować system. Powinien również umieć pracować z Twoją organizacją.

Dobry dostawca nie obiecuje braku problemów

Projekt IT zawsze zawiera niewiadome. Wymagania mogą się zmienić, integracja może okazać się trudniejsza, a część wcześniejszych założeń może wymagać korekty.

Najlepszy wykonawca nie jest firmą, która twierdzi, że wszystko przewidziała.

Jest nim zespół, który:

• jasno opisuje założenia;
• potrafi mówić o ryzykach;
• wcześnie pokazuje rezultaty;
• nie ukrywa problemów;
• dokumentuje decyzje;
• kontroluje zmiany;
• dba o jakość;
• pozwala klientowi zachować kontrolę nad własnym systemem.

Nie wybierasz firmy, która przygotowała najlepszą prezentację sprzedażową.

Wybierasz partnera, z którym będziesz podejmować trudne decyzje przez kolejne miesiące — a czasem przez kilka lat.

Nie masz pewności, jak porównać otrzymane oferty?

Jeżeli wyceny różnią się zakresem, ceną lub modelem realizacji, warto uporządkować je przed podpisaniem umowy.

Niezależna analiza pozwala ustalić:

• co rzeczywiście obejmuje każda oferta;
• czego w niej brakuje;
• gdzie mogą pojawić się dodatkowe koszty;
• jakie pytania należy zadać wykonawcom;
• która propozycja najlepiej odpowiada celowi i ryzyku projektu.