Jak oznámit novou funkci (bez ticha)

Většina oznámení funkcí umírá v kanálu, který nikdo nečte dvakrát: tweet, který proletí kolem, e-mail v den vydání pohřbený pod dalšími dvanácti, které odběratelka ten týden dostala, zpráva na Slacku v kanálu, který polovina týmu ztlumila před měsíci. Funkce vyšla. Skoro nikdo z těch, kdo by ji používal, se to nedozvěděl. Napravit to má míň společného s psaním lepšího oznámení a víc s výběrem správného kanálu pro správnou čtenářku, a s tím, dostat se přímo k lidem, kteří o to výslovně žádali, místo spoléhání na to, že si všimnou obecné zprávy.

Kde by se nová funkce vlastně měla oznamovat?

Na víc než jednom místě, protože “všichni čtou stejný kanál” nikdy neplatí. Záznam changelogu nebo feedu slouží čtenářce, která kontroluje podle vlastního tempa a chce trvalý, datovaný záznam. Upozornění v aplikaci slouží čtenářce, která produkt už používá a funkci by využila ještě dnes, kdyby věděla, že existuje. E-mail slouží čtenářce, která momentálně není v produktu, ale vrátila by se kvůli té správné aktualizaci. Sociální sítě slouží dosahu za hranice existujících uživatelek, téměř bez cílení.

Žádný ze čtyř nestačí sám. Changelog je jediný dokument, který by měl nést každý release bez ohledu na velikost, protože je to záznam, na který všechno ostatní odkazuje zpět; zbylé tři jsou zesílení navrch, vybírané podle toho, jak velká je funkce doopravdy.

Co by mělo oznámení říct jako první?

Výsledek, ne mechanismus. “Přidali jsme vrstvu cache do endpointu reportů” popisuje, co tým postavil. “Reporty se teď načítají za méně než sekundu” popisuje, co se pro čtenářku změnilo, a právě tahle věta získává klik, protože odpovídá na “co z toho mám já” v první větě místo třetí. Mechanismus patří do záznamu changelogu nebo stránky s detaily, ne do nadpisu.

Konkrétnost před přídavnými jmény. “Rychlejší, výkonnější zážitek s reporty” neříká čtenářce nic, podle čeho by mohla jednat; “reporty se teď načítají za méně než sekundu a lze je filtrovat podle statusu” říká přesně, co se změnilo a co vyzkoušet. Druhá verze také působí důvěryhodněji, protože vágní tvrzení zní přesně tak, jak zní marketingový text, když není co konkrétního říct.

Čím se to liší od e-mailu s aktualizací produktu?

Překrývá se, ale není to totéž. E-mail s aktualizací produktu pokrývá e-mailový kanál konkrétně, včetně frekvence, předmětů, a kdy digest poráží jednorázové odeslání. Oznámení nové funkce je základní událost; e-mail je jeden ze čtyř kanálů výše, které by ji mohly nést, vybraný, když je funkce dost velká na to, aby ospravedlnila vyhrazené odeslání místo jízdy v příštím digestu. Malá funkce si zaslouží záznam changelogu a možná upozornění v aplikaci. Významná si zaslouží všechny čtyři kanály, časově sladěné.

Jak se dostat ke konkrétním lidem, kteří o to žádali?

Tohle je oznámení s nejlepším poměrem úsilí a přínosu, a skoro každý tým ho přeskočí. Pokud deset zákaznic žádalo o funkci jménem, těch deset lidí si zaslouží přímou, osobní zprávu v okamžiku vydání, bez ohledu na jakékoli širší oznámení, které jde ven. Uzavření smyčky zpětné vazby se zákazníkem pokrývá mechaniku celou; shrnutí zde je, že tohle funguje jen tehdy, když původní požadavek zůstal propojený s tou, kdo žádala, což je spíš problém sledování než problém oznamování. V changeloop, když se zpětná vazba z widgetu stala GitHub issue a sloučený pull request ho uzavírá (fixes #142), schválení záznamu changelogu zveřejní na tom issue, jednou, komentář “Shipped —

Jak napsat samotný záznam?

Stejná disciplína jako u kteréhokoli jiného záznamu poznámek k vydání: začít tím, co teď čtenářka dokáže, pokračovat potřebným nastavením, přeskočit interní zdůvodnění. Jak psát poznámky k vydání pokrývá plnou metodu; oznámení nové funkce je případ s nejvyšší sázkou, protože je to záznam nejpravděpodobněji zachycený jako screenshot, přeposlaný, a přečtený někým, kdo nikdy neviděl changelog produktu.

Kdy neoznamovat široce?

Když se funkce ještě rozjíždí na podmnožinu účtů, je opravdu beta, nebo má cenu či omezení takové, že devět z deseti čtenářek širokého oznámení by ji ještě nemohly použít. Široké oznámení funkce, kterou devět z deseti čtenářek nemůže použít, se čte jako návnada, a spaluje důvěru v příští oznámení víc, než buduje nadšení v tomhle. Řešením není ticho, ale rozsah: přímo informovat oprávněné účty a širší kanály přidržet, dokud dostupnost oznámení nedožene.

FAQ

Zaslouží si každá nová funkce vlastní oznámení? Každá si zaslouží záznam changelogu. Jen ty dost významné na to, aby změnily, jak někdo produkt používá, nebo výslovně požadované jménem, si zaslouží širší kanály jako e-mail nebo sociální sítě.

Jaký je nejlepší kanál pro malou funkci? Samotný changelog, plus upozornění v aplikaci, pokud je funkce objevitelná v toku, kde uživatelka už je. E-mail a sociální sítě stojí za to u funkcí, které ospravedlňují žádost o pozornost.

Jak oznámit funkci lidem, kteří o ni konkrétně žádali? Držet požadavek propojený s žadatelkou od okamžiku registrace, pak individuálně upozornit při vydání, odděleně od jakéhokoli širšího oznámení. Sdílený štítek statusu, který si žadatelka může zkontrolovat sama, také snižuje, kolik individuálních zpráv je vůbec potřeba.

Potřebuje oznámení funkce screenshot? U všeho vizuálního ano; popsaná, ale neviděná funkce se přeskakuje mnohem častěji než ta, u které čtenářky vidí náhled. U API nebo backendové schopnosti odvede krátký příklad kódu stejnou práci jako screenshot u změny UI.

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: Příklady changelogu, Dokumentace pro vývojáře