Jak odmítnout požadavek, aniž přijdete o klientku

Uzavření smyčky obvykle znamená říct někomu, že jeho požadavek byl vydán. Těžší polovina, pro kterou většina sledovacích systémů nemá žádný proces vůbec, je říct ne. Většina požadavků na funkce nikdy nevyjde, což znamená, že většina uzavírání smyčky, které produkt svým uživatelkám skutečně dluží, je odmítnutí, ne oznámení, a špatně zvládnuté odmítnutí stojí víc dobré vůle, než by stálo mlčení. Dobře zvládnuté může stát skoro nic, protože to, co ta, kdo žádá, chce nejvíc, většinou je vědět, že byla vyslyšena, ne samotná funkce.

Proč záleží na dobrém odmítání stejně jako na dobrém vydávání?

Protože mlčení se čte jako odmítnutí bez vysvětlení, a vysvětlené ne se čte jako pozornost. Ta, kdo neslyší nic, předpokládá, že požadavek byl buď ignorován, nebo se ztratil, a oba závěry ji naučí přestat se obtěžovat ptát, což je stejný výsledek, jaký produkt získá se skutečným odmítnutím, jen dosažený pomaleji a s víc zatrpklostí po cestě. Odpověď, která řekne ne, jasně a s důvodem, uzavírá smyčku stejně úplně jako vydaná funkce, a dělá to rychleji.

Co způsobí, že odmítnutí dopadne špatně?

Téměř vždy tři věci v kombinaci. Obecnost: šablonovité „díky za feedback”, které neodkazuje na to, oč se skutečně žádalo, se čte, jako by nebylo přečtené vůbec, i když bylo. Zpoždění: odmítnutí, které přijde šest měsíců po požadavku, kdy ta, kdo se ptala, už zapomněla, že se ptala, se cítí hůř než rychlé ne, protože naznačuje, že požadavek zůstal netknutý místo toho, aby byl zvážen a odmítnut. A důvod, který neobstojí: „není na naší roadmapě” neodpovídá na nic, zatímco „tohle by vyžadovalo přepracovat, jak fungují oprávnění, což letos neplánujeme řešit” dá tomu, kdo žádal, něco, co může skutečně zhodnotit a, pokud na tom dost záleží, eskalovat nebo obejít.

Co by mělo dobré odmítnutí skutečně říkat?

Čtyři věci, v tomto pořadí: potvrzení, které pojmenuje konkrétní požadavek, ne obecnou parafrázi; skutečný důvod, upřímně vyjádřený, i když je upřímný důvod „tohle nezapadá do toho, kam produkt směřuje” místo měkčí výmluvy; jestli jsou dveře zavřené, nebo jen teď nejsou otevřené, protože to vyžaduje velmi odlišné tóny; a, pokud existuje, alternativu, která řeší základní potřebu, i když to není doslova požadovaná funkce.

Ahoj Jamie,

Díky za požadavek přidat hromadný CSV import pro pozvánky do týmu.
Zvážili jsme to, a nebudeme to stavět: náš tok pozvánek je postavený
na individuální kontrole každého nového člena z bezpečnostních
důvodů, a hromadný import by proti tomu šel záměrně, ne přehlédnutím.

Pokud je skutečným problémem rychle pozvat velký tým, API podporuje
skriptované individuální pozvánky, což vám dá skoro celou rychlost bez
obcházení kontroly: [odkaz]. Dejte vědět, pokud chcete pomoct to
nastavit.

Všimněte si, co tohle udělá, co šablona nemůže: pojmenuje skutečnou funkci, dá důvod spojený se skutečným návrhovým rozhodnutím místo vágní politiky, a nabídne cestu, která řeší základní problém místo pouhého zavření ticketu.

Čím se to liší od uzavírání smyčky u vydané funkce?

