90% das avarias? Corrija-os rapidamente com os iniciadores do Sprint.

A maioria das falhas nos projetos não começa com um grande fracasso. Muitas vezes eles começam com uma pequena lacuna: - A equipe não tem certeza do que o sprint deve entregar. - Duas pessoas presumem que a outra pessoa possui uma tarefa. - Uma dependência permanece oculta até que o trabalho já esteja em andamento. - Uma solicitação do cliente muda, mas a equipe continua trabalhando no plano antigo. Eu uso um sprint starter para trazer essas lacunas à tona antes que elas desacelerem a equipe. É uma breve rotina de planejamento que ajuda todos a concordarem sobre a meta, o trabalho, os riscos e a próxima ação. Um sprint starter não substitui um bom gerenciamento de projetos. Isso dá à equipe um ponto de partida compartilhado. ## Comece com um resultado claro. Peço à equipe que complete esta frase: “Até o final deste sprint, iremos…” A resposta deve descrever um resultado, não uma lista de atividades. Exemplo fraco: > Trabalharemos na página de checkout. Exemplo mais claro: > Reduziremos erros de checkout adicionando validação de endereço e testando as principais formas de pagamento. A segunda versão dá à equipe uma forma de avaliar o progresso. Se uma tarefa não oferece suporte ao resultado, questiono se ela pertence ao sprint. Um resultado claro também ajuda quando surgem novas solicitações. A equipe pode perguntar: “Isso apoia o objetivo do sprint?” Essa questão impede que pequenas mudanças assumam o controle do plano. ## Nomeie o trabalho que importa. Divido o trabalho planejado em três grupos: Deve ser feito Essas tarefas apoiam diretamente o resultado do sprint. Útil se a capacidade permitir Essas tarefas podem ajudar, mas não devem afetar o resultado principal. Não faz parte deste sprint Essas tarefas podem ser válidas, mas precisam de um horário ou proprietário diferente. Essa divisão simples evita um problema comum. As equipes muitas vezes tratam cada solicitação como urgente e depois descobrem que o trabalho principal não tem mais espaço. Para uma equipe de produto, a lista pode ser assim: Deve ser feito - Adicionar validação de endereço - Atualizar mensagens de erro - Testar caminhos de pagamento por cartão e banco Útil se a capacidade permitir - Melhorar a animação de carregamento - Revisar notas de checkout mais antigas Não faz parte deste sprint - Redesenhar toda a área da conta - Adicionar um novo provedor de pagamento A lista cria um limite visível. As pessoas ainda podem registrar novas ideias sem permitir que alterem silenciosamente o sprint. ## Dê a cada tarefa um proprietário. A responsabilidade compartilhada pode parecer útil, mas muitas vezes cria incerteza. Eu atribuo uma pessoa para ser responsável por cada tarefa. Essa pessoa não precisa completar todas as partes sozinha. Eles garantem que a tarefa seja executada, que as perguntas cheguem às pessoas certas e que o resultado seja verificado. Um cartão de tarefas deverá responder: - A quem pertence? - O que significa “pronto”? - Quem pode precisar de ajuda? - O que poderia bloqueá-lo? - Quando a equipe irá revisá-lo? Uma instrução de tarefa útil é semelhante a esta: > Maya possui validação de endereço. Concluído significa que os endereços válidos foram aprovados, os endereços inválidos mostram uma mensagem clara e os principais casos de teste são registrados. Isso é mais fácil de seguir do que: > A equipe de desenvolvimento cuidará dos problemas de resolução. A segunda frase nomeia um grupo, não uma pessoa. Se a tarefa ficar mais lenta, todos poderão acreditar que outra pessoa está cuidando dela. ## Revelar dependências antecipadamente Uma dependência é qualquer coisa que outra tarefa, pessoa, sistema ou decisão deve fornecer antes que o trabalho possa continuar. Pergunto a cada proprietário: > “O que você precisa de outra pessoa antes que isso possa ser movido?” A resposta pode ser: - Acesso a uma conta de teste - Um arquivo de projeto - Uma decisão de preço - Uma resposta de um fornecedor - Uma revisão técnica - Permissão para usar um sistema A equipe registra esses itens ao lado da tarefa relacionada. Cada dependência recebe um proprietário e uma próxima ação. Exemplo: > A equipe de teste precisa de dados de pagamento de amostra. A Jordânia irá fornecê-lo antes da revisão do desenvolvimento. Essa frase é muito mais segura do que: > Estamos aguardando dados de teste. “Esperar” não mostra quem está agindo ou o que deve acontecer a seguir. ## Defina um pequeno número de regras de trabalho Um sprint pode perder tempo quando cada pessoa segue um processo diferente. Eu mantenho as regras curtas. Uma equipe pode concordar em: - Levantar um bloqueador no canal compartilhado quando ele aparecer. - Peça uma revisão antes que uma tarefa seja marcada como concluída. - Mantenha o trabalho em andamento abaixo de um limite definido. - Atualize o status da tarefa antes do check-in diário. - Registre decisões em um local compartilhado. O objetivo não é adicionar papelada. O objetivo é reduzir as suposições. Uma equipe remota também pode concordar com os tempos de resposta dos bloqueadores. Isso não significa que toda mensagem precise de uma resposta instantânea. Significa que as pessoas sabem quando pedir ajuda através de outro canal. ## Verifique a capacidade antes de fazer promessas Um plano de sprint pode falhar quando se baseia na esperança em vez do tempo disponível. Verifico: - Quem está ausente? - Quem está apoiando a produção ou os clientes? - Quais reuniões exigem capacidade da equipe? - Que tarefas necessitam de competências especializadas? - Quanto trabalho já está em andamento? Uma equipe com cinco pessoas pode não ter cinco colaboradores em tempo integral para o sprint. Uma pessoa pode estar cuidando do suporte. Outro pode estar participando de uma sessão de treinamento. Um terceiro pode ser necessário para o lançamento de outro projeto. Um plano prático reflete esses limites. Por exemplo, uma equipe pode reduzir o escopo do sprint de oito para cinco itens após verificar as tarefas de suporte. Essa decisão pode parecer menos ambiciosa, mas dá à equipa uma melhor oportunidade de alcançar o resultado acordado. ## Use uma breve conversa inicial para manter o foco na reunião inicial do sprint. Uma sessão de 20 a 30 minutos pode abranger: 1. O resultado do sprint 2. O trabalho obrigatório 3. Proprietários das tarefas 4. Dependências 5. Riscos conhecidos 6. Pontos de revisão 7. A primeira ação de cada proprietário Cada pessoa deve sair sabendo o que fazer a seguir. Não peço à equipe que resolva todos os problemas futuros durante o pontapé inicial. Se um tópico precisar de uma discussão separada, eu o gravo, designo um proprietário e defino um horário de acompanhamento. Isso mantém a reunião útil sem ignorar o problema. ## Fique atento aos primeiros sinais de alerta Alguns sinais mostram que o sprint pode estar à deriva: - As tarefas permanecem abertas sem uma próxima ação clara. - As pessoas usam diferentes definições de “pronto”. - Uma nova solicitação entra no plano sem retirar outro item. - O mesmo bloqueador aparece em mais de um check-in. - As revisões acontecem no final e não durante o trabalho. - Os membros da equipe não conseguem explicar o resultado do sprint com palavras semelhantes. Eu trato esses sinais como instruções para uma breve reinicialização. A equipe pode precisar esclarecer o objetivo, retirar uma tarefa do sprint ou trazer alguém que possua uma dependência. Uma reinicialização não é um fracasso. É uma forma de evitar que um pequeno problema se torne um atraso maior. ## Um exemplo prático Uma equipe de software planejou lançar uma nova atualização de checkout. No início, o objetivo principal parecia simples: melhorar a experiência de pagamento. O iniciador do sprint expôs três lacunas: - O designer achou que a equipe estava mudando o layout completo do checkout. - O desenvolvedor esperava que o provedor de pagamento fornecesse credenciais de teste. - O líder de suporte não foi informado sobre as alterações planejadas nas mensagens de erro. A equipe ajustou a meta: > Melhorar o tratamento de erros de pagamento para o fluxo de checkout atual. Eles designaram um proprietário para o trabalho de validação, solicitaram credenciais de teste e forneceram ao suporte um breve guia de mensagens. A equipe removeu as alterações de layout do sprint. O resultado foi um plano menor com menos tarefas pouco claras. A equipe poderia verificar o progresso em relação a um resultado, em vez de tentar concluir várias solicitações vagamente conectadas. ## Meu modelo de trabalho eu uso esta estrutura no início de cada sprint: Resultado do sprint: Qual resultado deve existir quando o sprint terminar? Trabalho obrigatório: Quais tarefas apoiam esse resultado? Proprietários de tarefas: Quem é responsável por levar cada tarefa adiante? Definição de concluído: Que evidências mostram que a tarefa foi concluída? Dependências: O que cada proprietário precisa e quem fornecerá isso? Riscos: O que pode atrasar o trabalho? Não incluído: Quais solicitações ficam fora do sprint? Primeiras ações: O que cada proprietário fará a seguir? Um modelo curto pode evitar longas discussões posteriores. Isso dá à equipe um local para verificar quando aparecem perguntas. As falhas do projeto nem sempre são causadas por esforços insuficientes. Muitos vêm de objetivos pouco claros, dependências ocultas e trabalham sem um proprietário claro. Um sprint starter oferece à equipe uma visão compartilhada antes do início da entrega. Eu o uso para diminuir o plano, expor os riscos mais cedo e criar um próximo passo claro para cada pessoa. O objetivo não é prever todos os problemas. O objetivo é tornar os problemas mais fáceis de ver e resolver.

