W skrócie: Artykuł dowodzi, że zespoły produktowe powinny najpierw poddać backlog kuracji, a dopiero potem go priorytetyzować. Priorytetyzacja jedynie szereguje istniejące zgłoszenia, natomiast kuracja usuwa pomysły, którym brakuje zgodności ze strategią, które leczą objawy, dublują istniejącą funkcjonalność, służą pojedynczym potrzebom lub dodają zbędnej złożoności. Jasna strategia produktowa, kurator z realnymi uprawnieniami, regularne czystki backlogu i przejrzysta lista „nie zbudujemy” pomagają utrzymać koncentrację i obniżyć koszt szumu w backlogu.

  • Kuracja decyduje, które pomysły zasługują na wejście do backlogu; priorytetyzacja szereguje te, które przetrwały.
  • Domyślną odpowiedzią na nowe zgłoszenie powinno być odrzucenie, chyba że problem, dowody i zgodność ze strategią są jasne.
  • Zamiast komitetu warto mieć jednego kuratora z realnymi uprawnieniami i wymagać opisu problemu zamiast proponowanych rozwiązań.
  • Co kwartał należy przeglądać i usuwać słabe pozycje, a także rozważyć publikację przejrzystej listy „nie zbudujemy”.
  • Kuracja powinna nastąpić po eksploracji, ale przed zobowiązaniem, w sekwencji: zgłoszenia, kuracja, priorytetyzacja, zobowiązanie i realizacja.

Ocena priorytetu jedynie porządkuje pracę, którą już wpuszczono do systemu. Kuracja to trudniejszy ruch: decyzja, czego w backlogu w ogóle nie powinno być.


Backlog liczy 400 pozycji. Zespół dostarcza 20 na kwartał. Stosowany jest scoring RICE, Weighted Shortest Job First albo własną macierz priorytetów. A mimo to powstają niewłaściwe rzeczy.
Problemem nie jest framework priorytetyzacji. Problem polega na próbie priorytetyzowania listy, która najpierw powinna przejść kurację. Priorytetyzacja porządkuje zbiór opcji. Kuracja decyduje, które opcje w ogóle zasługują na miejsce w tym zbiorze. Większość zespołów produktowych wykonuje tylko pierwszy krok, a potem dziwi się, że roadmapa przypomina listę zakupów, a nie strategię.

Dlaczego priorytetyzacja bez kuracji produkuje bezwartościowe backlogi

Każda metoda priorytetyzacji – RICE, WSJF, macierz Eisenhowera – bierze listę kandydatów i ich szereguje. Jeśli sama lista nie jest przefiltrowana, wynikiem jest uporządkowana lista złych pomysłów. Pozycja z najwyższym wynikiem wciąż może być funkcją, która rozbija spójność produktu, rozwiązuje problem, którego nikt nie ma, albo dubluje istniejącą funkcjonalność.
Weźmy konkretny przykład. Zespół, z którym współpracowaliśmy, ocenił metodą RICE dwie funkcje. Funkcja A: „przełącznik trybu ciemnego” uzyskała 80 punktów (duży zasięg, umiarkowany wpływ). Funkcja B: „integracja alertów w czasie rzeczywistym” uzyskała 70. Zespół przez dwa tygodnie spierał się o 10 punktów różnicy. Żadna z tych funkcji nie powinna była przetrwać kuracji. Produktem był dashboard dla sterowni działających w środowiskach, w których nigdy nie przygasza się światła. Tryb ciemny dokładał pracy utrzymaniowej i komplikował UX. Integracja alertów dublowała istniejące API. Kuracja wyeliminowałaby obie, zanim w ogóle dostałyby ocenę.
Kuracja to bramka przed rankingiem. Zadaje pytanie: czy ta pozycja w ogóle należy do listy? Czy wpisuje się w job-to-be-done produktu? Czy służy obecnej strategii, czy jest szumem od interesariusza, który w zeszłym tygodniu był na konferencji?
Większość zespołów pomija kurację, bo jest trudniejsza niż scoring. Scoring to formuła. Kuracja wymaga osądu, wyczucia produktu i gotowości do mówienia „nie” ludziom, których akceptacja jest potrzebna.

Stosunek sygnału do szumu w typowym backlogu

