Priorytetyzacja rosnącej liczby próśb o funkcje

Śledzenie próśb o funkcje rozwiązuje, gdzie żyją. Nie rozwiązuje, która idzie pierwsza, a to drugie pytanie jest tym, na którym zespoły naprawdę się zacinają. Backlog trzystu pogrupowanych, oznaczonych próśb wciąż potrzebuje reguły decyzyjnej, bo “zbuduj to, o co proszono najwięcej” działa tylko dopóki dwie prośby są blisko siebie, a trzecia ma głośną orędowniczkę, co zdarza się w większości tygodni. Poniższe ramy nie są konkurującymi odpowiedziami na to samo pytanie. Każda pasuje do innego typu prośby, a używanie jednej dla wszystkich to zwykle prawdziwy błąd.

Co odróżnia priorytetyzację próśb o funkcje od priorytetyzacji roadmapy?

Decyzja o roadmapie zaczyna się od strategii i pyta, co budować. Decyzja o prośbie o funkcję zaczyna się od popytu, który już istnieje, i pyta, czy na niego reagować, a te dwa ciągną w różne strony na tyle często, że prośba może mieć duży popyt i wciąż być błędem do zbudowania, albo mieć mały popyt i wciąż być warta zachodu, bo odblokowuje strategiczne konto. Traktowanie każdej prośby jak głosu w roadmapie pomija tę kontrolę.

Czym jest RICE, i czy działa przy prośbach o funkcje?

RICE ocenia pomysł według zasięgu, wpływu, pewności i wysiłku, a potem dzieli pierwsze trzy przez czwarte, by uzyskać porównywalną liczbę. Zbudowano go dla pomysłów roadmapy, w które zespół już wierzy, gdzie trudna część to porównywanie różnych zakładów ze sobą. Prośby o funkcje przychodzą już z liczbą zasięgu, liczbą osób, które prosiły, co jest bardziej konkretne niż zasięg, jaki zwykle ma świeży pomysł roadmapy. Tam, gdzie RICE napina się przy prośbie, to pewność i wpływ: zespół może być pewny, że prośba jest prawdziwa, i wciąż nie mieć podstaw, jak bardzo poruszy metrykę, bo “wpływ” dla prośby, która ma już nazwę i ślad prawdziwych użytkowników, to inny rodzaj szacunku niż wpływ pomysłu, którego nikt spoza pokoju jeszcze nie widział.

Używaj RICE dla próśb poważnie rozważanych i jeszcze nie rozstrzygniętych. Nie stosuj go do każdej przychodzącej prośby; wysiłek oceniania opłaca się tylko przy tych na tyle bliskich, że potrzebują rozstrzygnięcia remisu.

Ważyć według przychodu, czy według tego, kto prosił?

Według tego, kto prosił, ale nie tylko według przychodu. Konto bliskie odnowieniu, konto, które już eskalowało, i konto, którego prośba odblokowuje trwającą transakcję, niosą pilność, której sama płaska liczba przychodu nie łapie, a prośba z rejestracji próbnej wciąż może się liczyć, jeśli blokuje decyzję, która niedługo stanie się przychodem. Ważenie przychodem jest z tego wszystkiego najłatwiejsze do obliczenia, i właśnie dlatego najłatwiejsze do nadmiernego zaufania: poprawnie usuwa szum z kont bez prawdziwej stawki, i tak samo łatwo może zdegradować prośbę, która przyniosłaby dużo większe konto wciąż będące w lejku.

Jaką rolę naprawdę odgrywają głosy?

Tani, ciągły sygnał dla próśb, które już istnieją, i słaby sposób na odkrycie, jakie prośby powinny w ogóle istnieć. Liczba głosów dociera tylko do użytkowników, którzy już znaleźli prośbę i uznali ją za wartą kliknięcia, co oznacza, że suma głosów publicznej roadmapy odzwierciedla widoczność w takim samym stopniu co popyt: stara prośba blisko szczytu listy dalej zbiera głosy częściowo dlatego, że łatwo ją znaleźć, a nowsza, równie prawdziwa prośba zaczyna od zera. Artykuł o publicznej roadmapie przekonuje, żeby w ogóle nie pokazywać głosów na roadmapie. Traktuj głosy jako sygnał, który trzeba pogrupować i ważyć według świeżości, nie jako ranking budowany po kolei. Zgłoszenia do supportu vs. prośby o funkcje opisuje inny martwy punkt w liczbie głosów: prawdziwa luka może wygenerować prawie żadnych głosów, jeśli użytkowniczki, które na nią trafiają, nigdy nie znajdą tablicy, a jednocześnie głośno pojawia się w supporcie.

