Tema: process
-
DACI e RACI para decisões técnicas: um único aprovador e contribuidores definidos
O DACI define um driver que conduz a decisão, um único aprovador que a toma, contribuidores que têm voz mas não voto e informados que recebem o resultado; o RACI atribui a tarefas os papéis de responsável, aprovador final (accountable), consultado e informado. Ambos funcionam para decisões técnicas, desde que os papéis sejam registrados antes de a discussão começar.
-
Dívida técnica como decisão consciente, com registro contábil
A metáfora de Cunningham trata código ainda não totalmente correto como um empréstimo, e cada minuto de trabalho extra nele é o juro. Só funciona se a dívida for assumida de forma consciente, registrada e reavaliada com regularidade; como rótulo para tudo o que é feio ou como desculpa para desleixo, não vale nada.
-
Como escrever um relatório de bug utilizável
Um relatório de bug é utilizável quando uma pessoa de fora consegue reproduzir o erro sem fazer perguntas: título preciso, ambiente com versões, passos numerados para reproduzir, resultado esperado e resultado real separados, a mensagem de erro literal e um exemplo o menor possível. Suposições sobre a causa ficam numa seção própria.
-
Acompanhar as ações de um postmortem até o fechamento: tracking bugs, responsável único e revisão por idade
O Site Reliability Workbook alerta que, sem um processo formal de acompanhamento, as ações de um postmortem costumam ser esquecidas. Dê a cada item um tracking bug, um único responsável, um tipo e uma prioridade, revise os itens abertos por idade com periodicidade fixa e trate um item com prazo vencido como uma decisão a tomar, não como uma linha a ignorar.
-
Princípios ágeis como acordos de trabalho concretos
Os doze princípios por trás do Manifesto Ágil tornam-se úteis quando traduzidos em acordos verificáveis da equipe: cadência de entrega, comunicação direta, ritmo sustentável, excelência técnica e reflexão regular.
-
Atas de reunião com uma seção separada de decisões reduzem a reabertura de decisões
Hipótese: equipes cujas atas listam cada decisão em separado (enunciado, opções rejeitadas, responsável, data) e a copiam para um log de decisões duradouro reabrem questões já resolvidas com menos frequência do que equipes com atas narrativas, porque uma decisão que pode ser encontrada e citada tem menos chance de ser rediscutida do zero.
-
Tratar um pedido de titular de dados como processo de engenharia: exportação e exclusão
Trate o pedido de uma pessoa por uma cópia ou pela exclusão dos seus dados como um job: entrada com verificação, um exportador por armazenamento do mapa de dados gerando um manifesto, entrega por download autenticado com expiração, exclusão pelo pipeline, exceções listadas com códigos de motivo e teste com titular sintético em cadência fixa; quais pedidos devem ser atendidos e quando não é abordado.
-
Documentação de onboarding: o caminho de uma máquina nova até uma alteração integrada
A documentação de onboarding é um único caminho numerado que leva quem chega, pessoa ou agente, de uma máquina sem nada instalado até uma alteração integrada, usando apenas o que está escrito. Cada recém-chegado corrige o que o fez tropeçar, e o caminho tem um responsável e uma data de verificação.
-
Calendário de mudanças e janelas de manutenção para uma equipe pequena de operações
Registre toda mudança planejada que possa afetar usuários em um único calendário compartilhado, com responsável, janela, linha de rollback e regras de bloqueio; o livro de SRE do Google afirma que o SRE constatou que cerca de 70% das interrupções decorrem de mudanças em um sistema em produção, e por isso "o que mudou?" é a primeira pergunta em qualquer incidente e o calendário é onde ela é respondida.
-
Como escrever um documento de design (RFC) sobre o qual os revisores possam decidir
Um documento de design obtém a decisão antes de o código existir: primeiro o problema, depois objetivos e não objetivos, uma explicação no nível do usuário e outra no nível de referência, alternativas descartadas com justificativa, desvantagens e uma lista explícita de questões em aberto. A estrutura segue o que a PEP 1, o modelo de RFC do Rust e a prática de design docs da Google exigem.
-
Triagem de issues em um projeto pequeno: conjunto fixo de labels e revisão periódica
Triagem é decidir, para cada nova issue, o que ela é, se há algo a fazer e quem age em seguida. Um vocabulário pequeno de labels em três famílias (tipo, status, área) e uma revisão curta em cadência fixa mantêm o tracker confiável; as labels padrão do GitHub (entre elas bug, enhancement, documentation, duplicate, question, wontfix, good first issue e help wanted) servem como ponto de partida.
-
Retrospectivas que geram mudanças, não listas
Uma retrospectiva compensa o tempo investido quando termina com uma ou duas mudanças, cada uma com uma responsável, um prazo e um critério claro de conclusão. O Scrum Guide exige que as melhorias de maior impacto sejam tratadas o quanto antes, e a Prime Directive cria o clima em que as pessoas apontam os problemas reais.
-
Postmortems sem atribuição de culpa: registrar a sequência dos fatos, as causas e as ações corretivas
Um postmortem descreve o que aconteceu durante um incidente, quem foi afetado e por quanto tempo, que circunstâncias o tornaram possível e que ações tornam uma repetição menos provável. A ausência de culpa não é questão de cortesia, e sim a condição para que os envolvidos relatem fatos em vez de se defender.
-
Como projetar uma escala de plantão (on-call) e a passagem de turno
Uma escala de plantão precisa de um primário e de um backup, de um limite para a fatia do tempo de cada engenheiro, de durações de turno e regras de troca que permitam planejamento, de um orçamento de pager que dispare trabalho corretivo quando excedido e de uma passagem de turno escrita a cada troca; o livro SRE do Google e a documentação pública de resposta a incidentes da PagerDuty descrevem as restrições.
-
Pontuação RICE e ICE: o que os números significam e onde deixam de servir
O RICE multiplica alcance, impacto e confiança e divide pelo esforço; o ICE elimina o alcance e mantém impacto, confiança e facilidade. Ambos ajudam a tornar os argumentos de priorização explícitos e comparáveis, mas falham quando os dados são palpites disfarçados de números ou quando se ignoram dependências e estratégia.
-
Estimar esforço como um intervalo com nível de confiança declarado
Apresente a estimativa como um intervalo (melhor caso, valor esperado, pior caso) acompanhado da confiança de que o valor real esteja dentro dele; ajuste a largura com base nos resultados de trabalhos comparáveis anteriores, e não no plano, e reveja-a em pontos fixos. Um número único esconde justamente a incerteza de que as decisões dependem.
-
Cadência de lançamentos em um projeto pequeno: ciclos por tempo ou lançamento quando estiver pronto
O número da versão diz o que um lançamento promete; a política de cadência diz quando os lançamentos acontecem. O Rust lança uma versão estável a cada seis semanas, num esquema de trem com nightly, beta e stable; o Python adotou um lançamento anual de funcionalidades com a PEP 602; o Django publica versões de funcionalidades em calendário fixo e de correção conforme a necessidade. Um projeto pequeno pode seguir o mesmo modelo: versões de funcionalidades por calendário ou quando algo relevante se acumula, e versões de correção sempre que uma correção chega.
-
Como conduzir uma revisão de design: período de comentários, decisor nomeado e decisão registrada
Uma revisão de proposta precisa de um período de comentários delimitado, de uma pessoa ou grupo nomeado que decide, de uma decisão escrita (aceitar, rejeitar, adiar) com justificativa e de uma regra para reabrir o caso; os processos RFC do Rust e PEP do Python mostram o formato, e esta metodologia o adapta a uma única equipe.
-
Recusar um pedido de funcionalidade sem perder o contribuidor
Uma recusa que remete para um escopo documentado, chega logo, indica uma alternativa e encerra a discussão é mais gentil do que o silêncio e mantém o autor do pedido como contribuidor. Segundo os Open Source Guides, pôr as coisas por escrito facilita dizer não, e uma resposta raramente precisa de mais do que uma ou duas frases.
-
Critérios de aceitação por item de trabalho que podem virar testes
Escreva os critérios de aceitação de cada item de trabalho como exemplos concretos, com estado inicial, ação e resultado observável, usando a estrutura Given/When/Then do Gherkin ou equivalente e nomeando os casos-limite; critérios que não podem ser executados ou verificados por alguém que não seja o autor não são critérios.
Legível por máquina: JSON