Concrete Logo
Hamburger button

Missão: Resgate – Parte I

  • Blog
  • 19 de Março de 2013
Share
Resgate do Costa Concordia

Resgate do Costa Concordia

O termo Resgate de Projetos (Rescuing Troubled Project) é bem disseminado na comunidade de gerenciamento de projetos onde inúmeras metodologias, estratégias, processos, artigos e discussões das principais causas sobre fracassos estão propaladas pela rede. A intenção deste artigo é transparecer a experiência adquirida sob a ótica da engenharia de software numa linguagem pouco formal.

Você pode estar se perguntando que a missão de resgatar um projeto é recompor o sistema proposto e por analogia à ilustração, seria resgatar o navio. Mas de fato o resgate de um projeto está relacionado principalmente às pessoas.  Você perceberá adiante por quê.

O Drama

De repente você recebe uma ligação de seu cliente dizendo que está insatisfeito com um outro parceiro, que eles não entregam o produto, e que não dá mais, e que confia em você para seguir adiante com o projeto. Do outro lado da linha…(mudo)…e aí o lado comercial corajoso acaba falando mais alto – “ok, quando começamos?”. Mas depois que você desliga o telefone, vem as auto-indagações já com respostas especulativas.

  • “Será que o código-fonte está decente? Se não entregam, deve estar horrível.
  • “Será que os requisitos são claros?” Provavelmente não.
  • “Será que tem algo que possa ser aproveitado?” Tomara que sim.

Bom, e aí numa segunda conversa a pressão começa a aparecer. Tudo é “pra ontem” (adoro essa expressão, como música para meus ouvidos ♬ ♪) e que o projeto precisa ser implantado em três meses, que o cliente-final está pressionando e et-cetera. Por um momento você pensa: ”Fu*&ˆ% !”, mas quando cai em si e lembra como flashbacks das experiências passadas, o profissionalismo toma conta e a conhecimento nas práticas de Engenharia de Software ajuda a inibir qualquer anseio.

Os projetos falham por diversos motivos como podem ver na figura abaixo:

Causas relacionadas a falha de projetos

Causas relacionadas a falha de projetos

Neste caso enxergo alguns principais motivos que adernaram o navio:

  • Alta complexidade no Negócio;
  • Junioridade e turnover alto do time de desenvolvimento;
  • Requisitos inadequados ou confusos;
  • Metodologia inapropriada (Waterfall);
  • Inexistência de práticas de Engenharia de Software.

Começamos dizendo que só conseguiríamos dar prazos depois de uma revisão de código (code review) e de um teste de regressão (regression testing) para sabermos onde estávamos navegando – esta árdua tarefa demorou três semanas. Passado esse tempo, as confirmações: o código estava horroroso, as documentações eram confusas e realmente pouca coisa poderia ser aproveitada.

A partir daí foi que conseguimos pensar numa abordagem para tratar o projeto como deveria ser – dando a visão de que tínhamos que cortar as perdas o mais rápido possível e que a herança era na verdade uma dívida grande que não poderia afetar nossas decisões adiante.

Trecho do código que encontramos:

Ei, avisa aí que existe Math.round() em javascript, ok?

Um exemplo dos comentários no fonte:

Isto demonstra claramente a falta de entendimento pelo time de desenvolvimento sobre as regras de negócio.

O Plano

Sentiu o drama? E agora, quem poderá ajudar? No caso quem ajudou foi a montagem de um time sênior de desenvolvimento com a ajuda constante do próprio cliente. Estas peças reunidas, agregada a uma metodologia ágil, daria a eficiência de um código bom com a garantia de compliance sobre os requisitos.

Metodologia SCRUM

Metodologia SCRUM

 

Aproximar o cliente para o processo de desenvolvimento na minha visão é um dos movimentos mais importantes neste caso, você consegue minimizar e distribuir o risco de um novo fracasso, além de tornar a comunicação com o time de desenvolvimento muito mais dinâmica e aberta. As metodologias ágeis que adotamos, XP e SCRUM, falam bem sobre este modelo de trabalho.

 

Diante dos insumos gerados por nossa análise técnica, o plano extrapolou a expectativa em pouco mais de um mês. A incapacidade de testar três quintos do sistema reunida com a base de testes executadas nos deu coragem para planejar o refactoring desta parte desconhecida. Esta ação só foi possível porque criamos um ambiente de integração contínua (continuous integration) e implementamos testes unitários – detalhes para um outro post.

Sabíamos que geraria um desconforto muito grande para apresentar o plano então nada melhor que uma comunicação presencial para dar a má notícia. Obviamente que a irredutibilidade em assumir mais uma vez o atraso na entrega aos clientes-finais gritou; mas a péssima experiência com o funcionamento do sistema foi mais alto e foi aí que conseguimos reduzir o escopo pra encaixar nos três meses desejados.

É preciso ter cuidado ao propor uma redução de escopo porque se for retirada uma funcionalidade vital ao projeto/sistema, a entrega não terá utilidade. Para não cair nesta armadilha, aproxime-se bem do negócio envolvido e compartilhe desta responsabilidade com o próprio cliente.

Dicas

Seguem algumas para se montar um plano factível:

  • Saiba bem onde está navegando. Faça primeiro uma boa revisão de código e programe os testes;
  • Monte um time de desenvolvimento com capacidade além do esperado (tanto pra você quanto pro Cliente);
  • Tenha confiança para dar logo a má notícia antes que se gaste mais dinheiro;
  • Construa um ambiente de integração contínua para evitar esforços repetitivos e para manter a qualidade das entregas;
  • Traga o cliente para perto e faça-o perceber que sem a ajuda dele, o projeto não será entregue.

Neste momento, podemos perceber que um bom plano resume boas práticas e uma relação de transparência com o contratante. Isso só pode ser estabelecido por um time que reúne pessoas capazes e experientes – dos dois lados.

No próximo artigo, detalharei nossa experiência no refactory do sistema (medo).

To be continued…

Algumas fontes sobre o assunto: