Ir para o conteúdo

Adaptação e Superação I

A perspetiva de um programador e ex-oficial da Marinha sobre gestão de equipas e o modelo de entrega Agile. Esta história é a primeira parte de duas.

Introdução (Parte I)

Antes de trabalhar como Engagement Manager na Devoteam, fui Oficial da classe de Engenheiros Navais na Marinha Portuguesa durante 8 anos. Apesar das diferenças evidentes entre as duas ocupações, existe uma quantidade significativa de ferramentas, mentalidades e competências que aprendi enquanto militar e membro de uma guarnição de um navio combatente, que são transferíveis para o universo de projectos I.T.

Como Chefe de Serviço de Limitação de Avarias na fragata N.R.P. Vasco da Gama – tive a oportunidade de participar num treino NATO chamado Operational Sea Training, onde durante um mês foram simulados combates com e contra outros navios da NATO – para treinar processos de organização em combate e melhorar as competências requeridas para assegurar os níveis de prontidão operacional necessários.Esse mês foi um dos períodos mais estimulantes da minha vida. A guarnição era constantemente desafiada com exercícios em cenário de combate que permitiram uma tremenda aceleração ao longo da curva de aprendizagem e uma elevação dos padrões de prontidão. Neste artigo vou abordar 3 mindsets que permitiram à nossa guarnição alcançar os seus objectivos durante os exercícios e que são transferíveis para a nossa atividade diária de entrega em projetos IT.

Missão e Prioridades

Cada vez que se iniciava uma saída para o mar, o comandante estabelecia a Missão e as Três Prioridades de Comando. Também era um procedimento padrão durante os exercícios de combate. Uma missão típica seria, por exemplo:

Proteger a HVU (unidade de maior valor), ao longo do plano de navegação, com uma velocidade máxima disponível de 32 nós.

Adicionalmente, com base nos parâmetros definidos para o cenário, no caso de haver risco de ataque por meios aéreos ou outras embarcações, o Comando poderia definir como prioridade, a título de exemplo:

1 – Combate Anti-Aéreo

2 – Combate Ati-Superficie

3 – Combate Anti-Submarino

Através da definição do conjunto de Missão e Prioridades, todos os membros da guarnição sabem qual é o seu papel e qual o objectivo do navio naquele cenário. Pode parecer que falamos de meros procedimentos operacionais sem qualquer impato no desempenho das equipas, mas na realidade estes foram fatores chave para conseguirmos atingir os nossos objetivos.

A minha equipa pertencia à Unidade de Batalha Interna, cujo principal objetivo era garantir a prontidão do navio para o combate, em termos de sistemas, estabilidade e gestão de guarnição.

Num possível cenário em que fosse danificada alguma plataforma de armamento (por exemplo, Defesa Aérea ou Lançadores de Torpedos), um sistema de propulsão e um sistema de manobra (por exemplo, a Máquina do Leme) – ao verificarmos as prioridades de Comando, definidas anteriormente, torna-se claro quais são as nossas próprias prioridades enquanto equipa de Batalha Interna. Se existem ameaças aéreas e de superfície, então iríamos precisar de defesa aérea, velocidade e agilidade. Assim sendo as prioridades da nossa equipa seriam:

1 – Recuperar operacionalidade do sistema de defesa anti-aéreo

2 – Aumentar a velocidade máxima disponível

3 – Repor capacidade de navegação a nível máximo

Apenas conseguimos definir e validar estas três prioridades através das instruções fornecidas pelo Comando, e saber que sistemas devemos focar a atenção para manter a prontidão e operacionalidade. Este sistema de priorização vertical e descendente, assegura que todos trabalham para o mesmo objetivo comum. Considerando as prioridades de combate da Batalha Interna, consegui estabelecer prioridades mais detalhadas para a equipa de Limitação de Avarias. Desta forma defini os seguintes pontos de prioridade para as minhas equipas:

1 – Extinguir o incêndio na Sala de Telecomandos da Phalanx

