SaaS
Vous livrez toutes les deux semaines et vous en écrivez deux fois par an
Les équipes logicielles ne manquent pas de sujets. Elles manquent de la personne qui les écrit, car la rédaction est toujours la tâche qu'on déplace quand la livraison prend du retard — et elle est déplacée à chaque fois, jusqu'à ce que l'article le plus récent du blog ait onze mois et commence par « Présentation de ».
L'échec est structurel, pas éditorial
Chaque équipe sait qu'elle devrait écrire davantage. Les ingénieurs savent écrire ; le fondateur sait écrire ; quelqu'un y prend généralement plaisir. Le problème, c'est que la rédaction n'a pas d'échéance propre, et que tout ce qui n'a pas d'échéance perd face à tout ce qui en a une, toutes les deux semaines, pour toujours.
Un plan fournit l'échéance manquante. Un créneau daté, avec un thème et un rédacteur associés, est un engagement pris pendant une semaine calme, appliqué pendant une semaine qui ne l'est pas, et la version apparaît que quelqu'un s'en souvienne ou non. L'approuver prend quelques minutes ; l'écrire de zéro prend un après-midi qui n'arrive jamais.
C'est tout l'argument. Ce n'est pas qu'un modèle écrit mieux que votre équipe — ce n'est pas le cas. C'est qu'une version que vous corrigez mardi existe, et qu'un article que vous comptiez écrire n'existe pas.
Une feuille de route est un plan que vous avez déjà rédigé
L'essentiel des six mois est déjà décidé. Vous savez à peu près ce qui sera livré au cours des deux prochains trimestres, quelles parties du produit sont mal comprises, quelles intégrations on vous demande sans cesse, et quelles questions arrivent au support chaque semaine.
Chacune est un thème. La feuille de route fournit la cadence — une livraison devient une série de créneaux plutôt qu'une entrée de journal des modifications — et le support fournit la moitié intemporelle, car une question posée vingt fois par mois mérite qu'on l'écrive une fois et qu'on y renvoie pour toujours.
Laissez des espaces. Les livraisons glissent, et un plan sans créneaux vides transforme une livraison retardée en trois articles sur une chose qui n'existe pas encore. Un quart des créneaux laissés ouverts n'est pas du relâchement ; c'est la partie du plan qui survit au contact de votre calendrier réel.
- 1BlogCe qui a été livré et pourquoi cela existe. Le problème d'abord, la fonctionnalité ensuite.
- 2Facebook / InstagramLa version en une phrase, pour ceux qui n'ouvriront jamais un journal des modifications.
- 3BlogComment quelqu'un l'a réellement utilisé. Concret, avec les parties maladroites laissées en place.
- ·En cas de retardLes créneaux suivent la publication. Rien n'annonce une chose qui n'existe pas.
- 4BlogLa question d'assistance que cette publication répond enfin, rédigée une seule fois.
La feuille de route fixe la cadenceL'assistance fixe les thèmes
Votre journal des modifications n'est pas du contenu. C'est un justificatif.
Deux rédacteurs, parfois trois
Celui qui explique le produit, et celui qui parle de l'entreprise
Ce sont deux voix véritablement différentes, et les fusionner produit la fadeur particulière qui caractérise les blogs logiciels — un article qui n'est ni une explication technique ni un récit humain de quoi que ce soit.
Le rédacteur technique
Explique ce qu'une chose fait, avec précision, sans adjectifs. Sait à quoi votre produit est destiné et à quoi il ne l'est pas, et a le droit de le dire. C'est le rédacteur dont les articles sont cités dans les tickets d'assistance.
La voix de l'entreprise
Écrit sur les décisions, les compromis et ce que vous construisez. Utile d'une manière difficile à mesurer mais évidente lors des recrutements, des rendez-vous commerciaux, et dans la raison pour laquelle quelqu'un choisit un petit fournisseur plutôt qu'un grand.
Celui qui répond
Gère les commentaires selon votre politique. Répond à ce qu'il peut, signale ce qu'il ne peut pas, et ne spécule jamais sur une feuille de route. Tout ce qui ressemble à un incident d'assistance est immédiatement transmis à une personne.
Le filtre d'approbation fait ici un vrai travail
Pour une boulangerie, une publication non approuvée est une petite gêne. Pour une entreprise logicielle, c'est une charge d'assistance, une objection commerciale, ou un engagement que personne n'a accepté. Un brouillon qui décrit légèrement mal une limite vous sera cité par un client, et un brouillon qui évoque une date sera traité comme une promesse.
C'est donc le cas où le pilote automatique mérite le plus de prudence. Un arrangement raisonnable : le pilote automatique sur les courts créneaux sociaux qui reprennent quelque chose de déjà publié, et l'approbation sur tout ce qui formule une affirmation sur le produit. Tout ce qui concerne les tarifs, la capacité ou les dates doit être lu par une personne en permanence, et il vaut la peine de l'inscrire dans les règles du rédacteur afin que les brouillons de ce type soient retenus et signalés plutôt que mis en file d'attente.
Ce que le rapport dit à une petite équipe
Planifié contre publié est le chiffre qui compte, et pour une équipe logicielle, il est généralement inconfortable au premier trimestre. C'est aussi la seule mesure honnête pour savoir si la rédaction a de nouveau cessé de céder face à la publication.
La réception compte moins qu'il n'y paraît. Un article technique trouve son public en mois, pas en jours, et le juger dès la deuxième semaine vous fera abandonner les articles qui allaient fonctionner. L'équilibre des thèmes est plus utile au début : il montre si vous ne faites qu'écrire sur ce qui a été livré, ce qui est le mode d'échec standard et la raison pour laquelle tant de blogs logiciels ressemblent à un journal des modifications avec des paragraphes.
La partie honnête : si votre produit est véritablement technique, les articles les plus approfondis ont encore besoin d'un ingénieur pour un après-midi. Ce qu'un plan change, c'est que ces après-midis sont planifiés et que les quatre-vingts pour cent restants de la rédaction cessent de rivaliser avec eux.