Jakie pytania zadać firmie IT przed podpisaniem umowy?
Większość klientów zaczyna rozmowy z software house’em od dwóch pytań: “Ile to kosztuje?” i “Czy robiliście coś podobnego?”. To za mało. Zapominają o kluczowych kwestiach: ocenie ryzyka, SLA, własności kodu czy sposobie reagowania na awarie. Efekt jest przewidywalny: problemy powstają już na starcie, ale często ujawniają się dopiero po miesiącach.
W tym poradniku omawiamy, o co dokładnie pytać “na callu” i jak rozpoznać dobrą odpowiedź, aby wybrać partnera, z którym twój projekt odniesie sukces.
Zanim przejdziemy dalej, mała prośba: Nie zadawaj wszystkich tych pytań na jednym spotkaniu. Zlituj się nad handlowcem…
Pytania dotyczące procesu developmentu i komunikacji
Sposób, w jaki firma planuje i dostarcza kolejne funkcjonalności, decyduje nie tylko o koszcie, ale też o ostatecznym sukcesie lub porażce projektu. Przed podpisaniem umowy z dostawcą oprogramowania szukaj dowodów na ustandaryzowany proces, a nie obietnicy “szybkiego wrzucenia programistów do projektu”.
Ile godzin zaangażowania tygodniowo będziecie potrzebować z mojej strony?
Zapytaj: “Ile godzin tygodniowo potrzebujecie ode mnie i od mojego zespołu? Do czego konkretnie?” Dobry dostawca oprogramowania wie, że bez regularnego zaangażowania klienta projekt się nie uda. Oczekuj odpowiedzi rzędu kilku godzin tygodniowo, bo tyle realnie zajmują spotkania planistyczne, weryfikacja postępów i podejmowanie decyzji produktowych. Bez tego dostawca będzie zgadywał, zamiast budować to, czego naprawdę potrzebujesz.
Jak w praktyce będą wyglądały pierwsze 60 dni współpracy?
W odpowiedzi powinieneś usłyszeć konkrety: jak zespół zbiera i weryfikuje wymagania, jak ustala, co jest “gotowe” (Definition of Done) i czy CI/CD jest wdrażane od pierwszego dnia, a nie “gdzieś w przyszłości”. Pierwsze tygodnie każdego projektu zwykle wyglądają podobnie, więc dostawca powinien mieć dla nich zdefiniowany proces. Jeśli zamiast tego dostaniesz ogólniki, dopytuj. Jeśli w efekcie usłyszysz jeszcze więcej ogólników, może czas poszukać innego dostawcy?
Jak zbieracie wymagania i upewniacie się, że rozumiecie mój biznes?
Firma, która od razu “zamyka zespół w pokoju i odpala taksometr” bez zrozumienia biznesu klienta, powinna wzbudzić Twoje podejrzenia. Zapytaj wprost: “Skąd będę wiedzieć, że dobrze rozumiecie mój cel, zanim zaczniecie pisać kod?” Solidny dostawca najpierw zweryfikuje Twoje założenia biznesowe (np. przez Definition of Ready), a dopiero potem zabierze się za programowanie.
Skąd będę wiedzieć, że projekt realizuje moje cele biznesowe?
Wiele zespołów mierzy postępy w story pointach i zamkniętych zadaniach. Problem w tym, że można odhaczać dziesiątki tasków w sprincie i nie dostarczyć ani jednej użytecznej funkcji. To pytanie sprawdzi, czy dostawca rozumie cel Twojego produktu, czy po prostu klepie kod, bo mu za to płacisz. Oczekuj, że regularnie (np. na koniec każdego sprintu) zobaczysz realnie działające oprogramowanie i będziesz mógł sam ocenić, czy to, co powstaje, przybliża Cię do celu.
Jak często nowe zmiany będą trafiać na produkcję?
To pytanie dotyczy głównie CI/CD, czyli ciągłej integracji i ciągłego wdrażania. Sprawny zespół wdraża zmiany często i w dużej mierze automatycznie: kod przechodzi przez testy automatyczne, code review i trafia na produkcję bez dodatkowej pracy manualnej. Jeśli wdrożenie to u nich “wielkie święto robione ręcznie raz w miesiącu”, powinna zapalić Ci się czerwona lampka.
Kto ustala priorytety i czy możemy je zmienić w trakcie sprintu?
W teorii każdy software house mówi o sobie “Agile”. To pytanie weryfikuje, czy to coś więcej niż buzzword. Zapytaj: “Co jeśli nagle pojawi się szansa rynkowa i będę chciał zmienić cel obecnego sprintu?” Dobry dostawca powie, że zmiana priorytetów jest możliwa nawet z dnia na dzień, o ile obie strony rozumieją konsekwencje. Przedstawi też skrótowy plan, który zwykle realizuje w takich sytuacjach. Słaby też zapewni, że to jak najbardziej możliwe, ale nie wspomni o konsekwencjach i konkretach.
Pytania dotyczące kompetencji zespołu i wykorzystania AI
Kupujesz wiedzę konkretnych ludzi, a nie logotyp firmy. Masz prawo wiedzieć, kto dokładnie będzie pisał Twój produkt, zanim podpiszesz umowę.
Czy realizowaliście już projekty w mojej branży?
To standardowe pytanie, ale większość klientów zadaje je źle. Samo “czy robiliście coś w mojej branży?” nie wystarczy, bo każdy powie “tak”. Dopytaj o konkrety: “Jaki był Wasz największy projekt w tej branży, ile osób przy nim pracowało, jak długo trwał i czy ktoś z tego zespołu nadal u Was pracuje?” Ta ostatnia część jest kluczowa, bo dowiesz się, czy doświadczenie z tamtego projektu wciąż siedzi w firmie, czy dawno z niej odeszło.
Czy mogę porozmawiać z kimś, dla kogo realizowaliście podobny projekt?
Niewielu klientów o to pyta, a to najtańszy i najskuteczniejszy sposób, żeby sprawdzić, czy firma naprawdę umie to, co obiecuje. Zapytaj: “Czy możecie połączyć mnie z klientem z mojej branży, dla którego pracowaliście w ostatnich dwóch latach?” Poproś też o kontakt z obecnym klientem, bo referencje sprzed trzech lat mogą być mocno nieaktualne. Jeśli firma zasłoni się umowami NDA, to jeszcze nie powód do niepokoju. Ale jeśli nie jest w stanie dać Ci kontaktu do żadnego zadowolonego klienta, wyciągnij z tego wnioski.
Jaki jest Wasz stack technologiczny?
Jeśli nie jesteś osobą techniczną, to pytanie może wydawać się mało istotne. Ale stack technologiczny bezpośrednio wpływa na to, jak łatwo znajdziesz programistów, gdy zechcesz rozbudować zespół lub zmienić dostawcę. Zapytaj: “W jakich technologiach pracujecie i czy możecie pokazać przykładową architekturę podobnego systemu?” To pytanie nabiera szczególnego znaczenia, gdy masz już własny zespół techniczny, z którym dostawca będzie współpracować, albo planujesz w przyszłości przejąć system i rozwijać go samodzielnie.
Zwróć uwagę na to, jak dostawca reaguje na pytanie o technologię, w której nie ma doświadczenia. Firma, która otwarcie powie “nie pracowaliśmy w tym ostatnio, ale mamy te kompetencje” budzi większe zaufanie niż ta, która twierdzi, że jest ekspertem od wszystkiego.
Czy mogę porozmawiać z waszym Tech Leadem przed decyzją?
Na spotkaniach sprzedażowych rozmawiasz z handlowcami. Ale to nie oni będą pisać Twój kod. Zapytaj: “Czy przed podjęciem decyzji mogę porozmawiać z Tech Leadem, PO i inżynierem, którzy realnie będą pracować przy moim projekcie?” To w praktyce interview pod przykrywką. Sprawdzasz, czy to, co obiecał dział sprzedaży, ma pokrycie w kompetencjach i sposobie myślenia ludzi, z którymi będziesz pracować na co dzień.
Podczas tej rozmowy zwróć uwagę na kilka rzeczy. Czy zadają Ci mądre pytania o Twój biznes, czy tylko potakują? Czy potrafią wyjaśnić swoje podejście bez chowania się za żargonem? Czy odważą się zakwestionować Twoje założenie, jeśli widzą w nim problem? Szukasz partnerów, a nie potakiwaczy. Jeśli Tech Lead na wszystko mówi “tak, da się”, ale nie pyta “po co?”, to zły znak.
Ilu ludzi w zespole to Wasi pracownicy, a ilu będzie rekrutowanych?
Płacisz stawkę doświadczonej firmy, więc masz prawo wiedzieć, czy zespół faktycznie składa się z jej ludzi. Dopytaj, ile z tych osób pracuje w firmie od dłuższego czasu, a ile zostanie dopiero zrekrutowanych specjalnie pod Twój projekt. Zapytaj też o przewidywane seniority zespołu. Jeśli z odpowiedzi wynika, że brakuje 2/3 składu, powinna zapalić Ci się czerwona lampka. Dostaniesz wtedy nie zespół, tylko grupę ludzi, która dopiero będzie uczyć się ze sobą pracować. Na Twój koszt i przy Twoim projekcie.
Kto odpowiada za architekturę i jak zarządzacie długiem technologicznym?
Złe decyzje architektoniczne na starcie projektu są jak wady konstrukcyjne w budynku: im później je odkryjesz, tym drożej kosztuje naprawa. A dług technologiczny (czyli świadome “drogi na skróty” w kodzie) rośnie z każdym tygodniem. Jeśli nikt go nie kontroluje, z czasem dodanie każdej nowej funkcji będzie trwać coraz dłużej i kosztować coraz więcej. Zapytaj: “Kto będzie osobiście podejmował kluczowe decyzje architektoniczne i jak zarządzacie długiem technologicznym?” Szukasz konkretnej osoby z imieniem i nazwiskiem, a nie odpowiedzi “cały zespół decyduje wspólnie”.
Jak szybko dostarczycie zastępstwo za kluczowego dewelopera?
Ludzie odchodzą z projektów. To się zdarza i nie da się tego wyeliminować. Pytanie brzmi, co wtedy. Zapytaj: “Jak szybko jesteście w stanie dostarczyć kompetentne zastępstwo, gdy kluczowy programista odejdzie z projektu?” Chcesz usłyszeć konkretny czas (dni, nie tygodnie) i dowiedzieć się, czy firma ma “ławkę rezerwowych” w danej technologii. Dopytaj też, jak wygląda transfer wiedzy w zespole, bo jeśli cała wiedza o projekcie siedzi w głowie jednej osoby, to jej odejście może cofnąć Cię o miesiące.
Czy pozwolicie mi zweryfikować poziom ludzi w zespole?
Nie chodzi o to, żebyś zarządzał składem osobowym zespołu dostawcy. Chodzi o transparentność. Zapytaj: “Czy mój CTO lub zewnętrzny konsultant może przeprowadzić krótki wywiad techniczny z kluczowymi osobami w zespole?” To pytanie zadziała jak papierek lakmusowy. Firma zatrudniająca dobrych ludzi nie będzie miała z nim problemu. Opór lub wymijające odpowiedzi powinny dać Ci sporo do myślenia.
Jak wygląda Wasz proces rekrutacji i onboardingu?
Firma IT stoi na procesach. Jeśli nie ma sprawdzonego sposobu na weryfikację i wdrażanie nowych ludzi, prędzej czy później odbije się to na jakości. Nawet jeśli firma jako całość jakoś funkcjonuje, to Twój projekt może oberwać rykoszetem. Zapytaj: “Jak weryfikujecie nowo zatrudniane osoby i jak uczycie ich swoich standardów?” Samo hasło “mamy tu samych seniorów” nie znaczy nic, jeśli nie stoi za nim konkretny proces rekrutacji, onboardingu i kontroli jakości.
Czy macie doświadczenie w Project Rescue?
Dlaczego w ogóle sugerujemy to pytanie? Zbudować system od zera potrafi większość firm. Ale wejść w cudzy, często zaniedbany kod, przeprowadzić jego audyt i wyprowadzić projekt na prostą to zupełnie inna liga. Firma, która ma realne doświadczenie w ratowaniu projektów, siłą rzeczy musi mieć solidne procesy i standardy, bo bez nich żadna misja ratunkowa się nie udaje. Zapytaj: “Jak wygląda Wasz proces przejmowania projektów zaczętych przez kogoś innego?” Jeśli usłyszysz konkretny schemat działania (audyt, stabilizacja, plan naprawy), to dobry znak. Jeśli odpowiedź brzmi “jakoś to ogarniemy”, szukaj dalej.
Jak wykorzystujecie AI w procesach developerskich?
To, że kilku programistów w firmie korzysta z Copilota czy Claude Code, niewiele zmienia na poziomie organizacji. Ważne jest to, czy firma podeszła do wdrożenia AI systemowo. Zapytaj: “Czy macie ustandaryzowane zasady korzystania z AI w procesie developmentu?” Interesują Cię konkrety: wewnętrzne wytyczne dla programistów, rygorystyczne code review kodu generowanego przez AI, testy jakości. Firma, która odpowie “każdy używa czego chce”, traktuje AI jak zabawkę, a nie narzędzie produkcyjne.
Pytania dotyczące wyceny i optymalizacji kosztów
Pytania o pieniądze to nie tylko negocjacje. To test na to, czy dostawca rozumie Twoją sytuację finansową i potrafi doradzić najlepsze rozwiązanie w ramach budżetu, a nie tylko policzyć godziny i wystawić fakturę.
Co byście wycięli z projektu, gdyby trzeba było obciąć budżet?
Zapytaj: “Gdybyśmy musieli obciąć budżet o 30%, z czego byście zrezygnowali i dlaczego?” To pytanie-test. Dobry dostawca zaproponuje wycięcie funkcji, które realnie najmniej wpływają na wartość Twojego produktu. Może się okazać, że zmiana jednego wymagania (np. akceptacja dłuższego czasu przetwarzania danych) drastycznie obniży koszty infrastruktury. Słaby dostawca albo będzie nalegał na utrzymanie pełnego zakresu (bo więcej zarobi), albo spróbuje wyrzucić to, co jest dla niego trudne technicznie, a nie to, co jest dla Ciebie zbędne biznesowo.
Które z moich wymagań mają największy wpływ na cenę?
Dostawca, który potrafi jasno wytłumaczyć, co generuje największe koszty, naprawdę rozumie Twój problem. Kluczowe jest tu “dlaczego”. Jeśli usłyszysz konkretną odpowiedź (np. “obsługa wielu języków w pierwszej wersji podwoi czas developmentu, lepiej zacząć od jednego”), to znak, że rozmawiasz z kimś, kto naprawdę przeanalizował Twój problem. Jeśli dostaniesz tylko łączną kwotę bez rozbicia, to dostawca albo nie rozumie tego, co chcesz zbudować, albo nie chce, żebyś dokładnie wiedział, za co płacisz.
Ile będzie mnie kosztowała przerwa w developmencie?
Nie każdy projekt toczy się bez przerw. Czasem musisz wstrzymać prace na kilka miesięcy, bo szukasz kolejnej rundy od inwestora albo czekasz na decyzję zarządu. Zapytaj: “Jakie koszty poniosę, jeśli na dwa miesiące wstrzymamy development?” Chcesz wiedzieć, czy firma pobiera opłaty za “uśpienie” projektu (postojowe), czy może będziesz musiał pożegnać zespół i po przerwie zapłacić ponownie za ich onboarding. W obu przypadkach to realny koszt, który trzeba wliczyć w budżet z góry, a nie odkrywać go w połowie drogi.
Jak się rozliczymy? (Time & Materials czy Fixed Price)
Niektóre firmy oferują oba modele, inne specjalizują się w jednym. Zapytaj: “Jakie modele rozliczeń oferujecie i który rekomendujecie w mojej sytuacji?” W skrócie: Fixed Price to z góry ustalona cena za ustalony zakres. Daje przewidywalność budżetu, ale każda zmiana w wymaganiach to dodatkowe negocjacje i aneksy. Zmienisz zdanie w połowie projektu? Szykuj się na papierologię. T&M (Time & Materials) to płacenie za przepracowane godziny. Pełna elastyczność, ale musisz pilnować, na co zespół poświęca czas. Bez tego łatwo o sytuację, w której spaliłeś 80% budżetu, a zrealizowałeś 40% zakresu. Dostawca, który szczerze doradzi, który model lepiej pasuje do Twojej sytuacji (a nie do jego marży), zasługuje na dodatkowe punkty zaufania.
Pytania dotyczące utrzymania i bezpieczeństwa systemu
Sam development to zwykle mniejsza część całkowitego kosztu posiadania systemu. Większość budżetu w dłuższej perspektywie pochłoną utrzymanie i modernizacja. To trochę jak z kontraktami zbrojeniowymi: czołg kosztuje ułamek tego, co jego 20-letni pakiet serwisowy. Z oprogramowaniem jest podobnie. Poniższe pytania sprawdzą, czy dostawca myśli o Twoim produkcie w tej perspektywie.
Kto utrzymuje system po wdrożeniu na produkcję?
“Jakoś to będzie” to zdanie, które słyszymy zaskakująco często. A potem przychodzi pierwszy poważny bug na produkcji i okazuje się, że nikt nie wie, czyja to odpowiedzialność. Zapytaj: “Jak wygląda model wsparcia po wdrożeniu? Kto naprawia błędy i na jakich zasadach?” Dobra odpowiedź to konkrety: pakiet godzin miesięcznie, dedykowana osoba, gwarantowane SLA. Zła odpowiedź to cisza lub “ustalimy to później”. Jeśli dostawca nie ma na to gotowej odpowiedzi, prawdopodobnie nie ma też gotowego procesu.
Jak będziecie reagować na błędy poza godzinami pracy?
Wiele firm działa wyłącznie w godzinach 9-17. Jeśli Twój system obsługuje klientów w weekendy (np. sklep internetowy), awaria w niedzielę rano to nie “drobna niedogodność”, tylko realna strata pieniędzy. Zapytaj: “Jak monitorujecie system i jak szybko zareagujecie poza godzinami pracy?”
Tutaj warto znać trzy skróty. SLA to maksymalny czas reakcji na zgłoszenie (np. 15 minut). RTO mówi o tym, ile może trwać awaria, zanim system wstanie. RPO określa, ile danych z ostatnich godzin godzisz się stracić w najgorszym scenariuszu. Dopytaj też, co się stanie, gdy dostawca tych parametrów nie dotrzyma. Kary umowne za niedotrzymanie SLA to standard, nie fanaberia.
Co się stanie, gdy system padnie?
To pytanie wykracza poza technologię. Nie chodzi o to, czy serwer wstanie, tylko o to, czy Twój biznes przetrwa awarię bez strat. Zapytaj: “Jeśli system się wysypie, co stanie się z zamówieniami, danymi klientów i integracjami z zewnętrznymi platformami?” Dobry dostawca zaprojektuje architekturę tak, żeby w razie awarii jednego modułu reszta systemu działała dalej, a dane trafiały do bufora zamiast znikać w nicości. Jeśli w odpowiedzi usłyszysz tylko “podniesiemy serwer”, to za mało.
Gdzie będą trzymane dane i kto będzie miał do nich dostęp?
Bezpieczeństwo danych to “być albo nie być” wielu firm, a mimo to klienci rzadko pytają o nie przed podpisaniem umowy. Zapytaj: “Gdzie fizycznie będą przechowywane moje dane, kto będzie mógł je zobaczyć i jak wygląda Wasza polityka backupów oraz disaster recovery?” W odpowiedzi chcesz usłyszeć:
- lokalizacja serwerów (szczególnie jeśli podlegasz RODO),
- kto dokładnie będzie miał dostęp do danych Twoich użytkowników (programiści dostawcy? dostawca chmury? firmy trzecie?),
- częstotliwość backupów i procedura ich testowania,
- plan działania na wypadek utraty danych.
Jeśli dostawca nie ma na to gotowej odpowiedzi, to znak, że bezpieczeństwo danych nie jest wbudowane w ich procesy, tylko załatwiane ad hoc.
Jakie będą realne koszty infrastruktury?
Koszty chmury, serwerów i licencji potrafią rosnąć razem z liczbą użytkowników, a wielu klientów dowiaduje się o tym dopiero z pierwszej faktury po wdrożeniu. Zapytaj: “Ile orientacyjnie będzie kosztować miesięczne utrzymanie infrastruktury przy obecnej skali i jak ten koszt zmieni się, gdy liczba użytkowników wzrośnie dziesięciokrotnie?” Dobry dostawca potrafi dać Ci choćby widełki, bo miał już podobne projekty. Jeśli nie jest w stanie podać nawet przybliżonej kwoty, albo sam nigdy nie zarządzał infrastrukturą dla klienta, albo nie zadał sobie trudu, żeby dokładnie przeanalizować Twoje wymagania.
Pytania dotyczące ryzyka i zakończenia współpracy
Większość rozmów z dostawcą skupia się na tym, jak będzie wyglądać sukces. Mało kto pyta, co się stanie, gdy coś pójdzie nie tak albo gdy zdecydujesz się zakończyć współpracę. A to właśnie w kryzysie i przy rozstaniu okazuje się, z kim naprawdę masz do czynienia. Firma, która unika tych tematów na początku, będzie ich unikać też w trakcie projektu.
Opowiedzcie o projekcie, który był realnie zagrożony
Każdy software house miał w swojej historii trudny projekt. Jeśli mówią, że nie — po prostu kłamią. Dopytaj: “Co poszło nie tak i co zmieniliście w firmie po tamtej sytuacji?” Nie interesuje Cię wypolerowana wersja z prezentacji sprzedażowej. Interesują Cię fakty: co konkretnie się wydarzyło, kto podjął decyzję o działaniach naprawczych i jakie zmiany w procesach firma wprowadziła, żeby to się nie powtórzyło. Dobra odpowiedź to szczera historia z konkretnymi wnioskami. Zła to “u nas takich sytuacji nie było” albo opowieść, w której winny jest wyłącznie klient.
Kiedy ostatnio nie dowieźliście projektu na czas?
Pytanie, którego nikt nie zadaje, a wszyscy powinni. Samo w sobie zakłada, że tak się zdarzyło — i słusznie, bo to normalne w branży IT. Dopytaj: “Co było przyczyną i jak z tego wybrnęliście przed klientem?” Uczciwy dostawca opowie konkretną historię i powie, co zmienił, żeby podobna sytuacja się nie powtórzyła. Jeśli usłyszysz “u nas zawsze wszystko jest na czas”, traktuj to z dużą rezerwą.
Co robicie, gdy projekt zaczyna się sypać?
Poprzednie pytania dotyczyły przeszłości. To dotyczy przyszłości: Twojego projektu. Zapytaj: “Jaka jest Wasza procedura, gdy w projekcie dzieje się coś naprawdę złego — krytyczny bug na produkcji, odejście kilku osób naraz, poważny poślizg w harmonogramie?” Chcesz poznać konkretną ścieżkę eskalacji: kto podejmuje decyzje pod presją, w jakim czasie i jak wygląda komunikacja z klientem w trybie kryzysowym. Firma z doświadczeniem wie, jak deeskalować sytuację i komunikować się z klientem pod presją. Firma bez niego zacznie improwizować, a pożar w projekcie to nie jest moment na eksperymenty.
Skąd będę wiedział, że projekt idzie w złą stronę?
Jako klient, o problemach w projekcie zwykle dowiadujesz się za późno i za drogo. Zapytaj: “W jaki sposób zasygnalizujecie mi, że jest źle, zanim sam to odkryję?” Dobry dostawca nie czeka, aż zaczniesz zadawać niewygodne pytania. Sam przyjdzie z informacją: “mamy problem, oto jego skala, a oto nasz plan działania”. Jeśli w odpowiedzi usłyszysz tylko “będziemy wysyłać raporty tygodniowe”, to za mało. Żaden raport nie uratuje projektu. Uratuje go człowiek, który podniesie słuchawkę i powie “mamy problem”, zanim ten problem zamieni się w katastrofę.
Jak zarządzacie zmianą zakresu w trakcie projektu?
Zmiana zakresu to codzienność w projektach IT. Nowe wymagania, zmiany rynkowe, wnioski z testów z użytkownikami — powodów jest mnóstwo i żaden plan tego nie wyeliminuje. Zapytaj: “Opowiedzcie o sytuacji, w której musieliście zarządzić poważną zmianą zakresu. Jak to wyglądało?” W odpowiedzi zwróć uwagę na trzy rzeczy:
- kto zainicjował zmianę (klient, rynek, czy sam dostawca zauważył problem),
- jak szybko dostawca ocenił wpływ zmiany na harmonogram i budżet,
- jak przedstawił klientowi opcje i ich konsekwencje, żeby ten mógł podjąć świadomą decyzję.
Firma, która potrafi opowiedzieć taką historię ze szczegółami, ma na to wypracowany proces. Firma, która odpowiada ogólnikami, prawdopodobnie improwizuje za każdym razem.
Czy powiecie mi wprost, że to ja spowalniam projekt?
Nie zawsze to dostawca jest źródłem problemu. Czasem to Twoja firma blokuje postępy: opóźnione decyzje, brak dostępności kluczowych osób, wymagania zmieniające się co tydzień. Zapytaj: “Co zrobicie, jeśli po kilku miesiącach uznacie, że źródło opóźnień leży po mojej stronie?” Dostawca, który odważy się powiedzieć “problem leży po Twojej stronie”, jest więcej wart niż ten, który potakuje dla spokoju i kolejnych faktur. Szukasz partnera, któremu zależy na projekcie, a nie tylko na kontrakcie.
Czy zgodzicie się na zewnętrznego audytora w trakcie projektu?
Jeśli nie masz własnego zespołu technicznego, niezależny audyt kodu to jedyny sposób, żeby zweryfikować jakość tego, za co płacisz. Bez niego nie wiesz, czy pod maską nie rośnie dług technologiczny, który za pół roku zamieni każdą prostą zmianę w tygodniowy koszmar. Zapytaj: “Czy mogę w dowolnym momencie wynająć zewnętrznego konsultanta do przeglądu Waszego kodu?” Firma, która robi dobrą robotę, nie będzie miała z tym problemu. Opór lub próby odwlekania powinny zapalić Ci czerwoną lampkę — bo zwykle oznaczają, że jest co ukrywać.
Kto będzie właścicielem kodu źródłowego?
Większość klientów zakłada, że skoro płacą za development, to kod jest ich. Niekoniecznie. Bez odpowiedniego zapisu w umowie prawa do kodu mogą należeć do dostawcy. Zapytaj: “Kiedy dokładnie prawa do kodu przejdą na mnie i czy od pierwszego dnia będę miał dostęp do repozytorium?” Bieżący dostęp do repo to Twoje podstawowe zabezpieczenie na wypadek, gdyby współpraca się nie ułożyła. Jeśli dostawca zaproponuje przekazanie kodu “na koniec projektu”, ustal z góry, co to dokładnie oznacza i co się stanie z kodem, jeśli zdecydujesz się zakończyć współpracę przed realizacją pełnego zakresu.
Co się stanie, gdy zechcę zmienić dostawcę?
Zanim podpiszesz umowę, upewnij się, że da się z niej wyjść. Vendor lock-in to sytuacja, w której zmiana dostawcy jest tak kosztowna i bolesna, że w praktyce zostajesz z obecnym dostawcą, bo alternatywa jest gorsza. Nie powstaje ze złej woli — wystarczy brak dokumentacji, wiedza zamknięta w głowach kilku osób i kod, którego zrozumienie przypomina odszyfrowywanie hieroglifów. Zapytaj: “Jak wyglądałby proces przekazania projektu innemu zespołowi albo mojej firmie? Ile to zajmie i co dostanę?” Dobra odpowiedź to konkrety: aktualna dokumentacja techniczna, okres przejściowy z transferem wiedzy i kod napisany tak, żeby nowy zespół mógł go zrozumieć bez tłumacza.
Jakich pytań lepiej nie zadawać?
Skoro wiemy już, o co pytać, poświęćmy chwilę na pytania, których lepiej nie zadawać. Bo złe pytanie nie tylko nie pomaga — czasem aktywnie szkodzi, stawiając Cię w roli klienta, z którym trudno się pracuje.
“Jaki jest wasz najlepiej wykwalifikowany inżynier?”
Odpowiedź będzie albo “mamy człowieka z 30-letnim stażem”, albo odbicie piłeczki: “a w jakiej technologii konkretnie? Bo mamy full-stacka, który pracował już w 10 językach…” Żadna z tych odpowiedzi nie mówi Ci niczego o zespole, który realnie dostaniesz. Pytaj o ludzi, którzy będą pracować przy Twoim projekcie, a nie o statystyki z działu HR.
“Błagam, nie doprowadźcie mnie do zawału tą ceną.”
Cytat z prawdziwego spotkania. Dostawca nie ma jak na to odpowiedzieć, bo nie kontroluje Twojego budżetu. Ale może pomóc Ci dopasować zakres prac do kwoty, którą dysponujesz. Więc zamiast komentować cenę, zapytaj co można wyciąć.
Brak pytań (40-minutowy monolog o swoim biznesie)
Też z autopsji. Klient przez 40 minut opowiadał o 488% ROI ze swojej strategii tradingowej. Nie zadał ani jednego pytania. Słuchaliśmy grzecznie, ale po spotkaniu nie mieliśmy pojęcia, co w ogóle wycenić. Spotkanie, na którym mówisz tylko Ty, to spotkanie, z którego wychodzisz niewiele mądrzejszy niż przed nim.
“Czy robiliście projekty w fintechu?”
“Tak. Następne pytanie.” — mniej więcej tyle dostaniesz w odpowiedzi. Na tak ogólne pytania większość dostawców odpowie twierdząco i kompletnie nic z tego nie wyniknie. Zamiast pytać “czy robiliście coś w fintechu”, zapytaj o konkretny aspekt: “Czy budowaliście systemy zgodne z PSD2?”, “Jak wyglądała u Was integracja z dostawcą płatności w środowisku objętym PCI DSS?” albo “Jak rozwiązywaliście KYC w aplikacji mobilnej?”. Tutaj samo “tak” nie wystarczy — trzeba opowiedzieć historię.
Od czego zacząć pierwszą rozmowę z dostawcą IT?
Jeśli masz tylko 30 minut na rozmowę z dostawcą, zacznij od tych sześciu pytań. Odpowiedzi na nie powiedzą Ci więcej niż godzina prezentacji sprzedażowej.
- Doświadczenie: “Pokażcie mi podobny projekt i dajcie bezpośredni kontakt do klienta.”
- Proces: “Jak wyglądają pierwsze 60 dni współpracy i co dokładnie wtedy otrzymam?”
- Ryzyko: “Opowiedzcie o projekcie, który wam nie wyszedł. Co z tym zrobiliście?”
- Zrozumienie problemu: “Jak zbieracie wymagania i skąd będę wiedzieć, że rozumiecie mój cel?”
- Rozmowa z Tech Leadem: “Czy przed podjęciem decyzji mogę porozmawiać z osobą techniczną z Waszego zespołu?”
- Krytyczne spojrzenie: “Co Was najbardziej niepokoi w tym projekcie?”
Jak wybrać dostawcę IT — kluczowe wnioski
Zebraliśmy w jednym miejscu sporo pytań — od procesów, przez finanse, po scenariusze kryzysowe. Nie odpuszczaj żadnego tematu, bo każde z tych pytań ma ten sam cel: pomóc Ci uniknąć kosztownego błędu, jakim jest podpisanie umowy z nieodpowiednią firmą.
Samo zadanie tych pytań to dopiero połowa roboty. Druga połowa to uważne słuchanie odpowiedzi. Zwracaj uwagę na szczegóły, dopytuj, gdy coś brzmi zbyt gładko, i nie oceniaj każdej odpowiedzi z osobna — oceniaj obraz, na który się składają. Na jedno trudne pytanie potrafi dobrze odpowiedzieć każdy. Ale przy dziesiątym z rzędu różnica między dostawcą, który naprawdę wie, co robi, a tym, który dobrze sprzedaje, staje się wyraźna.
A co po podpisaniu umowy?
Dobry wybór dostawcy to fundament, ale to, co na nim zbudujesz, zależy od tego, jak prowadzisz produkt od pierwszego dnia developmentu. Strategia, discovery, jakość kodu, przywództwo: każdy z tych filarów decyduje o tym, czy Twój produkt będzie za rok zdrowy i konkurencyjny, czy zacznie po cichu niedomagać, zanim zdążysz to zauważyć. Zadbaj o zdrowie swojego produktu od pierwszego dnia z naszą checklistą kondycji produktu.
