timeBox

- Documentos por favor.
- Sim senhor.
- É…você tem uma irregularidade aqui.
- É mesmo é?
- É mesmo! Não vai poder seguir em frente não.

Não, eu não estou fugindo do tema desse blog e relatando um desfecho comum para os engarrafamentos de 1 hora no aterro do flamengo ( o tempo normal pra atravessa-lo é de 5 min).

Quando se desenvolve software para uma grande corporação, não é raro se deparar com essa situação ai do diálogo. No papel do policial normalmente está algum membro da EIB (Equipe de Infra-estrutura Básica) e na pele do motorista está algum desenvolvedor com a inevitável missão de submeter um sistema (ou pedaço de um) à aprovação da EIB.

Uma EIB normalmente é composta por um conjunto de pessoas, onde cada uma tem uma aptidão específica, como administração de banco de dados, ou arquitetura SOA por exemplo. Muitas vezes uma EIB é até composta por um conjunto de equipes menores, cada qual com sua especialidade. Mas enfim, a função dessa galera de infra é dar apoio as equipes de desenvolvimento de software, criando diretrizes e convenções corporativas, as quais devem ser seguidas pelas equipes de desenvolvimento.

Existem duas formas de se trabalhar essa questão “EIB vs equipes de desenvolvimento”:

1 – Colocando uma contra a outra nessa estratégia de BLITZ CORPORATIVA, onde o pessoal de EIB apenas gera um mar de documentos-diretrizes, envia esse “manual de trânsito” para as equipes de desenvolvimento e marca uma data (normalmente ao final de alguma entrega importante) para revistar (ops!) digo….analisar, o trabalho da galera de desenvolvimento.

2 – Promovendo a comunicação e a humildade (valores da modelagem ágil) entre ambas as partes. Isso se faz inserindo as pessoas de EIB em determinados projetos de desenvolvimento por algum período de tempo, fazendo com que elas compartilhem sua maturidade profissional nas áreas em que se especializaram. Assim, as diretrizes corporativas passam a ser amadurecidas, repassadas e colocadas em prática em um cenário real. De quebra, ainda se cria um ambiente amigável e colaborativo entre as partes. Isso funciona! Dia desses estava conversando sobre isso com o Gustavo Serafim e ele diz estar tendo bons resultados com essa abordagem.

Ah! não posso deixar de dizer isso. Um grande risco de insucesso que se corre usando essa segunda abordagem, é colocando pessoas com pouca ou nenhuma habilidade de comunicação na EIB. Para isso funcionar é preciso ter profissionais bons tecnicamente mas que sejam sociáveis também. Já imaginou a pessoa ser apresentada como nova especialista XPTO pra apoiar o projeto durante algumas semanas, daí após essas semanas sem falar um “ah” ela manda um “manual de trânsito” por e-mail e some?