Triaż - Jak ograniczyć pracę utrzymaniową

Odzyskaj czas na rozwój produktu, zamiast tonąć w zgłoszeniach maintenance.

Zespoły produktowe mierzą się z wyzwaniem, które wydaje się nierozwiązywalne. Z jednej strony muszą dostarczać nowe funkcje. Z drugiej - utrzymywać to, co już działa. Problem w tym, że ilość pracy rośnie szybciej niż możliwości zespołu.

Jak sobie z tym poradzić? Spróbujmy najpierw zrozumieć źródło problemu.

Przeciążenie pracą utrzymaniową

Poniżej mamy macierz pracy produktowej:

Dolna część to praca nieplanowana - wszystkie ad hoc, wrzutki, “pilne” sprawy:

• Customer Success przychodzi z problemem dużego klienta

• Monitoring wyrzuca alerty o błędach w systemie

• Support eskaluje zgłoszenie od użytkownika

• Sami zauważamy, że coś nie działa jak powinno

• Logi pokazują podejrzane wzorce, które trzeba zbadać

To właśnie ta praca utrzymaniowa zjada większość czasu zespołu. Awarie, bugi, pytania o konfigurację, drobne poprawki. Niektóre zgłoszenia przychodzą z zewnątrz, inne generujemy sami.

Zespół próbuje nadążyć:

• Przerywa pracę nad nową funkcją, żeby naprawić błąd.

• Odkłada refaktoring, bo trzeba odpowiedzieć na pytanie o konfigurację.

• Zmienia priorytety w środku sprintu dla “krytycznego” zgłoszenia.

• Pracuje w trybie reaktywnym - gasi to, co się pali najgłośniej.

Sprint za sprintem mija, a postęp minimalny. Roadmapa produktowa stoi w miejscu, bo zespół tonie w pracy reaktywnej.

Wszystko jest istotne = nic nie jest

Co stoi za tą sytuacją?

Każde zgłoszenie ma taki sam priorytet. Nie ma systemu, który pozwala odróżnić to, co krytyczne, od tego, co może poczekać.

Zespół nie ma ustalonych poziomów istotności:

• Osoba A może uważać, że błąd w raportach jest krytyczny.

• Osoba B twierdzi, że wolny checkout to większy problem.

• Osoba C mówi, że najpierw trzeba naprawić integrację z kurierem.

Nie ma obiektywnych kryteriów, które pozwolą rozstrzygnąć ten spór. Każdy ma swoją własną definicję “pilne”.

To samo dotyczy zgłaszających:

• Dla Customer Success każdy problem klienta jest krytyczny - przecież klient płaci.

• Dla Product Managera najważniejsze są nowe funkcje - konkurencja nie śpi.

• Dla Supportu liczy się liczba ticketów - im szybciej zamkną, tym lepiej.

• Dla CEO liczy się on sam - skoro zgłasza, to jest najważniejsze 🤣.

Każdy patrzy ze swojej perspektywy.

A że zgłoszenie nic nie kosztuje? Klik w “new issue”, opis “pilne dla klienta X” i czekamy. Nie trzeba uzasadniać wpływu na biznes. Nie trzeba porównywać z innymi zadaniami. Nie trzeba nawet sprawdzić, czy problem dotyczy jednego użytkownika czy tysięcy.

W efekcie naprawiamy kosmetyczne błędy, podczas gdy krytyczne problemy czekają w kolejce.

Na szczęście jest tutaj rozwiązanie, a przynosi je sektor medyczny ❤️‍🩹

Lekcja z medycznego triażu

Szpitalny Oddział Ratunkowy radzi sobie z setkami pacjentów dziennie. Każdy twierdzi, że jego przypadek jest pilny. SOR rozwiązał ten problem systemem triażu - pacjenci są kategoryzowani według rzeczywistego zagrożenia życia i zdrowia.

System triażu medycznego dzieli pacjentów na poziomy:

• Czerwony (natychmiastowy) - zagrożenie życia, natychmiastowa pomoc.

• Żółty (pilny) - stan może się pogorszyć, wymaga szybkiej interwencji.

• Zielony (standardowy) - stabilny stan, może poczekać.

• Biały - nie wymaga leczenia szpitalnego, może iść do apteki.

Kryteria są transparentne. Pacjent z zawałem dostaje czerwony. Złamana ręka to żółty lub zielony w zależności od komplikacji. Katar? Biały - idź do apteki.

System działa, bo:

