Não há tamanho perfeito para um loop de feedback
Quanto mais eu escrevia este post, mais parecia que eu deveria estar escrevendo algum tipo de TL;DR para certas pessoas que leem isso. Então, para economizar tempo, aqui está:
Estou escrevendo isso para aqueles que são novos no trabalho autônomo, gerenciamento de projetos ou geralmente têm menos experiência do que aqueles que estão perguntando “Por que você está escrevendo isso?" Em última análise, é algo que a maioria de nós aprende em algum momento deste indústria, mas se pudermos ajudar uns aos outros a encurtá-la mais cedo ou mais tarde, todos nós nos beneficiamos.
Se você ainda estiver interessado depois de ler a nota acima, suponho que você esteja procurando melhorar esse aspecto da comunicação. O que é bom, porque eu também sou 😏, e usar um pequeno loop de feedback é uma maneira que encontrei para fazer isso.
Cada indústria tem um pouco de seu próprio jargão e muitos de nós rimos disso, mas todos continuamos a usá-lo quando em um ambiente profissional. Somos engraçados assim.
De qualquer forma, em nossa indústria, uma das frases que usamos muito – inclusive eu – é “feedback loop”. A primeira vez que me deparei com a frase foi em relação ao feedback dos amplificadores. Não tinha nada a ver com software. No entanto, no que fazemos, geralmente o usamos para nos referirmos a ele como:
- enviar uma solicitação, comentário ou informação geral a um cliente,
- receber uma resposta do cliente em relação a essas informações.
E para aqueles que não estão acostumados com a ideia (porque há aqueles que fazem “lançamentos big bang” sobre os quais falarei daqui a pouco), os ciclos de feedback são geralmente considerados pequenos ou grandes.
Quanto mais tempo eu trabalho em software, mais eu sempre busco um pequeno ciclo de feedback, não importa o que aconteça.
O ciclo de feedback perfeito
Um pequeno ciclo de feedback significa que há comunicação frequente entre uma empresa e o cliente (portanto, naturalmente, um grande ciclo de feedback ocorre quando há comunicação menos frequente).
Se você vai usar jargão, pelo menos pense nisso de alguma forma divertida, certo?
Mas sabe aquele jargão que mencionei no início do artigo? Na conversão normal, eu apenas diria:
Quando se trata de trabalhar em um projeto, prefiro uma comunicação mais frequente.
E a razão pela qual eu prefiro isso e até o padrão é porque quando se trata de construir uma solução, independentemente do tamanho, para outra pessoa, sempre há partes móveis a serem consideradas.
Quando há várias partes em um projeto, há vários pontos de lugares onde algo pode precisar de ajustes ou alterações (ou que pode afetar o sistema geral) e acertar mais cedo do que mais tarde economiza muito tempo (e, portanto, dinheiro) e estresse para a maioria das partes envolvidas.
E daí?
Por que se preocupar em escrever sobre isso, no entanto? Para mim, a razão é porque quanto mais tempo administro uma pequena loja, mais ouço dos clientes sobre os problemas que surgem com a falta de clareza, comunicação e gerenciamento de projetos em projetos anteriores.
Desapontamento. Eu não quero executar esse tipo de operação. Então é uma coisa fácil de consertar, certo?
Além disso, o setor de desenvolvimento está cheio de pessoas que pegam os requisitos de um projeto, assumem que entendem tudo o que é necessário e depois voltam apenas para construir algo que não apenas erra o alvo, mas apenas se parece um pouco com o que o cliente pretendia.
Isso não é necessariamente um golpe para os programadores, mas todo esse “[perder] o alvo” pode ser corrigido se simplesmente nos comunicarmos com aqueles com quem estamos trabalhando com um pouco mais de frequência.
Não assuma que você sabe o que eles querem.
Em vez disso, faça perguntas, esclareça o requisito, trabalhe no recurso e apresente ao cliente em um ambiente de teste. Eles saberão se você construiu o que eles pediram. Se assim for, então para o próximo recurso. Se não, há mais trabalho a fazer. Operar dessa maneira agiliza muito dos pontos de tensão que surgem nos projetos.
E sim, fazer muitas perguntas pode se tornar tedioso e até irritante. Grande coisa. Mencione desde o início que você fará muitas perguntas para entender completamente o problema antes de tentar resolvê-lo. Dê uma razão pela qual você está fazendo o que está fazendo. Costuma render bem.
Lançamentos do Big Bang
No início do post, eu mencionei “lançamentos big bang” e isso geralmente se refere à ideia de um cliente fornecendo requisitos, você voltando a trabalhar nele por semanas a fio, depois aparecendo e dizendo “Ei, eu terminei – dê uma olhada!” apenas para descobrir que está longe.
Se eu fosse contextualizar isso dentro de um tipo de ciclo de feedback, eu diria que não há um. Não é nem grande porque nenhum feedback foi solicitado. É simplesmente:
- Aqui estão os requisitos para o projeto,
- Acabei com o projeto.
Muitas vezes, isso leva os desenvolvedores a não entenderem os requisitos, os clientes não saberem sobre o progresso e o projeto geral dar errado. Simplificando, não faça isso dessa maneira.
O Tamanho Perfeito?
Eu não sei qual é o tamanho perfeito de um loop de feedback. Há alguns clientes com quem trabalhei onde há check-ins diários, há alguns lugares onde há check-ins semanais e há alguns que disseram “apenas complete isso e me avise quando terminar”.
Check-ins semanais, commits, releases, etc. tendem a ser meus favoritos, mas isso se deve ao tamanho do projeto e ao tamanho da equipe com a qual trabalho. Diariamente também não é ruim dependendo da tarefa.
Eu nunca faço o estilo big bang, mesmo que um cliente diga que está tudo bem. Eu ainda gosto de ter postos de controle para minha própria sanidade. Portanto, qualquer tipo de ciclo de feedback que funcione melhor para você, sua equipe e seu cliente terá o tamanho perfeito.