Po czym poznać, że Twój dostawca software’u nie ma kontroli nad jakością

Kupowanie software’u, czy to jako projektu, czy jako stałej usługi rozwoju, jest trochę jak wynajmowanie ekipy do remontu mieszkania. Możesz mieć świetną umowę, piękny harmonogram i błyszczące slajdy. A potem i tak wszystko rozbije się o jedno pytanie: czy ta ekipa naprawdę kontroluje jakość, czy tylko dowozi „coś”, a poprawki będą Twoim codziennym sportem. W IT to bywa jeszcze trudniejsze, bo jakość potrafi wyglądać dobrze przez kilka sprintów, a rachunek przychodzi później, gdy rośnie liczba zmian, integracji i użytkowników.

Dobra wiadomość jest taka, że brak kontroli nad jakością da się rozpoznać szybciej, niż myślisz. Zła wiadomość jest taka, że wiele firm patrzy na złe sygnały, ale je racjonalizuje, bo przecież dowożą, bo przecież są mili, bo przecież mamy już podpisane. Ten artykuł jest po to, żebyś miał listę konkretnych sygnałów ostrzegawczych i wiedział, o co pytać, zanim problem stanie się kosztowny.

Pierwszy sygnał: nie potrafią powiedzieć, ile defektów trafia na produkcję

Jeśli dostawca nie mierzy defect escape rate albo nie umie go wyjaśnić, to jest ogromna czerwona flaga. Nie dlatego, że wszyscy muszą mieć idealne metryki. Dlatego, że firma, która kontroluje jakość, zawsze wie, ile problemów ucieka i gdzie ucieka. Jeżeli słyszysz odpowiedzi w stylu to zależy, nie mamy takich danych, u nas jest mało bugów, to znaczy, że jakość jest zarządzana intuicją, a intuicja nie skaluje się przy większym projekcie.

W praktyce nie chodzi nawet o samą liczbę. Chodzi o to, czy dostawca pokazuje trend i czy umie wskazać, które obszary produktu generują ryzyko. Bez tego nie ma kontroli, jest reakcja.

Drugi sygnał: testy są traktowane jak etap na końcu, a nie jak system

Dostawca bez kontroli jakości zwykle działa tak. Najpierw development, potem szybkie testy, potem poprawki, potem wydanie. To wygląda jak proces, ale w rzeczywistości jest to wodospad w dwutygodniowych sprintach. Kontrola jakości zaczyna się za późno, więc każdy błąd kosztuje więcej, a Ty dostajesz produkt, który jest „prawie gotowy”, tylko że prawie gotowy to w praktyce najdroższy stan.

Dostawca, który ma kontrolę, buduje jakość w procesie. Ma jasne Definition of Done, ma code review, ma automatyczne testy w CI, ma bramki jakościowe i ma monitoring. I co ważne, potrafi Ci to pokazać w liczbach, a nie w obietnicach.

Trzeci sygnał: regresja trwa długo, jest ręczna i wszyscy się do tego przyzwyczaili

Jeśli za każdym releasem jest wielodniowa regresja manualna, a zespół mówi, że tak musi być, to prawie zawsze oznacza brak inwestycji w automatyzację tam, gdzie daje zwrot. Taki dostawca będzie dowoził wolniej, będzie rzadziej releasował i będzie częściej wpadał w tryb gaszenia, bo feedback jest spóźniony.

Co gorsza, długa regresja ręczna bywa usprawiedliwiana jako dowód dbałości o jakość. To jest mylące. Dbałość o jakość to szybki feedback i stabilna bramka, nie tygodniowe klikanie. Tygodniowe klikanie to sygnał, że proces nie skaluje się z produktem.

Czwarty sygnał: dużo bugów wraca, mimo że były już naprawione

To jest klasyczny objaw słabej kontroli jakości. Jeśli to samo wraca, to znaczy, że nie ma skutecznych testów regresyjnych, nie ma analizy przyczyny źródłowej albo nie ma standardów, które zapobiegają powtórce. Dostawca może być bardzo sprawny w naprawianiu bugów, ale jednocześnie słaby w zapobieganiu im. A to jest różnica między ekipą, która robi jakość, a ekipą, która robi poprawki.

Dobre zespoły po poważnym defekcie robią krótkie postmortem, wyciągają wnioski i wprowadzają zabezpieczenie. Nie kolejną obietnicę, tylko konkret, test, check w CI, zmianę w Definition of Done, ulepszenie review. Jeśli dostawca nie ma takiego nawyku, to będziesz płacił za te same klasy problemów w kółko.

Piąty sygnał: testy są flaky albo środowiska są niestabilne i nikt nie traktuje tego poważnie

Flakiness to cichy zabójca. Jeśli testy raz przechodzą, raz nie, a odpowiedź brzmi to pewnie środowisko, to znaczy, że nikt nie kontroluje fundamentów. A bez fundamentów jakość jest loterią. Najgorsze jest to, że flakiness uczy ludzi ignorowania sygnałów. A jeśli ignorujesz sygnały, to prędzej czy później przepuszczasz realny defekt.

Dostawca z kontrolą jakości ma metryki flakiness, ma właściciela stabilności testów, ma izolację danych i środowisk, a czerwone buildy są traktowane jak alarm, nie jak tło.

