Jak zweryfikować zespół dostawcy oprogramowania przed umową?

Kilka lat temu przejęliśmy projekt Web3 od innego dostawcy. Ich kod był nie do uratowania. Potężny dług techniczny. Mockupy wmieszane w kod produkcyjny. Nie dało się stwierdzić, co właściwie działa. Klient później wspomniał, że z tamtym zespołem ciężko było się dogadać już od pierwszego tygodnia.

Wszystkie te problemy dało się wyłapać na starcie. Po prostu nikt ich nie szukał.

Większość firm ocenia zespoły dostawców po niewłaściwych sygnałach: latach doświadczenia, listach technologii i wypolerowanych diagramach architektury. Zapytałem naszego CTO i pięciu senior developerów, na co patrzeć zamiast tego. Ten artykuł bazuje na ich odpowiedziach.

Zanim przejdę do pytań, jedna uwaga: sami „świetni programiści” to za mało. Nawet bardzo dobrzy inżynierowie, bez sensownego produktowca i stałego kontaktu z biznesem, mają małe szanse na dowiezienie trafionego rozwiązania. W praktyce szybko może okazać się, że budują coś, co nie ma prawa zadziałać: rozjeżdża się scope, rośnie dług techniczny, a kluczowe decyzje zapadają zbyt wolno. Nie wspominając już o rynku, na którym sytuacja co chwilę się zmienia. I każdy z tych problemów bywa wystarczający, żeby położyć projekt.

Dlatego nigdy nie prowadzimy projektów bez Product Ownera. To on pilnuje, by zespół znał cele biznesowe, scope i sytuację rynkową – ale to w gestii inżynierów pozostaje korzystanie z tej wiedzy w praktyce. Dobrzy inżynierowie nie czekają, aż ktoś z zewnątrz wytłumaczy im powody biznesowe stojące za daną decyzją; dopytują, sami budują sobie obraz sytuacji i dopiero wtedy wybierają odpowiednie rozwiązania techniczne. W takim układzie da się dowieźć nawet bardzo złożone produkty.

Przejęliśmy wystarczająco dużo projektów w kryzysie, żeby wiedzieć, co się dzieje gdy w zespole brakuje PO: zdolni programiści wpadają w kłopoty, bo decyzje produktowe, biznesowe i techniczne przestają się ze sobą zgrywać. Dlatego, chociaż reszta tego artykułu skupia się na stronie inżynieryjnej – na tym, jak rozpoznać zespół, który myśli, zanim napisze kod, zadaje właściwe pytania i utrzymuje projekt na właściwych torach – miej tę produktową uwagę z tyłu głowy.

Co sprawdzić, oceniając zespół deweloperski dostawcy

Weryfikacja sprowadza się do dwóch pytań: jak myślą konkretni ludzie, których dostawca przypisze do Twojego projektu, i jak się zachowują, kiedy w projekcie robi się niewygodnie. Portfolio i case studies nie odpowiedzą Ci na żadne z nich.

To nie tylko nasza opinia. Mark Murphy w książce Hiring for Attitude opisuje trzyletnie badanie Leadership IQ obejmujące 20 000 nowo zatrudnionych osób. W ciągu pierwszych 18 miesięcy nie sprawdziło się 46% z nich. Tylko 11% tych niepowodzeń wynikało z braku kompetencji technicznych. Pozostałe 89% – z postawy: gotowości do przyjmowania feedbacku, inteligencji emocjonalnej, motywacji i temperamentu. Innymi słowy: kompetencje techniczne łatwiej zweryfikować i rzadko to one decydują o tym, czy konkretna osoba się sprawdzi.

Po Twojej stronie weryfikacja dzieli się tak samo. Kompetencje techniczne zweryfikujesz na kilka sposobów: przykładowe architektury, próbki kodu, certyfikaty albo krótkie płatne zadanie weryfikacyjne. Trudniej (i ważniej) jest sprawdzić, czy zespół, z którym zamierzasz pracować, dobrze przyjmie krytykę, w porę zasygnalizuje złe wieści, zakwestionuje pracę, w której nie widzi sensu, i nie odpuści, gdy zrobi się trudno. To testy postawy, nie umiejętności.

Ten sam podział oddziela juniorów od seniorów. Kacper ujmuje to tak:

• Jak to napisać – to terytorium juniora.
• Jak to zaprojektować (żeby system był skalowalny, bezpieczny i wydajny, a jednocześnie nie był przerostem formy nad treścią względem realnych potrzeb biznesu) – to terytorium seniora.

Terytorium seniora sprowadza się do sposobu myślenia – i tego właśnie nasz CTO oraz pięciu naszych senior developerów (zapytanych niezależnie od siebie) szukaliby u konkretnych ludzi, których dostawca wystawia do projektu. Konkretnie: świadomości kompromisów, rozumienia kontekstu biznesowego i umiejętności zadawania właściwych pytań, jasnego uzasadnienia decyzji technicznej oraz uczciwej refleksji nad błędami z przeszłości. Wszyscy są z Pragmatic Coders, więc potraktuj to jako naszą wewnętrzną perspektywę, a nie uniwersalną regułę.

Z kim rozmawiać w zespole dostawcy (i dlaczego)

Standardowym ruchem jest rozmowa z tech leadem. To on pokaże Ci sposób myślenia o architekturze, proces dostarczania (delivery), standardy jakości oraz to, jak zespół dogaduje się z biznesem w trudnych sytuacjach. Ponieważ rotacja w branży to norma, musisz też wypytać go (lub engineering managera) o procesy rekrutacji i onboardingu. Jeśli ktoś odejdzie, skąd pewność, że na jego miejsce nie wejdzie przypadkowy programista „z ulicy”, a cała wiedza o projekcie nie pójdzie w las? Przy okazji tej rozmowy upewnij się też, czy zespół będzie przypisany do Twojego projektu na pełen etat (full-time) – praca w ułamkach etatu to częsta pułapka.

Ale powinieneś też porozmawiać z senior developerem.

Tu pojawia się haczyk: dobry software house raczej nie zagwarantuje Ci przed podpisaniem umowy, że to dokładnie ta osoba trafi do Twojego projektu. Dostępni inżynierowie trafiają do tego klienta, który pierwszy złoży podpis. Jeśli dostawca z góry obiecuje Ci konkretne nazwiska, często świadczy to o desperacji (zbyt długa ławka) albo o klasycznym bait-and-switch: zagwarantuje Ci „gwiazdy” na etapie sprzedaży, żeby po podpisaniu umowy podmienić je na kogoś innego.

Po co więc rozmawiać z seniorem, skoro może nie trafić do Twojego zespołu? Żeby sprawdzić realną poprzeczkę talentów u dostawcy. Senior developer pokaże Ci praktyczne wzorce podejmowania decyzji: jak podchodzi do realnego problemu, czy zadaje pytania doprecyzowujące, czy potrafi wskazać kompromisy. To pokaże Ci, jakich ludzi faktycznie przepuszcza ich proces rekrutacyjny.

Inne osoby po stronie dostawcy (account managerowie, sprzedawcy) mogą dodać przydatny kontekst, ale to nie oni dostarczą Ci podstaw do podjęcia decyzji. Oprzyj swój wybór na ocenie procesów przez tech leada i próbce talentu od senior developera.

Jak przeprowadzić rozmowę z tech leadem dostawcy

Poniższe pytania pochodzą od naszego CTO, Marcina. Każde z nich testuje coś konkretnego, a prawie żadne nie sprawdza wiedzy technicznej bezpośrednio. Struktura odpowiedzi liczy się tu bardziej niż sama treść. Zwracaj uwagę na to, czy padają w niej konkrety, nazwane procesy i czy rozmówca potrafi krytycznie spojrzeć na własne decyzje.

