Sobre criar software e as políticas de repressão de criatividade
Ao assistir um talk do Greg Young sobre o evitar o “over-engineering” em projetos de software, notei um ponto muito interessante que pode ser chocante para empresa mais tradicionais:
“Vamos fazer um acordo: nós desenvolvemos as funcionalidades em 2 meses e vocês, usuários, se comprometem a usar o sistema. Tudo o que for encontrado para ser feito pode ser lançado como bug!” O talk está aqui e vale muita a pena ver:
https://www.youtube.com/watch?v=GRr4xeMn1uU
Comecei a refletir sobre esta estratégia e percebi que eu, intuitivamente, muitas vezes toquei projetos usando esta metodologia extremamente ágil e objetiva de desenvolvimento. Através de uso de prototipação rápida, testes integrados usando dados simulados e reais e foco exclusivo no que o cliente realmente precisa, quase sempre consegui criar software que foi pra produção nestes últimos anos.
Mas claro que também tive contato com o inferno dos métodos ágeis, conheci o inferno das políticas de medição de performance da equipe, vivi de perto o assédio moral de scrum masters e GPs achando que tudo é fácil e certamente sei que o que o Greg prega acima não funcionaria nas empresas GPTW e similares deste país.
Numa dessas oportunidades, eu estava contratado como o líder da equipe de um projeto que por si só já era uma merda de projeto, com uma merda de cliente e uma merda de situação técnica. Mas ainda assim, como era CLT e no momento tinha alguma coisa a perder caso não continuasse no emprego, resolvi tentar.
Em empresas mais organizadas e cheias de processos sérios e ferramentas de primeiro mundo, o desenvolvimento de um software geralmente tem toda uma cerimônia e um planejamento decente. Vai um analista para o cliente ver o que precisa ser feito, traz os requisitos mastigados, distribui o que precisa ser feito para o arquiteto ou algum dev mais esperto “groomar” (detalhar tecnicamente o que fazer/como fazer) e formalizar as user stories, itens de backlog e todo aquele inferno confuso. Nisso há uma reunião para que o time determine quanto tempo demoraria para fazer tal funcionalidade. Logo já há um primeiro instrumento de pressão comum: sempre haverá um babaca que dirá, no planning poker, que a atividade é exequível em bem menos tempo que o real. Acabei batendo de frente com a equipe de losers que eu me encontrava, porque afinal, não tinha nada claro no documento dizendo, justamente, como seriam feitas muitas coisas. E claro, os requerimentos sequer estavam estáveis. E o juninho acompanhado do pleninho vai lá e diz que consegue fazer uma procedure (vejam bem a situ: PRO CE DU RES!) em duas horas. Ok. O scrum master de merda começou a me odiar a partir daquele momento (na verdade ele ganhava uma miséria de salário e eu não — motivo bom pra ser odiado né!) justamente porque eu passei a ser o chato a dizer que nem tudo pode ser feito em tão pouco tempo.
Comecei a sprint com aquela alegria de quem espera a vez para ser enrabado sem dó. Com aquele time contra mim, com o scrum master começando a pegar no meu pé, comecei a fazer as entregas. Eu havia “groomado” uma parte das especificações e claro, como era uma parte menos integrada do que o resto, foi mais tranquilo e consegui usar uns conceitos inteligentes para montar um sistema de processamento de regras de negócio. É claro que ficou show. É claro que todo mundo conseguiu programar e fazer funcioanar corretamente. É claro que eu fui elogiado pelo cliente no meio da reunião com todos que me odiavam. É claro que isso irritou mais o time. E também é claro que nunca recebi um feedback positivo daquele job. E obviamente, nem tudo coube na sprint. E obviamente teve juninho trabalhando de graça em casa para tentar entregar.
Nisso o tempo foi passando e eu fui desenvolvendo também. E aí o canhão virou contra mim. Fui vítima do assédio mais comum que existe no desenvolvimento, entrando em mais um ponto da política de repressão: entreguei uma funcionalidade para testes e ela voltou com bugs. O scrum master começou a me criticar dizendo que eu estava entregando itens sem testes. Começou a encher o meu saco e o que aconteceu? A porra toda piorou. Meu psicológico acabou desestabilizado por causa dos crescentes assédios morais que começaram a acontecer. Os bugs começaram a acontecer cada vez mais e eu, como o sênior, para eles, não era mais que um desenvolvedor falastrão, tão bom quanto qualquer pleninho desta conhecidíssima empresa brasileira. E isso acabou me desestabilizando emocionalmente cada vez mais. É algo como ser um Michel Bastos no São Paulo, no fim de 2016.
Entretanto, meu espírito interno sempre prezou buscar o que a gente realmente precisava como sistema, como projeto e etc. Como o sistema era a materialização de um fluxo relativamente complexo, com várias e várias partes se comunicando entre si, vi que os bugs que neste momento afetavam toda a equipe eram mais do que simples incompetência e falta de testes do programador: a visão sistêmica do fluxo estava comprometida porque havia um mar de procedures complexas que chamavam outras procedures e por aí vai. O que eu fiz? Resolvi colocar, por conta própria, uma estrutura de logs para registrar as chamadas das procedures e seus argumentos, com o objetivo de entender melhor os fluxos e corrigir os bugs mais rapidamente.
Resultado, caí em mais uma forma de repressão: ao invés de ser elogiado pela iniciativa e aumento da visibilidade dos processos, fui duramente criticado em uma reunião de feedback por este scrum master porque eu deliberadamente coloquei o projeto em risco ao introduzir um novo ponto de falha, sem falar com ninguém. Sim, era verdade. Na minha visão, software também é assumir riscos para ter ganhos e como sênior da equipe, eu *achei* que tinha liberdade e autoridade técnica para melhorar o que precisava ser melhorado e não tinha tantos riscos. O fato de eu conseguir provar que ‘minha parte estava ok’, e conseguir apontar o erro rapidamente acabou sendo inesperado para eles. A cada bug que aparecia, meu nome era o culpado porque o sistema sempre chamava minha procedure para qualquer coisa. Eu consegui sobreviver alguns dias à “culpocracia”. Nessa empresa que tanto preza a individualidade e o trabalho em equipe, a situação ficou chata. Uns culpavam a qualidade do grooming; outros criticavam o desenvolvimento; outros criticavam as mudanças de escopo dentro da sprint. Tudo tinha uma culpa e a culpa só não poderia ficar comigo — percebi que minha vida na empresa dependia de fugir da culpa e por conseguinte, tentar foder o cara que efetivamente errou. Nojento. Só fiz a primeira parte, que é evitar assumir o erro. Não fiquei apontando culpados. Fui homem.
Alguns dias depois o scrum master mandou tirar os logs, mandou refazer as procedures e ainda disse que o meu “erro” havia prejudicado o projeto em meio período de 3 pessoas. Por quê? Porque o log tinha dado erro numa situação esotérica. Eu fui novamente criticado duramente, chamaram o arquiteto e ouvi bosta por quase uma hora. Foi meio chato né?
O resto vocês já sabem. Eu rodei e o projeto até agora não foi para produção. Eles continuam ganhando seus 3 a 5k e eu to ganhado bem mais do que 10k hoje em dia.
O ponto principal do texto é que infelizmente esta política de criminalização do bug e da escravização do desenvolvedor para que sempre trabalhe correndo (porque o juninho disse que faria em 2 horas!) acaba minando a criatividade dos bons programadores. Se você não tem tempo para pensar adequadamente na solução, se você tem horários rígidos, se você não tem possibilidade de home-office, se você tem um Jira te assustando e escravizando o tempo todo, se você tem scrum master agressivo minando as tuas iniciativas, se você tem um status quo focado em concorrência interna, carreirismo e planilhas de performance, a sua capacidade de criar coisas que realmente façam sentido para o cliente são nulas. A sua felicidade estará em jogo e você sempre começará perdendo o jogo de 7 a 1.
As empresas modernas, cheias de video-games e outras distrações estúpidas simplesmente não entendem como funciona o processo criativo de desenvolvimento do software. Muitas vezes o trabalho com um tempo rígido para um task acaba forçando o programador a criar um software ruim para que funcione no prazo. Muitas vezes o prazo é tão curto que onde antes havia uma chance de criar uma coisa bacana acaba se tornando mais um sistema legado neste mundo, cheio de bugs, débito técnico e necessidade de times grandes de manutenção.
Não caia nessa. Se você é apenas uma peça na linha de produção, se é apenas um recurso a criar telas rápido, se é apenas um arrastador de cards na lousa, repense rapidamente a tua carreira. Alguns dinheiros não podem ser o custo da tua felicidade. Mude de projeto, de time, de empresa ou de área. Ter satisfação no emprego e chances de criar algo relevante para o mundo ainda vale muito mais do que ser um número de dentro de alguma empresa, a jogar video-game a esmo e a esperar um aumento de 500 reais de vez em quando, como merda a girar no vaso. Não desconte tuas frustrações comendo, bebendo ou mesmo, se drogando.
Busque projetos e empresas onde possa errar livremente. Um bug é apenas um bug. Uma melhoria também pode ser considerado como bug.Priorize o que é importante. Erre. Erre muito. Pegue logs e estatísticas sobre como os usuários usam o sistema. Acompanhe-os durante o uso diário. Simplifique a vida deles. Não tente ou aceite automatizar 100% do domínio. Resolva 80% a 90% dos casos e seja feliz junto com o usuário. Não tenha medo de errar. Crie. Pense. Inove. Sonhe. Faça com que seu cliente se senta feliz em ter seu time à disposição.
Hoje estou numa empresa muito, muito foda. Temos um clima agradabilíssimo, sem concorrência interna, com liberdade e amplo trabalho em equipe real. Não tenho medo de pedir ajuda, ajudo sempre que me chamam, ouço conselhos e peço conselhos e almoçamos juntos sempre que possível. Até tem o video-game, até tem refrigerante e cerveja liberado para todos e até tem benefícios. Mas para mim, o maior benefício é ter uma galera que está junto comigo, disposta a estudar e evoluir sempre, buscando criar soluções bacanas e corretas para nossos clientes.
