Como lidar com a pressão para a entrega de projetos de TI

Para sistemas corporativos, a data de lançamento dos projetos é muito importante e é comum que os gerentes responsáveis sacrifiquem os limites de orçamento antes de se aterem a revisar os prazos pré-determinados.

A escolha é justificada por sólidas razões, já que bônus, comissões e até mesmo valores de ações dependem tanto da receita quanto do lucro dos trimestres. Desta maneira, não é recomendado mudanças nas datas que atrapalhem os resultados do período – aliás, entregas no início do trimestre são altamente aconselháveis.

Agora o problema. Vamos supor que restam poucos dias para o fim do prazo combinado, a pressão para concluir o projeto aumenta conforme a energia da equipe envolvida é reduzida. Chega o momento em que muitas pessoas abordam o desafio trazendo sugestões como:

1. Esqueça os testes de unidade, foque nas integrações.

2. Faça testes de integração e de aceitação do usuário em paralelo.

3. Adie o controle de configuração.

4. Conserte os bugs e outros problemas diretamente na produção.

5. Pule alguns dos testes mais difíceis, particularmente os de integração.

6. Faça testes funcionais somente para os três principais cases de uso.

7. Terceirize os testes de aceitação de usuário.

8. Deixe para se preocupar com a qualidade dos dados após o lançamento.

9. Chame uma equipe de programadores para expor erros e falhas de segurança.

10. Faça os consultores trabalharem dobrado.

11. Esqueça a validação dos processos de negócio e revisões de código.

12. Não ative todas as integrações até mais tarde; faça atualizações noturnas para manter as coisas sincronizadas.

13. Crie uma cópia temporária do novo sistema e migre alguns usuários de baixo impacto para ela, de modo a lançar o sistema dentro do prazo -- mesmo ainda mantendo os usuários pesados na ferramenta antiga. Enquanto isso, seus desenvolvedores trabalharão somente na versão real. A estratégia exige recursos externos para a entrada tripla de dados necessária.

14. Não faça treinamentos curtos semanais, efetivos e baseados em tarefas; ao invés disso, faça uma sessão longa de apenas um dia.

15. Pule todo o preciosismo envolvido no processo de entrega tradicional de TI (ela ocorrerá de qualquer forma) porque seus desenvolvedores precisam passar imediatamente para o próximo projeto – que também está atrasado.

Em outras palavras, você ouvirá diversas ideias incompletas, típicas de iniciantes, vindas de pessoas que, em outras situações, são profissionais. É o tipo de coisa que o levaria a recusar um candidato em uma entrevista de emprego, mas que quando vindas de um comitê revisor composto por chefes o leva a morder a língua.

Todo mundo passa por situações desse tipo. Tomar qualquer um dos atalhos “fáceis” não é recomendado, mas a indústria o faz desde os anos 60 e somente a equipe mais zelosa resistiria à tentação de recorrer a eles. A TI sequer sinaliza uma mudança de mentalidade, sobretudo no que se refere a projetos com complicações que poderiam ser evitadas.

Mas como entregar um projeto sem imbróglios não recorrendo aos atalhos? Aumentando o intervalo entre ele e o próximo, oferecendo margem de manobra maior, como foi feito com o desenvolvimento de software. Se você deseja inovar ao invés de tomar decisões em um modelo ultrapassado, também pode tentar as seguintes ideias:

1. Crie bônus e incentivos para o alcance de metas, mas certifique-se que não dizem respeito a datas específicas.

2. Até onde for possível, baseie todas as integrações em sistemas de mensagens reais que registrem todas elas (e mantenha seus logs por no mínimo algumas semanas) para aumentar os esforços de correção de bugs, testes, reconciliação e recuperação.

3. Assuma que todas as integrações terão mais dados corrompidos e semânticas problemáticas do que você pode prever. Assim, independente de quão realista o prazo para migração, normalização e limpeza seja, adicione 25% a ele.

4. Promova a integração contínua: complete a construção do sistema à noite, com suítes de testes que crescem junto com o código, e traga integrações externas e dados reais ao sistema o mais cedo possível.

5. Faça com que os usuários colaborem com a interface e avaliem qualquer resultado antes que se tenha alcançado 25% da verba do projeto e mantenha-os envolvidos até o fim.

6. Compre todas as sandboxes possíveis e use-as a partir da metade do projeto até o final. Conecte-as umas às outras para ter um desenvolvimento realista e testar o ambiente o mais cedo possível.

 7. Seus patrocinadores executivos precisam entregar demos das suas partes do sistema às suas equipes ao fim de cada etapa. Isso é bom para adoção de usuário, mas é ainda melhor para se certificar de que as expectativas a respeito do prazo e das ferramentas não se percam de vista.

8. A maneira de evitar a catástrofe próxima ao prazo final é reduzir a quantidade a ser entregue ao longo do projeto, de forma gradual. É difícil, mas ideal para as iniciativas que dispõem de mais tempo e verba do que é de fato necessário.

9. Tenha um plano B e discuta cerca de seis semanas antes do prazo final as consequências que não conseguir lançar um projeto traria para o negócio.

10. A cada revisão de etapa, instrua os membros da equipe a revelarem as informações negativas. Com palavras, ações e expressões, encoraje-os a serem realistas em relação a prazos e riscos, nunca punindo o mensageiro em caso de más notícias.

11. Use uma implementação por fases, como cada incremento funcional instalado a partir de uma base sólida do ciclo anterior. Depois, migre os dados de histórico (começando com os do ano passado, retrasado e assim por diante) e esteja disposto a manter offline por tempo indeterminado os de baixa prioridade.

Site: Computerworld
Data: 30/06/2015
Hora: 8h30
Seção: Gestão
Autor: ------
Link: http://computerworld.com.br/como-lidar-com-pressao-para-entrega-de-projetos-de-ti