1. „Skąd będę wiedział, że coś idzie nie tak? Przeprowadź mnie przez konkretny przykład z poprzedniego projektu.” To test na transparentność, zwłaszcza w przekazywaniu złych wieści. Jeśli zapytasz tylko o to, jakie metryki śledzą, usłyszysz wyuczoną formułkę od dostawców z ładnymi prezentacjami. Pytając o konkretną historię z przeszłości, zmuszasz ich do mówienia o faktach. Szukasz realnego przypadku: co wypłynęło, kiedy, kto pierwszy zasygnalizował problem i jak wyglądała rozmowa z klientem. Odpowiedź, przed którą ostrzega Marcin, to „damy znać, gdy pojawi się problem” bez podania przykładu – zanim faktycznie dadzą znać, będzie już za późno. Tech lead, który potrafi nazwać dawny problem i opowiedzieć, jak go eskalował, z dużym prawdopodobieństwem zrobi to samo u Ciebie.

2. „Opowiedz mi o sytuacji, w której Twój zespół dostał zadanie, które wydawało mu się bezsensowne. Co się wtedy wydarzyło?” To pytanie sprawdza, czy Twoi inżynierowie naprawdę angażują się w pracę, czy tylko ją odhaczają. Jest celowo otwarte: nie podpowiadasz, jakiego rodzaju „braku sensu” oczekujesz – biznesowego, technicznego, zakresowego czy priorytetowego. Tech lead sam musi wyciągnąć konkretny przykład z pamięci. Szukaj konkretnej historii: kto pierwszy zwrócił uwagę, co padło, co się zmieniło (albo dlaczego się nie zmieniło) i jak tech lead na to zareagował. W mocnych odpowiedziach pojawia się sprzeciw zespołu, pytania doprecyzowujące do klienta lub PO i rozwiązanie, które wzięło się z realnej rozmowy. Słaba odpowiedź jest ogólnikowa: „nasz zespół jest na ogół zaangażowany” albo „dbamy o to, żeby wszyscy rozumieli, po co to robią”. Bez konkretnego przykładu nie ma czego weryfikować. Zespół, który nigdy nie kwestionuje pracy, nie wychwyci momentu, w którym sam brief okazuje się błędny.

3. „Załóżmy, że mijają trzy miesiące, a ja jestem niezadowolony z tego, jak Wam idzie. Co najprawdopodobniej byłoby tego przyczyną?” Tym jednym pytaniem testujesz szczerość, doświadczenie i gotowość do wzięcia odpowiedzialności. Chcesz usłyszeć o konkretnym problemie z ich doświadczenia i o tym, czego się dzięki niemu nauczyli. Odpowiedzi, przed którymi Marcin szczególnie ostrzega, to „nie ma scenariusza, w którym byłbyś niezadowolony” oraz cokolwiek, co zrzuca winę na zmieniające się wymagania. Jedno i drugie sygnalizuje, że mogą w przyszłości próbować uniknąć odpowiedzialności.

4. „Opowiedz mi o sytuacji, w której klient miał obiekcje do tego, co Wasz zespół zbudował lub zaproponował. Jak brzmiał feedback, co pomyślałeś, gdy go usłyszałeś, i co faktycznie zmieniliście w rezultacie?” Ta trzyczęściowa struktura ma konkretny cel. Sprawdzasz w ten sposób, czy rozmówca potrafi przywołać realny przypadek, czy szczerze opowie o swojej pierwszej reakcji i czy ta sytuacja faktycznie zmieniła coś w sposobie pracy zespołu. W dobrych odpowiedziach przebija się jedno: ciekawość. Tech lead, który traktuje uwagi klienta jako sygnał do zrozumienia problemu („chcieliśmy się dowiedzieć, dlaczego tak to widzą”), a nie jako atak, dokładnie tak samo potraktuje Twój feedback. Sygnały ostrzegawcze według Marcina to: zrzucanie winy na klienta („gdy wytłumaczyliśmy im technikalia, przyznali nam rację”), defensywny dobór słów („klient nie do końca rozumiał nasze podejście”), bagatelizowanie obiekcji pod pretekstem tego, że zespół i tak świetnie pracował, albo mgliste „poprawiliśmy komunikację”, za którym nie idzie żadna konkretna zmiana w procesie.

