Estamos atentos antes, durante e na entrega de um projeto?

Faz um tempo que trabalho com o desenvolvimento de sistemas e já trabalhei com diversos clientes, cada um com sua peculiaridade. Durante esse tempo, após entregas feitas com sucesso e outras nem tanto, algumas perguntas passaram por minha cabeça e talvez elas sejam úteis para você também.

A ideia desse texto não é impor uma resposta para cada uma das perguntas, por mais que eu traga algumas ideias de tratativa para cada uma delas, a ideia central é que você e seu time reflitam sobre as perguntas e definam o melhor caminho para cada questionamento.

Eu trago mais questionamentos do que soluções. Na correria do dia a dia, as vezes esquecemos de parar e refletir sobre nossos processos, então minha ideia e fazer você e seu time refletir.

Chega de enrolação e vamos às perguntas.

1. Entendo/entendemos o projeto como um todo?
2. Estamos envolvendo o cliente nas etapas do projeto?
3. Estão claros os detalhes do requisito no qual vou atuar?
4. Meu código, está claro para que um colega de equipe atue na manutenção?
5. O requisito do cliente necessita que meu código seja escalável?
6. Estou atento quanto a performance de minhas consultas Sql?
7. Quando faço o teste do “dev”, deixo documentado?
8. Estou facilitando a vida do colega que vai testar meu requisito?
9. Quando faço um code review, estou atento em relação aos combinados do time?
10. Estamos fazendo um repasse com clareza para o cliente?

Entendo/entendemos o projeto como um todo?

Aposto que você já viu essa imagem abaixo em alguma aula, apresentação, artigo ou algum post de internet.

Fonte imagem: projectcartoon

Mas, eu trouxe essa imagem novamente para fazermos uma reflexão. No nosso dia a dia, paramos e nos perguntamos, será que essa solução vai atender o problema do cliente? Eu entendi o problema do cliente? Ficou claro para o cliente a solução que estou propondo?

Arquiteto/PO (Product Owner), sobre a solução que foi apresentada ao cliente, você está tranquilo de que ele entendeu o que será entregue? Dev, quando você recebeu o projeto, fez sentido o projeto que está sendo proposto com relação a solicitação do cliente?

Se necessário, crie fluxogramas, faça protótipos de telas, faça um desenho no quadro branco. Busque deixar bem claro o que será desenvolvido, e ter certeza de que o cliente entendeu a essência do projeto. Para que no final todas as expectativas sejam cumpridas e todos os lados estejam satisfeitos.

Estamos envolvendo o cliente nas etapas do projeto?

Hoje em dia o que mais se fala é sobre o tal do Desenvolvimento Ágil, no papel ele é lindo. Agora, quando o seu cliente recebe uma proposta e depois ele só vai ouvir falar novamente do projeto na entrega, essa é a sensação do cliente durante todo o projeto.

Muitas vezes nossa equipe está trabalhando no modelo ágil, fazemos as sprints certinhas, temos a review da equipe, quebramos os requisitos em tarefas e até pontuamos a tarefa, mas a pergunta que não quer calar, seu cliente foi envolvido nas reviews? Não estou falando de que ele deve estar em todas as reuniões, mas poderia pelo menos juntar algumas entregas e apresentar ao cliente, fazer uma reunião de status e não deixar tudo para o final.

Pense nisso, você pode descobrir um problema antes do fim, ter tempo para ajustar antes da entrega e resolver muita dor de cabeça que você teria após a entrega do projeto.

Estão claros os detalhes do requisito no qual vou atuar?

Muitas vezes a gente recebe o requisito, dá uma lida e inicia o desenvolvimento mesmo que tenham ficado algumas dúvidas. Eu gostaria de reforçar a importância de sanar todas as dúvidas antes de iniciar o desenvolvimento, o PO está ali do seu lado para te ajudar, então pode perguntar à vontade.

É de suma importância não entregar um requisito “achando” que entendeu, pois o produto que foi desenvolvido pode não atender a necessidade do cliente e isso pode gerar algumas dores de cabeça desnecessárias.

