Comprometimento do time: não faça hoje o que você pode deixar para amanhã.

Essa é uma situação que todos nós sabemos que acontece, porém, sempre fazemos vista grossa, e nisso eu incluo todos os envolvidos no projeto: diretoria, gerência, analistas, desenvolvedores, testers, DBA`s e demais pessoas que participam do projeto. Os desenvolvedores acham que “iludem” o gerente dizendo que os percentuais de desenvolvimento estão dentro do prazo, que não estão tendo problemas e que tudo está andando como esperado. Os gerentes “iludem” seus diretores dizendo que as coisas estão caminhando bem, que seu Gantt Chart está perfeito, que o plano está sendo seguido como esperado, mas que não vai dar moleza para o time, pois se eles não estiverem com um chicote nas costas as coisas não andam…afinal, ele precisa mostrar que tem autoridade sobre o time.

Em geral, isso acontece muito em um cenário tradicional de gerenciamento de projeto, pois a cultura atual leva este profissional (ou recurso, como preferir) a ter essa postura. O que é muito comum em ambientes de projetos é a aparição da famosa síndrome do estudante (quando é que você estuda para a prova mesmo?): quando o desenvolvedor recebe suas tarefas e olha para o tempo que tem para codificá-las, qual é o primeiro pensamento que vêm a sua mente (pelo menos eu também pensava assim) ? “Ah, tem tempo ainda, posso continuar a resolver essa pendência, a ler o livro, a navegar na internet, a ler e responder e-mails diversos, … “, e com isso se passam minutos, horas e muitas vezes dias.

Na minha opinião, os principais pontos que acarretam essas situações são :

– Prazos longos nos dão uma sensação de conforto
– O fato do programador não ter dado a palavra dele do que é ou não possível de ser feito
– Falta de comunicação e excesso de papéis dizendo, ou melhor, tentando dizer o que o time precisa fazer
– Cultura da empresa, acostumada a atrasos e fins de projetos “cheios de emoção”;
– Desenvolvedores ignoram a comunicação e se escondem em seu mundo (com seus fones de ouvido cada vez maiores)
– A falta de uma definição de pronto, o que reflete diretamente na qualidade (Vou fazer o que está escrito aqui e se compilar: “pronto!”)

O comprometimento do time é um dos principais fatores que levam ao sucesso do projeto, afinal um time comprometido com o trabalho e focado em uma meta vai fazer o possível para atingí-la, simples assim! Em times Scrum esse comprometimento é alcançado naturalmente pela forma de trabalho que o Scrum propõe. O fator “síndrome de estudante” fica difícil de ser aplicado já que trabalhamos com iterações curtas e isso teoricamente leva o time a trabalhar firme desde o primeiro dia de trabalho, além disso as reuniões diárias são fortes agentes de combate a este vício.
Falando em comprometimento e estimativa, em times Scrum é o próprio time quem planeja as suas Sprints dizendo quais são os itens que irão entrar naquele período de 2 a 4 semanas, ou seja, a palavra do time tem valor e isso faz com que eles sintam essa confiança que neles é depositada. Quando o time planeja e estima os requisitos que serão desenvolvidos naquela Sprint, eles estão focando em uma meta definida pelo Product Owner, ou seja, para a Sprint ser bem sucedida, a “meta” tem que ser alcançada. Indo mais a fundo, para desenvolver um item do Product Backlog, o time quebra ele em pequenas tarefas que serão desenvolvidas por todos os membros do time, isso mesmo, todos do time irão trabalhar em um mesmo item: o item de maior prioridade para Product Owner, o que tem mais retorno sobre o investimento do projeto. Sei que a primeira impressão é, “isso é impossível” mas acreditem, não é! Essa definição de tarefas que precisam ser executadas para que um item seja considerado pronto são discutidas e criadas pelo time, seguindo a ordem de prioridade definida pelo cliente, e isso também contamina o time para que todos se comprometam e colaborem entre si para que as tarefas de um requisito sejam finalizadas, garantindo que aquele item fique realmente “pronto”. Uma pessoa do time não irá pegar uma tarefa de um outro item se houverem tarefas de um requisito de maior prioridade para serem desenvolvidas, ou seja, ele tem o comprometimento com a “meta” que foi acordada entre eles e o Product Owner.
Esse espírito de união que é gerado dentro do time é um fator que estimula o comprometimento, pois quando vemos que todos os membros do time estão empenhados e trabalhando firme, isto acaba contaminando a todos, e se alguém não estiver comprometido, acredite, ele irá se sentir mal, pois este é um processo natural que ocorre em times ágeis. Esse comprometimento ajuda muito quando temos um dos membros do time que está passando por dificuldades com alguma tarefa que faz parte de um item que compõe a meta, é fato que a ajuda por outros membros do time irá aparecer espontaneamente, pois times ágeis são auto-gerenciáveis.

Outro fator que estimula o comprometimento é que em uma gestão ágil não vemos um Gerente de Projeto “no pé” do desenvolvedor perguntando qual é o percentual que falta para executar a tarefa, porque acreditamos que ele é capaz de fazer o seu trabalho, ou seja, nós confiamos no time e sabemos que eles irão fazer o possível para atingir a meta. Times ágeis possuem um contato muito próximo ao cliente, e isso elimina o “telefone sem fio” quando o gerente escuta a necessidade do cliente, passa para o analista que gera a documentação para o desenvolvedor e este tem que fazer milagres pra entender aquela “maravilhosa” especificação. Isto elimina também a mania que temos de usar os documentos para substituir uma comunicação, a regra de negócio é passada diretamente do cliente para o time em reuniões periódicas de planejamento o que dá mais segurança e confiança para o time desenvolver aqueles requisitos, estimulando mais uma vez o comprometimento do time. Lembrando, documentos são importantes, mas não substituem a comunicação.
Bom, não quero dizer que isso é uma verdade absoluta, apenas estou compartilhando com vocês a minha experiência sobre o que vejo no comprometimento de times que trabalham com uma gestão ágil e naqueles que trabalham com uma gestão mais tradicional. Existem vários outros fatores sobre o comprometimento de times que poderiam ser citados aqui, mas creio que com essas informações já consegui passar o meu recado. Formar um time comprometido e auto-gerenciado é uma das responsabilidades do ScrumMaster, afinal isto não acontecerá como num passe de mágica, mas sim com muito trabalho, dedicação é tendo educação como palavra-chave.

Comentários são bem vindos para nosso crescimento e melhoria: inspect and adapt.