Dlaczego jakość oprogramowania spada pod presją
Problemy z jakością w wytwarzaniu oprogramowania ujawniają się przez swoje konsekwencje. To bug produkcyjny, którego można było wyłapać na testach, klient zaskoczony tym, co dostaje, albo nowy developer, który wdraża się do projektu dwa razy dłużej, bo dokumentacja nie istnieje.
Problem nie leży w niedbałości programistów ani nierealistycznych wymaganiach interesariuszy. Chodzi o to, że obie strony nie mają wspólnego punktu odniesienia — nie wiedzą, co tak naprawdę oznacza jakość, nie mają jasnych kryteriów kompromisów, gdy terminy się zmieniają, ani wglądu w to, czy standardy się sprawdzają pod presją.
Reagują więc z przeciwnych stron barykady. Tech leadzi wprowadzają obowiązkowe code review, testy jednostkowe, testy integracyjne — praktyki, które działają, gdy jest czas, ale wyparowują, gdy zbliża się deadline. Stakeholderzy biznesowi naciskają na większą widoczność — więcej raportów, statusów, etapów akceptacji.To daje poczucie kontroli, ale nie zawsze odpowiada na pytanie, czy jakość faktycznie się utrzymuje.
Efekt? Dostarczanie projektów balansuje między improwizacją a biurokracją. W pierwszym przypadku jakość zależy od okoliczności — kto akurat jest dostępny i ile ma czasu. W drugim są procesy i checklisty, które zespoły wypełniają na papierze, a w praktyce omijają. Tak czy inaczej, jakość pozostaje niespójna.
Potrzeba czegoś zupełnie innego niż te dwie skrajności.
Systemu na tyle rygorystyczngo, by przetrwać presję terminów — by jakość nie znikała, gdy robi się ciężko. Na tyle elastyczny, by się dostosować — niezależnie od tego, czy to trzyosobowy projekt MVP, czy enterprise’owe przedsięwzięcie wielu osób. I na tyle transparentny, by wszyscy — programiści, managerowie, klienci — widzieli, czy rzeczywiście działa.
Czy to w ogóle możliwe?
Dlaczego opracowaliśmy Polarisa
To pytanie zadaliśmy sobie w 2022 roku.
Certyfikacje ISO 27001 i ISO 9001 wymagały od nas szczegółowego, możliwego do audytu opisania naszych procesów. Ten zewnętrzny impuls uruchomił coś naprawdę wartościowego: wewnętrzny przegląd tego, jak faktycznie pracujemy. Rozpisaliśmy więc całą ścieżkę klienta — od pierwszych warsztatów, przez wdrożenie, aż po utrzymanie — i na każdym etapie szukaliśmy potencjalnych ryzyk.
Audyt pokazał, że mamy solidne praktyki, ale różnią się one w zależności od projektu. W jednych testy były wbudowane w proces, w innych trafiały na sam koniec; gdzie indziej pod presją terminów narastał dług techniczny, a onboarding nowych osób ciągnął się zbyt długo.
Jakość zależała więc od historii projektu i okoliczności, a nie od systemowego podejścia. Wraz z rozwojem firmy stało się to problemem, którego nie mogliśmy już ignorować.
Zeszliśmy więc głębiej i przeanalizowaliśmy całe nasze portfolio projektowe, szukając powtarzalnych wzorców. Które projekty dowoziliśmy na czas i w ramach budżetu? Które miały problemy? Co odróżniało te udane od pozostałych?
Z czasem zaczęliśmy dostrzegać wyraźny wzorzec. Udane projekty bazowały na współpracy trzech obszarów: przemyślanych decyzjach produktowych, solidnym dostarczaniu oprogramowania oraz ciągłym QA. Świetny kod nie wystarczy, jeśli kuleje komunikacja z klientem. Jasne wymagania też nie obronią projektu, jeśli testy są słabe i błędy i tak trafiają na produkcję. Potrzebne są wszystkie trzy elementy, a nie jeden czy dwa.
To wtedy podjęliśmy decyzję, by wokół tych trzech obszarach uporządkować nasz standard jakości delivery — każdy z nich traktując jako osobny filar, z jasno określonym zakresem i odpowiedzialnością.
Framework Polaris
Gwiazda Polarna od wieków służyła żeglarzom za stały punkt odniesienia — coś, na czym zawsze mogli polegać. W rzeczywistości Polaris nie jest jednak pojedynczą gwiazdą, lecz układem trzech powiązanych ze sobą tak ściśle, że z daleka wyglądają jak jeden punkt odniesienia.
Tworząc naszego Polarisa, skorzystaliśmy z tej samej struktury i oparliśmy framework na trzech filarach:
- Produkt i proces — zapewnia zespołom jasność co do tego, co budują i dlaczego; odpowiada za niego Delivery Lead
- Technologia i rozwój — dba o rygor inżynierski na każdym etapie, od kodu po wdrożenie; odpowiada za niego Head of Engineering
- Dokumentacja i testy — gwarantuje, że wszystko jest udokumentowane i zweryfikowane; odpowda za niego QA Lead
Właściciele poszczególnych filarów dbają o standardy w swoich obszarach, dzielą się sprawdzonymi wzorcami między projektami i wspierają zespoły, gdy pojawiają się trudności. Regularnie spotykają się z liderami na poziomie projektów, by omawiać wyzwania, proponować usprawnienia i — gdy trzeba — wchodzić w rolę konsultantów.
W ramach tych trzech filarów zebraliśmy 57 praktyk, które konsekwentnie wpływały na rezultaty projektów. Zidentyfikowaliśmy je podczas warsztatów międzyzespołowych i retrospektyw.
Część z nich była oczywista — jak automatyczne testy czy jasne kryteria akceptacji. Inne wyłoniły się dopiero przy analizie wzorców: projekty z regularnymi podsumowaniami komunikacji z klientem rzadziej miały spory o zakres. Tam, gdzie decyzje architektoniczne były dokumentowane, nowi deweloperzy wdrażali się szybciej.
Pięćdziesiąt siedem brzmi jak dużo — i rzeczywiście tak by byłoby, gdyby wszystkie praktyki trzeba było wdrażać wszystko naraz. Ale Polaris działa inaczej.
Framework nie jest listą kontrolną, lecz mapą diagnostyczną, która pokazuje wszystkie obszary, które mogą mieć wpływ na jakość projektu. Zespoły oceniają swój kontekst — poziom złożoności, harmonogram, profil ryzyka — i uruchamiają to, co w danym przypadku ma największe znaczenie. Niewielki projekt startupowy może skupić się na podstawach: bazowym DoR/DoD, testowaniu krytycznych ścieżek i lekkiej dokumentacji. Z kolei rozbudowane, regulowane wdrożenie enterprise’owe wymaga pogłębienia: kompleksowych bramek testowych, formalnej dokumentacji, skanów bezpieczeństwa i rejestrów audytowych.
57 praktyk nie tworzy zamkniętej listy. Gdy w naszym delivery pojawia się coś nowego, staramy się dostosować Polarisa do zmieniającego się kontekstu. Tak było wtedy, gdy projekty oparte na AI stały się codziennością i dołożyliśmy praktyki MLOps.
Wszystkie 57 praktyk opisaliśmy w darmowym ebooku — razem z uzasadnieniem każdej z nich oraz wskazówkami, kiedy świadomie ją pominąć. Pobierz ebooka o Polarisie
Kiedy framework był już dobrze opisany, przyszedł czas na prawdziwy test: czy nasze projekty rzeczywiście według niego pracują? Użyliśmy więc Polarisa jako narzędzia diagnostycznego.
Od frameworka do praktyki
Zaczęliśmy od sprawdzenia wszystkich aktywnych projektów pod kątem standardu Polaris. Każdy projekt i każdy zespół ewaluowaliśmy pod kątem praktyk w trzech filarach.
Dzięki temu powstała mapa cieplna pokazująca, na jakim etapie znajduje się każdy projekt: zielony oznaczał praktyki stosowane konsekwentnie, żółty — wdrożone częściowo, czerwony — luki wymagające uwagi.
Spotkania z zespołami prowadziliśmy w formule diagnostycznej, a nie jako przeglądy wyników. Chodziło o to, by pomóc projektom się poprawić, a nie szukać winnych.
Audyt pokazał dokładnie, jakich praktyk brakuje w poszczególnych projektach. W jednym przypadku były brakowało bramek testowych. W innym — sprinty były dobrze zaplanowane, ale nie istniał zestaw testów regresyjnych. Luki jakościowe nie pojawiały się losowo, lecz skupiały się wokół konkretnych praktyk w ramach konkretnych filarów.
Co ważne, nie oczekiwaliśmy zmiany z dnia na dzień. Na początek zespoły wybierały dwie–trzy brakujące praktyki wskazane w audycie i wdrażały je jako pierwsze. Gdy te wchodziły w nawyk, dokładano kolejne.
Co dwa tygodnie ownerzy trzech filarów spotykali się, by wspólnie sprawdzić postępy. Co działa? Gdzie pojawia się tarcie? Co wymaga korekty?
Z czasem dobre praktyki zaczęły rozszerzać się nie tylko przez formalne trzymanie się standardów, ale też w sposób naturalny — przez wymianę wiedzy między zespołami. eden zespół wzmocnił komunikację z klientem, wysyłając podsumowania sprintów po każdej iteracji, a spory o zakres wyraźnie się zmniejszyły. Gdy inne zespoły to zauważyły, zaczęły stosować to samo podejście.
Co dało nam systemowe podejście do jakości
1. Delivery stało się przewidywalne.
Wskaźniki dowożenia sprintów wzrosły z 60% do 85%. W jednym z systemów e-commerce wydania, które wcześniej opóźniały się o dwa–trzy tygodnie, zaczęły trafiać niemal co do dnia. Zespoły planują dziś dokładniej, bo wiedzą, co naprawdę znaczy „done”, i potrafią realnie ocenić swoją przepustowość.
2. Koszty utrzymania spadły.
W jednym z systemów wewnętrznych wydatki na utrzymanie zmniejszyły się o 20% — to o 20% więcej budżetu na rozwój zamiast gaszenia pożarów. Liczba błędów po wdrożeniach spadła, bo problemy były wychwytywane wcześniej.
3. Jakość po wdrożeniu wzrosła.
Liczba błędów po wdrożeniach wyraźnie spadła, bo problemy były wychwytywane wcześniej. W jednym z projektów włączenie statycznej analizy kodu zmniejszyło liczbę defektów o około 30%. Proste błędy przestały docierać do użytkowników — były łapane automatycznie po drodze.
4. Wydania przyspieszyły.
Jeden z zespołów po audycie Polaris zautomatyzował testy UI. Testy regresji, które wcześniej zajmowały dwa dni, skróciły się do kilku godzin. Zespół przeszedł z wydań miesięcznych na tygodniowe. Wąskim gardłem nie było tempo developmentu — tylko pewność, że nic się nie zepsuje. Testy dały im tę pewność z powrotem.
5. Zespoły skalowały się bez tarcia.
W projektach z solidną dokumentacją onboarding skrócił się z sześciu tygodni do dwóch. Nowi deweloperzy znajdowali odpowiedzi w dokumentach, zamiast przerywać pracę innym. Gdy trzeba było rotować ludzi między projektami albo szybko zwiększyć zespół, dało się to zrobić bez typowego spadku produktywności.
Ale same liczby nie oddają pełni zmiany. Zespoły zaczęły traktować jakość jak rzemiosło, a nie jak wymóg do odhaczenia.
Jeden z deweloperów ujął to wprost:
„Polaris sprawia, że czujemy się jak profesjonaliści — mamy swój sposób pracy i możemy dowozić z klasą.”
Potwierdziły to wewnętrzne badania wśród naszych programistów, w których wzrosły oceny przy stwierdzeniach „wiem, czego się ode mnie oczekuje” oraz „potrafię dowozić wysokiej jakości rezultaty”.
Zespoły szczególnie doceniły, że Polaris nie odbierał im autonomii. Deweloperzy pozostawali odpowiedzialni za jakość, jednocześnie zachowując kontrolę nad tym, jak pracują. To właśnie ten balans — jasne oczekiwania połączone z przestrzenią do adaptacji — sprawił, że Polaris nie został listą do odhaczenia, a stał się czymś, z czego zespoły faktycznie korzystały.
W efekcie spadła także rotacja, a wraz z nią koszty rekrutacji i ponownego wdrażania. Zespoły cenią środowiska, w których mogą wykonywać dobrą pracę, zamiast ciągle gasić pożary pod presją terminów.
Różnicę zauważyli także klienci. Projekty realizowały kamienie milowe zgodnie z planem. Po wdrożeniach pojawiało się mniej niespodzianek. Komunikacja była bardziej klarowna — klienci wiedzieli, na jakim etapie jest projekt, bez konieczności ciągłego dopytywania.
To zaufanie przełożyło się na relacje. Zadowoleni klienci wracali z kolejnymi projektami i poleceniami. Jakość stała się wyróżnikiem biznesowym — nie tylko wewnętrznym standardem.
Poznaj pełny framework Polaris i zacznij z niego korzystać
Problemy, które rozwiązuje Polaris, nie są unikalne tylko dla Inwedo. Każdy zespół tworzący oprogramowanie mierzy się z tym samym napięciem: jak utrzymać jakość, gdy zmieniają się terminy, skład zespołu albo rośnie złożoność projektu.
W artykule pokazaliśmy sposób myślenia stojący za Polarisem. Jeśli chcesz pójść krok dalej i zobaczyć, jak zastosować to podejście w praktyce, przygotowaliśmy darmowego ebooka z kompletnym frameworkiem Polaris.
W środku znajdziesz:
- Wszystkie 57 praktyk w trzech filarach — każda z jasnymi kryteriami, które pomogą ocenić, gdzie dziś są Twoje projekty
- Pełny proces audytu — krok po kroku, jak przeprowadzić przegląd w stylu Polaris razem z zespołem
- Rzeczywiste historie wdrożeń — co zadziałało, co nie i jakie wnioski z tego wyciągnęliśmy
- Definition of Ready i Definition of Done w praktyce — jak z nich korzystamy, z przykładami, które możesz zaadaptować
- Przewodnik po pułapkach — jak uniknąć rozrostu biurokracji, oporu zespołów i efektu „wdrożyliśmy i zapomnieliśmy”
Jeśli jesteś tech leadem lub engineering managerem, znajdziesz tu framework, który da się zastosować od razu. A jeśli reprezentujesz biznes, zyskasz jasność, jak wygląda systemowe podejście do jakości oraz jakie pytania warto zadawać — partnerom technologicznym albo własnym zespołom.
Gwiazda Polarna dla przewidywalnej realizacji projektów IT
Pobierz ebook Polaris