Um revés pode fazer com que um projeto pareça estagnado. Um prazo não cumprido, um resultado de teste fraco ou uma ideia de produto que não desperta o interesse pode deixar a equipe insegura sobre o que fazer a seguir. Descobri que muitas vezes o problema não é o revés em si. O verdadeiro problema é a falta de um próximo passo claro. Sprint Starters oferecem uma maneira simples de transformar um momento difícil em ação focada. Em vez de pedir à equipe que resolva tudo de uma vez, divido o trabalho em um ciclo curto com um objetivo claro, um pequeno número de tarefas e um ponto de revisão prático. ### Comece nomeando o contratempo. Começo com fatos. O que aconteceu? O que era esperado? O que mudou? Qual parte do plano não cabe mais? Uma equipe pode dizer: “A campanha falhou”. Essa afirmação é demasiado ampla para orientar a acção. Uma versão mais clara poderia ser: - A landing page recebeu visitas, mas poucas inscrições. - Os clientes usaram o produto uma vez, mas não devolveram. - O projeto demorou mais que o planejado. - O grupo de teste não entendeu a característica principal. Uma linguagem clara reduz a culpa. Também dá à equipe algo em que ela pode trabalhar. ### Escolha um resultado para o sprint Um sprint curto funciona melhor quando tem um resultado principal. Esse resultado deve ser fácil de verificar. Os exemplos incluem: - Reescrever a mensagem da página de destino e testar duas versões. - Entrevistar cinco usuários que deixaram de usar o serviço. - Crie uma versão básica de um recurso do produto. - Revise o processo de vendas e remova uma etapa confusa. - Crie um novo e-mail de integração e avalie as respostas dos usuários. Evito objetivos como “consertar o produto” ou “melhorar o marketing”. Esses objetivos parecem úteis, mas dão à equipe muito espaço para se desviar. Um resultado focado me ajuda a decidir o que pertence ao sprint e o que pode esperar. ### Divida o trabalho em pequenas ações Uma vez claro o objetivo, listo as ações necessárias para alcançá-lo. Para um teste de landing page, o trabalho pode ser assim: 1. Revise a página atual. 2. Encontre as três perguntas mais comuns dos visitantes. 3. Escreva duas novas declarações de valores. 4. Ajuste a estrutura da página. 5. Peça feedback a um pequeno grupo de usuários. 6. Compare as respostas. 7. Registre a próxima alteração. Cada ação deve ser pequena o suficiente para que uma pessoa entenda e conclua. Se uma tarefa ainda parecer grande, eu a divido novamente. Essa abordagem ajuda a equipe a identificar antecipadamente as informações ausentes. Também torna o progresso visível quando o plano original falhou. ### Use contratempos como sinais úteis Um resultado ruim pode revelar algo que um resultado positivo pode esconder. Um teste de produto com pouco interesse pode mostrar que o público não entende a oferta. Um projeto atrasado pode revelar que uma etapa de aprovação cria uma longa espera. Uma reclamação de um cliente pode apontar para uma lacuna no processo de serviço. Não trato cada revés como prova de que toda a ideia está errada. Pergunto o que o resultado me diz sobre a próxima decisão. É aqui que o Sprint Starters pode ajudar. O método transforma um problema amplo num curto ciclo de aprendizagem: - O que sabemos? - O que precisamos aprender? - Que pequena ação pode nos dar essa informação? - O que mudaremos depois de analisar o resultado? ### Mantenha o sprint curto e prático Um sprint precisa de um limite de tempo claro. A duração pode variar de acordo com o projeto, mas o trabalho deve ser curto o suficiente para manter a atenção em um resultado. Um plano de sprint simples pode incluir: Objetivo: Melhorar as inscrições na página do produto. Pessoas envolvidas: Redator, designer, líder de produto. Período de trabalho: Cinco dias úteis. Evidência: Feedback do usuário e dados de inscrição. Ponto de revisão: decida se deseja manter, alterar ou descartar a nova versão da página. A revisão deve centrar-se nas evidências e não nas preferências pessoais. Uma equipe pode discutir o que os usuários fizeram, o que disseram e o que os números mostram. ### Dê a cada pessoa um papel claro. Os contratempos muitas vezes criam confusão. Várias pessoas podem tentar resolver o mesmo problema, enquanto outra tarefa não recebe atenção. Atribuo funções simples: - Uma pessoa é responsável pela meta do sprint. - Cada tarefa tem um proprietário responsável. - Um revisor verifica o trabalho antes do final do sprint. - O grupo concorda em como o resultado será medido. Isso não significa que uma pessoa trabalhe sozinha. Isso significa que a equipe sabe quem faz cada tarefa avançar. ### Aprenda com um exemplo prático Imagine uma pequena empresa de educação online. A equipe cria uma página do curso, mas muitos visitantes saem antes de verificar os detalhes da aula. A primeira reação pode ser redesenhar todo o site. Isso exigiria mais tempo e pode não resolver o problema real. Um Sprint Starter poderia se concentrar em uma pergunta: “Os visitantes entendem para quem é o curso?” A equipe analisa as mensagens dos clientes, entrevista alguns visitantes e cria duas versões mais claras da seção de abertura. Após um breve teste, a equipe verifica se os visitantes passam mais tempo na página ou avançam para os detalhes da lição. O resultado pode mostrar que o problema não foi o design. O público pode ter precisado de uma explicação mais clara sobre o nível, formato ou resultado esperado do curso. Esse insight dá à equipe um próximo passo útil sem reconstruir tudo. ### Registre o que mudou Ao final do sprint, registro quatro pontos: - O problema que trabalhamos. - A ação que tomamos. - As provas que recolhemos. - A decisão que se segue. Este registro evita discussões repetidas. Também ajuda os novos membros da equipe a entender por que uma escolha foi feita. Uma breve nota é suficiente. O objetivo não é criar um relatório longo. O objetivo é evitar que o aprendizado útil seja perdido. ### Evite problemas comuns de sprint Um sprint pode perder valor quando a equipe: - Adiciona muitos objetivos. - Começa a trabalhar sem definir o problema. - Mede a atividade em vez dos resultados. - Muda o alvo no meio do ciclo. - Trata um resultado fraco como um fracasso total. - Atrasa a revisão até que os detalhes sejam esquecidos. Prefiro um teste pequeno e honesto a um plano grande, sem uma maneira clara de verificar o progresso. Um revés não precisa decidir o futuro de um projeto. Pode mostrar onde está escondida a próxima pergunta útil. Sprint Starters fornecem uma estrutura prática para fazer essa pergunta, testar uma resposta e escolher o próximo passo com melhores informações.