• Kryteria są jasne - każdy wie, dlaczego trafił do danej kategorii.

• Ocena jest obiektywna - parametry życiowe, nie opinie.

• Priorytet wynika z rzeczywistego ryzyka - nie z tego, kto głośniej prosi.

• Zasady są znane wszystkim - transparentność w praktyce.

To ostatnie to kluczowa zasada z Kanbana - Make Policies Explicit. Reguły są ustalone i spójne dla wszystkich. Pacjenci ze skręconą kostką rozumieją, dlaczego osoba z urazem głowy jest przyjmowana przed nimi. System jest “uczciwy”.

Dokładnie tego potrzebują zespoły produktowe. Obiektywnego systemu kategoryzacji zadań według rzeczywistego wpływu na biznes i użytkowników.

Triaż w produkcie

Podobnie jak SOR kategoryzuje pacjentów, zespoły produktowe mogą kategoryzować zgłoszenia. Zamiast reagować na wszystko z taką samą intensywnością, wprowadzamy poziomy istotności oparte na obiektywnych kryteriach.

Kryteria triażu

Patrzymy na kilka wymiarów:

• Wpływ na przychody - czy tracimy pieniądze w tej chwili?

• Liczba dotkniętych użytkowników - wszyscy, segment, czy pojedynczy przypadek?

• Ryzyko eskalacji - czy problem się pogarsza z czasem?

• Wpływ na reputację - czy to psuje wizerunek naszej firmy?

• Zgodność prawna - czy naruszamy przepisy lub umowy?

Kluczowe jest przełożenie tych pytań na konkretne liczby i progi. Każdy zespół musi ustalić własne, mierzalne granice między poziomami. Przykładowe progi:

• Wpływ na przychody: utrata >50% transakcji (critical) vs 5-20% (medium) vs <5% (low)

• Liczba użytkowników: >80% dotkniętych (critical) vs 10-50% (medium) vs <10% (low)

• Wydajność: czas odpowiedzi >10s (critical) vs 2-5s (medium) vs <2s (low)

• Eskalacja: problem narasta co godzinę (critical) vs stabilny (medium) vs izolowany (low)

• Reputacja: publiczne posty w social media (critical) vs tickety (medium) vs wewnętrzne zgłoszenia (low)

Proces oceny

Przychodzi zgłoszenie. Co robimy?

• Sprawdzamy rzeczywisty wpływ na produkt - dane z monitoringu, logi, metryki.

• Wyciągamy checklistę kryteriów i sprawdzamy, które są spełnione.

• Przypisujemy poziom na podstawie najwyższego spełnionego kryterium.

• Dokumentujemy decyzję - dlaczego taki poziom, nie inny.

• Informujemy zgłaszającego o przypisanym priorytecie i przewidywanym czasie reakcji.

Zgłaszający widzi, gdzie wylądowało jego zgłoszenie i dlaczego. Ma jasność co do kolejnych kroków.

Przykład kryteriów dla ecommerce

Pracujesz w firmie B2B ecommerce, która obsługuje setki sklepów internetowych. Twój zespół Checkout & Payments odpowiada za proces finalizacji zakupów. Codziennie wpływają dziesiątki zgłoszeń od różnych klientów.

Twoje poziomy mogą wyglądać następujące:

Każdy poziom ma jasno zdefiniowane kryteria. Zespół wie, że Critical oznacza natychmiastową reakcję. Low może poczekać do kolejnego sprintu. No Maintenance - przekierowujemy do Product Managera.

Wdrożenie procesu w zespole

Mamy kryteria, mamy poziomy. Teraz trzeba to wdrożyć. Nie da się tego zrobić odgórnie - zespół musi być częścią procesu od początku.

Aby proces zakorzenił się w organizacji warto go rozbić na kilka kroków:

1. Warsztaty z zespołem

Rozpoczynamy od wspólnego ustalenia poziomów. Zbieramy zespół na godzinny warsztat:

• Przechodzimy przez przykłady realnych zgłoszeń z ostatnich miesięcy.

• Dyskutujemy, gdzie powinny trafić według nowych kryteriów.

• Tam, gdzie są niezgodności - doprecyzowujemy kryteria.

• Zapisujemy decyzje, tworzymy pierwszą wersję poziomów triażu.

Zespół musi czuć, że to ich system, nie narzucony z góry.

2. Pierwszy dry-run

Bierzemy bieżące zgłoszenia z backlogu. Przechodzimy przez nie używając nowych kryteriów:

