Cinco problemas que (quase) todo projeto de tecnologia possui
Eu imagino que meus caros leitores atuem de alguma forma na área da tecnologia da informação - afinal de contas, este é um blog que cobre as notícias e as novidades desse “espaço”. Posto isso, também assumo que grande grande parte desse público trabalhe com projetos de tecnologia (sejam eles de curta ou longa duração) ou mesmo com produtos de tecnologia. Estou chegando perto?
Se esse é o seu caso, eu acredito que o texto abaixo será de seu interesse 😉
Como parte de um exercício mental, eu escrevi essa carta aberta para os líderes de um projeto de TI fictício que não anda muito bem das pernas. Tentei incorporar os problemas mais comuns que um profissional de tecnologia passa durante as principais fases do projeto (iniciação, planejamento, execução e monitoramento, no caso) e também elenquei algumas soluções, pois como se diz aqui na terrinha “se seu problema não tem solução, toda preocupação será em vão”.
A dura realidade de um tradicional projeto de TI
Prezados gestores do Projeto X
Estou escrevendo com grande respeito e sincera estima¹.
À medida que navegamos por entre nossos desafios atuais, refletir sobre os principais aspectos que influenciaram nossa jornada é mais do que natural. Nesta carta aberta, não pretendo atribuir culpas, mas encorajar um diálogo transparente e construtivo para nos ajudar a avançar com maior alinhamento e eficácia.
Os pensamentos e opiniões expressos aqui representam minha perspectiva pessoal sobre o estado atual e futuro do Projeto X. Eles são baseados em meu entendimento, observações e experiência, mas não devem ser interpretados como a avaliação definitiva ou final do assunto.
Os obstáculos²
Desde o início, nosso projeto encontrou obstáculos significativos, muitos dos quais decorrem de decisões fundamentais que moldaram nossa trajetória. Gostaria de destacar os seguintes pontos que, acredito, são os mais importantes:
Precificação do projeto e alinhamento do escopo - A estrutura de preços inicial oferecida ao nosso cliente foi subestimada em relação à complexidade real do trabalho necessário. Como resultado, introduziu restrições financeiras e operacionais, dificultando a manutenção do nível de qualidade que todos aspiramos entregar. Além disso, o escopo inicialmente definido e acordado representava apenas uma fração das expectativas reais, levando a ajustes contínuos e esforços não planejados.
Definição e discussão de requisitos - Os requisitos do projeto não foram discutidos completamente antes da execução, resultando em ambiguidades e lacunas que se tornaram aparentes à medida que progredimos.
Viabilidade do cronograma e expectativas de entrega - A urgência em atender ao cronograma do cliente resultou em um planejamento ambicioso que não permitiu uma avaliação adequada das principais dependências.
Avaliação de maturidade e prontidão da equipe (readiness assessment) - O nível de maturidade e prontidão da equipe para as demandas do projeto não foram avaliados completamente.
Codificação e requisitos técnicos - Certos aspectos técnicos, como padrões de codificação e decisões arquitetônicas, não receberam a atenção necessária nos estágios iniciais. Isso levou a retrabalho e dívida técnica que poderiam ter sido mitigados com uma estrutura inicial mais forte.
As lições aprendidas
Embora seja muito cedo para formalizar um processo de "lições aprendidas" para o projeto (já que ainda temos muitas entregas planejadas e dezenas de ajustes técnicos para executar em nossa base de código), tive a oportunidade de pensar sobre isso com moderação e conversar com vários membros da equipe técnica, coletando valiosos feedbacks que, creio, me permitem iniciar esta discussão crítica com as seguintes suposições:
Um processo de escopo mais completo (scoping process) no início poderia ter nos ajudado a definir expectativas mais realistas.
Uma abordagem mais abrangente e iterativa para coleta de requisitos teria fornecido maior clareza e uma base mais forte para a tomada de decisões em cada estágio do desenvolvimento.
Embora reconheçamos totalmente a importância de atender às expectativas do cliente, um cronograma mais equilibrado poderia ter facilitado um processo de entrega estruturado e eficaz, reduzindo o risco de retrabalho e desafios inesperados.
Garantir que a equipe tenha a experiência, o suporte e as ferramentas necessárias é crucial para manter a produtividade e o moral. Não obstante, uma avaliação mais aprofundada da prontidão do cliente para a nuvem (cloud readiness) ajudaria no planejamento de recursos e na mitigação de riscos.
Estabelecer diretrizes técnicas bem definidas desde o início aumentaria a eficiência e a manutenibilidade.
Reconhecer essas oportunidades perdidas pode nos permitir focar no que é essencial e no que precisa ser feito para concluir o projeto com a qualidade desejada no tempo restante e com a certeza de que entregamos valor ao negócio do nosso cliente.
O papel da equipe de liderança
Nossas equipes de desenvolvimento e migração estão enfrentando desafios técnicos significativos, o que é esperado em um projeto com os obstáculos descritos acima. No entanto, a abordagem atual da equipe de liderança tende a se concentrar principalmente na identificação de deficiências dentro dessas equipes, em vez de mobilizar nossa expertise coletiva para superar obstáculos.
Essa ênfase na responsabilidade, embora importante, pode estar inadvertidamente criando um ambiente em que os membros da equipe hesitam em levantar preocupações ou propor soluções inovadoras. Quando nossas discussões se concentram em determinar a responsabilidade pelos problemas em vez de resolvê-los de forma eficiente, corremos o risco de estender os prazos e diminuir a qualidade de nossos resultados.
Meu entendimento é que poderíamos alcançar melhores resultados ajustando nossa abordagem de várias maneiras:
Primeiro, reformulando nossas discussões para priorizar o desenvolvimento de soluções em vez da atribuição de responsabilidade. Essa mudança provavelmente aceleraria a resolução de problemas e encorajaria uma identificação mais proativa de problemas.
Segundo, reconhecendo que mesmo o planejamento mais completo não pode antecipar todos os desafios no Projeto X. Esse reconhecimento promoveria uma avaliação mais realista do nosso progresso e desafios.
Terceiro, estabelecer mecanismos que incentivem a comunicação transparente em todos os níveis da organização, garantindo que os problemas potenciais sejam identificados e resolvidos antes que afetem as entregas críticas.
Nossa experiência combinada é mais do que suficiente para superar os desafios que enfrentamos. Ao enfatizar a resolução colaborativa de problemas e criar um ambiente em que todos os membros da equipe se sintam capacitados para contribuir com as soluções, podemos melhorar significativamente nossa eficiência e qualidade de trabalho.
Agradeço a oportunidade de discutir essas observações mais detalhadamente e contribuir para o desenvolvimento de uma estrutura mais colaborativa para o Projeto X.
Atenciosamente,
--
Ricky Martin
Arquiteto de Soluções em Nuvem
Contoso³ @ Projeto X
Notas:
⁰ Alguns termos em português podem não expressar completamente o sentido de alguns conceitos descritos no texto; para esses casos, coloquei o termo correspondente em inglês entre parênteses.
¹ Essa frase é um resquício do tempo em que eu trabalhei na CDHU (Companhia de Desenvolvimento Habitacional e Urbano de São Paulo).
² Resolvi suavizar um pouco a coisa toda e tomei a liberdade de usar “obstáculos” como um eufemismo para “problemas”.
³ A Microsoft usa uma variedade de nomes de empresas ficcionais nos materiais de treinamento e documentação de seus produtos. Contoso é uma dessas empresas 😁
