Projetos de software são normalmente organizados, dirigidos e conduzidos por gerentes de projetos.  Na grande maioria dos casos, entretanto, gerentes de projeto não possuem o conhecimento necessário para coordenar e liderar tecnicamente um projeto. O efeito prático é o adiamento de riscos técnicos “desconhecidos” ou uma priorização inadequada das ativdiades de projeto o que provoca efeitos crônicos ou mesmo  desastrosos em projetos.

Diversas metodologias já perceberam esta questão e suportam idéias para criar um contra-ponto técnico de liderança em projetos.  Um exemplo a respeito  é o AUP, que tem como um dos seus princípios basear o projeto em arquitetura – “Focus on the architecture early to minimize risks and organize development”.

Este contra-ponto pode ser visto também como o papel do arquiteto e das atividades de arquitetura de software em um projeto. Parafraseando Paul Clements, podemos definir arquitetura como “Um pequeno conjunto de decisões técnicas que produzem um grande efeito positivo  no projeto e no produto de software sendo construído”.

O Produtor e o Diretor de Software

“O produtor é quem gerencia as necessidades práticas e  que organiza um orçamento e o cronograma a ser aprovado pelo executivo.”, Wikipedia
“O diretor de cinema é considerado, em termos gerais, o criador do filme.”, Wikipedia

Isto  cria uma divisão positiva e saudável na produção de filmes no cinema, que inclusive guarda fortes correlações com projetos de software, conforme discutimos no blog Fazer Software É Como Construir uma Ponte ou Dirigir um Filme.

Em termos de TI, podemos criar a seguinte metáfora:

• O produtor é o gerente do projeto.
• O diretor é o arquiteto de software do projeto.

Esta metáfora pode ser vista como um novo estilo de projeto, chamado de projeto dirigido por arquiteturas de software. Neste tipo de projeto, a arquitetura é o elemento primário e central para tomar decisões como:

• Organização de projetos e estruturas de times.
• Desenvolvimento de cronogramas realistas.
• Planejamento de testes.
• Organização do escopo.
• Priorização de requisitos.
• Mitigação de riscos.

Em termos práticos, apresento aqui um pequeno exemplo de priorização de requisitos, realizado com e sem o uso de conhecimento de arquiteturas de software.

Considere que você receba (enquanto gerente)  um conjunto de requisitos do usuário. Um gerente típico atacaria estes requisitos com foco apenas na prioridade colocado pelo cliente. Um arquiteto, por outro lado, elabora mais o problema e usa a matriz abaixo para organizar o seu trabalho.

A prioridade continua sendo importante, mas os requisitos prioritários e complexos são endereçados e implementados  primeiro. Com isso, os riscos são expostos cedo no projeto. Em termos práticos, aspectos de usabilidade, desempenho, escalabilidade ou segurança se tornam latentes no primeiro ou secundo décimo temporal do projeto, enquanto ainda temos tempo de endereça-los.

Para os curiosos no tema, este estilo de fazer projetos é discutido com mais ênfase no livro  Architecture-Centric Software Project Management: A Practical Guide.