Jak śledzić prośby o funkcje, nie gubiąc ich

Śledzenie próśb o funkcje zawodzi niemal zawsze na jeden z dwóch sposobów. Albo prośby nie mają gdzie trafić, więc żyją w skrzynkach odbiorczych i wątkach Slacka, gdzie są zapominane pojedynczo, albo mają miejsce, do którego nikt już nie zagląda, więc są zapominane zbiorowo. Działający system musi przetrwać obie awarie: potrzebuje jednego miejsca, do którego trafia każda prośba, i powodu, żeby otworzyć to miejsce ponownie w przyszłym miesiącu.

Skąd naprawdę biorą się prośby o funkcje?

Z większej liczby kanałów, niż zakłada większość systemów śledzenia. Ticket wsparcia z “byłoby fajnie, gdyby”. Komentarz na publicznej roadmapie. Rozmowa sprzedażowa, w której potencjalna klientka nazywa tę jedną rzecz blokującą transakcję. Widget w produkcie. Każdy kanał ma własną właścicielkę i własne narzędzia, i właśnie dlatego prośby się rozpraszają: kolejka ticketów wsparcia i backlog zespołu produktowego rzadko są tym samym systemem, a prośba, która dociera tylko do jednego z nich, w praktyce dociera tylko do jednego działu.

Jeden formularz zgłoszeniowy dla każdego kanału nie działa, bo nikt go nie przyjmuje. Działa jeden cel, do którego spływa każdy kanał, nawet jeśli routing to najpierw pięć minut kopiowania i wklejania dziennie, dopóki nie zostanie zautomatyzowany.

Co naprawdę psuje śledzenie próśb o funkcje?

Niemal zawsze dwie rzeczy. Pierwsza to brakujący cel: prośby dostają odpowiedź w kanale, w którym przyszły, i nigdzie nie są trwale zapisywane, więc ta sama prośba od trzech różnych klientek wygląda jak trzy niepowiązane, jednorazowe odpowiedzi zamiast jednego sygnału. Druga, częstsza, to cel, który się zapełnia i przestaje być czytany. Arkusz kalkulacyjny z 400 wierszami bez filtrowania to już nie system śledzenia; to archiwum, które przypadkiem da się edytować.

Druga awaria jest groźniejsza, bo wygląda, jakby śledzenie działało. Prośby są rejestrowane. Nic nie wygląda na zepsute, dopóki ktoś nie zapyta “ile osób poprosiło o X”, a szczera odpowiedź brzmi “musielibyśmy przeczytać wszystkie 400 wierszy, żeby to wiedzieć”.

Co powinna naprawdę rejestrować prośba o funkcję?

Wystarczająco dużo, żeby później odpowiedzieć na trzy pytania bez ponownego czytania oryginalnej wiadomości: o co poproszono, jeśli to możliwe własnymi słowami osoby proszącej; kto poprosił, i jak się z nią skontaktować, jeśli odpowiedź brzmi ostatecznie “zbudowaliśmy to”; i co byłoby potrzebne, żeby wiedzieć, czy to powszechna prośba, czy jednorazowy przypadek. Dosłowny cytat liczy się bardziej niż parafraza, bo parafraza napisana przez tę, która triażowała prośbę, niesie już swoją własną interpretację, i to właśnie tej interpretacji druga osoba nie może zweryfikować sześć miesięcy później.

Które etykiety się opłacają?

Dwie, i odpowiadają na różne pytania. Etykieta typu oddziela prośbę o funkcję od zgłoszenia błędu, bo obie potrzebują różnych właścicielek i harmonogramów, a mieszanie ich w jednej kolejce pozwala najgłośniejszym skargom wyprzedzać prośby. Etykieta priorytetu, ograniczona do małego zbioru jak low, medium i high, oddziela “blokuje komuś korzystanie z produktu” od “byłoby miło”, bo obie zasługują na bardzo różne czasy reakcji i żadna nie powinna dziedziczyć tempa drugiej. Poprawne ustawienie etykiety typu zakłada, że prośba jest tym, za co się podaje; kiedy prośba o funkcję jest naprawdę zgłoszeniem błędu opisuje przypadek, w którym własne słowa klientki kierują tę etykietę w złą stronę.

Automatyczny triaż może zastosować obie w momencie, gdy prośba przychodzi. W changeloop zgłoszenie z widgetu dostaje etykietę feature-request lub bug i etykietę priority:low|medium|high w tym samym kroku, plus tag from-widget, żeby źródło było widoczne bez otwierania elementu. To wystarcza, żeby przefiltrować backlog w minutę zamiast popołudnia: pokaż mi każdą wysokopriorytetową prośbę o funkcję z widgetu z tego miesiąca.

