-
@ Bolsonitro Ucrânia 🇺🇦🇻🇦
2024-10-08 13:42:23O capítulo 2 tem um ótimo título: "Dizendo não". O autor argumenta que profissionais dizem a verdade, e isso inclui dizer "não" a seus gerentes. Isso é interessante, dado o fato de que essa é uma palavra não usual para brasileiros, que costumam usar frases como "vou ver e te aviso" ou "vou tentar" em vez de dizer simplesmente "NÃO" — E o autor vai nessa linha do "vou tentar" em vez de dizer "não" para coisas que serão impossíveis.
E como papéis são contraditórios, gerentes vão sempre querer o máximo de trabalho no menor prazo possível, e os desenvolvedores devem saber dizer "não", mesmo quando pressionados. Negociar com os gerentes pode ser uma forma de obter o melhor resultado para ambas as partes, entregando uma demo incompleta, por exemplo, desde que isso tenha sido acordado entre ambas as partes.
O autor também argumenta que isso não deve gerar uma cultura de "nós" contra "eles", pois ambos estão defendendo seus interesses; cabe a nós desenvolvedores defender os nossos.
Todos nós já escutamos sobre o quanto é importante saber trabalhar em equipe. Isso significa desempenhar seu papel da melhor forma possível e ajudar seus colegas quando estiverem com problemas. Aquele que sabe trabalhar em equipe se comunica frequentemente, mantém o olho nos colegas e executa suas responsabilidades da melhor forma.
E o mais importante: Não existe a palavra “tentar”, ou é sim, ou é não, o “vou tentar” vai ser aceito como um sim, e será uma mentira caso o desenvolvedor saiba que nada de diferente para acelerar a entrega será feita.
Ao prometer “tentar”, estará se comprometendo com o fracasso.
E para dar um exemplo, o autor reproduz um blog post "Is Good Code Impossible?" inteiro de John Blanco no livro, onde um desenvolvedor vai aceitando demandas, codando com grandes sacrifícios (horas extras e um código ruim sendo escrito) conforme o escopo do projeto vai aumentando. Ele concordou com tudo, tentando ser um herói em busca de reconhecimento por ter feito uma entrega tão grande em tão pouco tempo.
No final, no dia do aplicativo entrar no ar, o cliente da empresa disse: "Desistimos da ideia, pode tirar o aplicativo do ar." Realmente, ele deve ter ficado com cara de palhaço 🤡 nessa.
Então o autor começa a discorrer sobre esse blog post, questionando de quem seria a culpa. Do cliente? Da empresa? Ou dele mesmo? Porque o cliente procurou a empresa buscando quem entregasse o projeto em duas semanas, a empresa concordou, e ele concordou com esse prazo dados os requisitos iniciais. Porém, o escopo foi aumentando e, ao ver que seria necessário um grande sacrifício, ele deveria ter dito NÃO.
E porque Jhon fez isso? Ele nos diz em termos incertos: “Apertei enviar, recostei na cadeira e, com um sorriso amarelo, comecei a fantasiar como a empresa me carregaria em seus ombros e faria uma procissão ao longo da Av. 42, enquanto eu era coroado como o ‘Maior desenvolvedor de todos os tempos’”
Resumindo, Jhon estava tentando ser herói, Viu uma chance para ser louvado e foi atrás dela. Ele se inclinou e agarrou a coroa.
Porém, como argumenta o autor, profissionais não tentam ser heróis, eles tornam-se heróis ao fazer seu trabalho bem feito, dentro do prazo e do orçamento possíveis, sem tentar "salvar o dia".
Isso inclusive me faz refletir sobre uma experiência pessoal, onde o CEO e CTO da empresa estavam no cangote do tech lead da minha squad, ansiosos pela entrega rápida de um projeto. Estávamos fazendo horas extras e trabalhando de domingo a domingo, até que, para garantir a entrega na data que queriam, começamos a negligenciar a qualidade e pequenos bugs, e seguimos codando. Quando finalmente terminamos, deixamos disponível para homologação pela área de negócio. Do jeito que o tech lead estava sendo cobrado, imaginamos que seria homologado rapidamente, enquanto trabalhávamos nas correções dos pequenos bugs que ficaram no sistema e já partíamos para outros épicos que também deveriam ser feitos (nunca falta backlog).
Pois bem, o projeto só começou a ser homologado pela área de negócio dias depois, e só foi dado o OK para a subida em produção duas semanas depois. Ou seja, era uma hard date que na verdade não era uma hard date; poderíamos ter trabalhado de forma mais tranquila. E parece que até hoje o tech lead é meio que lembrado sobre como o projeto poderia supostamente ter sido entregue antes, quando não poderia — era simplesmente muita coisa, mas para quem está níveis acima do chão de fábrica, tudo parece "fácil".
Como o autor do blog diz e o autor do livro concorda:
[...] cada recurso que um cliente pede será sempre mais complexo de ser escrito do que explicado.
Em resumo, a lição do autor e do blog post é clara: ao tentar ser um herói e aceitar prazos e demandas irrealistas, o resultado pode ser desastroso tanto para o profissional quanto para o projeto. Saber dizer 'não' é uma habilidade essencial para qualquer desenvolvedor que deseja realizar um trabalho de qualidade sem sacrificar sua saúde ou a integridade do projeto.