Kiedy wygrywa najgłośniejszy klient, i czy to problem?

Czasami, i jest to problem tylko wtedy, gdy nikt tego nie zauważa. Klient, który często eskaluje, pisze szczegółowe zgłoszenia albo ma bezpośrednią linię do kogoś w zespole, zobaczy swoje prośby rozpatrzone szybciej niż cichszy klient z równie ważną prośbą, a proces priorytetyzacji, który nigdy tego nie sprawdza, będzie systematycznie faworyzował tego, kto najbardziej naciska, nie tego, kto ma najmocniejszy przypadek. Głośni klienci nie są problemem do naprawienia; ich prośby są często naprawdę ważne. Naprawa to nawyk: okresowo przeglądaj backlog według źródła i sprawdzaj, czy ta sama garstka kont tłumaczy większość niedawno wydanego, i zapytaj, czy to zgadza się z tym, gdzie naprawdę jest popyt.

Jak decyzja o priorytetyzacji zmienia się w odpowiedź?

Każda decyzja tutaj wytwarza zwycięzców i przegranych, i obaj zasługują na odpowiedź, która nazywa prawdziwe rozumowanie, nie tylko zmianę statusu bez wyjaśnienia. Jak odrzucić prośbę o funkcję opisuje, co powiedzieć prośbie, która przegrała, w sposób utrzymujący relację nienaruszoną zamiast brzmieć jak generyczna odmowa. Praca grupowania i etykietowania, która to wszystko umożliwia, jest opisana w śledzeniu próśb o funkcje; priorytetyzacja działa tylko na prośbach już zarejestrowanych i wystarczająco dobrze pogrupowanych, żeby je porównać.

FAQ

Jaka jest najlepsza rama do priorytetyzacji próśb o funkcje? Żadna sama w sobie. Użyj surowych liczb, żeby znaleźć najgłośniejszy sygnał, RICE, żeby porównać krótką listę poważnych kandydatów, i sprawdzenia przychodu lub konta, żeby złapać przypadki, gdy cichy popyt ze strategicznego konta waży więcej niż głośniejsza, ale mniej ważna grupa.

Czy prośby o funkcje powinny być priorytetyzowane tak samo jak pomysły roadmapy? Nie. Pomysły roadmapy zaczynają się od strategii; prośby o funkcje zaczynają się od popytu, który już istnieje. Ocenianie ich razem sprawia, że dobrze uzasadniony strategiczny zakład z małym istniejącym popytem konsekwentnie przegrywa z prośbą, o którą po prostu prosiło więcej osób.

Czy głosy na publicznej roadmapie dokładnie odzwierciedlają popyt? Tylko wśród osób, które już znalazły prośbę. Starsze, bardziej widoczne prośby zbierają głosy szybciej, niezależnie od tego, ile prawdziwego popytu stoi za nowszą, więc traktuj sumy głosów jako sygnał, pogrupowany i ważony według świeżości, nie jako ranking budowany po kolei.

Jak często priorytety próśb o funkcje powinny być ponownie oceniane? Według stałego cyklu, nie tylko gdy ktoś eskaluje. Comiesięczne albo cokwartalne przejście, które grupuje prośby na nowo i sprawdza ważenie, wychwytuje dryf, jak garstka kont dominująca to, co się wydaje, czego czysto reaktywny proces nigdy sam nie ujawnia.

Twierdzenia techniczne w tym artykule nie zostały niezależnie zweryfikowane. Jeśli coś się nie zgadza, daj nam znać, a poprawimy to.

Powiązane w changeloop: Dokumentacja dla deweloperów, Porównanie narzędzi do changeloga