Jak wybrać software house do projektu IT? 7 kryteriów i pytania do wykonawcy

Przed rozmową z software house opisujemy problem biznesowy, użytkowników, istniejące systemy, ograniczenia, budżet i oczekiwany termin. Taki materiał pomaga oddzielić potrzebny rezultat od listy funkcji, które można doprecyzować po poznaniu ryzyk.

Przygotowujemy jednostronicowy opis: kto ma korzystać z rozwiązania, jakie zadanie ma wykonać, jak firma realizuje je obecnie i po czym pozna poprawę. Wymieniamy integracje, źródła danych, wymagania bezpieczeństwa, ograniczenia organizacyjne oraz osobę decyzyjną. Jeśli zakres jest nieznany, zaznaczamy to wprost i pytamy o etap rozpoznania potrzeb.

Rozdzielamy wymagania konieczne od pomysłów na później. Wymaganiem koniecznym może być eksport danych lub połączenie z systemem, bez którego proces nie zadziała. Pomysł do późniejszego etapu może poprawiać wygodę, ale nie blokuje uruchomienia pierwszej wersji.

Do pierwszego spotkania przygotowujemy też pytania o sposób pracy z niepewnością: jak wykonawca sprawdzi założenia, pokaże ryzyka i oszacuje zakres przed wiążącą wyceną. Jeśli projekt ma obsługiwać sprzedaż online, sklep internetowy na WooCommerce jest konkretnym zakresem, który można zestawić z wymaganiami. Ta oferta dotyczy sklepów WooCommerce, więc nie zastępuje oceny wykonawcy dowolnego systemu IT.

Doświadczenie wykonawcy oceniamy na podstawie konkretnych realizacji, roli firmy i podobieństwa problemu, a nie samych nazw technologii. Prosimy o opis projektu, który pozwala ustalić, co zespół faktycznie zaprojektował, zbudował i utrzymuje.

Pytamy, jaki problem rozwiązywała realizacja, jakie były ograniczenia, kto odpowiadał za analizę i wdrożenie oraz jak wykonawca obsługiwał zmianę zakresu. Referencja powinna dotyczyć doświadczenia istotnego dla naszego ryzyka: integracji, migracji, skali danych, pracy regulowanej lub utrzymania systemu. Nie wymagamy ujawniania poufnych informacji o kliencie.

Tabela pomaga sprawdzić, czy portfolio zawiera dowody adekwatne do projektu. Jeśli wykonawca nie może pokazać materiałów ze względu na poufność, może opisać architekturę, decyzje i proces w formie zanonimizowanej. Brak publicznego case study sam w sobie nie przesądza o braku kompetencji.

Proces i skład zespołu porównujemy przez pytania o odpowiedzialność, dostępność specjalistów i sposób weryfikacji kolejnych wersji. Nazwy stanowisk nie wystarczą, jeśli nie wiadomo, kto podejmuje decyzje i kto odpowiada za jakość.

Pytamy, czy projekt rozpocznie się od discovery, czyli etapu rozpoznania potrzeb, ryzyk i zakresu. Ustalamy, kto poprowadzi analizę, projektowanie, programowanie, testy i wdrożenie oraz czy osoba kontaktowa będzie uczestniczyć w pracach. Prosimy o opis typowego przebiegu iteracji i sposób akceptacji funkcji.

Sprawdzamy, kto faktycznie będzie pracował przy projekcie, jak wykonawca zastąpi nieobecną osobę i czy specjalistów współdzieli z innymi klientami. Pytamy też o dostępność decydenta technicznego i osoby odpowiedzialnej za produkt. Jeśli kluczowa kompetencja ma być dostępna tylko doraźnie, prosimy o opis wpływu na terminy i koszty.

Mini scenariusz rozmowy: prosimy wykonawcę, by przeszedł przez jedną niejednoznaczną funkcję. Powinien zapytać o użytkownika i cel, wskazać niewiadome, zaproponować sposób sprawdzenia założeń i opisać, kto podejmie decyzję. Gładka odpowiedź bez pytań może oznaczać, że zakres jest jeszcze zbyt słabo rozpoznany.

Ofertę oceniamy przez zakres, założenia, wyłączenia, model rozliczenia, warunki odbioru i koszty utrzymania. Dwie podobne kwoty nie są porównywalne, jeśli jedna obejmuje analizę, testy i wdrożenie, a druga zakłada gotowe wymagania i dostępne środowisko.

Wycena ryczałtowa ogranicza zmienność ceny w zakresie opisanym umową, ale wymaga jasnych kryteriów i procedury zmian. Rozliczenie czasowe może lepiej pasować do odkrywania zakresu, ale potrzebuje limitów, raportowania i decyzji o kontynuacji. W obu modelach pytamy, co jest poza ceną, jak liczone są poprawki i kto finansuje pracę nad zależnościami zewnętrznymi.

Tabela ujawnia różnice w założeniach, nawet jeśli oferty nie podają tych samych pozycji. Zanim porównamy cenę, prosimy o dopisanie brakujących informacji albo jawne oznaczenie ich jako wyłączonych. Nie podajemy pozornej sumy całkowitej, jeśli jeden z wykonawców nie określił kosztu utrzymania, zmian lub infrastruktury.

Koszt projektu obejmuje także czas zespołu klienta, przygotowanie danych, licencje, infrastrukturę i obsługę po wdrożeniu. Warto porównać oferty dopiero po uzgodnieniu wspólnego zakresu, a następnie oddzielnie ocenić ryzyko i jakość procesu.

O bezpieczeństwo, własność kodu i utrzymanie pytamy przed podpisaniem umowy, aby wiedzieć, kto ma dostęp do zasobów i jak firma odzyska kontrolę nad projektem. Ustalenia powinny obejmować kod źródłowy, repozytorium, konta chmurowe, zależności, kopie zapasowe i przekazanie wiedzy.

