FABLS
FABLS megnyitása

SaaS

Kéthetente szállít, és évente kétszer ír róla

A szoftvercsapatoknak nincs hiányuk mondanivalóból. Hiányuk van abból az emberből, aki kimondja, mert az írás mindig az a feladat, amit eltolnak, ha a kiadás késik — és minden alkalommal eltolják, amíg a blog legutóbbi bejegyzése tizenegy hónapos nem lesz, és az „introducing” szót viseli.

A hiba szerkezeti, nem szerkesztési

Minden csapat tudja, hogy többet kellene írnia. A mérnökök tudnak írni; az alapító tud írni; általában valaki szereti is. A gond az, hogy az írásnak nincs saját határideje, és aminek nincs határideje, az mindig alulmarad a határidősekkel szemben — kéthetente, örökre.

A terv adja a hiányzó határidőt. Egy dátumozott hely témával és íróval egy nyugodt héten vállalt kötelezettség, amelyet egy nem nyugodt héten alkalmaznak, és a vázlat megjelenik, akire emlékeznek, akire nem. Jóváhagyni percek; nulláról írni egy soha meg nem érkező délután.

Ez az egész érv. Nem az, hogy egy modell jobban ír a csapatánál — nem ír. Hanem az, hogy a keddi szerkesztésre szánt vázlat létezik, és a megírandó bejegyzés nem.

A roadmap egy terv, amelyet Ön már megírt

A hat hónap nagy része már eldöntve. Ön nagyjából tudja, mi készül el a következő két negyedévben, a termék mely részei félreértettek, mely integrációkat kérik folyamatosan, és mely kérdések érkeznek minden héten az ügyfélszolgálatra.

Mindegyik egy téma. A roadmap adja a ritmust — egy kiadás helyek sorozatává válik egyetlen changelog-bejegyzés helyett —, az ügyfélszolgálat adja az örökzöld felét, mert a hónapban hússzor feltett kérdés egy egyszer megírt és örökre hivatkozott anyag.

Hagyjon réseket. A kiadások csúsznak, és egy üres helyek nélküli terv a csúszó kiadásból három bejegyzést csinál egy még nem létező dologról. A helyek negyedének nyitva hagyása nem lazaság; ez a terv azon része, amely túléli az Ön tényleges naptárával való találkozást.

Hogyan működik a szezonalitás és a rések →

Egy kiadás, három bejegyzésIllusztráció
  • 1BlogMi készült el, és miért létezik. Előbb a probléma, aztán a funkció.
  • 2Facebook / InstagramAz egymondatos változat, azoknak, akik sosem nyitnak ki changelogot.
  • 3BlogHogyan használta valójában valaki. Konkrétan, a kellemetlen részekkel együtt.
  • ·Ha csúszikA idősávok a kiadással együtt mozognak. Semmi sem jelenti be, ami nem létezik.
  • 4BlogA támogatási kérdés, amelyre ez a kiadás végre választ ad, egyszer megírva.

A roadmap diktálja a ritmustAz ügyfélszolgálat diktálja a témákat

A changelogja nem tartalom. Ez egy nyugta.

Két író, néha három

Az egyik a terméket magyarázza, a másik a cégről beszél

Ezek valóban különböző hangok, és összeolvasztásuk azt a különös fakóságot adja, amelyről a szoftveres blogok ismertek — egy bejegyzést, amely sem technikai magyarázat, sem emberi beszámoló nem igazán.

A technikai író

Pontosan magyarázza el, mit tesz valami, melléknevek nélkül. Tudja, mire való az Ön terméke és mire nem, és kimondhatja ezt. Ő az az író, akinek a bejegyzéseire a támogatási jegyekből hivatkoznak.

A cég hangja

Döntésekről, kompromisszumokról és arról ír, ami felé építenek. Olyan módon hasznos, amit nehéz mérni, de nyilvánvaló a toborzásban, az értékesítési hívásokban, és abban, hogy valaki miért választ kisebb szállítót egy nagy helyett.

A válaszolós

Az Ön szabályzata szerint kezeli a hozzászólásokat. Azt válaszolja meg, amit tud, jelzi, amit nem tud, és soha nem spekulál a roadmapról. Bármi, ami támogatási ügyre hasonlít, azonnal emberhez kerül.

Itt a jóváhagyási kapu valódi munkát végez

Egy pékségnek egy nem jóváhagyott bejegyzés csak kis kínos helyzet. Egy szoftvercégnél az támogatási terhelés, értékesítési kifogás, vagy olyan ígéret, amelyet senki nem vállalt. Egy vázlat, amely egy korlátot kissé pontatlanul ír le, visszaidézve érkezik egy ügyféltől, és egy vázlat, amely dátumra utal, ígéretként kezeltetik.

Ez tehát az az eset, amikor az autopilotra a legnagyobb óvatosság jár. Észszerű megoldás az autopilot a rövid közösségi idősávokra, amelyek már publikált dolgot ismételnek, és jóváhagyás mindenre, ami állítást tesz a termékről. Bármi, ami árazásról, kapacitásról vagy dátumokról szól, maradandóan ember által olvasandó, és érdemes ezt beleírni az író szabályaiba, hogy az ilyen vázlatok várakoztatva és jelölve legyenek, ne sorba állítva.

Mit mond a jelentés egy kis csapatnak

A tervezett és a publikált aránya az a szám, ami számít, és egy szoftvercsapatnak az első negyedévben általában kellemetlen. Ugyanakkor ez az egyetlen őszinte mérőszáma annak, hogy az írás abbahagyta-e a vesztést a kiadás ellen.

A fogadtatás kevésbé fontos, mint látszik. Egy technikai írás hónapok alatt találja meg a közönségét, nem napok alatt, és ha a második héten ítélik meg, azokat az írásokat vonja vissza, amelyek működtek volna. A témák egyensúlya korábban hasznosabb: megmutatja, hogy csak a kiadott dolgokról ír-e, ami a szokásos hibamód, és az oka annak, hogy annyi szoftveres blog bekezdésekkel kiegészített changelogként olvasható.

Az őszinte rész: ha az Ön terméke valóban technikai, a legmélyebb írásokhoz még mindig kell egy mérnök egy délutánra. Azt változtatja meg a terv, hogy ezek a délutánok bekerülnek az ütemtervbe, és az írás másik nyolcvan százaléka nem versenyez velük.