SaaS
Du leverer annenhver uke og skriver om det to ganger i året
Programvareteam mangler ikke ting å si. De mangler personen som sier det, fordi skriving alltid er oppgaven som flyttes når releasen er forsinket — og den flyttes hver gang, til bloggens nyeste innlegg er elleve måneder gammelt og sier «introduserer».
Feilet er strukturelt, ikke redaksjonelt
Alle team vet at de burde skrive mer. Ingeniørene kan skrive; grunnleggeren kan skrive; som regel liker noen det. Problemet er at skriving ikke har noen frist av egen, og alt uten frist taper mot alt med en, annenhver uke, for alltid.
En plan leverer den manglende fristen. En datert plass med et tema og en skribent tilknyttet er et løfte gitt i en rolig uke, innfridd i en uke som ikke er rolig, og utkastet dukker opp uansett om noen husket det eller ikke. Å godkjenne det tar minutter; å skrive det fra bunnen av tar en ettermiddag som aldri kommer.
Det er hele argumentet. Det er ikke at en modell skriver bedre enn teamet ditt — det gjør den ikke. Det er at et utkast du redigerer på tirsdag finnes, og et innlegg du hadde tenkt å skrive, gjør ikke det.
En veikart er en plan du allerede har skrevet
Det meste av de seks månedene er allerede bestemt. Du vet omtrent hva som leveres i de neste to kvartalene, hvilke deler av produktet som blir misforstått, hvilke integrasjoner du stadig blir spurt om, og hvilke spørsmål som kommer inn til support hver eneste uke.
Hvert av disse er et tema. Veikartet leverer rytmen — en release blir en rekke plasser i stedet for én changelog-oppføring — og supporten leverer den eviggrønne halvdelen, fordi et spørsmål stilt tjue ganger i måneden er et innlegg verdt å skrive én gang og lenke til for alltid.
La hull være igjen. Releaser glipper, og en plan uten tomme plasser gjør en forsinket release til tre innlegg om noe som ikke finnes ennå. En fjerdedel av plassene åpne er ikke slurv; det er delen av planen som overlever kontakt med den faktiske timeplanen din.
- 1BloggHva som ble levert og hvorfor det finnes. Problemet først, funksjonen etterpå.
- 2Facebook / InstagramVersjonen med én setning, for folk som aldri åpner en changelog.
- 3BloggHvordan noen faktisk brukte det. Konkret, med de klossete delene igjen.
- ·Hvis det glipperPlassene flytter seg med utgivelsen. Ingenting kunngjør noe som ikke finnes.
- 4BloggStøttespørsmålet denne utgivelsen endelig svarer på, skrevet én gang.
Veikartet setter rytmenKundestøtten setter temaene
Endringsloggen din er ikke innhold. Den er en kvittering.
To skribenter, av og til tre
Den som forklarer produktet, og den som snakker om selskapet
Det er genuint forskjellige stemmer, og å blande dem gir den særegne flatheten programvareblogger er kjent for — et innlegg som verken er en teknisk forklaring eller et menneskelig beretning om noe.
Den tekniske skribenten
Forklarer hva noe gjør, presist, uten adjektiver. Vet hva produktet ditt er til og ikke er til, og får lov til å si det. Dette er skribenten hvis innlegg blir lenket til fra støttesaker.
Selskapsstemmen
Skriver om beslutninger, avveininger og hva dere bygger mot. Nyttig på en måte som er vanskelig å måle og åpenbar i ansettelsesprosesser, i salgsmøter, og i grunnen til at noen velger en liten leverandør fremfor en stor.
Den som svarer
Håndterer kommentarer under retningslinjene dine. Svarer på det den kan, flagger det den ikke kan, og spekulerer aldri i et veikart. Alt som ligner en støttehendelse går umiddelbart til et menneske.
Godkjenningsporten gjør et reelt arbeid her
For et bakeri er et ugodkjent innlegg en liten flauhet. For et programvareselskap er det en støttebelastning, et salgsinnvending eller et løfte ingen har gått med på. Et utkast som beskriver en begrensning litt feil, blir sitert tilbake til deg av en kunde, og et utkast som antyder en dato, blir behandlet som et løfte.
Så dette er tilfellet der autopilot fortjener mest forsiktighet. En fornuftig ordning er autopilot på de korte sosiale plassene som gjentar noe som allerede er publisert, og godkjenning på alt som gjør et påstand om produktet. Alt om priser, kapasitet eller datoer bør leses av et menneske permanent, og det er verdt å skrive det inn i skribentens regler, slik at utkast av den typen holdes tilbake og flagges i stedet for å legges i kø.
Hva rapporten forteller et lite team
Planlagt versus publisert er tallet som betyr noe, og for et programvareteam er det vanligvis ubehagelig i første kvartal. Det er også det eneste ærlige målet på om skriving har sluttet å tape mot utgivelsen igjen.
Mottakelse betyr mindre enn det ser ut som. En teknisk artikkel finner publikummet sitt over måneder, ikke dager, og å dømme den i uke to gjør at du pensjonerer artiklene som kom til å fungere. Temabalanse er mer nyttig tidlig: den viser om du bare skriver om det som er lansert, som er standardfeilen og grunnen til at så mange programvareblogger leses som en endringslogg med avsnitt.
Det ærlige: hvis produktet ditt er genuint teknisk, trenger de dypeste artiklene fortsatt en ingeniør en ettermiddag. Det en plan endrer, er at de ettermiddagene blir planlagt, og at de andre åtti prosentene av skrivingen slutter å konkurrere med dem.