Warto spojrzeć na własny backlog. Ile pozycji jest starszych niż sześć miesięcy? Ile dodały osoby, które już nie pracują nad produktem? Ile jest sformułowanych jako rozwiązania, a nie problemy?
Zdrowy backlog ma wysoki stosunek sygnału do szumu. Każda pozycja powinna zasłużyć na swoje miejsce. Domyślnym stanem nowego zgłoszenia powinno być odrzucenie, a nie akceptacja. Potrzebny jest powód, żeby coś dodać, a nie powodu, żeby to pominąć.
Koszt szumu nie jest zerowy. Każda pozycja niskiej jakości pochłania uwagę podczas groomingu, estymacji i sesji planistycznych. Odciąga od pozycji, które mają znaczenie. Tworzy iluzję postępu, gdy zamyka się zgłoszenie, które nigdy nie powinno było zostać otwarte.

Jak kuracja zmienia proces decyzyjny

Kuracja zmienia pytanie zadawane przy każdej pozycji. Zamiast „jak wartościowe to jest?” pytamy „czy to w ogóle powinno istnieć?”. Poprzeczka jest wyżej. Filtr jest grubszy.
W praktyce kuracja oznacza:

  • Odrzucanie pozycji, które leczą objawy, a nie przyczyny. Prośba o „lepszy przycisk eksportu” może maskować prawdziwy problem: użytkownicy nie rozumieją formatu danych.
  • Odrzucanie pozycji, które służą jednemu klientowi kosztem dziesięciu. Funkcje szyte na miarę jednego klienta enterprise, których nie da się uogólnić.
  • Odrzucanie pozycji, które konkurują z podstawowym zadaniem produktu. Aplikacja do notatek dodająca widok kalendarza, bo prosili o to użytkownicy, choć kalendarze to odrębna kategoria produktów.
  • Odrzucanie pozycji, które dokładają złożoności konfiguracyjnej. Prośba, by „dashboard był konfigurowalny”, często kończy się stroną ustawień, z której nikt nie korzysta, podczas gdy widok domyślny pozostaje przeciętny.
    Kuracja nie jest pilnowaniem bramy dla samej zasady. Chroni spójność produktu. Każda dodana funkcja sprawia, że produkt trudniej opanować, działa wolniej i droższe jest jego utrzymanie. Najlepsze produkty mają wyraźne zdanie – robią kilka rzeczy dobrze i odmawiają robienia reszty.

Pułapka „obniżymy temu priorytet później”

Zespoły często przyjmują pozycje do backlogu z zamiarem obniżenia im priorytetu. Wmawiają sobie, że nadadzą im niską ocenę i te nigdy nie trafią na szczyt. To fantazja.
Pozycje w backlogu wywierają presję. Interesariusz widzi swoje zgłoszenie na liście i pyta, kiedy zostanie zrealizowane. Nowy product manager przejmuje backlog i zakłada, że wszystko w nim zostało zweryfikowane. Backlog staje się dokumentem politycznym, a nie strategicznym.
Widzieliśmy zespół, który przyjął od wiceprezesa zgłoszenie typu „quick win”, nadał mu niską ocenę, a potem przez sześć miesięcy odpowiadał na comiesięczne pytania, kiedy zostanie zbudowane. Wiceprezes nigdy nie odpuścił. Zespół stracił więcej czasu na obronę decyzji, niż zajęłoby zbudowanie tej funkcji. Prawdziwym kosztem nie był nakład deweloperski – była nim erozja zaufania i nieustanne przełączanie kontekstu.
Kuracja oznacza powiedzenie „nie”, zanim pozycja trafi na listę. Nie „nie teraz” – lecz „nigdy, chyba że zmieni się coś fundamentalnego”. To wymaga jasnej strategii produktowej, która określa, czego firma nie zbuduje, a nie tylko co zbuduje.

Otwierająca scena koncepcyjna: nie podano treści źródłowej
Otwierająca scena koncepcyjna: nie podano treści źródłowej

Kiedy kuracja zawodzi: przypadki brzegowe

Kuracja nie jest rozwiązaniem uniwersalnym. Zawodzi, gdy:

  • Brakuje strategii produktowej. Bez jasnej definicji zadania produktu nie ma podstaw, by cokolwiek odrzucić. Każde zgłoszenie wydaje się równie zasadne.
  • Kuracja służy unikaniu trudnych rozmów. Powiedzenie „to nie pasuje do naszej strategii” jest uczciwe. Powiedzenie „dodamy to do backlogu” w nadziei, że sprawa zniknie, nie jest kuracją – to tchórzostwo.
  • Selekcja następuje za wcześnie. W fazie discovery potrzebna jest szerokość. Przedwczesna kuracja zabija uczenie się. Kluczem jest kuracja przed zobowiązaniem się do budowy, a nie przed eksploracją.
  • Kuracja zostaje delegowana osobie bez uprawnień. Jeśli kurator nie może odmówić wiceprezesowi albo dużemu klientowi, proces staje się teatrem. Osoba odpowiedzialna za wizję produktu potrzebuje organizacyjnego wsparcia, by egzekwować filtr.
    Kuracja działa, gdy stoi za nią jasna strategia i realne uprawnienia decyzyjne. Bez nich to po prostu kolejny proces, który ludzie będą omijać.