5. „Jakich standardów technicznych będzie trzymał się Wasz zespół? Przeprowadź mnie przez Waszą techniczną checklistę.” Szukaj fizycznej checklisty lub nazwanych standardów. Konkretny sygnał ostrzegawczy według Marcina: „wysokie standardy włączymy, jak już projekt na dobre ruszy”. Standard albo obowiązuje od pierwszego dnia, albo nie istnieje.

6. „Opowiedz mi, jak wyglądały pierwsze 2–4 tygodnie w podobnym projekcie, który prowadziłeś. Nie plan, który sprzedaliście – faktyczny pierwszy miesiąc.” Czas przeszły użyty celowo. Wypolerowaną roadmapę na cztery tygodnie łatwo zmyślić. Realny przebieg tych tygodni – co odkryto, co wpłynęło na scope, co zaliczyło poślizg – znacznie trudniej udawać. Jeśli potrafi tydzień po tygodniu opisać to, co faktycznie się wydarzyło (a nie to, co miało się wydarzyć), to znaczy, że zespół naprawdę coś kiedyś dowiózł. W tym pytaniu szukasz też procesu, z którym przychodzą. Jak zauważa Marcin: programistę możesz po prostu zatrudnić; od dostawcy kupujesz sprawdzone procesy dostarczania, a nie tylko ręce do pisania kodu. Jeśli uciekają w slogany typu „zaczęlibyśmy od discovery i ustawilibyśmy sprint planning”, opisują suchą teorię, a nie sprawdzony w boju proces.

Jak przeprowadzić rozmowę z senior developerem dostawcy

Ta sekcja bazuje na doświadczeniach pięciu naszych senior developerów – tych samych ludzi, którzy prowadzą u nas techniczne rozmowy rekrutacyjne. Poniższe wzorce to sygnały, na które sami zwracają uwagę, przełożone na perspektywę klienta.

Większość nietechnicznych klientów wpada w tę samą pułapkę: próbują ocenić twarde umiejętności programistyczne, chociaż nie mają do tego narzędzi ani wiedzy. Wcale nie musisz tego robić. Sposób, w jaki senior zabiera się za problem, powie Ci prawie wszystko co powinieneś wiedzieć.

Według Sebastiana najlepszym testem jest rzucenie seniorowi konkretnego problemu z prawdziwego projektu (najlepiej Twojego) i obserwowanie, jak do niego podejdzie. Prawdziwy senior najpierw zadaje pytania, bo zanim cokolwiek zaproponuje, chce zrozumieć specyfikę i ograniczenia projektu. Dopiero potem, z lotu ptaka, opisuje, z jakich bloków musiałby składać się system, jakie są alternatywy dla tych bloków i z jakimi kompromisami się wiążą. Sebastian podsumowuje to w ten sposób: ta jedna 20-minutowa wymiana zdań powie Ci więcej niż jakiekolwiek CV. Dowiesz się z niej, czy lata wpisane w życiorys to faktyczne doświadczenie w rozwiązywaniu problemów, czy tylko czas spędzony na stanowisku.

Zwróć uwagę, jak Twój rozmówca strukturyzuje swoje myślenie:

• Czy najpierw zadał pytania doprecyzowujące?
• Czy pytał o problem biznesowy, a nie tylko o jego techniczną warstwę?
• Czy wymienił alternatywy?
• Czy wytłumaczył, dlaczego wygrała konkretna opcja?