As avarias repetidas esgotam mais do que os orçamentos de reparação. Eles interrompem a produção, atrasam os pedidos dos clientes, aumentam a pressão sobre sua equipe e fazem com que cada nova falha pareça mais difícil de gerenciar. Já vi empresas substituirem a mesma peça várias vezes sem perguntar por que ela continua falhando. O reparo pode resolver o sintoma, mas a causa permanece ativa. Uma abordagem mais forte começa antes do próximo colapso. ### Procure o padrão. Começo revisando cada falha recente, mesmo as pequenas. Um simples registro pode mostrar detalhes que são fáceis de perder: - Quando a falha ocorreu - Qual máquina ou componente foi afetado - O que a máquina estava fazendo no momento - Qual peça foi substituída - Quanto tempo durou o reparo - Se os mesmos sinais de alerta apareceram antes da falha Uma bomba que para a cada poucas semanas pode não ter uma “bomba ruim”. A causa pode ser mau alinhamento, filtros bloqueados, vibração excessiva, velocidade operacional inadequada ou problema de energia. O histórico de reparos me dá um ponto de partida. Não deve ser tratado como papelada que ninguém lê. ### Separe o sintoma da causa Uma correia quebrada é um sintoma. O desalinhamento pode ser a causa. Um motor queimado é um sintoma. Sobrecarga, ventilação insuficiente ou energia instável podem estar por trás disso. Um selo com vazamento é um sintoma. Excesso de pressão, movimento do eixo ou instalação incorreta podem estar causando o vazamento. Faço uma pergunta direta após cada reparo: O que permitiu que esta peça falhasse? Essa pergunta muda o trabalho de substituir peças para encontrar a condição que as danificou. ### Verifique o básico antes de fazer grandes alterações Muitas falhas repetidas começam com problemas simples: - Conexões soltas - Lubrificação deficiente - Passagens de ar bloqueadas - Rolamentos desgastados - Configurações incorretas - Sensores sujos - Pontos de montagem fracos - Verificações de segurança ausentes - Peças que não correspondem às especificações do equipamento Uma revisão completa do sistema pode ser útil, mas não deve ser a primeira resposta para todos os problemas. Prefiro inspecionar as causas comuns, comparar a máquina com seu guia de operação e confirmar as condições reais de trabalho. Isso mantém o plano prático e ajuda a controlar os custos do serviço. ### Elabore um plano de manutenção em torno do equipamento Um cronograma de manutenção deve refletir como o equipamento é usado. Uma máquina funcionando oito horas por semana pode precisar de um plano de inspeção diferente de um plano de operação diurno e noturno. Poeira, calor, umidade, vibração, mudanças de carga e métodos de limpeza também afetam as necessidades de serviço. Um plano útil pode incluir: 1. Verificações diárias de ruído, vazamentos, calor e danos visíveis 2. Verificações semanais de fixadores, filtros, correias e níveis de fluido 3. Verificações mensais de alinhamento, conexões elétricas e funções de segurança 4. Substituição programada de peças com vida útil conhecida 5. Um registro claro de descobertas e reparos O objetivo não é inspecionar tudo no mesmo nível. O objetivo é dar atenção às peças com maior probabilidade de afetar a segurança, o rendimento e a frequência de reparos. ### Forneça instruções claras à sua equipe Os registros de manutenção geralmente falham porque pessoas diferentes descrevem o mesmo problema de maneiras diferentes. “A máquina parece estranha” é difícil de agir. “Ruído agudo do lado da unidade após 20 minutos de operação” dá ao próximo técnico algo útil. Encorajo as equipes a registrar: - A localização exata do problema - O som, cheiro, temperatura ou movimento observado - A condição operacional quando apareceu - Fotos ou leituras quando adequado - Qualquer ação tomada antes da ocorrência da falha Notas claras reduzem o tempo gasto na busca pela causa. Eles também ajudam a revelar se uma falha é nova ou parte de um padrão repetido. ### Use sinais de alerta precoce As avarias geralmente fornecem pistas antes de parar o equipamento. Vibração incomum, aumento de temperatura, produção mais lenta, maior uso de energia, alarmes repetidos e pequenos vazamentos podem indicar o desenvolvimento de falhas. Estes sinais não devem ser ignorados simplesmente porque a máquina ainda funciona. Por exemplo, uma linha de produção pode continuar funcionando enquanto um rolamento começa a se desgastar. Uma breve inspeção nessa fase pode evitar danos às peças próximas. Esperar até que o rolamento trave pode transformar uma pequena tarefa de serviço em um reparo mais longo. Não recomendo reagir a cada pequena alteração com uma substituição cara. Recomendo registrar a alteração, verificar sua origem e acompanhar se ela cresce. ### Revise o reparo após a máquina retornar ao serviço Um reparo não estará concluído quando o equipamento for reiniciado. Verifico se a falha original parou, se a máquina está operando em condições normais e se outras peças foram afetadas. Um breve acompanhamento após vários ciclos de operação pode mostrar se o reparo solucionou a causa. Considere uma fábrica que substituiu um motor transportador três vezes em um ano. Uma inspeção mais detalhada descobriu que a estrutura do transportador estava ligeiramente fora de linha. Cada novo motor funcionou por um período, depois carregou carga extra e superaqueceu. A correção do alinhamento reduziu as falhas repetidas do motor sem adicionar um motor maior. A lição útil é simples: substituições repetidas nem sempre significam que a peça era de má qualidade. As condições circundantes podem necessitar de atenção. ### Crie um plano de resposta para a próxima falha Mesmo com manutenção regular, o equipamento pode falhar. Um plano de resposta ajuda a equipe a agir sem confusão. Defina: - Quem deve ser contatado - Quais equipamentos podem ser isolados com segurança - Quais informações o técnico precisa - Quais peças de reposição são adequadas - Como os clientes ou equipes internas serão atualizados - Quando o reparo deve ser revisto Este plano economiza tempo e reduz decisões precipitadas. Também dá aos novos funcionários um processo claro a seguir. Avarias repetidas são um sinal. Eles mostram que uma abordagem apenas de reparo pode não ser mais adequada ao equipamento ou à forma como está sendo usado. Começo com registros, inspeciono a causa, combino a manutenção com as condições reais de operação e faço acompanhamento após cada reparo. Pequenas mudanças na forma como uma equipe observa e relata falhas podem levar a melhores decisões e a menos interrupções repetidas.