2 – Reparar o alagamento na sala de comunicações interna

3 – Reparar a bomba do leme número 2

A primeira prioridade garante que uma equipa de manutenção de armas consegue chegar ao controlo da plataforma Phalanx (um sistema de defesa antiaéreo) e efectuar reparações. A segunda assegura o critério de manutenção da velocidade máxima, evitando a entrada de água na sala de Comunicação Interna. A terceira assegura a capacidade de manobra e navegação.

Entrega de Projetos em T.I.

Comparando estes cenários de batalha com os desafios que enfrentamos diariamente, é possível encontrar pontos de ligação e paralelismos. Imaginemos que temos um projecto com este objectivo:

Entregar a solução de Gestão Hospitalar com qualidade, garantido o controlo orçamental e os prazos de entrega

Como neste cenário estamos no meio de um sprint na fase de desenvolvimento, podemos ter as seguintes Prioridades de Entrega:

1 – Definir o backlog do Sprint 3

2 – Correção Bugs UAT

3 – Ponto situação do orçamento

Com estas prioridades, a equipa de projeto consegue saber claramente em que ponto estão e o que ainda precisa de ser feito para passar a uma próxima fase. Adicionalmente, utilizando a mesma estratégia de organização vertical descendente utilizada no cenário militar, o Tech Lead pode analisar e desenhar as suas próprias tarefas e prioridades – alinhadas com os objectivos de entrega do projeto. Neste caso, o Tech Lead poderia considerar:

1 – Gerir esforço de correcção bugs Sprint 1

2 – Definir estruturas JSON para as APIs do Hospital

3 – Apoiar a entrega backlog Sprint 3

Podemos verificar que estes estão perfeitamente alinhados com os objectivos de entrega nesta fase do projecto. A tarefa de definir prioridades do Tech Lead ficou muito facilitada com um mapeamento prévio “de cima para baixo” dos objetivos mais gerais e abrangentes.

Podemos ainda aumentar o nível de detalhe, com o mesmo modelo usado na Marinha. Enquanto o Tech Lead trabalha as prioridades que definiu, a equipa de desenvolvimento e cada programador individualmente pode definir as suas prioridades em alinhamento com a estratégia de entrega e do Tech Lead. Isto traduzir-se-ia por exemplo, na seguinte ordem de trabalho para um programador:

1 – Terminar US35 e US36 para encerrar backlog

2 – Entregar lista de correcções de bugs em desenvolvimento

3 – Atualizar estado do Sprint no Jira

A este nível, estas tarefas são muito mais operacionais do que as prioridades de entrega definidas em níveis anteriores – o que faz todo o sentido, porque os programadores são o núcleo operacional da equipa que constrói a solução. Como são eles que dispõem as pedras com que vão “construir a catedral”, quanto mais foco tiverem e melhor alinhadas estiverem as tarefas com o objetivo do projeto e da fase de entrega, melhor conseguirão ajudar o Tech Lead a atingir os seus objetivos e prioridades.

Esta linha condutora, que flui da estratégia de entrega para o desenvolvimento, termina no objetivo do projeto e unifica todas as prioridades – é um factor crucial para uma equipa de alto desempenho. Mas estabelecer prioridades não é suficiente. Se apenas fizermos essa parte, não passam de palavras escritas num papel, sem forma de as materializar. Para conseguir o compromisso e empenho de cada membro da equipa, em perfeito alinhamento, é necessário comunicar e compreender as prioridades. Não somos robôs. Cada pessoa precisa de acreditar no objetivo para estar completamente comprometida.

Se a equipa conseguir trabalhar para o objetivo, estabelecer e atualizar sistematicamente as prioridades e comunicar e assegurar a compreensão real daquilo que se pretende, é o caminho para a liderança descentralizada, onde cada um tem o conhecimento e autonomia para ser o seu próprio líder e tomar decisões quanto ao caminho a seguir, para o objectivo de fazer uma entrega de qualidade.