Scope Creep: Projetos que mudam DEMAIS durante o desenvolvimento - O cliente é o inimigo?

Você acaba de ser chamado para participar de um novo projeto. A tecnologia a ser usada, será de ponta, já que o cliente deseja alterar uma aplicação e pediu, especificamente, para usar o que há de mais moderno.

O problema é que o prazo está curto demais e o Gerente Noçãoless™, prometeu que tudo seria feito dentro do prazo acordado, com o desenvolvimento iniciando-se imediatamente. E como o tempo é curto não foi especificado direito o que a entrega deveria conter. E como o sistema precisa estar pronto para ontem, não é feito um protótipo de tela. O código começa a ser feito imediatamente, com base em vários "print screens" fornecidos do sistema anterior.

Feito o pagamento inicial, a equipe começa a desenvolver algumas telas, código de acesso à base de dados e quando já se passaram 20% do tempo, já existe uma versão funcional do sistema. O mundo é perfeito e estão todos felizes, mesmo virando algumas noites e perdido 2 ou 3 finais de semana. Chega o dia para mostrar 1 mês de trabalho duro...

E a primeira coisa que o seu cliente diz é: "Cadê o gráfico em pizza e a importação/exportação para Excel?". A primeira coisa que se passa pela cabeça do desenvolvedor é: "PQP!" ou "[Frase auto-censurada, o Meio Bit é um blog família]!". Com tantas outras funcionalidades e componentes complicados que deram um trabalhão, o cliente se preocupou com algo nunca antes mencionado. O gerente noçãoless entuba tudo e diz que isso estará feito na próxima entrega, antes do prazo final. Entubar é o termo técnico usado em tecnologia para aceitar tudo e qualquer coisa, sem avaliar custo, tempo, recursos e ainda com areia. Só há um problema: ninguém JAMAIS havia mencionado gráficos em pizza ou importação/exportação de planilhas até aquele momento.

O requisito do projeto mudou e o ciclo se repete a cada entrega. O prazo final se aproxima, e por mais que a equipe se esforce, a quantidade de pedidos cresce semanalmente, sempre faltando alguma coisa. A interface muda o tempo todo também, com mais e mais recursos "essenciais" sendo requisitados. Muitas vezes, pessoas diferentes pedem funcionalidades conflitantes. Enquanto a atenção é fortemente focada em pontos como esse, a criptografia de arquivos, importantíssima, ficou de lado.

O Scope Creep, que poderia ser traduzido de diversas formas como escopo arrastado, deformação de escopo, escopo movediço. Para quem está começando na área, escopo de projeto é uma espécie de lista do que será entregue, e ainda mais importante, uma lista do que não será. É um documento simples, que define limites do que deve ser feito e uma vez que ele está fechado, você terá um prazo e custo. Mudanças são necessárias e serão pedidas, mas se elas saírem de controle, você terá um frankensoft, um cliente insatisfeito e nenhuma compensação/reconhecimento pelo esforço,

Moral do Post:

- Ninguém deve achar nada em um projeto. Converse bastante com as pessoas responsáveis por usar o seu programa e anote suas expectativas.
- Nada de prazos-mandrake: a perda de confiança irá minar completamente futuros projetos.
- Coloque tudo em papel, assinado por 3 pessoas, com visto em todas as páginas. Por menor que seja o seu projeto, ele precisa de um acordo mínimo.
- Se o escopo mudar, avise-o sobre prazo e custo: você não está fazendo um favor, mas prestando um serviço profissional.
- Crie, junto com o seu cliente, uma lista de prioridades. Se ela mudar, avise-o sobre prazo e custo.
- Não tenha medo de informar que aquele botãzinho novo para mandar arquivos "com senha" irá demorar 200 horas para ser criado e testado. Aproveite as reuniões para redefinir as prioridades.
- Lembre-se: não é preciso usar metodologias complexas para evitar problemas. Um simples e-mail pode evitar enormes dores de cabeça depois.

Fonte: Bicalho´s Memory About Fraked Up Projects