Meu código, está claro para que um colega de equipe atue na manutenção?

Eu tenho certeza que em algum momento, um colega de equipe precisou realizar uma manutenção em um código que escrevi, e essa foi a sensação da pessoa.

É muito importante que o time defina alguns padrões e que o código seja claro no que ele está fazendo.

Então, dev, faça a seguinte pergunta: Se eu precisar dar manutenção nesse código daqui 1 ano, vai ser fácil ou difícil de entender essa lógica?

Fica a dica, pense no colega e facilite a vida dele, pois amanhã pode ser você dando manutenção no código dele.

Ah! Eu fiz um texto sobre algumas boas práticas de desenvolvimento, vale a pena dar uma lida nele. Boas práticas de codificação.

O requisito do cliente necessita que meu código seja escalável?

Essa eu já cai algumas vezes nela, e quando isso acontece é “barata voa para todos os lados”.

Vou contar uma história de um perrengue que já passei.

Cliente interno solicitou um portal de matrículas pois estava muito difícil e lento fazer as matrículas no ERP padrão, fizemos o levantamento e partimos para o desenvolvimento. Antes, uma matrícula demorava cerca de 10 minutos para ser feita, com o novo portal essa mesma matrícula agora é finalizada em 3 minutos. Sucesso, certo? infelizmente, não. O cliente em certos períodos fazia o famoso plantão de matrículas e dava alguns descontos maiores buscando atrair mais alunos, e qual foi o resultado? A matrícula voltou a demorar 10 minutos para ser finalizada, pois nossa infra e nem o portal estavam preparados para tantas matrículas ao mesmo tempo. Foi uma correria para todos os lados para resolver, mas fique tranquilo, que nesse caso no final deu tudo certo. 😀

Essa pergunta precisar estar na “alma” do dev, pois nem todo projeto precisa ser escalável, mas quando precisa e o programa não for, vai ser uma dor de cabeça gigante. Vai por mim, gaste um tempinho analisando esse ponto, vai te poupar muitos problemas no futuro.

Estou atento quanto a performance de minhas consultas Sql?

Essa pergunta é complementar a pergunta anterior e é outra dor de cabeça.

Precisamos ficar atentos quanto à performance de nossas consultas sql, em nosso ambiente estamos falando de centenas de registros, já no cliente estamos falando de milhares de registros. Uma consulta que demore 1 segundo no seu ambiente, no cliente pode demorar minutos para ser executada, e isso vai impactar no banco como um todo e no tempo de resposta de sua aplicação. Se essa sua consulta estiver dentro de um for, vai ser uma eternidade para que esse processo possa ser executado. Tenha bastante atenção em relação às suas consultas.

Cuidado com consulta dentro de consulta, unions, order by’s e até a ordem dos campos no where.

Caso tenha interesse, em breve vou escrever um texto com boas práticas na hora de montar sua consulta sql.

Quando faço o teste do “dev”, deixo documentado?

É uma prática comum entre muitos desenvolvedores, realizar um teste básico da nossa programação. Algumas vezes temos um caso de teste para seguir, mas em sua grande maioria, fazemos o teste de algumas partes seguindo um roteiro que só existe na cabeça e jogo que segue.

Mesmo que não tenha um caso de teste, acredito que seja importante o dev montar um caso de teste do seu requisito, isso vai tanto auxiliar no seu teste e com isso aumentar a qualidade da codificação, quanto ajudar uma outra pessoa que for testar o requisito.

Estou facilitando a vida do colega que vai testar meu requisito?

Essa pergunta é complementar à anterior, nela falamos sobre o dev montar um caso de teste e como isso pode facilitar para que uma outra pessoa realize o teste do requisito. Podemos também deixar os scripts de banco separados e identificados, ou até um documento explicando como montar o ambiente. Aqui não existe uma regra, mas na finalização do seu requisito, pense na pessoa que vai testar e como você pode ajudá-la.

Quando faço um code review, estou atento em relação aos combinados do time?

