É uma tarde de terça-feira, e o gerente de projetos está em uma reunião com o responsável pela área de compliance, um Product Owner e a equipe do fornecedor que está desenvolvendo um portal do paciente para uma rede hospitalar. A área de compliance precisa da aprovação formal de um conjunto de controles até uma data de auditoria já definida. O Product Owner apresenta uma nova série de alterações solicitadas por profissionais de saúde — recebidas naquela mesma manhã — que são mudanças significativas, e não apenas ajustes de redação. O fornecedor solicita um documento de requisitos estável para que possa concluir o desenvolvimento e os testes. Todos fazem solicitações razoáveis, mas é impossível atender a todas simultaneamente. A cada semana, a equipe congela os requisitos para obter a aprovação necessária e, logo depois, reabre o escopo para incorporar o feedback real dos usuários. O retrabalho se acumula, o tempo para testes é comprimido e o rastro de auditoria começa a ficar confuso, pois decisões são revistas sem registros claros de aprovação.
Antes de definir uma metodologia de entrega, preveja onde este projeto falharia primeiro caso nenhuma ação fosse tomada.
A armadilha está em pensar que a equipe precisa escolher entre ser rápida e estar em conformidade. O verdadeiro problema é que o projeto mistura dois tipos diferentes de trabalho. Uma parte exige rastreabilidade, o que significa que devemos ser capazes de demonstrar como um requisito se transformou em design, depois em implementação, teste e, finalmente, aprovação. Outra parte exige aprendizado rápido, o que significa que esperamos revisar o que construímos à medida que aprendemos com os usuários. Quando se força o aprendizado rápido dentro de um processo de aprovação burocrático, surgem gargalos. Quando se força a rastreabilidade em um ciclo rápido sem controles claros, surgem apontamentos de auditoria. O instinto de quem está começando é pedir que todos se alinhem e congelem o escopo. Isso parece uma atitude de liderança, pois reduz ruídos momentâneos, mas frequentemente gera uma explosão de solicitações de mudança mais tarde, quando a realidade se impõe.
Realidade da Gestão de Projetos Em trabalhos regulamentados, não se negocia a data da auditoria. Negocia-se o que está no escopo para essa data e como as mudanças fluem pelos processos de aprovação.
Quando as pessoas falam em Agile (Ágil) ou Waterfall (Cascata), geralmente se referem a um conjunto de decisões. Neste curso, vamos dividir esse conjunto em três alavancas práticas que você pode definir intencionalmente.
A primeira alavanca é o ciclo de feedback, que se refere à frequência com que você obtém informações reais de usuários ou partes interessadas e as transforma em alterações no que está sendo construído. Ciclos curtos ajudam a aprender rapidamente, mas também geram um volume maior de mudanças que precisam ser gerenciadas.
A segunda alavanca é o horizonte de planejamento, que indica com quanta antecedência você planeja detalhadamente antes de se comprometer com a implementação e os testes. Um horizonte longo pode aumentar a previsibilidade, mas pressupõe que os requisitos permaneçam estáveis. Um horizonte curto aceita a incerteza, mas exige que as partes interessadas permaneçam engajadas para que a equipe não precise trabalhar com suposições.
A terceira alavanca são os pontos de controle, ou seja, momentos em que o trabalho deve atender a critérios definidos antes de prosseguir. Um ponto de controle pode ser uma aprovação formal, uma revisão de segurança ou uma etapa de validação para entrada na fase de testes. Pontos de controle reduzem riscos, mas adicionam carga administrativa de governança e tempo de espera.
Relacione essas três alavancas aos resultados do projeto e observe as compensações (trade-offs) envolvidas.