To, czy technologia, którą zaproponował, jest poprawna, nie ma na tym etapie znaczenia – i tak nie jesteś w stanie tego zweryfikować. Znacznie ważniejsze jest to, czy jego pytania pokazują, że próbuje zrozumieć, co budujesz, a nie tylko jak to zbudować. Senior, który zagłębia się wyłącznie w stack technologiczny, będzie potrzebował kogoś, kto przetłumaczy mu każdą decyzję biznesową.

Oprócz omówienia realnego problemu, przetestuj seniora w czterech kolejnych obszarach:

• Uzasadnianie kompromisów (Paweł). Zapytaj o niedawną decyzję architektoniczną: jakie były alternatywy i dlaczego wygrała ta konkretna. Dla Pawła dobrym sygnałem jest struktura X/Y/Z: prawdziwy senior mówi „opcjami były X, Y i Z. Wybrałem X z powodu A, B i C”. Brak takiej struktury oznacza brak decyzji, której warto by bronić.
• Świadomość konsekwencji (Mateusz). Zapytaj, czy niedawna decyzja przetrwała próbę czasu i co dziś zrobiłby inaczej. Prawdziwy senior potrafi ocenić swoje wybory z perspektywy czasu. Ktoś, kto nie potrafi wskazać niczego do poprawy, prawdopodobnie nigdy nie odpowiadał za projekt na tyle długo, by zderzyć się z konsekwencjami własnych decyzji.
• Prawdziwe powody wyboru technologii (Mateusz). Wybierz technologię, z której zespół intensywnie korzysta, i poproś o jej obronę. Nie zadowalaj się hasłem „bo to standard”. Szukaj konkretnego powodu. Największy sygnał ostrzegawczy to odpowiedź „bo tak się to robi” – to branżowy odpowiednik powiedzenia „jeśli masz tylko młotek, wszystko wygląda jak gwóźdź”. W efekcie zapłacisz za rozwiązanie w kształcie młotka.
• Test na przerost formy nad treścią (Kacper). Zapytaj: „jak zbudowałbyś prostą wewnętrzną aplikację CRUD dla 50 użytkowników?”. Prawdziwy senior zaproponuje rozwiązanie adekwatne do skali. Ktoś, kto do 50-osobowego CRUD-a proponuje mikroserwisy, event sourcing i autorski design system, ma poważny problem z oceną sytuacji. Umiar liczy się w IT tak samo jak umiejętność skalowania.

Przez to wszystko przewija się jeden wspólny mianownik: dobrzy seniorzy najpierw zadają pytania, a dopiero potem cokolwiek proponują. Sebastian zwrócił na to szczególną uwagę. Ktoś, kto od razu rzuca gotowym rozwiązaniem, po prostu dopasowuje znane sobie schematy do powierzchownych poszlak. Rozwiązuje problem, który widział już wcześniej – a to wcale nie musi być Twój problem.

Jedna uwaga do całej tej sekcji: oceniaj to, o co senior pyta i jak argumentuje, a nie to, jak gładko to sprzedaje. Niektórzy znakomici inżynierowie bywają szorstcy, zacinają się albo po prostu nie czują się dobrze w komunikacji biznesowej. Sygnałem, którego szukasz, jest struktura ich myślenia. Gładka gadka niczego tu nie dodaje, a jej brak niczego nie przekreśla.

Kiedy zaprosić doradcę technicznego do weryfikacji dostawcy

Powyższe pytania działają niezależnie od tego, czy masz doświadczenie techniczne, czy nie. Jednak bez wiedzy inżynierskiej Twoje możliwości oceny w pewnym momencie się kończą.