Szósty sygnał: nie ma jasnych kryteriów akceptacji i Definition of Done

Jeśli wymagania są miękkie, a akceptacja dzieje się na końcu jako „czy działa”, to będziesz miał spory, poprawki i rozjechane oczekiwania. Dostawca bez kontroli jakości często lubi takie rozmycie, bo daje pole manewru. Dostawca z kontrolą jakości chce jasności, bo jasność pozwala budować testy, automaty i przewidywalność.

W praktyce dobrym testem jest to, czy dostawca potrafi Ci pokazać, co znaczy gotowe dla jednego user story. Jeśli to jest lista typu kod zreviewowany, testy jednostkowe, testy integracyjne, aktualizacja dokumentacji, monitoring, to jest dobrze. Jeśli to jest działa u mnie, to jest źle.

Siódmy sygnał: jakość jest raportowana językiem aktywności, a nie wpływu

Jeśli dostawca raportuje liczbę testów, liczbę wykonanych przypadków, liczbę zgłoszonych bugów, to jest to raportowanie operacyjne, nie zarządcze. Może być przydatne, ale nie świadczy o kontroli jakości. Kontrola jakości jest wtedy, gdy dostawca mówi o trendach, ryzykach i wpływie, czyli defect leakage, MTTR, stabilność pipeline, pokrycie krytycznych ścieżek.

Jeśli raporty brzmią jak encyklopedia, a nie jak instrukcja decyzji, to znaczy, że dostawca nie umie zarządzać jakością na poziomie systemu.

Ósmy sygnał: release zawsze jest stresujący i wymaga heroizmu

To jest sygnał kulturowy. Jeśli każde wdrożenie to nocne czuwanie, manualne checki, modlitwa i szybkie poprawki po wydaniu, to znaczy, że proces jest oparty na heroizmie, a nie na kontroli. Kontrola jakości oznacza, że release jest nudny. Nuda w release jest oznaką dojrzałości.

Dostawca, który ma kontrolę, ma feature flags, ma rollback, ma monitoring i ma szybkie mechanizmy reagowania. Dostawca, który jej nie ma, ma stres i nadgodziny.

Dziewiąty sygnał: brak przejrzystości w danych jakości i brak dostępu do wyników

Jeśli nie masz wglądu w wyniki testów, w historię buildów, w status pipeline, w defekty i ich klasy, to znaczy, że jakość jest w czarnej skrzynce. Czasem to wynika z narzędzi, czasem z procesów, a czasem z chęci kontroli narracji. Niezależnie od powodu, dla klienta to jest ryzyko. Bo jeśli nie widzisz danych, nie widzisz trendu, a jeśli nie widzisz trendu, to dowiesz się o problemie dopiero wtedy, gdy już zaboli.

Dziesiąty sygnał: wszystko da się zrobić, ale nic nie da się oszacować

To jest sygnał, który na pierwszy rzut oka nie dotyczy jakości, ale dotyczy jej bardzo mocno. Dostawca bez kontroli jakości często nie potrafi stabilnie estymować, bo nie ma kontroli nad długiem technicznym, stabilnością testów i liczbą regresji. Wtedy wszystko jest możliwe, ale terminy pływają, bo jakość generuje nieprzewidywalną pracę w tle.

Dostawca z kontrolą jakości potrafi pokazać, skąd biorą się estymaty, jakie jest ryzyko i co może je zmienić. To jest oznaka dojrzałości procesu.

Co zrobić, jeśli widzisz te sygnały

Najgorsze, co można zrobić, to przeczekać. Jeśli dostawca nie ma kontroli nad jakością, problem nie rozwiąże się sam. Możesz natomiast szybko postawić warunki, które to wymuszą.

Poproś o trzy rzeczy. Po pierwsze, jeden executive dashboard jakości: defect leakage, trend, MTTR, flakiness, czas pipeline, pokrycie krytycznych ścieżek. Po drugie, jasne Definition of Done i kryteria akceptacji. Po trzecie, plan skrócenia feedback loop, czyli w praktyce zmiany w pipeline i w strukturze testów. Jeśli dostawca nie jest w stanie tego zrobić, to nie dlatego, że nie chce. Najczęściej dlatego, że nie umie. A wtedy decyzja biznesowa jest prosta.

Podusumowanie

Brak kontroli nad jakością u dostawcy nie objawia się jednym wielkim błędem. Objawia się stałym wzorcem. Długie regresje, brak metryk, powracające defekty, niestabilne testy, stresujące wdrożenia, brak transparentności. Jeśli widzisz kilka z tych sygnałów naraz, to nie jest pech. To jest system.

Jeśli chcesz sprawdzić, czy Twój dostawca naprawdę ma kontrolę nad jakością, w Quality Island robimy niezależny audyt jakości dostawcy z perspektywy klienta. Sprawdzamy metryki, proces, definicje done, stabilność pipeline i realne ryzyko dla biznesu, a potem dajemy Ci jasną listę warunków, które trzeba postawić, żeby jakość zaczęła być przewidywalna. Jeśli dostawca jest dobry, pomożemy go wzmocnić. Jeśli nie jest, pomożemy Ci to zobaczyć zanim rachunek przyjdzie na produkcji.