SaaS
Publicas cada quincena e escribes sobre iso dúas veces ao ano
Aos equipos de software non lles faltan cousas que dicir. Fáltalles a persoa que as di, porque escribir é sempre a tarefa que se adia cando o lanzamento vai atrasado — e adíase cada vez, ata que a entrada máis recente do blog ten once meses e di "presentamos".
O fallo é estrutural, non editorial
Todos os equipos saben que deberían escribir máis. Os enxeñeiros saben escribir; o fundador sabe escribir; a alguén normalmente gústalle. O problema é que escribir non ten prazo propio, e calquera cousa sen prazo perde contra calquera cousa con el, cada quincena, para sempre.
Un plan fornece o prazo que falta. Un espazo con data, tema e escritor asignados é un compromiso tomado nunha semana tranquila e aplicado nunha semana que non o é, e o borrador aparece aínda que ninguén se lembre. Aprobalo leva minutos; escribilo dende cero leva unha tarde que nunca chega.
Ese é todo o argumento. Non é que un modelo escriba mellor que o teu equipo — non o fai. É que un borrador que editas o martes existe, e unha entrada que tiñan intención de escribir non.
Unha folla de ruta é un plan que xa escribiches
A maior parte dos seis meses xa está decidida. Sabes máis ou menos que se lanza nos próximos dous trimestres, que partes do produto están mal entendidas, que integracións pídenche constantemente e que preguntas chegan ao soporte todas as semanas.
Cada unha desas é un tema. A folla de ruta fornece a cadencia — un lanzamento convértese nunha serie de espazos en vez dunha única entrada no rexistro de cambios — e o soporte fornece a metade perenne, porque unha pregunta feita vinte veces ao mes é un contido que vale a pena escribir unha vez e enlazar para sempre.
Deixa ocos. Os lanzamentos atrasanse, e un plan sen espazos baleiros converte un lanzamento atrasado en tres entradas sobre unha cousa que aínda non existe. Un cuarto dos espazos abertos non é folga; é a parte do plan que sobrevive ao contacto co teu calendario real.
- 1BlogQue se lanzou e por que existe. Primeiro o problema, despois a funcionalidade.
- 2Facebook / InstagramA versión nunha soa frase, para quen nunca abrirá un rexistro de cambios.
- 3BlogComo o usou alguén de verdade. Concreto, coas partes incómodas incluídas.
- ·Se se atrasaAs franxas móvense coa publicación. Nada anuncia unha cousa que non existe.
- 4BlogA pregunta de soporte que esta versión finalmente responde, escrita unha soa vez.
A folla de ruta marca o ritmoO soporte marca os temas
O teu rexistro de cambios non é contido. É un recibo.
Dous redactores, ás veces tres
O que explica o produto, e o que fala da empresa
Son voces realmente distintas, e mesturalas produce esa insipidez tan característica dos blogs de software: un artigo que non é nin unha explicación técnica nin un relato humano de nada.
O redactor técnico
Explica o que fai unha cousa, con precisión e sen adxectivos. Sabe para que serve o teu produto e para que non, e pode dicilo. Este é o redactor cuxos artigos se citan nos tickets de soporte.
A voz da empresa
Escribe sobre decisións, concesións e cara a onde se está a construír. Útil dun xeito difícil de medir e evidente nas contratacións, nas chamadas de vendas e no motivo polo que alguén elixe un provedor pequeno fronte a un grande.
O que responde
Xestiona os comentarios segundo a túa política. Responde o que pode, sinala o que non pode e nunca especula sobre a folla de ruta. Calquera cousa que semelle un incidente de soporte pasa inmediatamente a unha persoa.
Aquí a porta de aprobación fai un traballo real
Para unha panadaría, un artigo non aprobado é unha pequena vergoña. Para unha empresa de software é unha carga de soporte, unha obxección de vendas ou un compromiso que ninguén aceptou. Un borrador que describe un límite lixeiramente mal devolverácho un cliente citado, e un borrador que insinúa unha data tratarase como unha promesa.
Así que este é o caso no que o piloto automático merece máis precaución. Unha disposición razoable é piloto automático nas franxas sociais curtas que reiteran algo xa publicado, e aprobación en todo o que faga unha afirmación sobre o produto. Calquera cousa sobre prezos, capacidade ou datas debería lela unha persoa de xeito permanente, e vale a pena escribir iso nas regras do redactor para que os borradores dese tipo se retengan e se sinalen en vez de quedar en cola.
O que o informe lle di a un equipo pequeno
Planificado fronte a publicado é a cifra que importa, e para un equipo de software adoita ser incómoda no primeiro trimestre. Tamén é a única medida honesta de se a escritura deixou de perder de novo fronte á versión.
A acollida importa menos do que parece. Un artigo técnico atopa o seu público en meses, non en días, e xulgalo na segunda semana farache retirar os artigos que ían funcionar. O equilibrio de temas é máis útil ao principio: mostra se só escribes sobre o que se publicou, que é o modo de fallo estándar e o motivo polo que tantos blogs de software se len como un rexistro de cambios con párrafos.
A parte honesta: se o teu produto é realmente técnico, os artigos máis profundos aínda necesitan un enxeñeiro durante unha tarde. O que cambia cun plan é que esas tardes se programan e o outro oitenta por cento da escritura deixa de competir con elas.