Como deixar de cometer erros tontos no trabalho?

Três coisas vão ajudá-lo a ser mais preciso:

• utilize listas de verificação e procedimentos (escreva os seus próprios) e siga-os. Inclua passos como “verificar duas vezes qual o servidor que está a visar”. Quando as consequências de um erro forem altas, imprima realmente a lista e verifique as coisas com uma caneta à medida que avança.
• quando a tecnologia o ajudar, tire um momento para verificar. Digamos que o seu cliente de e-mail preenche a linha To depois de digitar a primeira letra. Não escreva apenas a letra e clique em Enviar. Pare e olhe e veja o que preencheu.
• sempre que cometer um erro, pergunte-se porquê. Que passo é que saltou? Para que não olhou? Porque é que a coisa certa e a coisa errada se assemelhavam tanto? Como poderia ser mais fácil ter a certeza de que o está a fazer bem? **Com o tempo, irá desenvolver hábitos e processos que garantem que está a fazer as coisas correctamente. Na verdade, é mais ou menos isso que a experiência é.

Como deixar de cometer erros bobos no trabalho?

Você tem um problema de qualidade no trabalho e precisa de um sistema para descobrir erros, a fim de criar um feedback adequado para melhorar/desenvolver procedimentos pessoais e hábitos de trabalho. A melhoria da qualidade tem a ver com o desenvolvimento de mecanismos para descobrir erros e a causa dos mesmos, desenvolvendo depois um plano de acção para os corrigir.

Passo 1: Reconheça que os erros não são “tolos” - são graves. Você pode perder o seu emprego por causa deles. Penso que um grande indicador do seu problema é que estes parecem ser coisas fáceis de evitar, e mesmo assim continua a fazê-los. No entanto, ao não os prevenir, tem um problema grave.

Passo 2: Abrande. Muitas vezes os programadores e engenheiros “rock star” são vistos como os que se movem rápido e furiosos - nada os detém! A realidade é que eles não são assim. Há situações em que isso acontece, mas há muitas situações em que isso não é verdade. Pare de se sentir apressado, respire fundo e baixo.

Passo 3: Antes de “terminar” alguma coisa, pare e faça uma pausa, depois volte a ela e reveja. Tome um café, leia um e-mail, ou algo que não o distraia muito, para tirar a sua mente da tarefa em mãos e assim terá uma nova perspectiva quando voltar a ela. Poderá sentir que isto o vai atrasar ou reduzir a sua produtividade. No entanto, esta abordagem permite-lhe detectar erros precocemente, o que é importante para ser produtivo. Por isso, antes de clicar em “enviar” - leia outro e-mail ou verifique o estado de um servidor ou algo assim. Isto não se trata apenas de escrever código.

Passo 4: Quando encontrar um erro, não se limite a corrigi-lo. Tire um momento para tentar perceber porque é que o erro ocorreu. Para onde se apressa? Copiar/colar o erro? Confiança no trabalho ou opinião de outra pessoa? Isto irá ajudá-lo a estar mais consciente da causa dos erros ** no momento em que eles ocorrem***. Descobrir mais tarde não é muito útil, como sabe.

Passo 5: Acompanhe o seu progresso. Preste atenção à utilidade dos seus novos hábitos e práticas. Guarda uma folha de cálculo para contar erros ou problemas que encontraste depois de fazeres uma pausa. Nota também se uma descoberta impediu algo que teria irritado o teu chefe ou que teria sido embaraçoso. Isto desenvolve a tua capacidade de auto-avaliar melhor a aceitabilidade do teu próprio trabalho e também de tentar aprender que hábitos são mais eficazes.

Passo 6: Desenvolve procedimentos e listas de verificação (ou actualiza as já existentes) onde vês padrões a emergir das tuas observações acima. Não pode desenvolver listas de verificação ou procedimentos para tudo, por isso após algum tempo (ou mesmo bastante rapidamente) encontrará padrões de erros onde pode criar um método reprodutível para prevenir certos tipos de erros. Isto só é útil para tarefas frequentes que são complexas. Caso contrário será tentado a não verificar a lista, não a manter actualizada ou poderá fazer mais listas e procedimentos do que aqueles que consegue gerir, tornando-os obsoletos e desactualizados - possivelmente levando a mais erros.