Trzecia etykieta opłaca się, gdy tylko istnieje publiczna roadmapa: status, który osoba proszącą może sama sprawdzić. Publiczna roadmapa opisuje statusy planned, building i shipped w całości; krótko mówiąc, ta etykieta zamienia prywatną kolejkę w coś, co osoba proszącą może sprawdzić bez ponownego pytania.

Jak decyduje się, co zbudować dalej?

Najpierw grupuj, potem licz. Dziesięć różnie sformułowanych próśb o tę samą podstawową zdolność czyta się jak dziesięć rozproszonych wierszy w arkuszu, a jako silny sygnał, gdy są pogrupowane, i to grupowanie jest zwykle brakującym krokiem, nie liczeniem. Surowa liczba bez grupowania ma tendencję do nagradzania funkcji z najbardziej chwytliwą nazwą, nie tej z największym rzeczywistym popytem za nią.

Waż według tego, kto pyta, nie tylko ilu pyta. Prośba z konta bliskiego odnowieniu niesie inną pilność niż ta sama prośba z rejestracji próbnej, a system śledzenia, który odrzuca ten kontekst na rzecz nagiej liczby, optymalizuje pod liczbę najłatwiejszą do obliczenia, nie najbardziej przydatną.

Każda decyzja tutaj tworzy też prośby, które przegrywają, i one też zasługują na odpowiedź; jak odrzucić prośbę o funkcję opisuje, co powiedzieć tym, których prośba nie przeszła. Grupowanie i ważenie to tylko połowa “co budować dalej”; priorytetyzacja próśb o funkcje opisuje prawdziwe ramy, RICE, ważenie przychodem i surowe liczby, oraz gdzie każda z nich zawodzi.

Jak zamknąć pętlę, gdy coś zostanie wydane?

To krok, który systemy śledzenia najczęściej pomijają, i ten, który osoby proszące naprawdę zauważają. Zamykanie pętli feedbacku z klientem opisuje mechanikę w całości; to, co pasuje tutaj, to że zamykanie pętli działa tylko wtedy, gdy oryginalna prośba pozostała powiązana z osobą, która ją złożyła. Szablon prośby o funkcję zbudowany z issue na GitHubie, z tożsamością osoby proszącej przypiętą do issue zamiast pogrzebaną w komentarzu, jest tym, co umożliwia automatyczne powiadomienie “wydane” zamiast takiego, o które ktoś musi pamiętać. Szablon prośby o funkcję pokazuje konkretny szablon i do czego służy każde pole.

FAQ

Jakiego narzędzia użyć do śledzenia próśb o funkcje? To, co zespół już codziennie sprawdza, bije każde dedykowane narzędzie, którego nikt nie otwiera. Tracker issues na GitHubie działa dobrze, jeśli inżynieria już tam żyje; lekka tablica działa dobrze, jeśli produkt tam żyje. Narzędzie liczy się mniej niż to, czy jest ponownie otwierane.

Jak zapobiec duplikowaniu się próśb o funkcje? Grupuj według podstawowej zdolności, zanim triażujesz według sformułowania. Wyszukiwanie wśród istniejących próśb przed utworzeniem nowej wyłapuje większość duplikatów; miesięczna sesja grupowania wyłapuje resztę. Scalanie duplikatów bez utraty oryginalnego głosu ujmuje, co zrobić ze sformułowaniem, gdy samo grupowanie jest już gotowe, żeby scalenie po cichu nie zawężało prośby do tego, o co przypadkiem poprosiło zgłoszenie, które przyszło pierwsze.

Czy każda prośba o funkcję powinna dostać odpowiedź? Każda powinna dostać potwierdzenie, nawet krótkie, ale nie każda potrzebuje decyzji od razu. Widoczny status, jak etykieta roadmapy, którą osoba proszącą może sama sprawdzić, zastępuje większość indywidualnych odpowiedzi, które zespół musiałby inaczej dawać.

Czym różni się śledzenie próśb od publicznej roadmapy? Śledzenie to wewnętrzny zapis każdej prośby, w tym tych, które nigdy nie zostaną wydane. Publiczna roadmapa to podzbiór, do którego zespół publicznie się zobowiązuje, ze statusem, który osoba proszącą może zobaczyć bez ponownego pytania.

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