As publicações precisam de cuidado.

Perceber de tecnologia não chega. O difícil é encontrar pessoas que percebem de tecnologia e de publicações. Pessoas que entendem o que significa realmente "a newsletter de sexta-feira não foi enviada", porque continua a acontecer e quanto custa isso à equipa. Pessoas que entendem como funcionam os conselhos de uma organização sem fins lucrativos, como as doações e as campanhas de correspondência se comportam na prática, como os prazos editoriais se movem de verdade. Passámos tempo suficiente dentro das redações para ler esse ritmo antes de começarmos a escrever código. É essa a diferença.

É aí que começam muitos projetos com publicações. Fazemos uma breve descoberta, normalmente de uma semana, em que nos sentamos com editores, engenheiros e quem tem estado a construir os improvisos. Voltamos com um âmbito escrito, um esboço do modelo de conteúdo e um cronograma. Fica com um plano real do que vale a pena fazer primeiro, o que vem depois e o que pode esperar. Valor fixo pela semana, sem compromisso para além disso.

Não lhes pedindo que abandonem o que funciona. Começamos por mapear o fluxo atual, incluindo as partes que ninguém documentou. Depois construímos o novo sistema para dar suporte a esses hábitos antes de o abrir a qualquer lado onde a equipa queira mais. Os editores notam a mudança porque é melhor, não porque têm de reaprender tudo.

Manda-nos mensagem no Slack. Vemos o que mudou, descobrimos a dependência e ou reativamos o plugin ou escrevemos um patch rápido para que o site sobreviva sem ele. Depois enviamos ao editor uma nota de um parágrafo sobre porque é que isso importava, sem qualquer censura. Para clientes com contrato contínuo, todo esse ciclo demora minutos. Sem contrato, o mesmo canal, a mesma pessoa com quem tem estado a trabalhar. Sem filas de tickets, sem chatbots, sem uma linha de triagem entre si e as pessoas que realmente construíram isto.