Jak odrzucić prośbę o funkcję, nie tracąc klientki

Zamykanie pętli zwykle oznacza powiedzenie komuś, że jego prośba została wydana. Trudniejsza połowa, dla której większość systemów śledzenia nie ma żadnego procesu, to powiedzieć nie. Większość próśb o funkcje nigdy nie jest wydawana, co oznacza, że większość zamykania pętli, które produkt naprawdę jest winien swoim użytkowniczkom, to odmowa, nie ogłoszenie, a źle obsłużona odmowa kosztuje więcej dobrej woli, niż kosztowałaby cisza. Dobrze obsłużona może kosztować prawie nic, bo to, czego prosząca chce najbardziej, przez większość czasu, to wiedza, że została wysłuchana, nie sama funkcja.

Dlaczego dobre odrzucanie liczy się tyle samo co dobre wydawanie?

Bo cisza czyta się jak odmowa bez wyjaśnienia, a wyjaśnione nie czyta się jak uwaga. Ta, która nic nie słyszy, zakłada, że prośba została zignorowana lub zgubiona, a oba wnioski uczą ją, by przestała fatygować się pytaniem, co jest tym samym rezultatem, jaki produkt uzyskuje przy prawdziwej odmowie, tylko osiągniętym wolniej i z większą urazą po drodze. Odpowiedź, która mówi nie, jasno i z powodem, zamyka pętlę tak samo kompletnie jak wydana funkcja, i robi to szybciej.

Co sprawia, że odmowa źle wypada?

Niemal zawsze trzy rzeczy, w połączeniu. Ogólność: szablonowe „dzięki za feedback”, które nie odnosi się do tego, o co naprawdę poproszono, czyta się jakby wcale nie zostało przeczytane, nawet jeśli było. Opóźnienie: odmowa, która przychodzi sześć miesięcy po prośbie, gdy prosząca już zapomniała, że pytała, czuje się gorzej niż szybkie nie, bo sugeruje, że prośba leżała nietknięta, zamiast być rozważoną i odrzuconą. I powód, który się nie broni: „nie ma tego na naszym roadmapie” nie odpowiada na nic, podczas gdy „to wymagałoby przeprojektowania działania uprawnień, czego nie planujemy ruszać w tym roku” daje proszącej coś, co naprawdę może ocenić i, jeśli wystarczająco jej zależy, eskalować lub obejść.

Co powinna właściwie mówić dobra odmowa?

Cztery rzeczy, w tej kolejności: potwierdzenie, które nazywa konkretną prośbę, nie ogólną parafrazę; prawdziwy powód, podany szczerze, nawet gdy szczerym powodem jest „to nie pasuje do tego, dokąd zmierza produkt”, zamiast łagodniejszej wymówki; czy drzwi są zamknięte, czy po prostu nie są teraz otwarte, bo to wymaga bardzo różnych tonów; i, gdy istnieje, alternatywa adresująca leżącą u podstaw potrzebę, nawet jeśli nie jest to dosłownie żądana funkcja.

Cześć Jamie,

Dzięki za prośbę o dodanie masowego importu CSV dla zaproszeń
zespołu. Sprawdziliśmy to i nie zamierzamy tego budować: nasz
przepływ zaproszeń opiera się na indywidualnym przeglądzie każdego
nowego członka ze względów bezpieczeństwa, a masowy import działałby
przeciwko temu z założenia, nie przez przeoczenie.

Jeśli prawdziwym problemem jest szybkie zaproszenie dużego zespołu,
API obsługuje skryptowe indywidualne zaproszenia, co daje niemal całą
szybkość bez omijania przeglądu: [link]. Chętnie pomogę to
skonfigurować, jeśli chcesz.

Zwróć uwagę, co robi to, czego szablon nie może: nazywa rzeczywistą funkcję, podaje powód związany z prawdziwą decyzją projektową zamiast niejasną polityką, i oferuje ścieżkę, która rozwiązuje leżący u podstaw problem zamiast tylko zamykać ticket.

Czym różni się to od zamykania pętli na wydanej funkcji?