Pytamy, czy repozytorium będzie dostępne dla klienta w trakcie prac, kto administruje dostępami i jak wycofuje się dostęp po zakończeniu współpracy. Ustalamy, jakie licencje dotyczą użytych bibliotek, kto przekazuje dokumentację i jak wykonawca zgłasza komponenty wymagające aktualizacji. Nie zakładamy, że samo przekazanie plików oznacza możliwość samodzielnego utrzymania systemu.

Dla utrzymania uzgadniamy zakres monitoringu, kopii zapasowych, aktualizacji, reakcji na zgłoszenia i procedury awaryjnej. SLA, czyli umowa opisująca poziom obsługi, powinno precyzować kanał zgłoszeń, godziny dostępności i sposób liczenia czasu reakcji. Pytamy, czy gwarancja obejmuje usuwanie błędów w ustalonym zakresie, a prace rozwojowe rozlicza się osobno.

Zapisy o prawach autorskich, licencjach, poufności i odpowiedzialności powinien sprawdzić prawnik znający umowy IT. Zespół projektowy może wskazać, czego potrzebuje do pracy, ale nie zastępuje analizy prawnej.

Komunikację sprawdzamy, obserwując, jak wykonawca podsumowuje ustalenia, nazywa ryzyka i reaguje na brak informacji. Przed podpisaniem umowy można już ocenić, czy rozmowy prowadzą do wspólnego rozumienia problemu.

Po spotkaniu prosimy o krótkie podsumowanie obejmujące cel, założenia, niewiadome, ryzyka i następne kroki. Sprawdzamy, czy dokument oddaje nasze ustalenia, czy tylko powtarza język oferty. Pytamy, kto może eskalować problem, jak szybko dostaniemy informację o opóźnieniu i w jakim rytmie będą przeglądane decyzje.

Dobry sygnał stanowi jawne wskazanie tego, czego wykonawca jeszcze nie wie i jak chce to sprawdzić. Sygnałem ostrzegawczym jest zapewnienie o terminie bez rozpoznania zależności albo unikanie rozmowy o ryzykach. Nie traktujemy stylu prezentacji jako dowodu kompetencji technicznych; sprawdzamy konkretne przykłady zachowania w procesie.

Umowa powinna opisywać zakres, sposób zmian, odbiory, płatności, prawa do rezultatów, poufność i zakończenie współpracy. Konkretne brzmienie zapisów zależy od modelu projektu, dlatego przed podpisaniem warto poddać je konsultacji prawnej.

W zakresie opisujemy rezultat, założenia, zależności od klienta i wyłączenia. Przy zmianach ustalamy, kto przedstawia wpływ na koszt i termin oraz kto zatwierdza pracę. Przy odbiorach zapisujemy kryteria, termin na zgłoszenie uwag i sposób rozstrzygania różnicy zdań.

Płatności można powiązać z etapami lub uzgodnionym rozliczeniem pracy. Ustalamy, co dzieje się z kodem i dokumentacją przy przerwaniu współpracy, jakie dostępy zostają przekazane oraz jak rozliczane są rozpoczęte prace. Zapisujemy też odpowiedzialność za dane, dostęp do środowisk i zależności po stronie klienta.

Wspólne ustalenia powinny chronić obie strony: klient wie, czego może oczekiwać, a wykonawca wie, jakie decyzje i materiały są potrzebne do realizacji. Jeśli zakres jest niepewny, umowa powinna opisać etap jego doprecyzowania, zamiast zakładać, że każdą niewiadomą da się wycenić z góry.

Kandydatów porównujemy siedmioma kryteriami, przypisując każdemu wagę, ocenę i konkretny dowód. Brak krytycznego dowodu wymaga dodatkowej weryfikacji niezależnie od wyniku punktowego.

Można zastosować skalę od 1 do 5, gdzie 1 oznacza brak dowodu, a 5 oznacza dowód bezpośrednio związany z ryzykiem projektu. Waga odzwierciedla znaczenie kryterium dla firmy; suma wag w poniższym przykładzie wynosi 100 punktów. Ocena jest narzędziem wspólnej rozmowy, a nie obiektywnym pomiarem jakości.

Wagi w tabeli są przykładowym szablonem do dostosowania, a nie wynikiem badania rynku. Jeśli projekt przetwarza wrażliwe dane albo integruje krytyczne systemy, firma może zwiększyć wagę bezpieczeństwa i utrzymania, a zmniejszyć wagę innych kryteriów.

Perspektywa KC Mobile: wybór wykonawcy jest bezpieczniejszy, gdy firma klienta ma osobę zdolną do szybkiego podejmowania decyzji i odbioru kolejnych etapów. Nawet dobry proces po stronie software house nie zastąpi właściciela biznesowego, który potwierdza priorytety i dostarcza dostępne dane.

Zanim wybierzemy najwyższy wynik, sprawdzamy krytyczne braki: brak dostępu do kodu, niejasne kryteria odbioru, niepotwierdzony skład zespołu albo nieustalone utrzymanie mogą przeważyć nad sumą ocen. Gdy projekt dotyczy e-commerce, wykonanie sklepu internetowego WooCommerce może pasować do zakresu, jeśli wymagania nie obejmują rozbudowanego systemu szytego na miarę. Przy ocenie relacji z wykonawcą warto też ustalić zasady współpracy z software house.

• Jak efektywnie współpracować z software house'em od briefu do wdrożenia
• Sklep internetowy z dofinansowania: wymagania przed wnioskiem
• Jak zarabiać na aplikacji mobilnej? Modele przychodu i wybór strategii
• Logowanie społecznościowe WooCommerce: konfiguracja, bezpieczeństwo i testy