Ao criar produtos, dizer não para algumas coisas é vital. Devemos dizer “não” para coisas porque sempre há muitas funcionalidades para construir, direções demais que podemos tomar, e muitas políticas que podemos adotar. Ao mesmo tempo, é extremamente difícil dizer “não”. Então, estou aqui para te incentivar a dizer “não” muito mais.
Como desenvolvedores, designers, e product managers, uma situação que devemos frequentemente dizer “não” é quando alguém quer introduzir uma nova política ao nosso processo em resposta a algum problema. Muitas vezes, esse problema será abordado durante uma retrospectiva, mas ele pode surgir de outras formas.
E o problema provavelmente é muito real. Não estou tentando minimizar isso. Devemos corrigir o problema. Mas muito frequentemente adotamos como padrão a introdução de uma nova política em nosso processo porque (a) isso nos protege de sermos culpados por erros futuros (por exemplo, “foi o processo que falhou, não eu”), e (b) nos faz sentir seguros contra erros futuros (por exemplo, “o problema x não pode acontecer novamente por causa da política z”). Mas acredito que 9 em cada 10 vezes a melhor solução é comunicar claramente os problemas e possíveis soluções e confiar que seu time irá implementá-las.
Deixe-me dar alguns exemplos que podem tornar as coisas mais concretas.
Cenário 1: O bug que aumenta as barreiras
Suponha que um bug tenha sido introduzido ao seu produto. O bug foi detectado e a equipe o corrigiu, mas não antes que alguns clientes reclamassem. Durante uma retrospectiva, o problema é levantado e alguém sugere: “isso deveria ter sido detectado na revisão de código. Como ninguém percebeu isso? A partir de agora, Jeff (um desenvolvedor/designer particularmente talentoso) deve aprovar todas as revisões de código. E vamos definir o requisito do GitHub de que duas pessoas devem aprovar o pull request antes que qualquer código possa ser mesclado”.
Neste exemplo, o problema é muito real: um bug foi introduzido que afetou os clientes. A solução, no entanto, parece um exagero. A equipe certamente deve fazer revisões de código, mas de repente transformamos Jeff em um gatekeeper. Agora, os pull requests provavelmente ficarão parados porque Jeff, uma única pessoa com tempo limitado, deve revisar e aprovar cada uma delas. Para piorar, transferimos a responsabilidade pelo código que está sendo introduzido para longe do indivíduo com o conhecimento mais intrincado da funcionalidade (o que abre o pull request) para alguém com menos conhecimento (no nosso caso, Jeff).
Qual é a alternativa ao “aumentar as barreiras”?
Não estou dizendo que ter várias pessoas revisando seu código é ruim, especialmente se uma delas for um desenvolvedor/designer muito talentoso em sua equipe. Acho ótimo. Mas há uma alternativa para introduzir essa política. A alternativa é confiar que você pode falar com sua equipe sobre o problema e que eles se comportarão de maneira responsável para corrigi-lo.
Voltando ao nosso exemplo: acho que seria melhor dizer “Equipe, vamos ser mais proativos na revisão de código. Não mescle os seus pull requests a menos que você tenha recebido boas revisões e feedback. Se você não recebeu revisões de código, não se acanhe. Peça mais revisões de código”. Isso capacita desenvolvedores e designers a serem os proprietários do que estão introduzindo na base de código, e isso é feito confiando neles. Além disso, como especialistas na funcionalidade que estão introduzindo, eles podem saber quem seria a pessoa essencial para revisar sua funcionalidade e podem pedir a essa pessoa de acordo. Portanto, confie que sua equipe é composta por adultos responsáveis que podem se comportar profissionalmente.
Na thoughtbot, temos dois pontos em nossos guias de revisão de código que destacam essa confiança e responsabilidade:
Lembre-se de que você (a pessoa que está revisando o pull request) está aqui para fornecer feedback, não para ser a pessoa guardiã dos pull requests.
O controle editorial final é de quem tem a autoria do pull request.
Cenário 2: Os tickets não especificados e a reunião de um dia inteiro
Suponha que, durante a última iteração, dois tickets não foram especificados corretamente. Como resultado, foram necessárias muitas conversas de ida e volta entre um desenvolvedor e o product manager para descobrir o que precisava ser feito. Durante a retrospectiva, o desenvolvedor traz isso à tona, e a equipe decide implementar uma reunião de toda a equipe todas as segundas-feiras para passar por todos os tickets para a próxima iteração.
Mais uma vez, o problema é muito real. Quando os tickets não são especificados corretamente e muito trabalho precisa ser feito antes que eles estejam prontos para a implementação, isso pode causar atrasos sérios no lançamento de funcionalidades. Mas agora transformamos uma situação que custou algum tempo a um desenvolvedor em uma reunião semanal que leva 1 hora para 8 pessoas. São 8 horas combinadas, um dia inteiro de trabalho!
Qual é a alternativa à falta de especificação?
Como no exemplo anterior, a alternativa que eu sugeriria é a comunicação e a confiança. Informe ao product manager que os tickets não foram especificados corretamente. Pergunte se houve algo que o bloqueou quando estava escrevendo. Nesta situação, pode ser que o product manager precisasse pedir mais contribuições de desenvolvedores e designers antes que a iteração começasse. Mas, em vez de criar uma reunião obrigatória, confie que o product manager será mais proativo em obter contribuições quando achar necessário. Se o problema ressurgir, reveja-o na próxima retrospectiva. Pode haver um bloqueio diferente da próxima vez.
Adicionar políticas é fácil. Removê-las é difícil.
Introduzir novas políticas tende a ser fácil. Mas remover políticas desatualizadas pode ser muito difícil. E quanto mais políticas você tiver, mais rígido seu processo se tornará. Essa rigidez diminuirá a velocidade com que sua equipe pode iterar. Portanto, mesmo que o custo de introduzir uma única política pareça pequeno, os custos se acumulam rapidamente.
Acho que uma citação de Rework no capítulo Não cicatrize no primeiro corte realmente captura a essência do problema,
As políticas são cicatrizes organizacionais. Elas são reações exageradas codificadas para situações que provavelmente não acontecerão novamente.
A alternativa de comunicação e confiança permite que a equipe permaneça flexível e itere rapidamente. Também capacita os colegas de trabalho, confiando que eles abordarão o problema de forma responsável, sem a necessidade de um decreto obrigatório. Adicione políticas ao seu processo apenas quando for absolutamente necessário. Não cicatrize no primeiro corte.
Qual é a quantidade certa de processo?
É verdade que a quantidade certa de processo varia em cada empresa, e o processo deve se adaptar à medida que as equipes crescem e mudam. Na thoughtbot, tivemos muito sucesso com um processo leve e dois conceitos principais que incentivam a comunicação aberta e a confiança, reuniões diárias e retrospectivas semanais. E descobrimos que, muitas vezes, isso é o suficiente.