As divisões da equipe raramente começam com um evento dramático. Eles geralmente surgem de pequenos erros: uma tarefa fica sem proprietário, uma decisão de produto permanece em um tópico de bate-papo ou um desenvolvedor encontra um detalhe importante após o início do sprint. Já vi equipes chamarem isso de “problemas pessoais”, quando o verdadeiro problema muitas vezes era a forma como o trabalho se processava na equipe. Um sprint pode expor os pontos fracos, mas também pode dar à equipe uma janela curta e prática para repará-los. O objetivo não é consertar todos os hábitos da equipe de uma só vez. O objetivo é tornar o próximo sprint mais fácil de seguir do que o anterior. Comece com o detalhamento, não com a culpa Quando um sprint sai do caminho, faço três perguntas: - Onde o trabalho parou de avançar? - Que informações estavam faltando? - Qual decisão não teve dono claro? Essas perguntas afastam a conversa das críticas pessoais. “Sarah não respondeu” dá pouco trabalho à equipe. “A solicitação de revisão não teve tempo de resposta nem proprietário reserva” aponta para uma mudança que a equipe pode fazer. Uma breve revisão pode revelar padrões como: - propriedade pouco clara da tarefa - transferências com detalhes faltantes - longos atrasos na aprovação - mudança de prioridades durante o sprint - reuniões que geram discussão, mas nenhuma decisão - trabalho que é marcado como concluído antes da conclusão do teste Uma equipe não precisa de um relatório longo. Três análises específicas são suficientes para começar. Use um sprint como janela de reparo Escolha um sprint e defina uma meta restrita. Uma equipe pode escolher: - cada tarefa tem um proprietário nomeado - cada revisão recebe uma resposta dentro de um dia útil - cada nova solicitação passa por um canal acordado - cada tarefa bloqueada é levantada durante o check-in diário - cada história inclui uma condição de teste clara Um alvo estreito é mais fácil de observar. Também dá à equipe uma maneira justa de avaliar o progresso. Se a equipe tentar reparar a comunicação, o planejamento, a documentação e os hábitos de reunião ao mesmo tempo, as pessoas podem não saber qual mudança ajudou. Prefiro um acordo de sprint simples: > Durante este sprint, cada tarefa tem um proprietário, uma próxima ação e um bloqueador visível. O acordo é pequeno o suficiente para ser lembrado. Também dá à equipe uma linguagem compartilhada quando o trabalho fica mais lento. Tornar a propriedade visível A responsabilidade compartilhada pode parecer saudável, mas muitas vezes cria lacunas silenciosas. Quando todos são donos de uma tarefa, ninguém pode se sentir responsável por levá-la adiante. Cada item de trabalho deve mostrar: - a pessoa que conduz a próxima ação - a pessoa que aprova o resultado - as pessoas que precisam de atualizações - a data ou condição para a próxima verificação Isso não significa que uma pessoa faz cada parte do trabalho. Um designer, desenvolvedor, testador e gerente de produto podem contribuir. Uma pessoa ainda precisa manter o item em movimento. Uma nota de tarefa útil pode ser assim: - Proprietário: Maya - Próxima ação: confirmar a mensagem de erro de pagamento com o suporte - Revisor: Daniel - Bloqueador: aguardando o texto aprovado - Check-in: quarta-feira Este formato ajuda a equipe a ver a lacuna antes do final do sprint. Reparar transferências com um modelo curto As transferências geralmente falham porque o remetente assume um contexto compartilhado. O receptor pode não saber o que mudou, o que resta ou que tipo de resposta é necessária. Utilizo quatro linhas para uma transferência: 1. O que mudou? 2. O que ainda precisa de melhorias? 3. O que a próxima pessoa deve verificar? 4. Que decisão ou resposta é necessária? Um desenvolvedor pode escrever: > O formulário de checkout agora aceita códigos postais com espaços. A mensagem de erro ainda precisa de uma revisão de conteúdo. Teste layouts para celulares e tablets. Preciso de confirmação sobre o texto final. Esta mensagem é mais fácil de agir do que “O formulário está pronto para revisão”. O mesmo padrão funciona em todos os departamentos. Uma equipe de vendas pode transmitir uma solicitação do cliente ao produto. Uma equipe de suporte pode enviar um relatório de bug para a engenharia. Uma equipe de marketing pode compartilhar as alterações da campanha com o design. Crie um caminho claro para bloqueadores Uma tarefa bloqueada torna-se mais cara quando permanece oculta. As pessoas podem contornar isso, iniciar tarefas não relacionadas ou esperar por uma reunião que ocorrerá em vários dias. Defina uma regra de bloqueio visível: - adicione o bloqueador à tarefa - nomeie a pessoa ou equipe necessária para ajudar - indique a próxima ação - levante-a no próximo check-in da equipe - use uma mensagem direta para questões de serviço urgentes A equipe também precisa de um limite de resposta. Esse limite não precisa prometer uma resposta instantânea. Pode dizer: “Se nenhuma resposta chegar até o próximo dia útil, leve o problema ao proprietário do backup”. Em uma empresa de software com seis pessoas, uma tarefa de liberação era aguardada porque a pessoa que poderia aprovar a cópia estava de licença. A equipe havia discutido o texto anteriormente, mas nenhum aprovador alternativo foi listado. Após esse lançamento, a equipe adicionou um nome de backup para tarefas que dependiam de um único tomador de decisão. A mudança não eliminou todos os atrasos. Isso impediu que um tipo comum de atraso permanecesse invisível. Reduza reuniões que não movimentam o trabalho Uma divisão da equipe pode ficar oculta em um calendário completo. As pessoas participam de várias reuniões, mas saem sem decisão, proprietário ou próximo passo. Antes de realizar uma reunião, pergunte: - Que decisão cabe aqui? - Quem precisa comparecer? - O que deve estar pronto antes da reunião? - Onde a decisão será registrada? - Quem é o dono da próxima ação? Uma breve atualização por escrito pode substituir uma reunião quando o tópico precisar de informação em vez de discussão. Uma reunião ao vivo faz mais sentido quando a equipe precisa resolver uma situação difícil ou remover um bloqueador. Ao final de cada reunião, registre apenas três itens: - decisão - proprietário - próxima ação A nota pode caber em uma ferramenta de projeto ou documento compartilhado. As pessoas não deveriam precisar pesquisar em um longo histórico de bate-papo para encontrá-lo. Proteja o sprint contra mudanças silenciosas de prioridade As equipes geralmente perdem o foco quando novos trabalhos chegam por meio de mensagens privadas. Um gerente pode solicitar uma pequena alteração, pode surgir um problema com o cliente ou outro departamento pode solicitar ajuda. Cada solicitação pode parecer insignificante. Juntos, eles podem mudar o plano do sprint. Use um caminho de entrada para novos trabalhos. A solicitação deve incluir: - o motivo da mudança - o resultado esperado - o proprietário - o esforço estimado - o trabalho que pode ser transferido Isto cria uma compensação visível. Se um novo item entrar, outro item poderá precisar sair ou mudar de escopo. Não trato um plano de sprint como uma promessa bloqueada. O trabalho pode mudar quando a razão é forte. A mudança precisa ser vista pelas pessoas afetadas e não adicionada silenciosamente à lista de tarefas de uma pessoa. Analise o sprint com evidências Uma revisão útil do sprint analisa os padrões de trabalho, não apenas os itens concluídos. Verifique: - quantas tarefas foram transferidas - quanto tempo os itens bloqueados permaneceram bloqueados - quantas tarefas mudaram de proprietário - onde as revisões aguardavam - quais solicitações chegaram após o planejamento - quais defeitos vieram de informações faltantes Use os dados como um estímulo para discussão. Uma alta contagem de transferências não prova um desempenho ruim. Pode mostrar que as tarefas eram demasiado grandes, as prioridades foram alteradas ou as aprovações foram lentas. Peça a cada pessoa para compartilhar: - uma prática que ajudou - um ponto que causou atrito - uma mudança para manter no próximo sprint Escolha uma ou duas mudanças. Uma equipe precisa de tempo suficiente para tornar normal um novo hábito. Fique atento a um erro comum Algumas equipes respondem às falhas adicionando mais processos. Eles criam formulários extras, reuniões mais longas, mais campos de status e cadeias de aprovação mais amplas. O trabalho se torna mais fácil de rastrear, mas mais difícil de concluir. Um teste melhor é simples: > Esta etapa ajuda alguém a tomar uma decisão, concluir uma tarefa ou remover um bloqueador? Se não fizer nada disso, a equipe pode não precisar dele. Um sprint saudável não significa que todas as tarefas sejam concluídas sem dificuldade. Isso significa que a equipe pode ver os problemas mais cedo, discuti-los sem culpa e dar a cada problema uma próxima ação clara. Quando trabalho com uma equipe que parece dispersa, não começo com um grande plano de transformação. Procuro uma transferência interrompida, um proprietário pouco claro ou um bloqueador oculto. Reparamos esse ponto durante o próximo sprint, verificamos o que mudou e usamos o resultado para escolher o próximo reparo. Pequenas mudanças tornam-se úteis quando a equipe consegue vê-las, repeti-las e ajustá-las em conjunto. Contate-nos em Tina Xing: ms.xing@sprintstartergen.com/WhatsApp +8618351687794.

Referências Jeff Sutherland 2014 Scrum A arte de fazer o dobro do trabalho na metade do tempo Ken Schwaber e Jeff Sutherland Novembro de 2020 O Guia Scrum Project Management Institute 2021 Um guia para o corpo de conhecimento em gerenciamento de projetos Guia PMBOK Sétima edição Amy C Edmondson 2018 A organização destemida Criando segurança psicológica no local de trabalho para aprender inovação e crescimento Atul Gawande 2010 O Manifesto da lista de verificação Como obter As coisas estão certas John Moubray 1997 Manutenção centrada na confiabilidade, segunda edição