Esses pré-requisitos são baseados na minha experiência sendo:

• Líder técnico;
• Scrum Master
• Liderado

Eles servem para qualquer equipe, sendo de TI ou não.

Vamos aos 5 pré-requisitos:

1. O projeto deve ter um propósito que valha a pena. Perguntas básicas:

• Ele vai resolver algum problema?
• Ele vai ajudar o cliente de fato a potencializar o seu negócio?
• Ele não é um projeto puxa-saco-de-cliente-apenas-para-fazer-filme-do-gerente?

2. O projeto deve ter um fim claro ou pelo menos suas partes entregáveis devem ser utilizadas.

• Nada mais desmotivante que projetos que são engavetados. O desperdício do cliente, seja ele um órgão público ou uma empresa privada, não costuma ser digerido muito bem por quem gosta de ver seu trabalho sendo útil.

3. O projeto deve ser rentável ou pelo menos deve atrair outros bons projetos rentáveis.

• Muitos podem achar que o problema a respeito do faturamento não deve ser da conta dos colaboradores, mas quase nenhum colaborador trabalha sem pensar em como vão as coisas na área financeira da empresa.

4. O projeto deve ser repassado com uma antecedência saudável para ser tocado pela equipe.

• Na grande maioria dos casos que vivenciei com projetos-bomba que tinham prazos absurdamente curtos, o problema do prazo apertado era motivado por falta de gestão e organização da gerência e por falta de boa articulação na hora de negociar projetos com clientes.
• Algo muito comum é negociar prazos com o cliente antes de conversar com a equipe. Algo completamente inaceitável no modelo ágil.
• Falta de transparência também ocorre intensamente. Confiança na equipe é primordial. Fazê-la trabalhar incessantemente em um prazo “fake” apenas para garantir com tranquilidade o prazo acordado com o cliente é motivo suficiente para rever uma série de conceitos: sua má gestão, sua equipe não confiável…

5. Feedback contra a ansiedade.

O Feedback contínuo tranquiliza. Fale sempre:

• Com alguém que fez algo errado no momento em que esse alguém tenha feito besteira. Falar muito tempo depois pode gerar um desconforto desnecessário e uma famigerada desculpa de possível “perseguição”. Ficar relembrando o acontecido é pior do que não ter dado o feedback.
• Que a equipe cumprir o prazo. É obrigação de todos entregar no prazo mas nem por isso você precisa tratar esse acontecimento como algo ordinário.
• Que alguém da equipe se destacar. Elogiar é bom, sem exceções.
• Que o cliente der um feedback. Antecipe as perguntas da equipe: – “E aí? O que o cliente disse? Ele gostou? Homologaram? Deu algum erro?”