Os Termómetros de uma equipe

Uma imagem fala mais que mil palavras. Muitas vezes usamos essa frase em diversas situações, mas as vezes esquecemos que isso pode ser útil em um projeto de TI Também. O Ron Jeffries um dos criadores do XP dá muito em foque nessa questão de sinalizar o que está acontecendo no projeto.

Mas a questão não é apenas sinalizar isto para os stakeholders mas sim para a própria equipe do projeto também. Essa não é mais uma das coisas que vem do *Agile Hype*. Claro os caras fala nisso também, mas isso está ligado com uma questão muito maior e em muitas vezes mais perturbadora o Planejamento Estratégico.

O Planejamento estratégico deve vir de cima, ou seja vir da aérea de negócio, assim ele pode ser cascateado para a TI e subseqüentemente cascateado para projetos de software através de uma técnica chamada Balanced Score Card.

A partir do ponto que existe um planejamento maior por conta da organização a TI e os projetos derivados dela começam a ganhar sentido, sem esse alinhamento não garantia de que a TI está indo na direção a qual a empresa deseja.





A Diferença do Alinhamento Estratégico

Nota: Percebam que está não é um post que tem o propósito de advogar contra agile e ou a favor de BSC, acredito que são propósitos diferentes que se completam :)

Mas voltando a figura a cima o planejamento estratégico ou alinhamento estratégico funciona como um grande catalizador que da o norte para a empresa. Esse norte não pode ser dado de dentro da TI nem mesmo com Agile, RUP ou qualquer governança de TI.

O que podemos fazer é suportar o planejamento da organização com uma melhor organização e estruturação da TI utilizando uma solução de governança corporativa, leia-se Cobit, ou alguma solução customizada que se preocupe com a Engenharia de Software + Algo do tipo PMI.

Se a organização tem e subseqüentemente a TI implementa isso é necessário de alguma forma medir/mesurar se o que está se fazendo está atendendo as expectativas/metas da organização.

A forma de se fazer isso é com métricas e indicadores, os indicadores podem ser os mais variados como por exemplo, números de Bugs encontrados por release, Erros em especificações ou Previsto/Realizado de Casos de uso em uma Release.

Apenas ter esses indicadores não resolve nada! É necessário expressar de forma veemente. A melhor forma de se fazer isso é utilizando recursos visuais como gráficos. Esses gráficos são os termômetros da equipe. Recomendo espalhar diversos gráficos pela sala do projeto e não tem problema se eles não forem escritos a mão, um bom MS Excel já resolve!

Os gráficos são excelentes para mostrar a situação do projeto e como eles estão todos os dias ali na nossa frente nos dizendo que algo não está bom ou está bom eles servem como um grande sinal de fumaça para a equipe e para quem está de fora.

Se você utilizando alguma técnica que traz alguma engenharia social ao seu projeto como o Scrum por exemplo. em momentos de reflexão como as reuniões de Retrospectivas é um momento ideal para falar sobre os gráficos.


Popular posts from this blog

Kafka Streams with Java 15

Rust and Java Interoperability

HMAC in Java