Kiedy prośba o funkcję jest naprawdę zgłoszeniem błędu

“Czy możecie dodać ustawienie zwiększające limit eksportu?” brzmi jak prośba o funkcję, i większość systemów triażu od razu tak ją etykietuje. Czasem tak jest. Czasem eksport zawodzi przy liczbie niższej niż udokumentowany limit z powodu błędu, a klientka, nie widząc kodu, wymyśliła najbardziej prawdopodobne rozwiązanie, jakie potrafi opisać: dajcie mi większą liczbę, może zadziała. Które etykiety się opłacają opisuje etykietę typu, która dzieli backlog na prośby o funkcje i błędy; to jest przypadek, w którym własne słowa klientki kierują etykietę w złą stronę, a koszt pomyłki to powolny dryf w stronę backlogu pełnego próśb, których nikt naprawdę nie chce, gdy się pod nie zajrzy.

Jak wygląda prośba o funkcję, która w rzeczywistości jest błędem?

Nazywa obejście zamiast problemu. Prawdziwa prośba o funkcję zwykle opisuje wynik, którego produkt w ogóle nie obsługuje: “pozwólcie mi zaplanować to na później”, “dodajcie ciemny motyw”. Błędnie sklasyfikowany błąd opisuje konkretną liczbę, próg lub zachowanie, które brzmi jak brakujące ustawienie, ale w rzeczywistości jest objawem: “zwiększcie timeout”, “dodajcie opcję ponowienia”, “pozwólcie mi eksportować więcej wierszy naraz”. Sygnałem jest to, że proszący proponuje implementację, ustawienie, przełącznik, nadpisanie, zamiast opisać cel, bo już wypróbowała funkcję tak, jak jest udokumentowana, i nie zrobiła tego, co dokumentacja mówi, że powinna zrobić.

Dlaczego to ma większe znaczenie, niż się wydaje?

Bo obie kolejki mają różnych właścicieli, harmonogramy i kryteria sukcesu, a błąd zarejestrowany jako prośba o funkcję jest priorytetyzowany przeciwko prośbom o funkcje, konkurując o uwagę z prawdziwymi lukami produktowymi zamiast być naprawianym w harmonogramie, na jaki zasługuje błąd. Jak śledzić prośby o funkcje opisuje, dlaczego mieszanie błędów i funkcji w jednej kolejce pozwala najgłośniejszym skargom wyprzedzać prawdziwe prośby; prośba o funkcję, która potajemnie jest błędem, wyrządza odwrotną szkodę, pozostaje w backlogu produktu zbierając głosy na “funkcję”, która zniknęłaby, gdy tylko podstawowy błąd zostałby naprawiony, co marnuje sygnał priorytetyzacji dla każdego, kto czyta ten backlog.

Jak odróżnić, gdy własne słowa klientki wskazują w złą stronę?

Zapytajcie, czego się spodziewała, że się stanie, nie co chce, żebyście dodali. “Eksport zatrzymał się na 500 wierszach, a potrzebuję 2000, czy możecie zwiększyć limit” brzmi jak prośba o funkcję zwiększenia limitu, dopóki pytanie uzupełniające, “czy 500 to udokumentowany limit,” nie ujawnia, że udokumentowana liczba wynosiła 5000, a eksport zawodzi wcześniej. To jedno pytanie, czego się spodziewała kontra co się stało, wykonuje większość pracy sortującej, bo prawdziwa prośba o funkcję nie ma udokumentowanego zachowania, którego nie spełnia; nie ma czego się spodziewać, bo możliwość jeszcze nie istnieje.

Czy to agentki supportu, czy inżynierki powinny to decydować?

Agentki supportu robią pierwsze przejście, bo widzą zgłoszenie pierwsze, ale etykieta powinna być łatwa do zmiany i tania do pomylenia, nie jednorazową decyzją, która na zawsze utrwala element w złej kolejce. Lekka druga kontrola, inżynierka przeglądająca co tydzień nowe etykiety “prośba o funkcję” pod kątem czegokolwiek, co pachnie przebranym błędem, wyłapuje te, których agentka supportu bez kontekstu kodu nie mogłaby rozpoznać. Nie musi być formalna; to bardziej pięciominutowe spojrzenie niż proces przeglądu.

Czy zamykanie pętli zmienia się po znalezieniu prawdziwego błędu?

Tak, i poprawia wiadomość, którą możecie wysłać. Zamykanie pętli feedbacku klienta opisuje informowanie proszącej, gdy jej prośba zostaje wydana; przeklasyfikowany błąd dostaje lepszą wersję tej wiadomości, bo “znaleźliśmy i naprawiliśmy błąd stojący za tym” brzmi jak kompetencja, podczas gdy “zbudowaliśmy funkcję, o którą prosiłaś” byłoby prawdziwe tylko przypadkiem, bo prawdziwa prośba o funkcję, naprawdę wyższy limit eksportu, może nigdy nie zostać zbudowana, gdy błąd zniknie, a oryginalny limit 5000 wierszy wystarczy.

Co się stanie, jeśli błędna klasyfikacja nigdy nie zostanie wyłapana?

Backlog wypełnia się prośbami, które wyglądają jak prawdziwy popyt, a nim nie są, a decyzje priorytetyzacyjne podejmowane przeciwko temu backlogowi dziedziczą zniekształcenie. “Funkcja” z czterdziestoma głosami może w rzeczywistości być czterdziestoma osobami natrafiającymi na ten sam błąd, a zbudowanie dosłownej prośby, ustawienia zwiększającego limit, który nigdy naprawdę nie był ograniczeniem, dostarcza złożoność, która niczego nie naprawia, podczas gdy podstawowy błąd nadal generuje nowe “prośby o funkcje” od klientek, które jeszcze nie znalazły tego wątku.

FAQ

Czy warto dodać formalny krok sprawdzania każdej prośby o funkcję pod kątem znanych błędów? Nie formalny krok, raczej nawyk: ktokolwiek triażuje nową prośbę o funkcję powinien zapytać “czy udokumentowane zachowanie już twierdzi, że to robi” przed zastosowaniem etykiety, bo to jedno pytanie wyłapuje większość błędnych klasyfikacji bez dodawania obciążenia procesowego.

A jeśli klientka nadal upiera się, że to prośba o funkcję nawet po znalezieniu błędu? Wyjaśnijcie, co znaleźliście i dlaczego proponowane przez nią ustawienie nie byłoby już potrzebne, gdy błąd zostanie naprawiony. Większość klientek prosi o obejście, bo założyły, że prawdziwa naprawa jest niedostępna, nie dlatego, że chciały konkretnie tego ustawienia.

Czy przeklasyfikowany element traci głosy lub komentarze, które zebrał jako prośba o funkcję? Powinien je zachować, widoczne, bo te głosy są dowodem, który doprowadził do znalezienia błędu w pierwszej kolejności, a ukrywanie tego śladu utrudnia wyłapanie tej samej błędnej klasyfikacji następnym razem, na innym zgłoszeniu.

Czy to może się zdarzyć odwrotnie, zgłoszenie błędu, które w rzeczywistości jest prośbą o funkcję? Rzadziej, ale tak: “to jest zepsute” czasem oznacza “to nie robi tego, co zakładałam, że będzie robić,” co jest brakującą możliwością, nie defektem. To samo pytanie, czego się spodziewała kontra co jest udokumentowane, sortuje też w tym kierunku.

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