Jeśli masz po swojej stronie CTO lub doświadczonego tech leada, wejdźcie głębiej. Szymon uważa 30-minutową sesję pair programmingu za najmocniejszy możliwy sygnał. Przez pół godziny wspólnego pisania kodu Twój ekspert dowie się więcej o tym, jak myśli inżynier po drugiej stronie, niż z trzech zwykłych rozmów. To jednak wymaga twardych kompetencji po Twojej stronie – bez doradcy technicznego na spotkaniu nie będziesz w stanie zinterpretować tego, co widzisz.

Jeśli nie masz takich kompetencji u siebie w firmie, poszukaj ich na zewnątrz. Wynajmij doradcę technicznego na kilka godzin. Poproś o przysługę znajomego CTO. Ściągnij kogoś z zarządu, kto ma za sobą przeszłość inżynierską. Trudno oszacować w liczbach, o ile dokładnie rośnie ryzyko, gdy weryfikujesz dostawcę bez technicznego wsparcia – nie mamy takich danych. Możemy jednak powiedzieć, że matematyka jest tu bezlitosna: kilka godzin pracy doświadczonego inżyniera kosztuje niewiele. Zły dostawca, którego będziesz musiał wymienić po trzech miesiącach, kosztuje fortunę.

Sygnały ostrzegawcze u dostawcy oprogramowania

Większość z tych sygnałów wyłapiesz już podczas rozmów, o których pisaliśmy wyżej. Łączy je jeden wspólny mianownik: ogólniki tam, gdzie oczekujesz konkretu. Najmocniej waż jednak sygnały dotyczące postawy – tego, jak ludzie po stronie dostawcy reagują na presję, krytykę i niepewność. To one częściej niż same kompetencje techniczne przesądzają o powodzeniu projektu.

• Brak przykładów własnych pomyłek. Tech lead, który nie potrafi przywołać żadnego błędu – własnego ani zespołu – jest albo nierefleksyjny, albo nie mówi Ci wszystkiego. Każda z tych opcji to problem.
• Bezkonfliktowa narracja o zespole: „nigdy nie mieliśmy poważnej różnicy zdań z klientem” albo „zespół jest zawsze zgrany”. Prawdziwe zespoły się ścierają; te, które udają, że nie – zarządzają Twoim wrażeniem.
• Unikanie odpowiedzialności przy pytaniach o przeszłe błędy: „nie ma scenariusza, w którym byłbyś niezadowolony” (Marcin).
• Rekomendowanie rozwiązania przed zadaniem pytań. To dopasowywanie schematów, a nie rozwiązywanie problemów (Sebastian).
• „Bo tak się to robi.” Brak umiejętności uzasadnienia decyzji technicznej (według Mateusza to największa czerwona flaga).
• Mgliste opowieści o procesie w pierwszych tygodniach: „zaczniemy od spotkań scrumowych” zamiast konkretnego planu (Marcin).
• Jakość odłożona na później: „wdrożymy pełny standard, jak już na dobre ruszymy” (Marcin).
• Rzucanie terminami (np. „odpalimy to za rok”), zanim zakres zostanie w ogóle zdefiniowany (Marcin).
• Przerost formy nad treścią (over-engineering): np. proponowanie mikroserwisów i event sourcingu do prostego narzędzia wewnętrznego (Kacper).
• Procesy rekrutacyjne oparte na łamigłówkach algorytmicznych w stylu LeetCode, zamiast na ocenie architektonicznego rozsądku (Szymon).

Jeśli prosisz o konkretny przykład, a w zamian słyszysz ogólny opis procesu, to już masz swoją odpowiedź. Znaczy to po prostu tyle, że nie mają żadnego przykładu, którym mogliby się podzielić.

Podsumowanie

W tym tekście omówiliśmy tylko jeden aspekt weryfikacji. Pełna lista pytań, które powinieneś zadać dostawcy przed podpisaniem umowy, jest znacznie dłuższa i obejmuje też kwestie procesu, wyceny, utrzymania oraz ryzyka.

Podsumuj ten artykuł za pomocą sztucznej inteligencji

ChatGPT

Claude

Perplexity