SaaS
Je levert elke twee weken en schrijft er twee keer per jaar over
Softwareteams hebben geen gebrek aan dingen om te vertellen. Ze missen de persoon die het vertelt, want schrijven is altijd de taak die wordt doorgeschoven als de release vertraging heeft — en dat gebeurt elke keer opnieuw, tot de meest recente blogpost elf maanden oud is en "we introduceren" zegt.
Het probleem is structureel, niet redactioneel
Elk team weet dat het meer zou moeten schrijven. De ingenieurs kunnen schrijven; de oprichter kan schrijven; meestal doet iemand het met plezier. Het probleem is dat schrijven geen eigen deadline heeft, en alles zonder deadline verliest van alles mét een deadline, elke twee weken, voor altijd.
Een plan levert de ontbrekende deadline. Een gedateerde plek met een thema en een schrijver is een toezegging gedaan in een rustige week, uitgevoerd in een week die niet rustig is, en de versie verschijnt of iemand eraan gedacht heeft of niet. Goedkeuren kost minuten; schrijven vanuit het niets kost een middag die nooit komt.
Dat is het hele argument. Het is niet dat een model beter schrijft dan jouw team — dat doet het niet. Het is dat een concept dat je dinsdag bewerkt bestaat, en een post die je had willen schrijven niet.
Een roadmap is een plan dat je al hebt geschreven
Het grootste deel van die zes maanden is al beslist. Je weet globaal wat er de komende twee kwartalen verschijnt, welke delen van het product misverstaan worden, welke integraties er steeds om gevraagd worden, en welke vragen elke week opduiken in support.
Elk van die dingen is een thema. De roadmap levert het ritme — een release wordt een reeks plekken in plaats van één changelog-item — en support levert de groenblijvende helft, want een vraag die twintig keer per maand gesteld wordt is een stuk dat je één keer schrijft en voor altijd linkt.
Laat gaten. Releases lopen vertraging op, en een plan zonder lege plekken maakt van een uitgestelde release drie posts over iets dat nog niet bestaat. Een kwart van de plekken openlaten is geen slordigheid; het is het deel van het plan dat contact met je echte planning overleeft.
- 1BlogWat er is verschenen en waarom het bestaat. Eerst het probleem, dan de feature.
- 2Facebook / InstagramDe versie in één zin, voor mensen die nooit een changelog openen.
- 3BlogHoe iemand het echt gebruikt. Concreet, met de ongemakkelijke delen er nog in.
- ·Als het uitlooptDe plekken schuiven mee met de release. Niets kondigt iets aan dat niet bestaat.
- 4BlogDe supportvraag die deze release eindelijk beantwoordt, één keer geschreven.
De roadmap bepaalt het ritmeSupport bepaalt de thema's
Jouw changelog is geen content. Het is een bon.
Twee schrijvers, soms drie
Degene die het product uitlegt, en degene die over het bedrijf praat
Dat zijn echt verschillende stemmen, en ze samenvoegen levert de specifieke flauwte op waar softwareblogs om bekend staan — een post die geen technische uitleg is en ook geen menselijk verhaal over iets.
De technische schrijver
Legt precies uit wat iets doet, zonder bijvoeglijke naamwoorden. Weet waar je product wél en niet voor bedoeld is, en mag dat zeggen. Dit is de schrijver wiens posts vanuit supporttickets worden gelinkt.
De bedrijfsstem
Schrijft over beslissingen, afwegingen en waar je naartoe bouwt. Op een manier nuttig die moeilijk te meten is en duidelijk bij het werven van personeel, bij verkoopgesprekken en in de reden waarom iemand voor een kleine leverancier kiest in plaats van een grote.
Degene die antwoordt
Behandelt reacties volgens jouw beleid. Beantwoordt wat het kan, vlagt wat het niet kan, en speculeert nooit over een roadmap. Alles dat op een supportincident lijkt gaat onmiddellijk naar een mens.
De goedkeuringspoort doet hier echt werk
Voor een bakkerij is een ongekeurde post een kleine gênante situatie. Voor een softwarebedrijf is het een supportlast, een verkoopbezwaar of een toezegging die niemand heeft gedaan. Een concept dat een beperking nét verkeerd beschrijft wordt door een klant aan je teruggeciteerd, en een concept dat een datum suggereert wordt als belofte behandeld.
So this is the case where autopilot deserves the most caution. A reasonable arrangement is autopilot on the short social slots that restate something already published, and approval on everything that makes a claim about the product. Anything about pricing, capacity or dates should be read by a person permanently, and it is worth writing that into the writer's rules so that drafts of that kind are held and flagged rather than queued.
Wat het rapport een klein team vertelt
Gepland versus gepubliceerd is het getal dat telt, en voor een softwareteam is het in het eerste kwartaal meestal ongemakkelijk. Het is ook de enige eerlijke maatstaf voor of schrijven weer is blijven steken op de release.
Ontvangst telt minder dan het lijkt. Een technisch stuk vindt zijn publiek over maanden, niet dagen, en het na twee weken beoordelen maakt dat je de stukken schrapt die wél zouden werken. De themabalans is vroeger nuttiger: die laat zien of je alleen schrijft over wat er is verschenen, wat de standaardfaalmodus is en de reden dat zoveel softwareblogs lezen als een changelog met alinea's.
Het eerlijke deel: als je product echt technisch is, hebben de diepste stukken nog steeds een ingenieur voor een middag nodig. Wat een plan verandert, is dat die middagen ingepland worden en dat de andere tachtig procent van het schrijven niet meer met ze concurreert.