Geralmente quando vamos fazer um code review, analisamos se tem algum erro no código, ou se tem um texto escrito com uma grafia errada. Mas em sua grande maioria, os times possuem um combinado sobre as boas práticas na hora de desenvolver uma nova funcionalidade.

É sempre bom ter essas boas práticas em mente na hora de realizar o code review e caso veja que tenha muita coisa diferente, não tenha receio de chamar o colega de equipe e explicar quais pontos ele precisa alterar. Em um primeiro momento pode parecer uma perda de tempo, mas um código que segue as práticas do time vai ser muito mais fácil de ser interpretado por outro colega, caso ele necessite analisar sua codificação.

Se seu time não tem um documento com as boas práticas, incentive seu time a montar esse documento, garanto que a longo prazo será muito benéfico.

Estamos fazendo um repasse com clareza para o cliente?

Te peço que faça a seguinte reflexão e se ponha no lugar desse analista.

Você trabalha em uma empresa e está cheio de tarefas para fazer, seu chefe resolveu implantar um novo sistema ou customizar uma parte do sistema existente, sendo você o analista que vai utilizar esse sistema. Em alguns cenários, você participa de algumas conversas no inicio do projeto e em outros cenários você nem foi incluído nas tomadas de decisão, muitas vezes nem se sabe o que está rolando. Chega um determinado dia, você é informado sobre a entrega desse projeto, uma pessoa de uma outra equipe ou empresa te apresenta o projeto em 15 minutos, e seu chefe fala que você que tem ali uma semana ou 15 dias para testar todo o projeto. Você nem recebe um plano de teste e isso tudo tem que ser realizado junto com as tarefas que você já tem que lidar no seu dia a dia.

Aí te faço a seguinte pergunta, você acredita que esse analista vai conseguir testar tudo em uma semana? E te reportar todos os bugs? Você acredita que ele vai realizar esses testes com empolgação? Ou vai fazer tudo na correria só para finalizar e ficar livre logo dessa tarefa?

Tempos depois, se esse mesmo analista que está utilizando o sistema encontrar algum problema, você acredita que a empresa vai pagar de boa pelos ajustes, ou vão querer que você faça o ajuste sem cobrar por isso, pois não tiveram tempo de testar tudo antes?

Levando em consideração o cenário em que esse analista consegue fazer o trabalho dele mais os testes nesse prazo pequeno, e identificar algo que não se encaixa na realidade dizendo que o sistema não está atendendo. Você acredita que o chefe dele vai pagar uma alteração de escopo feliz ou ele vai ficar no seu pé para que o ajuste seja feito antes de aceitar a conclusão do projeto? E se essa alteração de escopo exigir 50% de tempo de todo o projeto para ser ajustado? Quem vai ficar com esse prejuízo? Como bem sabemos, tempo é dinheiro.

Essa pergunta é um complemento das duas primeiras perguntas, precisamos envolver o cliente nas etapas do projeto e precisamos instigar que ele envolva as pessoas que efetivamente vão utilizar o sistema.

Se possível faça entregas menores, para que o cliente consiga ir testando o projeto em partes, para que possamos ir corrigindo os bugs encontrados e ir ajustando qualquer coisa que não esteja em conformidade.

Muitas vezes não criamos um plano de teste para o cliente, mas podemos juntar os planos de teste que o dev passar para o tester e enviar para o cliente.

Ajude o cliente a entender a solução que está sendo entregue e engaje-o no processo como um todo. Precisamos do cliente do nosso lado e não o contrário.

Conclusão

Bom, é isso. Espero que essas perguntas ajudem você e o seu time a refletir sobre alguns processos do dia a dia. Acredito que com um bom bate papo entre os membros, algumas definições escritas, vocês vão conseguir melhorar os processos, realizar entregas com mais qualidade e dessa forma permitir uma maior satisfação do cliente. Lembre-se, cliente feliz é igual à uma boa reputação, uma boa reputação atrai novos projetos e novos projetos são iguais a dinheiro no bolso.

Boa codificação.