• Każde zgłoszenie oceniamy według checklisty.

• Przypisujemy poziom triażu i zapisujemy uzasadnienie.

• Notujemy przypadki, gdzie kryteria nie pasują lub są niejednoznaczne.

• Sprawdzamy czy rozkład poziomów ma sens biznesowy.

To pokaże, czy system działa. Czy 80% zgłoszeń nie wpadło przypadkiem do Critical? Czy może wszystko jest Low? Jeśli tak - trzeba skorygować progi.

3. Retrospektywa po dry-runie

Na najbliższym retro omawiamy:

• Co było najtrudniejsze do oceny?

• Których informacji brakowało w zgłoszeniach?

• Czy kryteria są zrozumiałe i jednoznaczne?

• Gdzie pojawiły się największe rozbieżności w ocenach?

Na podstawie feedbacku dopracowujemy kryteria. Dodajemy brakujące przypadki. Upraszczamy to, co było za skomplikowane.

4. Drugi dry-run z biznesem

Teraz czas na edukację interesariuszy. Organizujemy spotkanie z Customer Success, Product Managerem, Supportem:

• Pokazujemy system triażu i kryteria.

• Przechodzimy przez przykłady ich zgłoszeń - gdzie by trafiły.

• Wyjaśniamy czasy reakcji dla każdego poziomu.

• Zbieramy feedback - czego nie rozumieją, z czym się nie zgadzają.

To kluczowy moment. Interesariusze muszą zrozumieć, że nie wszystko może być Critical. Że są obiektywne kryteria. Że Low nie oznacza “nieważne”, tylko “może poczekać”.

5. Oficjalne uruchomienie

Po dwóch dry-runach i zebranym feedbacku możemy wystartować:

• Ogłaszamy nowy proces wszystkim zainteresowanym.

• Udostępniamy kryteria i poziomy w widocznym miejscu.

• Ustalamy osobę odpowiedzialną za triażowanie na początku.

• Monitorujemy, jak idzie, i korygujemy na bieżąco.

Pamiętajmy - to proces. Będzie ewoluował wraz z naszym produktem i organizacją.

Automatyzacja z GenAI

Dużą część pracy dookoła utrzymania można zautomatyzować, jeśli mamy ją ustrukturyzowaną. Triaż i jasne kryteria pozwalają nam zastosować automatyzację połączoną z GenAI.

Bot może zanalizować każde zgłoszenie zanim trafi do zespołu:

• Wyciągnie kluczowe informacje z treści.

• Zada dodatkowe pytania: “Ilu użytkowników to dotyczy?”.

• Sprawdzi logi i metryki z ostatniej godziny.

• Zasugeruje poziom triażu na podstawie kryteriów.

Człowiek tylko weryfikuje i potwierdza decyzję. Zgłaszający od razu dostaje informację, na jaki poziom trafiło zgłoszenie i dlaczego. Transparentność buduje zaufanie.

To działa w praktyce. Khan Academy używa automatycznego triażu osiągając 92% satysfakcji klientów. Equinix z Moveworks drastycznie zredukował kolejkę IT. Firma e-commerce zanotowała 40% redukcję czasu odpowiedzi. Wystarczy dobrze ustrukturyzowany prompt i integracja z monitoringiem.

Korzyści i moc push backu

Triaż produktowy to narzędzie organizacyjne, które przynosi konkretne, mierzalne korzyści.

Zespół odzyskuje skupienie. Zamiast przeskakiwać między dziesiątkami “pilnych” zgłoszeń, koncentruje się na tym, co naprawdę ważne. Czas na deep work wzrasta. Nowe funkcje powstają szybciej, bo nikt nie przerywa pracy dla kosmetycznych poprawek.

Interesariusze uczą się lepiej zgłaszać problemy. Muszą uzasadnić wpływ biznesowy. Przestają rzucać “to pilne” bez kontekstu. Widzą transparentną kolejkę i rozumieją, dlaczego ich zgłoszenie trafiło na dany poziom. Zgłaszają mniej “na wszelki wypadek”, bo wiedzą, że system i tak to odfiltruje.

Efekt? Roadmapa przestaje być fikcją. Sprint faktycznie kończy się dostarczeniem nowych funkcji. Liczba zgłoszeń maintenance spada, bo interesariusze sami się filtrują. Zespół wreszcie może budować produkt, zamiast biegać jak kot z pęcherzem.