Tente abordagens diferentes para descobrir onde estão os seus erros antes que estes se tornem problemas. Embora muitas das respostas aqui se concentrem no desenvolvimento de processos/procedimentos/listas de verificação (especialmente em torno do desenvolvimento de códigos), a premissa da “gestão da qualidade” ou “melhoria da qualidade” tem a ver com a detecção de erros como meio de feedback para o desenvolvimento e/ou melhoria de processos. Não se pode desenvolver um processo “melhor” se não se conhecer a causa dos erros. Trabalhe para descobrir a causa dos erros Muito provavelmente está apenas a apressar-se e não a “verificar duas vezes” o seu trabalho. Estas são algumas dicas para tornar um ritmo mais lento e mais produtivo.

Parar de Trabalhar. É a única maneira de parar de cometer erros.

Não, a sério: Vais sempre cometer alguns erros. Isso faz parte de ser humano (o que eu sinto que é seguro supor que você é). Qualquer desenvolvedor profissional vai produzir trabalho com algum número de bugs, e não há problema. Esta é a razão pela qual temos coisas como o Desenvolvimento Test Driven, Testes Unitários e Departamentos de Qualidade. Se o seu gestor está à espera de um software sem bugs na primeira passagem, então não está a lidar com expectativas razoáveis.

Dito isto, vivemos num mundo onde não podemos parar de trabalhar só porque os erros acontecem, por isso tomamos medidas para reduzir o risco de erro. Eu trabalho numa loja de fabrico, por isso a palavra de ordem é Poke-yoke (literalmente japonês para Mistake-Proofing); que é um processo automatizado concebido para eliminar o erro humano. Isto significa automação. Eu definidamente* recomendo a passagem para um processo de construção automatizado para a instalação de software na produção. Isto exigirá o envolvimento de mais do que apenas um desenvolvedor, mas vale a pena ir o mais longe que puder.

Onde não se pode automatizar, leve o seu tempo. Muitos erros podem ser evitados se for preciso tempo para rever antes de cometer uma acção. Dedique um minuto a rever o seu código antes de cometer alterações. Passe o minuto extra para rever e-mails antes de pressionar o botão Send.

Finalmente, não tenha medo de pedir ajuda. Como programador, uma das minhas primeiras acções ao encontrar um bug é pedir a um colega de trabalho de confiança para dar uma vista de olhos. Um novo conjunto de olhos pode ver todo o tipo de problemas que você inconscientemente filtrou para fora. E se não tiveres um colega de trabalho de confiança, procura um novo emprego; parece que és um desenvolvedor de nível júnior/médio e precisas de um sistema de apoio para cresceres como um desenvolvedor. Ter outros programadores de software a quem lançar ideias não é uma parte opcional do teu desenvolvimento como Programador Profissional de Software.

Em resumo: Automatiza sempre que possível, leva o teu tempo quando não for possível, e não tenhas medo de pedir ajuda.

Não, não vai eliminar os erros. Mas talvez consiga apanhar os erros mais importantes. É importante estar consciente do que está a fazer e procurar formas de o fazer com mais segurança.

Identificar os esforços arriscados. Não se pode estar atento a cada segundo do dia - mas todos cometem pequenos erros durante todo o dia. A maioria dos erros pode ser corrigida sem esforço, por isso, melhore ao reparar quando algo tem potencial para correr mal de uma forma que não pode ser tão facilmente corrigida. Qualquer comunicação com um cliente, qualquer implementação para um site, qualquer mudança global para um documento, etc.

Question o que está a fazer. Compreende o que está a fazer, porquê, e como? Isto pode ser feito de forma mais segura? Tem a certeza que é melhor fazê-lo do que não o fazer?

Pausa antes de avançar com esforços arriscados. Não envie um e-mail sem verificar os destinatários, o assunto, o conteúdo e os anexos. Um a um. Leve o seu tempo. Enviar um orçamento para o Cliente A para o Cliente B pode perder ambos os clientes. É melhor passar um minuto ou mais a verificá-lo. Não se sinta tentado a apressar, mesmo em ‘emergência’.

