Merge pull request #21 from mrbrunelli/new-post

New post

blog/2023-10-04-nao-espere-um-ambiente-favoravel-para-fazer-algo-com-qualidade/index.md

@@ -0,0 +1,79 @@
+---
+slug: nao-espere-um-ambiente-favoravel-para-fazer-algo-com-qualidade
+title: Não espere um ambiente favorável para fazer algo com qualidade
+description: Como fazer um excelente trabalho, mesmo quando o ambiente é desfavorável?
+keywords: [carreira, dicas, qualidade, testes, negociar, prazos]
+image: /img/peace.jpg
+tags: [carreira, dicas, qualidade, testes, negociar, prazos]
+authors: brunelli
+---
+
+Já ouviu essa frase alguma vez?
+
+> "eu até queria fazer algo melhor, mas o pessoal passou um prazo curto e falou pra deixar os débitos para depois"
+
+Pois é, bem chato né? Só que na maioria das vezes que isso acontece, a culpa é sua!
+
+<!-- truncate -->
+
+## Frustação
+
+Essa é uma das frases mais comuns no trabalho, e ela é carregada de frustração, seja por não conseguirmos entregar algo relativamente bom, ou por sempre estarmos trabalhando sob pressão de **prazos malucos, que as vezes nós mesmos damos**.
+
+Hoje eu gostaria de compartilhar como eu consegui erradicar esse tipo de frustação da minha rotina de trabalho, e como isso tem mais a ver com **inteligência emocional** do que conhecimento técnico\*.
+
+### Um ciclo interminável
+
+Eu já fiz muito trabalho com qualidade duvidosa, e sempre vivia mal com isso, porque eu acabava tendo que refazer o trabalho, porque não tava tempo de entregar a feature **devidamente validada**.
+
+Desde a época de faculdade eu já me interessava por **programação orientada a objetos** e **testes automatizados**, isso pra mim era trabalhar com **inteligência e eficiência**, entretanto isso era muito difícil de aplicar no trabalho, porque todo mundo sempre estava apagando incêndios e remendando coisas.
+
+E como o _modus operandi_ do caos é mais caos, esse ciclo nunca tinha fim. Eu fazia um remendo, e logo o remendo arrebentava, necessitando um novo remendo.
+
+## Inteligência emocional
+
+Algo que aprendi com a experiência e com ótimos mentores, é que o caos começa da nossa própria negligência. Se tudo é prioridade, logo nada é prioridade.
+
+Com o tempo comecei a perceber que as pessoas que estavam acima de mim também não sabiam o que estavam fazendo, e talvez as pessoas acima delas também não, e isso é muito comum em uma organização.
+
+### Questionar é o começo
+
+Quando passei a questionar as demandas que chegavam para mim, sem medo de levar carteirada _(algumas vezes levei carteirada)_, percebi que muita coisa era descenessária para o negócio, e que haviam coisas mais importantes à serem priorizadas.
+
+Isso resolveu uma parte da frustração, pois discutindo mais sobre os problemas o time todo passou a compreender melhor as reais necessidades do negócio.
+
+**Questionar deveria ser um comportamento natural de um engenheiro**, já que muito tempo será despendido para realizar uma feature, que no final das contas poderá ser inútil para o cliente.
+
+### Lidar com prazos e requisitos não funcionais
+
+Na maioria das vezes que o time de engenharia negocia os prazos, eles não fazem ideia do que terão que fazer, logo o prazo vira um chutômetro.
+
+Outro cenário é quando o time não sabe interpretar os **requisitos não funcionais**, como boa **abstração de código, arquitetura coesa, documentação e testes automatizados**.
+
+Entenda, para o cliente é importante a feature de valor, isso gerará caixa para o negócio. Mas para essa feature de valor ser sustentável, ela precisa ter os pontos dos requisitos não funcionais que citei acima.
+
+O cliente não precisa de testes automatizados ou documentação técnica, **mas você precisa**. Só é possível evoluir um sistema, sem efeitos colaterais, se ele estiver com uma boa abstração, bem documentado e coberto por testes. Do contrário ficará cada vez mais difícil garantir a qualidade das features que virão.
+
+### Negocie melhor
+
+Portanto, mude seu discurso de _"a task sem os testes ficará pronta em 12 horas de trabalho"_ para _"a task ficará pronta em 16 horas de trabalho"_. Coloque na sua estimativa de trabalho todos os requisitos, inclusive os **não funcionais**.
+
+Hoje com essa abordagem, imbutindo todos os requisitos não funcionais no prazo, eu consigo realizar meu trabalho com muito mais prazer, consigo fazer um código com uma abstração decente, com testes automatizados e ainda entregando no prazo combinado.
+
+## Invertendo o ciclo
+
+Agora as novas features serão desenvolvidas com menor tempo, já que o código estará mais modular, e com as regras de negócio validadas com testes. Logo, terei mais folga, e poderei refatorar aqueles trechos legados e bisonhos e adicionar cobertura de testes a eles também.
+
+Os bugs natualmente irão diminuir, e agora não precisarei fazer remendos sem fim, isso é trabalhar com inteligência, **fazer menor esforço e alcançar um resultado melhor que antes**.
+
+Invertendo esse ciclo, os deploy não serão mais um caos, com hotfix pra todo lado (isso é bizarro) e todos em uma sala de guerra com o stakeholder no cangote. Essa é uma forma amadora de trabalhar, e muito estressante para todos.
+
+## Conclusão
+
+Se ficarmos esperando as pessoas acima de nós terem essa maturidade, nosso trabalho sempre será um inferno, e nós só vamos criar engenhocas e códigos descartáveis e inúteis que terão que ser reescritos.
+
+\*Eu disse lá no começo do post que isso tem mais a ver com inteligência emocional do que com capacidade técnica, pois eu estou aceitando o fato de que você já saiba fazer o seu trabalho bem, mas que por motivos não técnicos, acaba sempre frustrado.
+
+Porém **se você ainda não compreende a importância de se ter um código bem testado**, com um bom design e documentado, essa inteligência emocional que mencionei será inútil para você.
+
+Se esse é o seu caso, se dedique primeiro a aprender coisas que realmente importam, e busque avançar em sua senioridade, e então esses outros pontos que explanei aqui farão sentido pra você.