Mechanika je podobná, tón ne. Uzavření smyčky zpětné vazby se zákazníkem pokrývá vydaný případ, kde je zpráva dobrá novinka a hlavním rizikem je zapomenout ji poslat. Odmítnutí je špatná novinka, nebo přinejmenším nechtěná novinka, a potřebuje víc péče v daném důvodu a míň automatizace v doručení: oznámení o vydané funkci může být šablonovitý komentář spuštěný změnou stavu, ale odmítnutí, které se čte jako šablonovité, je přesně ten selhávající způsob, kterému se celý tento přístup snaží vyhnout. Obě přesto sdílejí jeden požadavek: původní požadavek musí zůstat propojený s tou, kdo ho podala, stejná disciplína sledování, kterou pokrývá sledování požadavků na funkce, jinak není způsob, jak poslat kteroukoli z těch dvou zpráv individuálně.

Mělo by být odmítnutí veřejné, jako stav na veřejné roadmapě?

Obvykle ne konkrétní důvod, i když stav ano. Veřejná roadmapa pokrývá stavové štítky, které si ta, kdo žádala, může zkontrolovat, aniž by se znovu ptala, a stav „odmítnuto” nebo „neplánováno” může být součástí tohoto systému. Ale podrobný důvod, zvlášť když se dotýká interních priorit nebo nelichotivého kontextu, obvykle víc stojí za to v individuální odpovědi než na veřejné stránce stavu, kde stejná formulace musí fungovat pro každou čtenářku místo pro jedinou osobu, která se skutečně ptala.

Zaslouží si každý odmítnutý požadavek individuální odpověď?

Každý požadavek od jmenované, dosažitelné osoby ano, alespoň krátkou. Požadavky s vysokým objemem, duplikáty nebo anonymní jsou výjimkou: seskupování podobných požadavků a odpovídání jednou za skupinu, nebo aktualizace sdíleného stavového štítku, je rozumné, když individuální odpovědi opravdu neškálují. Hranice, kterou je třeba držet, je, že „nemůžeme odpovědět všem individuálně” by mělo být skutečné provozní omezení, ověřené proti skutečnému objemu, ne výchozí výmluva k přeskočení odpovědi, která by zabrala dvě minuty.

FAQ

Je lepší odmítnout rychle se slabým důvodem, nebo si vzít čas na dobrý? Rychle, s upřímným důvodem, poráží obojí zvlášť. Rychlá odpověď se skutečným důvodem, i krátkým, předčí pomalou odpověď s vyleštěným; samotné zpoždění je součástí toho, co poškozuje důvěru.

Mělo by odmítnutí někdy slíbit, že požadavek přehodnotí později? Jen pokud je to skutečně pravděpodobné a existuje mechanismus, jak ho skutečně přehodnotit, jako štítek, který ho znovu vynese na plánovacím cyklu. Vágní „necháme si to projít hlavou” bez takového mechanismu je funkčně totéž co mlčení, jen formulované laskavěji.

Co když je upřímný důvod něco, co firma nemůže sdílet, třeba konkurenční obava? Řekněte to přímo, místo vymýšlení měkčího důvodu. „Nemůžeme tady sdílet konkrétní zdůvodnění, ale tohle není něco, co plánujeme stavět” je upřímnější, a víc respektované, než vymyšlené vysvětlení, které se zhroutí při doplňující otázce.

Znamená odmítnutí požadavku, že by měl být smazán ze sledování? Ne. Ponechte ho, označený jako odmítnutý s důvodem, aby byl součástí vzorce, proti kterému se seskupí další podobný požadavek, a aby ho pozdější změněný kontext (nová integrace, nová priorita týmu) mohl znovu vynést místo toho, aby hodnocení začínalo od nuly.

Technická tvrzení v tomto článku nikdo nezávisle neověřil. Pokud tu něco nesedí, dej nám vědět a opravíme to.

Související na changeloop: Dokumentace pro vývojáře, Srovnání nástrojů pro changelog