Pierwsza rozmowa z software house’em zwykle idzie gładko. Dostawca mówi o doświadczeniu, standardach i procesie, a Ty próbujesz ocenić, ile z tego jest realnym sposobem pracy, a ile dobrze przećwiczoną sprzedażą. Problem zaczyna się wtedy, gdy prosisz o przykłady z poprzednich projektów i słyszysz ogólniki.
Właśnie wtedy najłatwiej sprawdzić, z kim naprawdę rozmawiasz: czy dostawca potrafi pokazać, jak dowoził jakość, opanowywał kryzys i zaczynał współpracę z klientem.
Dostawca nie umie pokazać standardów jakości w praktyce
Każdy dostawca powie, że dba o jakość kodu. Pytanie brzmi: jak to udowodni?
Nie wystarczy odpowiedź w stylu: „mamy seniorów”, „robimy code review” albo „piszemy testy”. To są puste hasełka, a nie standardy. Poproś o konkretne zasady jakości, których zespół trzymał się w poprzednich projektach. Jeśli dostawca nie potrafi ich nazwać, jakość zależy od dobrej woli konkretnych osób. A dobra wola szybko przegrywa z presją, rosnącym zakresem i zbliżającym się deadlinem.
Podstawy jakości nie są tajemnicą. Dostawca powinien umieć powiedzieć, jak w poprzednich projektach wyglądały code review, automatyczne testy i Definition of Done (wspólna definicja ukończonego zadania). Powinien też jasno opisać CI/CD, czyli automatyzację integracji i wdrażania zmian, dokumentację, monitoring oraz standardy bezpieczeństwa.
Uciekanie w ogólniki jest tu najważniejszym sygnałem ostrzegawczym. Jeśli słyszysz: „dobierzemy proces po starcie” albo „standardy zależą od projektu”, dopytaj o poprzedni projekt. Co dokładnie było obowiązkowe przed mergem? Czy testy automatyczne blokowały wdrożenie? Czy Definition of Done obejmowała dokumentację i jasne kryteria odbioru? Jeśli dostawca nie potrafi odpowiedzieć na tym poziomie konkretu, sprzedaje obietnicę, nie standard.
Dostawca nie umie opisać, jak reaguje na kryzysy w projektach
W każdym projekcie IT prędzej czy później coś pójdzie niezgodnie z planem. Opóźni się decyzja, kluczowa osoba po stronie klienta nie będzie dostępna albo po demo okaże się, że zespół źle zrozumiał wymagania. Dlatego obietnica „u nas nie będzie problemów” jest bezwartościowa. Liczy się to, jak dostawca mówi o przeszłych problemach i ich rozwiązywaniu.
Zapytaj: „Opowiedzcie o projekcie, w którym coś poszło źle. Co się stało, kiedy powiedzieliście o tym klientowi i jak rozwiązaliście problem?”. Takie pytanie szybko oddziela doświadczenie od prezentacji sprzedażowej.
Mocna odpowiedź schodzi do konkretów: jaki był problem, kiedy wyszedł na jaw, kto zdecydował o eskalacji, jak wyglądała rozmowa z klientem i co zmieniło się później w procesie.
Sygnałem ostrzegawczym jest odpowiedź bez historii. Deklaracja o „bieżącej komunikacji” nie wystarczy, jeśli dostawca nie potrafi przedstawić trudnej rozmowy z klientem. Cotygodniowe spotkanie statusowe też nie rozwiązuje problemu. Ktoś po stronie dostawcy musi umieć powiedzieć wprost: mamy problem, znamy jego skalę i proponujemy taki a taki plan działania.
Właśnie dlatego nie kończ rozmów na kontakcie ze sprzedażą. Poproś o rozmowę z osobą techniczną. Dopiero wtedy weryfikacja zespołu deweloperskiego pokaże, czy po stronie dostawcy jest ktoś, kto potrafi mówić o błędach bez uciekania w wymówki.
Dostawca nie ma ustandaryzowanego planu na pierwsze tygodnie współpracy
Firma, która regularnie zaczyna nowe projekty, powinna mieć spójny onboarding klienta: zbieranie informacji, ustawienie komunikacji, porządkowanie wymagań i uruchomienie pracy zespołu. Szczegóły będą się różnić, ale struktura powinna być przewidywalna.
Zapytaj dostawcę, jak wyglądały pierwsze dwa do czterech tygodni w podobnym projekcie. Nie plan z oferty, tylko faktyczny przebieg. Co zespół zrobił w pierwszym tygodniu? Kiedy powstało repozytorium? Kiedy ustalono Definition of Ready (zasady, które musi spełnić zadanie, zanim trafi do developmentu)? Kiedy pojawiło się pierwsze demo?
Odpowiedź w stylu „zaczęlibyśmy od warsztatów, potem byłyby sprinty i regularna komunikacja” to ogólnik. Dopytaj o konkrety: jakie materiały dostawca przygotuje, kogo będzie potrzebował po stronie klienta i co powinno być gotowe po pierwszym miesiącu.
Jeśli dostawca nie potrafi odtworzyć przebiegu pierwszych tygodni w podobnym projekcie, trudno mówić o powtarzalnym onboardingu. A jeśli chaos towarzyszy projektowi od samego początku, zwykle nie znika z czasem, tylko eskaluje.
O co zapytać przed kolejną rozmową z software house’em
Na pierwszej rozmowie nie oceniaj tego, czy dostawca brzmi profesjonalnie. Sprawdź, czy potrafi pokazać, jak pracował w poprzednich projektach. Standardy jakości, komunikacja w kryzysie i onboarding klienta powinny istnieć przed Twoim projektem.
To tylko trzy sygnały ostrzegawcze. Przed podpisaniem umowy trzeba sprawdzić też zespół, utrzymanie, ryzyka, dostęp do kodu i zasady zakończenia współpracy. Zebraliśmy je w praktyczną listę pytań do dostawcy IT, która pomaga rozmawiać o konkretach zamiast o sprzedażowych obietnicach.
Materiał promocyjny