Disponha um plano de recuperação. Saiba antecipadamente o que vai fazer se algo correr mal. Prepare-se para que, se precisar de corrigir o seu erro, o possa fazer rapidamente - mas sem se apressar. Como vai saber se fez algo de errado? Existe uma forma de descobrir mais cedo?

Documento qualquer coisa que tenha muitos passos. Se tem documentação, siga-a como uma lista de verificação para poder saber se é suficientemente boa ou se está desactualizada, incompleta ou defeituosa. Mesmo que o faça apenas uma vez - antes de escrever o seu relatório, escreva uma lista de todas as coisas que precisam de entrar.

Track too-dos especialmente se o esquecimento for um problema. Qualquer coisa que precise de fazer e não esteja a fazer _ agora mesmo_ deve entrar lá. Rastreie-os a todos de uma só vez e volte à sua lista de afazeres. Não confie em notas post-it dobradas e guardadas no seu bolso de trás.

Automate sempre que possível. Se tem uma lista de cinco coisas para escrever, pode escrever um programa para fazer essas cinco coisas e depois só tem uma coisa para se enganar? Se está a fazer software, pode fazer testes automáticos para detectar erros quando introduzir bugs? Pretende uma cobertura a 100%? Você testa com o objetivo de quebrar o seu código? Tem uma integração contínua para não ter de se preocupar em esquecer de executar testes?

Ask para uma segunda opinião se está a fazer algo arriscado que não consegue verificar e do qual não consegue recuperar facilmente. É uma prática comum para software que o código é sempre testado por outra pessoa antes de ser aceite.

Aprenda*. Cada erro cometido é uma oportunidade de rever o processo.

Toma conta de ti*. Encontre tempo durante o dia para limpar a sua mente e tenha alguns minutos de silêncio ou relaxamento. Antes do trabalho, depois do trabalho, pausas para almoço, etc. Durma o suficiente. Coma regularmente e de forma saudável.

É claro que nunca será perfeito, mas há formas de melhorar a precisão. O melhor curso que penso é introduzir procedimentos adicionais que não sejam apenas a dupla verificação do seu próprio trabalho, pois as pessoas são naturalmente propensas a cometer pequenos erros. Não é muito provável que apanhe este tipo de coisas apenas por “ser mais cuidadoso” ou “verificar duas vezes”, por isso, tentar apenas isso está a colocar-se no caminho do fracasso. Algumas sugestões específicas:

1. Testes unitários. Com testes unitários adequados, sempre que fizer uma alteração ao código, execute os testes em tudo, e isso irá verificar se introduziu inadvertidamente um bug.

2. Melhor procedimento de implantação. Implante primeiro num servidor de encenação, usando os comandos exactos que usaria para o prod, e verifique se a implantação está correcta, antes de ir para a produção.

3. Exceptuando os testes unitários, reserve tempo em cada implementação, uma vez que acredite que está feito, para passar pela sua compilação e testar o máximo que puder novamente. Não se limite a testar as áreas que pensa ter mudado.

Sempre que cometer um erro, tente pensar em soluções neste sentido, para estabelecer salvaguardas contra erros humanos naturais, e apresente estas ideias ao seu chefe.

Trabalho como engenheiro/arquitecto de software há mais de 10 anos, e posso dizer com toda a certeza que nunca eliminarão todos os erros. O melhor conselho que lhe posso dar é determinar quais as tarefas de maior risco e tomar medidas para mitigar esse risco.