Praktyczny proces kuracji

Kuracja nie musi być skomplikowana. Oto proces, który sprawdza się w zespołach liczących 10-200 osób:

  1. Zdefiniować job-to-be-done produktu w jednym zdaniu. Każda pozycja musi to zadanie realizować albo je umożliwiać. Jeśli nie – należy ją odrzucić. To zdanie staje się kryterium filtra. Warto napisać je na ścianie.
  2. Wymagać opisu problemu, a nie rozwiązania. „Użytkownicy muszą eksportować dane do CSV” to rozwiązanie. „Użytkownicy muszą przenieść swoje dane do Excela, by je analizować” to problem. Rozwiązaniem może być API, a nie przycisk eksportu.
  3. Wyznaczyć kuratora, a nie komitet. Jedna osoba decyduje, czy pozycja trafia do backlogu. Zespół priorytetyzuje z wyselekcjonowanej listy. To chroni przed śmiercią przez konsensus. Kuratorem powinien być product manager lub tech lead – ktoś, kto odpowiada za wizję produktu.
  4. Co kwartał przeglądać backlog i usuwać wszystko, co nie spełnia poprzeczki. W razie potrzeby można archiwizować. Ale należy to usunąć z aktywnej listy. Kwartalna czystka utrzymuje wysoki poziom sygnału.
  5. Opublikować listę „nie zbudujemy”. Jest bardziej użyteczna niż roadmapa. Pokazuje interesariuszom, czego zespół świadomie nie robi i dlaczego. Buduje zaufanie i ogranicza powtarzające się prośby.
Ciemna redakcyjna grafika DataTip do artykułu: Backlog nie potrzebuje więcej priorytetyzacji. Potrzebuje kuracji.

Relacja między kuracją a priorytetyzacją

Kuracja i priorytetyzacja nie są alternatywami. To kolejne etapy jednego procesu:
Zgłoszenia → Kuracja → Priorytetyzacja → Zobowiązanie → Realizacja
Kuracja filtruje strumień zgłoszeń. Priorytetyzacja szereguje te, które przetrwały. Jeśli kuracja jest dobrze prowadzona, priorytetyzacja staje się łatwiejsza, bo szereguje się wyłącznie pozycje, które zasługują na istnienie.
Błędem jest priorytetyzowanie listy, która nie przeszła kuracji. Efektem jest uszeregowana lista 200 pozycji, z których 180 nigdy nie powinno było zostać zaproponowanych. Pierwsze 20 jest odrobinę mniej złe niż reszta, ale wciąż nie są to właściwe rzeczy do zbudowania.
Można o tym myśleć jak o procesie rekrutacji. Nie tworzy się rankingu każdego kandydata, który przejdzie przez drzwi. Najpierw sprawdza się minimalne kwalifikacje – to kuracja. Potem przeprowadza się rozmowy i szereguje krótką listę – to priorytetyzacja. Backlogi produktowe potrzebują tego samego dwuetapowego procesu.

Praktyczne wskazówki wdrażania kuracji

  • Warto zacząć od 30-dniowego moratorium na nowe pozycje w backlogu. Ten czas należy wykorzystać, by wyczyścić istniejący backlog do zera. Następnie można ponownie otworzyć kanał zgłoszeń, już z kuracją.
  • Warto stworzyć prosty formularz zgłoszeniowy, który zmusza zgłaszających do opisania problemu, dowodów i zgodności ze strategią produktową. Jeśli nie potrafią go wypełnić, pozycja nie zostaje zarejestrowana.
  • Należy edukować interesariuszy i wyjaśniać, że wyselekcjonowany backlog oznacza szybsze dostarczanie tego, co ma znaczenie. Większość ludzi akceptuje „nie”, gdy rozumie uzasadnienie.
  • Warto stosować technikę „pięciu dlaczego” przy każdym zgłoszeniu. Przy piątym „dlaczego” często okazuje się, że prawdziwy problem jest inny niż zaproponowany.
  • Świętować usunięcia. Usunięcie pozycji z backlogu warto traktować jako sukces. Oznacza to mniej szumu, mniej utrzymania i więcej koncentracji. Warto uczynić to widocznym: „W tym kwartale wyeliminowaliśmy 50 pozycji – oto dlaczego.”
    Więcej o tym, jak decyzje produktowe wpływają na architekturę systemu i tempo zespołu, znajdą Państwo w naszej analizie kryzysu długu wiedzy. Jeśli z kolei brakuje dyscypliny w mówieniu „nie”, warto zastanowić się, czy strategia produktowa jest wystarczająco jasna, by kierować takimi decyzjami. Rozmyta strategia daje rozmyty backlog, niezależnie od tego, jak dobry jest framework priorytetyzacji.

