Cum anunți o funcționalitate nouă (fără tăcere)

Majoritatea anunțurilor de funcționalități mor într-un canal pe care nimeni nu îl citește de două ori: un tweet care trece derulându-se, un e-mail de ziua lansării îngropat sub celelalte douăsprezece pe care le-a primit o abonată în acea săptămână, un mesaj de Slack într-un canal pe care jumătate din echipă l-a silențiat cu luni în urmă. Funcționalitatea a fost lansată. Aproape nimeni dintre cei care ar fi folosit-o nu a aflat. Rezolvarea asta ține mai puțin de a scrie un anunț mai bun și mai mult de a alege canalul potrivit pentru cititoarea potrivită, și de a ajunge direct la cei care au cerut-o explicit, în loc să te bazezi pe faptul că observă un mesaj general.

Unde ar trebui de fapt anunțată o funcționalitate nouă?

În mai mult de un loc, pentru că “toată lumea citește același canal” nu e niciodată adevărat. O intrare de changelog sau feed deservește cititoarea care verifică în ritmul ei și vrea înregistrarea permanentă, datată. O notificare din aplicație deservește cititoarea care folosește deja produsul și ar folosi funcționalitatea azi dacă ar ști că există. E-mailul deservește cititoarea care nu e momentan în produs dar ar reveni pentru actualizarea potrivită. Rețelele sociale deservesc acoperire dincolo de utilizatoarele existente, aproape fără direcționare.

Niciunul din cele patru nu e suficient singur. Changelog-ul e singurul document care ar trebui să poarte fiecare lansare indiferent de mărime, pentru că e înregistrarea la care se raportează înapoi tot restul; celelalte trei sunt amplificare adăugată deasupra, aleasă după cât de mare e funcționalitatea de fapt.

Ce ar trebui să spună anunțul primul?

Rezultatul, nu mecanismul. “Am adăugat un strat de cache la endpoint-ul de rapoarte” descrie ce a construit echipa. “Rapoartele se încarcă acum în mai puțin de o secundă” descrie ce s-a schimbat pentru cititoare, și asta e propoziția care obține click-ul, pentru că răspunde la “ce câștig eu din asta” în prima frază în loc de a treia. Mecanismul aparține intrării de changelog sau paginii cu detalii, nu titlului.

Concret înaintea adjectivelor. “O experiență de rapoarte mai rapidă, mai puternică” nu spune cititoarei nimic pe care să acționeze; “rapoartele se încarcă acum în mai puțin de o secundă și pot fi filtrate după status” spune exact ce s-a schimbat și ce să încerce. A doua versiune pare și mai credibilă, pentru că o afirmație vagă sună exact cum sună textul de marketing când nu e nimic concret de spus.

Cum diferă de un e-mail de actualizare a produsului?

Se suprapun dar nu sunt identice. E-mail de actualizare a produsului acoperă canalul de e-mail specific, inclusiv cadența, subiectele, și când un digest bate o trimitere unică. Un anunț de funcționalitate nouă e evenimentul de bază; e-mailul e unul din cele patru canale de mai sus care ar putea să-l poarte, ales atunci când funcționalitatea e suficient de mare cât să justifice o trimitere dedicată în loc să meargă în următorul digest. O funcționalitate mică merită o intrare de changelog și poate o notificare din aplicație. Una semnificativă merită toate patru canalele, coordonate în timp.

Cum ajungi la persoanele exacte care au cerut-o?

Acesta e anunțul cu cel mai bun raport dintre efort și impact, și aproape toate echipele îl sar. Dacă zece clienți au cerut o funcționalitate pe nume, acele zece persoane merită o notă directă, personală în momentul lansării, indiferent de orice anunț mai larg care iese. Închiderea buclei de feedback cu clientul acoperă mecanica integral; rezumatul de aici e că funcționează doar dacă cererea originală a rămas legată de cea care a cerut-o, ceea ce e mai degrabă o problemă de urmărire decât o problemă de anunț. La changeloop, când feedback-ul din widget a devenit un issue GitHub și pull request-ul integrat îl închide (fixes #142), aprobarea intrării de changelog publică pe acel issue, o singură dată, comentariul “Shipped —

Cum se scrie intrarea în sine?

Aceeași disciplină ca orice altă intrare de note de lansare: începe cu ce poate face acum cititoarea, continuă cu configurarea necesară, sari peste justificarea internă. Cum scrii note de lansare acoperă metoda completă; un anunț de funcționalitate nouă e cazul cu cea mai mare miză, pentru că e intrarea cel mai probabil să fie capturată în screenshot, redistribuită, și citită de cineva care nu a văzut niciodată changelog-ul produsului.

Când nu ar trebui anunțat pe scară largă?

Când funcționalitatea încă se lansează treptat către un subset de conturi, e cu adevărat o beta, sau e prețuită ori blocată astfel încât nouă din zece cititoare ale unui anunț larg nu ar putea încă s-o folosească. Un anunț larg pentru o funcționalitate pe care nouă din zece cititoare nu o pot folosi se citește ca o momeală, și arde încrederea în următorul anunț mai mult decât construiește entuziasm în acesta. Soluția nu e tăcerea, e scara: informează direct conturile eligibile și păstrează canalele largi până când disponibilitatea ajunge din urmă anunțul.

FAQ

Merită fiecare funcționalitate nouă propriul anunț? Fiecare merită o intrare de changelog. Doar cele suficient de semnificative cât să schimbe cum folosește cineva produsul, sau cele cerute explicit pe nume, merită canalele mai largi precum e-mailul sau rețelele sociale.

Care e cel mai bun canal pentru o funcționalitate mică? Doar changelog-ul, plus o notificare din aplicație dacă funcționalitatea e descoperibilă într-un flux în care se află deja utilizatoarea. E-mailul și rețelele sociale merită pentru funcționalitățile care justifică să ceri atenție.

Cum anunți o funcționalitate persoanelor care au cerut-o specific? Păstrează cererea legată de cea care a făcut-o din momentul înregistrării, apoi notifică individual la lansare, separat de orice anunț mai larg. O etichetă de status partajată pe care cea care a cerut o poate verifica singură reduce și câte mesaje individuale sunt necesare din capul locului.

Are nevoie un anunț de funcționalitate de un screenshot? Pentru orice e vizual, da; o funcționalitate descrisă dar nevăzută e sărită mult mai des decât una pentru care cititoarele pot vedea o previzualizare. Pentru un API sau o capacitate de backend, un exemplu scurt de cod face aceeași treabă ca un screenshot pentru o schimbare de UI.

Afirmațiile tehnice din acest articol nu au fost verificate independent. Dacă ceva nu e corect, spune-ne și vom corecta.

Pe changeloop: Exemple de changelog, Documentație pentru dezvoltatori