Dando prosseguimento, vou falar sobre o segundo motivo da minha bronca com templates:

• 02. Templates dão a falsa sensação de que o processo que será
  utilizado já está definido, e terminam matando a fase de setup, que é uma
  das mais importantes da vida de um projeto.

Não acredito em um processo fechado de desenvolvimento de software. Acho que ninguém acredita (pelo menos não de verdade).

Acredito que existem vários excelentes meta-processos, cada um com
maior ou menor formalidade e que todos eles podem ser customizados para
atender necessidades especificas de um projeto.

E customizar é extremamente necessário, porque cada projeto é um projeto. Cada caso é um caso.

E, dessa forma, a melhor estratégia é analisar as necessidades daquele
caso e formatar um  processo especifico, contendo as
práticas e as técnicas que melhor se adequam a ele.

Para isso, acredito também que deve sempre existir em um projeto de software
um período que gosto de chamar de setup, mas que pode ter diversos
outros nomes dependendo da sua norma/autor/metodologia favorita.

No setup, analisamos o problema, definimos como iremos proceder, como
iremos trabalhar, quais ferramentas serão usadas, quais artefatos serão
gerados, quais são os papeis, como comunicaremos progresso, como
controlaremos escopo e por aí vai…

Gosto de pensar que é nessa fase que definimos quais perguntas serão
feitas durante o projeto (“quando a funcionalidade x fica pronta?”,
“quando o release y vai ser entregue?”) e como elas serão
respondidas.

Mas o que isso tem a ver com templates?

Tem a ver no fato de que muitas empresas confundem os templates como se eles fossem o próprio processo.

A existência desses formulários-padrão eliminaria a necessidade de um
setup de projeto, pois já estaria “pronto”, só precisando ser
“seguido” (ou seria “preenchido”).

Nessas organizações, é comum ouvir “o processo aqui na empresa é
assim, você preenche essa lista de requisitos no início do projeto,
baseado nela escreve os casos de uso seguindo esse modelo, controla os
prazos nessa planilha, faz as entregas preenchendo esse formulário e no
final escreve esse termo de encerramento”.

E se faltar algo em um template? E se sobrar? E se não existir um template para uma necessidade?

Teoricamente, seria no setup que isso seria detectado e resolvido. Mas
como o processo está “pronto”, normalmente esses problemas não são
notados. E quando surgem tende-se a tentar “encaixar” a informação que
falta em algum “template” já existente. Por que não adaptar o
“processo” nesse momento? Porque existe sempre o medo de se mudar o que
já esta feito e que teoricamente funciona. Bancar uma cruzada contra uma
mentalidade dominante é sempre desgastante, muitas vezes as pessoas
preferem se encaixar em uma realidade (ou processo) do que tentar
melhorá-lo.

Esses comportamentos muitas vezes são reforçados pelas auditorias
internas de processo. Essas auditorias deveriam procurar evidências de
controle dos projetos (se as perguntas que esclarecem o andamento do
projeto estão sendo respondidas), mas terminam muitas vezes checando
simplesmente se uma série de formulários estão preenchidos.

Para não dizerem que eu só reclamo, deixo minhas sugestões:

• Nunca abra mão do tempo de setup do projeto. Esse será o momento em que você e sua equipe irão analisar o problema e definir como vai ser
  atacado. É nesse ponto que se estabelece a estratégia inicial. Com o
  tempo, essa estratégia será alterada, mas pelo menos vocês terão ideia
  de por onde e como começar.

• Acredito que a relação entre um gerente de projetos e o gerente de
  desenvolvimento deve ser a seguinte: o gerente de desenvolvimento
  determina as informações de que ele vai precisar durante o ciclo de vida do
  projeto. Daí a equipe apresenta as maneiras que ela vai utilizar para
  fornecer tais informações.

• Uma renca de documentos não são um processo.

• Preencher um monte de documentos não torna ninguém um gerente de projetos.

• Preencher documentos não aumenta nem diminui as chances de sucesso de um projeto. Mas gastam tempo e paciência.

• O cliente quer controle, não formulários preenchidos. Se você
  conseguir provar que controla o projeto com Origamis (provar mesmo), o
  cliente aceitará numa boa.

Resumindo. Se sua empresa conseguir usar os templates como uma base
para construção de processos melhores, ótimo. Porém, se eles deixarem de
ser uma inspiração pare se tornarem uma realidade a ser seguida, fuja
deles. Vão te engessar sem te trazer benefício algum.