Najważniejsze wnioski

  • Priorytetyzacja porządkuje opcje. Kuracja decyduje, które opcje istnieją. Większość zespołów robi tylko to pierwsze.
  • Wyselekcjonowany backlog ma mniej pozycji, ale silniejszy sygnał. Każda pozycja niesie mniej szumu i większą wagę strategiczną.
  • Kuracja wymaga jasnej strategii produktowej i gotowości do mówienia „nie”. Bez obu tych elementów to tylko kolejny proces.
  • Domyślnym stanem nowego zgłoszenia powinno być odrzucenie. Niech zgłaszający udowodnią, że pozycja należy do backlogu.
  • Kuracja i priorytetyzacja działają po kolei: najpierw filtrowanie, potem ranking.
  • Koszt szumu nie jest abstrakcyjny – to godziny pracy inżynierów zmarnowane na grooming i obronę złych pozycji.

Najczęściej zadawane pytania

Jak postępować z interesariuszami, którzy nalegają, by ich zgłoszenie trafiło do backlogu?

Warto wyjaśnić, że backlog bez kuracji szkodzi wszystkim, i zaproponować wspólny przegląd zgłoszenia pod kątem strategii produktowej. Jeśli rzeczywiście się w nią wpisuje, należy do backlogu. Jeśli nie, należy otwarcie powiedzieć dlaczego. Większość interesariuszy bardziej ceni jasność niż niejednoznaczność.

Co jeśli selekcjonuję zbyt agresywnie i przeoczę dobry pomysł?

Kuracja jest odwracalna. Pozycję zawsze można dodać później. Koszt dodania złej pozycji do backlogu jest wyższy niż koszt tymczasowego przeoczenia dobrej. Warto prowadzić listę „może” poza aktywnym backlogiem i przeglądać ją co kwartał.

Czy kuracja sprawdzi się w startupie, w którym wszystko wydaje się pilne?

W startupie kuracja jest ważniejsza, a nie mniej ważna. Ograniczone zasoby sprawiają, że każda decyzja o budowie ma znaczenie egzystencjalne. Wyselekcjonowany backlog wymusza skupienie na jednej rzeczy, która liczy się najbardziej. Alternatywą jest rozpraszanie sił i budowanie niczego porządnie.

Kto powinien być kuratorem w małym zespole?

W zespole liczącym 5-15 osób kuratorem jest zazwyczaj product manager lub lider techniczny – ten, kto najgłębiej rozumie wizję produktu i ma uprawnienia, by powiedzieć „nie”. W większych zespołach rola kuratora może być rotacyjna, ale uprawnienia decyzyjne muszą być jasne. Należy unikać komitetów; produkują najniższy wspólny mianownik.

Podsumowanie

Priorytetyzacja to narzędzie. Kuracja to dyscyplina. Zespoły, które budują świetne produkty, nie tylko dobrze szeregują pomysły – mają dyscyplinę, by eliminować złe pomysły, zanim te w ogóle dostaną ocenę. Backlog nie jest magazynem. To filtr strategiczny. I tak należy go traktować.
Jeśli brakuje dyscypliny w mówieniu „nie”, warto zastanowić się, czy strategia produktowa jest wystarczająco jasna, by kierować takimi decyzjami. Rozmyta strategia daje rozmyty backlog, niezależnie od tego, jak dobry jest framework priorytetyzacji.




Następny krok

Przed dodaniem kolejnego modelu scoringowego warto przeanalizować sposób przyjmowania zgłoszeń do backlogu. Porozmawiaj z DataTip.

Kontakt

Republika Słowacka+421911948347

DATATIP, s.r.o.
Alžbetina 30
Košice 040 01
IČO: 36869112
NIP UE: SK2023131594
IBAN: SK80 8330 0000 0022 0024 5482

Republika Czeska+420773926377

DATATIP CZ, s.r.o.
Pelušková 1443
Praha 198 00
IČO: 24853577
NIP UE: CZ24853577
IBAN: CZ81 2010 0000 0023 0033 8790

Privacy Preference Center