Problemas Waterfall - PRD

Temos uma dificuldade muito grande em desenhar/antecipar como o projeto sera entregue no final, documentando o escopo como um todo sem deixar nada de fora. Alem de sabermos que o cliente irá solicitar alterações, pois o negocio vive mudando e o tempo de mudança hoje é muito curto. A gestão de Mudança utilizando o Waterfall é mais trabalhoso e gera retrabalho e onera bastante o custo. O cliente quer entregas rápidas, e como no waterfall gastamos muita energia na fase de planejamento, o cliente já começa descontente antes de receber qualquer entrega. Resumindo: Alto custo; mais tempo gasto no planejamento; retrabalho; e demora para iniciar as entregas ao cliente.

O processo Waterfall é mais engessado, traz muita dificuldade nas alterações que surgem durante todo o processo, seja por mudança de negócio, alteração de legislação, aprendizado, experiência, etc.

Acredito que planejar com antecedência seu projeto não é totalmente negativo. Pois no geral quanto mais claro são suas metas e o quê tem que ser feito para alcançá-las, melhor é a dinâmica do trabalho. Porém se você não tiver o "jogo de cintura" para lidar com as mudanças vai emperrar seu projeto. É nesse ponto que vejo o valor do Agile de oferecer ferramentas e parâmetros para adequar seu planejamento com as necessidades de seus clientes (uma habilidade que pode alcançada de maneira empírica com anos de experiência e dedicação).

O modelo Waterfall, como o próprio nome cita, diz respeito a uma cachoeira, e assim como são as águas de uma cachoeira, são os processos Watelfall, pré estabelecidos, definidos e não voltam etapas ou retocedem. Gerando graves problemas a tipos de projetos como os de software que precisam estar em constante mudança;

Penso que o modelo Waterfall não considera projetos nos quais os resultados são incertos. Por exemplo, um projeto de desenvolvimento de modelo preditivo para determinar quais clientes irão cancelar um serviço. Nesse tipo de projeto não há como saber antecipadamente quais variáveis serão necessárias e se o modelo será assertivo. Portanto, um processo de desenvolvimento que não permite um escopo mais aberto não atende esse tipo de projeto.

Quando se trata de desenvolvimento de software, na maioria das vezes o(s) cliente(s) do projeto não tem conhecimento adequado em sistemas de informação para definir um escopo que seja aderente aos seus processos. Na verdade, muitas vezes o cliente não tem nem mesmo seus processos mapeados. É utópico achar que o cliente vai conseguir definir todo o escopo antes mesmo de ver uma primeira versão do sistema. É neste ponto que vejo o quanto o modelo Watherfall castiga os times de desenvolvimento na busca da satisfação do cliente, pois qualquer mudança (e ela vai ocorrer) gera impactos significativos na execução do projeto. Quais mais cedo se entrega valor ao cliente e o mesmo tem a oportunidade de confirmar ou rever seus requisitos, maior a chance de sucesso na entrega final e é neste ponto que o modelo Ágil se sobressai.

Jailton, é isso mesmo. Muitos clientes não têm uma ideia clara do seu processo para conquistar o objetivo desejado com um desenvolvimento de software. Para ser sincero, o cliente nem mesmo precisa ter conhecimento de Sistemas de Informação para que o projeto tenha sucesso, basta que ele apresente a ideia geral e o desenvolvedor traga um protótipo do que pode atendê-lo. O cliente precisa ter maturidade para saber que a entrega não será perfeita e o desenvolvedor, a maturidade de questionar e entender o processo, para trazer a melhor solução tecnológica. A metodologia ágil é excelente para fazer este trabalho a quatro mãos e finalizar o projeto com sucesso no menor tempo! O maior ganho da metodologia, para mim, é a gestão de expectativa, pois a evolução fica transparente para o cliente. O que acham?