SaaS

Du leverer kvar fjortande dag og skriv om det to gonger i året

Programvarelag manglar ikkje ting å seia. Dei manglar personen som seier det, fordi skriving alltid er oppgåva som blir flytta når utgjevinga er forsinka — og den blir flytta kvar gong, til det nyaste innlegget på bloggen er elleve månader gammalt og seier «vi introduserer».

Feilet er strukturelt, ikkje redaksjonelt

Kvart lag veit at dei burde skriva meir. Ingeniørane kan skriva; grunnleggjaren kan skriva; som regel gleder nokon seg til det. Problemet er at skriving ikkje har noka eigen frist, og alt utan frist tapar mot alt med frist, kvar fjortande dag, for alltid.

Ein plan leverer den manglande fristen. Ein datert plass med eit tema og ein forfattar knytt til seg er eit lovnad gjeve i ei roleg veke, gjennomført i ei veke som ikkje er roleg, og utkastet dukkar opp uansett om nokon hugsa det eller ikkje. Å godkjenna det tar minutt; å skriva det frå null tar ein ettermiddag som aldri kjem.

Det er heile argumentet. Det er ikkje at ein modell skriv betre enn laget ditt — det gjer den ikkje. Det er at eit utkast du redigerer på tysdag finst, og eit innlegg du meinte å skriva gjer ikkje det.

Ein veiplan er ein plan du allereie har skrive

Det meste av dei seks månadene er allereie avgjort. Du veit omtrent kva som blir levert dei neste to kvartala, kva delar av produktet som er misforstått, kva integrasjonar du stadig blir spurt om, og kva spørsmål som kjem inn til kundetenesta kvar einskild veke.

Kvar av desse er eit tema. Roadmapet gjev rytmen — ein release blir eit løp av plassar i staden for éi changelog-oppføring — og supporten gjev den eviggrøne halvdelen, fordi eit spørsmål som blir stilt tjue gonger i månaden er eit stykke som er verdt å skriva éi gong og lenka til for alltid.

La att gap. Releases glipper, og ein plan utan tomme plassar gjer at ein glippa release blir tre innlegg om noko som ikkje finst enno. Ein fjerdedel av plassane som står opne er ikkje sløving; det er delen av planen som overlever møtet med den faktiske timeplanen din.

Korleis sesongvariasjon og gap fungerer →

Éin release, tre innleggIllustrasjon

1Bloggday 0Kva som vart levert og kvifor det finst. Problemet først, funksjonen etterpå.
2Facebook / Instagramday 0–2Utgåva på éi setning, for dei som aldri opnar ein changelog.
3Bloggday 12Korleis nokon faktisk brukte det. Konkret, med dei kleinsame delane igjen.
·Om det glipperPlassane flyttar seg med releasen. Ingenting kunngjer noko som ikkje finst.
4BloggevergreenSupport-spørsmålet denne releasen endeleg svarar på, skrive éi gong.

Roadmapet set rytmenSupporten set temaene

Changeloggen din er ikkje innhald. Det er ein kvittering.

To forfattarar, nokre gonger tre

Den som forklarar produktet, og den som snakkar om selskapet

Det er faktisk to ulike røyster, og å blanda dei gjev den særeigne flatheita som programvarebloggar er kjende for — eit innlegg som verken er ei teknisk forklaring eller eit menneskeleg skildring av noko.

Den tekniske forfattaren

Forklarar kva noko gjer, presist, utan adjektiv. Veit kva produktet ditt er for og ikkje er for, og får lov til å seia det. Dette er forfattaren som innlegga blir lenka til frå support-sakene.

Selskapsrøysta

Skriv om avgjerdene, avvegingane og kva de bygger mot. Nyttig på ein måte som er vanskeleg å måla og tydeleg i rekruttering, i salmøter og i grunnen til at nokon vel ein liten leverandør framfor ein stor.

Den som svarar

Handterer kommentarar etter policyen din. Svarar på det den kan, flaggar det den ikkje kan, og spekulerer aldri i eit roadmap. Alt som liknar på ein support-hending går straks til eit menneske.

Godkjenningsporten gjer eit reelt arbeid her

For eit bakeri er eit ugodkjent innlegg eit lite pinleg moment. For eit programvareselskap er det ein supportbyrde, eit salisinne, eller eit løfte ingen har gått med på. Eit utkast som skildrar ei grense litt feil blir sitert tilbake til deg av ein kunde, og eit utkast som hintar om ein dato blir behandla som eit løfte.

Så dette er tilfella der autopilot fortener mest varsamheit. Ei fornuftig ordning er autopilot på dei korte sosiale plassane som gjentakar noko som alt er publisert, og godkjenning på alt som gjer eit påstand om produktet. Alt om prisar, kapasitet eller datoar bør lesast av eit menneske permanent, og det er verdt å skriva det inn i forfattarens reglar slik at utkast av den typen blir haldne att og flagga i staden for lagt i kø.

Kva rapporten fortel eit lite team

Planlagt versus publisert er tallet som tel, og for eit programvareteam er det vanlegvis ubehageleg i første kvartal. Det er også det einaste ærlege målet på om skriving har slutta å tapa mot releasen igjen.

Mottaking tel mindre enn det ser ut som. Eit teknisk stykke finn publikum sitt over månader, ikkje dagar, og å dømma det i vekje to gjer at du pensjonerer stykka som kom til å fungera. Temabalanse er meir nyttig tidleg: den viser om du berre skriv om det som vart levert, som er standardfeilen og grunnen til at så mange programvarebloggar les som ein changelog med avsnitt.

Det ærlege: om produktet ditt faktisk er teknisk, treng dei djupaste stykka framleis ein ingeniør i ein ettermiddag. Det ein plan endrar er at desse ettermiddagane blir lagt inn i kalenderen, og at dei andre åtti prosenta av skrivinga sluttar å konkurrera med dei.