Mechanika jest podobna, ton nie. Zamykanie pętli feedbacku z klientem obejmuje wydany przypadek, gdzie wiadomość to dobra wiadomość, a głównym ryzykiem jest zapomnienie o jej wysłaniu. Odmowa to zła wiadomość, a przynajmniej niechciana wiadomość, i wymaga więcej staranności w podanym powodzie i mniej automatyzacji w dostarczeniu: powiadomienie o wydanej funkcji może być szablonowym komentarzem wyzwolonym zmianą statusu, ale odmowa, która czyta się jak szablonowa, jest dokładnie tym trybem awarii, którego całe to podejście ma unikać. Oba dzielą jednak jeden wymóg: oryginalna prośba musi pozostać powiązana z proszącą, ta sama dyscyplina śledzenia, którą obejmuje śledzenie próśb o funkcje, inaczej nie ma sposobu, by wysłać którąkolwiek z tych wiadomości indywidualnie.

Czy odmowa powinna być publiczna, jak status na publicznej roadmapie?

Zwykle nie konkretny powód, nawet jeśli status tak. Publiczna roadmapa obejmuje etykiety statusu, które prosząca może sprawdzić bez ponownego pytania, a status „odrzucone” lub „nieplanowane” może być częścią tego systemu. Ale szczegółowy powód, zwłaszcza gdy dotyka wewnętrznych priorytetów lub niepochlebnego kontekstu, zwykle jest więcej wart w indywidualnej odpowiedzi niż na publicznej stronie statusu, gdzie to samo sformułowanie musi działać dla każdej czytelniczki zamiast dla tej jednej osoby, która naprawdę pytała.

Czy każda odrzucona prośba zasługuje na indywidualną odpowiedź?

Każda prośba od nazwanej, osiągalnej osoby tak, przynajmniej krótką. Prośby o wysokim wolumenie, duplikaty lub anonimowe są wyjątkiem: grupowanie podobnych próśb i odpowiadanie raz na grupę, lub aktualizowanie wspólnej etykiety statusu, jest rozsądne, gdy indywidualne odpowiedzi naprawdę się nie skalują. Granica do utrzymania jest taka, że „nie możemy odpowiedzieć wszystkim indywidualnie” powinno być prawdziwym ograniczeniem operacyjnym, sprawdzonym względem rzeczywistego wolumenu, nie domyślną wymówką do pominięcia odpowiedzi, która zajęłaby dwie minuty.

FAQ

Czy lepiej odrzucić szybko ze słabym powodem, czy poświęcić czas na dobry? Szybko, z uczciwym powodem, bije oba z osobna. Szybka odpowiedź z prawdziwym powodem, nawet krótkim, przewyższa powolną odpowiedź z wypolerowanym; samo opóźnienie jest częścią tego, co niszczy zaufanie.

Czy odmowa powinna kiedykolwiek obiecywać ponowne rozważenie prośby później? Tylko jeśli to naprawdę prawdopodobne i istnieje mechanizm, by naprawdę ją ponownie rozważyć, jak etykieta, która przywraca ją przy cyklu planowania. Niejasne „będziemy o tym pamiętać” bez takiego mechanizmu jest funkcjonalnie tym samym co cisza, tylko sformułowane milej.

A jeśli uczciwy powód jest czymś, czego firma nie może udostępnić, jak obawa konkurencyjna? Powiedz to wprost, zamiast wymyślać łagodniejszy powód. „Nie możemy udostępnić tu konkretnego uzasadnienia, ale to nie jest coś, co planujemy budować” jest bardziej szczere, i bardziej szanowane, niż zmyślone wyjaśnienie, które załamuje się przy dopytaniu.

Czy odrzucenie prośby oznacza, że powinna zostać usunięta ze śledzenia? Nie. Zachowaj ją, oznaczoną jako odrzuconą z powodem, żeby była częścią wzorca, do którego grupowana jest następna podobna prośba, i żeby zmieniony później kontekst (nowa integracja, nowy priorytet zespołu) mógł ją przywrócić zamiast zaczynać ocenę od zera.

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