SaaS
Izdate na dva tedna in o tem pišete dvakrat na leto
Programskim ekipam ne primanjkuje tem. Manjka jim oseba, ki jih pove, ker je pisanje vedno tisto opravilo, ki ga ob zamujenem izidu prestavijo — in prestavijo ga vsakič, dokler zadnja objava na blogu ni stara enajst mesecev in se ne glasi »predstavljamo«.
Napaka je strukturna, ne uredniška
Vsaka ekipa ve, da bi morala pisati več. Inženirji znajo pisati; ustanovitelj zna pisati; nekdo to običajno celo uživa. Težava je, da pisanje nima lastnega roka, vse brez roka pa vedno izgubi proti vsemu z rokom — vsaka dva tedna, za vedno.
Načrt zagotovi manjkajoči rok. Datiran termin s temo in piscem je obljuba, dana v mirnem tednu, izpolnjena v tednu, ki mirnega ni, in osnutek nastane, ne glede na to, ali si je kdo sploh zapomnil zanj. Odobritev traja minute; pisanje od nič traja popoldne, ki se nikoli ne zgodi.
To je celoten argument. Ni tako, da bi model pisal bolje kot vaša ekipa — ne piše. Gre za to, da osnutek, ki ga v torek uredite, obstaja, objava, ki ste jo nameravali napisati, pa ne.
Načrt izdelkov je načrt, ki ste ga že napisali
Večina teh šestih mesecev je že odločena. Veste približno, kaj bo izdano v naslednjih dveh četrtletjih, kateri deli izdelka so napačno razumljeni, katere integracije nenehno zahtevajo in katera vprašanja prihajajo v podporo vsak teden.
Vsak od teh je tema. Načrt (roadmap) določa ritem — izdaja postane niz terminov namesto enega samega zapisa v dnevniku sprememb — podpora pa prispeva večno zeleni del, ker vprašanje, zastavljeno dvajsetkrat na mesec, vredno besedila, ki ga napišete enkrat in večno povezujete.
Pustite vrzeli. Izdaje se zamikajo, načrt brez praznih terminov pa zamujeno izdajo spremeni v tri prispevke o nečem, kar še ne obstaja. Četrtina odprtih terminov ni pomanjkanje prizadevnosti; to je del načrta, ki preživi stik z vašim dejanskim urnikom.
- 1BlogKaj je izšlo in zakaj obstaja. Najprej težava, nato funkcija.
- 2Facebook / InstagramRazličica v enem stavku, za ljudi, ki si dnevnika sprememb nikoli ne bodo odprli.
- 3BlogKako je nekdo izdelek dejansko uporabil. Konkretno, z vsemi nerodnimi podrobnostmi.
- ·Če se zamikaTermini se premaknejo z izdajo. Nič ne napoveduje stvari, ki ne obstaja.
- 4BlogVprašanje podpore, ki ga ta izdaja končno odgovarja, napisano enkrat.
Načrt določa ritemPodpora določa teme
Vaš dnevnik sprememb ni vsebina. Je potrdilo.
Dva pisca, včasih trije
Tisti, ki razlaga izdelek, in tisti, ki govori o podjetju
To sta res dva različna glasova, njuno združevanje pa daje tisto posebno brezbarvnost, po kateri so znani programski blogi — prispevek, ki ni niti tehnična razlaga niti človeški opis česar koli.
Tehnični pisec
Natančno razlaga, kaj stvar počne, brez pridevkov. Ve, za kaj je vaš izdelek in za kaj ni, in mu je dovoljeno to povedati. To je pisec, katerega prispevke povezujejo iz zahtevkov za podporo.
Glas podjetja
Piše o odločitvah, kompromisih in o tem, kam gradite. Uporaben je na način, ki ga je težko izmeriti, očiten pa je pri zaposlovanju, na prodajnih klicih in v razlogu, da kdorkoli izbere majhnega ponudnika namesto velikega.
Tisti, ki odgovarja
Upravlja komentarje v skladu z vašo politiko. Odgovori, kar lahko, označi, česar ne more, in nikoli ne ugiba o načrtu. Vse, kar spominja na primer podpore, takoj posreduje človeku.
Vrata odobritve tu opravljajo pravo delo
Za pekarno je neodobren prispevek majhna zadrega. Za programsko podjetje je to obremenitev podpore, prodajni ugovor ali obljuba, s katero se ni stral nihče. Osnutek, ki rahlo napačno opisuje omejitev, vam bo stranka citirala nazaj, osnutek, ki namiguje na datum, pa bo razumljen kot obljuba.
Zato je to primer, kjer avtopilot zasluži največ previdnosti. Razumna ureditev je avtopilot za kratke družabne termine, ki ponavljajo že objavljeno, in odobritev za vse, kar izpostavlja trditve o izdelku. Vse o cenah, zmogljivosti ali datumih naj trajno prebere človek, in vredno je zapisati to v pravila pisca, da se osnutki te vrste zadržijo in označijo namesto da gredo v vrsto.
Kaj poročilo pove majhni ekipi
Načrtovano v primerjavi z objavljenim je številka, ki šteje, in za programsko ekipo je v prvem četrtletju običajno neprijetna. Hkrati je edini pošten merilo, ali pisanje spet izgublja proti izdaji.
Sprejem je manj pomemben, kot se zdi. Tehnični prispevek najde svoje občinstvo v mesecih, ne dnevih, in če ga ocenjujete v drugem tednu, boste umaknili prispevke, ki bi uspeli. Ravnovesje tem je zgodaj koristnejše: pokaže, ali pišete le o tem, kar je izšlo — to je standardni način neuspeha in razlog, da toliko programskih blogov beremo kot dnevnik sprememb z odstavki.
Pošten del: če je vaš izdelek resnično tehničen, najgloblji prispevki še vedno potrebujejo inženirja za eno popoldne. To, kar spremeni načrt, je, da se ta popoldneva razporedijo in da se preostalih osemdeset odstotkov pisanja preneha z njimi tekmovati.