1. Na maioria das vezes, enviar um e-mail para a pessoa errada não é um grande problema. Não sei dizer quantas vezes recebi um e-mail destinado a um dos outros Jennings que trabalham aqui. Mas se está a enviar um e-mail que pode conter informação sensível, leve sempre tempo a verificar os destinatários e o conteúdo.
2. Se está a escrever um documento importante, escreva uma lista de verificação do que tem de estar nele e verifique duas vezes o conteúdo antes de o enviar.
3. Para a implementação de builds, utilize sempre um processo automatizado e, se possível, instale primeiro no servidor secundário. A minha equipa implementa os nossos serviços Ruby para um servidor secundário, testa e depois passa o servidor secundário para o primário. Se houver algum problema nesse ponto, podemos sempre voltar para o servidor antigo. Se nenhuma destas coisas for possível, isso acarreta um risco muito maior, por isso o meu conselho é que gaste mais tempo e atenção à tarefa. Duplique e triplique a verificação de tudo para cada passo que acarrete um elevado nível de risco.
4. Para bugs em código, certifique-se de que está a escrever bons testes de unidade/integração que cobrem fluxos de trabalho normais e casos de borda. É uma boa ideia certificar-se que o projecto como um todo tem a maior cobertura de testes unitários possível para garantir que se mudar alguma coisa que quebre alguma outra coisa, um teste unitário irá falhar e você irá apanhar o bug mais cedo. Isto não vai apanhar todos os erros, mas é um bom começo. Assim que o código estiver pronto para o teste da caixa negra, não teste apenas o fluxo de trabalho em que o seu código toca, analise que outras partes do projecto o seu código pode ter impactado e teste também esses fluxos de trabalho. O teste da caixa negra também deve abranger tanto os casos normais como os casos de borda.

Fora disto, eu diria apenas para gastar mais tempo e atenção a tarefas de maior risco do que normalmente gastaria em tarefas do dia-a-dia.

Quão bem documentados são os processos que tem? Por exemplo, implementar a compilação errada no servidor ao vivo parece ser um erro grave que deve ser minimizado através de verificações redundantes para garantir que a compilação X vai para o servidor Y, enquanto o software pode ter bugs no código, uma vez que as coisas podem não ser apanhadas tão facilmente. Eu ficaria tentado a criar soluções e propô-las ao chefe para que alguns erros possam ser evitados no futuro. Esteja ciente do que pode querer verificar algumas vezes e do que pode não ser assim tão bom para fazer um monte de verificações.

Infelizmente, você é humano e, portanto, os erros ** irão** acontecer. A perfeição raramente é atingida, pois mais do que alguns dos chamados grandes do desporto falharam o remate vencedor do jogo como Michael Jordan. Se você quer que algumas terapias olhem para a Terapia de Comportamento Cognitivo, Terapia de Comportamento Dialetal, assim como a Terapia de Aceitação e Compromisso que seria usada para combater o padrão de pensamento negativo que você tem aqui de querer ser perfeito. Os erros vão acontecer, a chave é considerar como responder a eles e quão boa é a sua inteligência emocional como auto-consciência e auto-gestão pode ser algo mais a estudar se quiser outra ideia.

Para algo documentado, eu consideraria actualizar a documentação e adicionar mais verificações que podem ser úteis para o material importante. De certa forma, isto é semelhante a pessoas que sugeririam esperar alguns segundos antes de rever uma mensagem de correio electrónico que queira enviar, para que não tenha erros de digitação que possam ser uma dica útil em alguns casos.

Estou no mesmo barco que você em alguns casos, mas sou de um passado diferente. Quando pressionamos o código ao vivo no meu antigo emprego, tínhamos processos automatizados em vigor. No novo emprego, infelizmente, não podemos pôr em prática processos automatizados. Como tal, sinto falta de pequenos detalhes aqui e ali que não deveriam ser. O meu gerente é muito mais simpático, mas decepcionado.

Em todo o caso, eu próprio melhorei ao certificar-me primeiro de escrever os passos num bloco de notas. Asseguro-me que tenho a lista de ficheiros que quero empurrar para cima, e verifico duas vezes antes de o fazer. Também tenho um procedimento mental do que vou fazer antes de o fazer. Isso ajuda. Finja que o está a fazer antes de o fazer para não se esquecer de nada.

Gostaria também de acrescentar que deve falar com o seu gestor. Um a um e explicar-lhe que gosta de melhorar e delinear como gostaria de o fazer. Explique que lhe faltam alguns pequenos detalhes aqui e ali e que gostaria de melhorar. Talvez ele possa dar sugestões, mas eu diria que se ele está a ameaçar despedi-lo por causa de pequenos pormenores, isso é algo que terá de considerar e para o qual terá de se preparar.