Lições aprendidas na forma de Padrões de Projeto: Case Aplicativo

Uma das ferramentas mais poderosas para otimizar o trabalho de gestão de projetos no dia-a-dia é a coleta de Lições Aprendidas. Essas lições, que são experiências de projetos passados, podem ser coletadas de diversas formas, a mais comum é a criação de documentos em que cada projeto deve registrar o que “deu certo” e o que “deu errado”. Os problemas do uso deste documento são dois: Muitos GPs se sentem desconfortáveis de registrar seus erros e de divulgá-los para a empresa e o outro, é que esses docuRAmentos geralmente ficam armazenados nas pastas dos projetos, não sendo nunca divulgados para o resto da Organização.

No intuito de solucionar estes dois problemas, certa vez, participei da criação de um “padrão de projeto”. A empresa onde eu trabalhava na época realizava projetos de infraestrutura de TI e montamos estes padrões para reduzir a incidência de erros recorrentes. Neste padrão incluímos os pontos abaixo, que compuseram sua estrutura básica:

• Escopo – Registra o que “normalmente” faz parte do escopo desse tipo de projeto
• Premissas e Restrições – Já que os projetos são similares, pode-se também reutilizar as premissas (pressupostos) e as restrições.
• Matriz de Responsabilidades – No formato de uma tabela RACI, estruturamos um padrão de tomada de decisão, incluindo os stakeholders que normalmente participavam daquele tipo de projeto.
• Riscos mais frequentes – Apresenta os riscos mais críticos que podem ocorrer na categoria de projeto.
• Cronograma de Marcos – Em alguns casos é possível identificar tempos-padrão para execução de atividades de um projeto. Com isso, é possível montar um cronograma de marcos (pontos importantes do projeto), para tomar como base de prazo para projetos futuros.

O resultado deste padrão tomou um formato similar ao modelo abaixo. Neste caso, apresento um exemplo de padrão para o desenvolvimento de aplicativos, por ser mais didático.

Em projetos de aplicativos, de forma simplificada, tem-se uma fase de Concepção, em que são coletados os requisitos e determinados os padrões visuais (User Interface – UI) e de experiência do usuário (User Experience – UX). Na fase de Desenvolvimento é definida uma arquitetura de software e é realizada a codificação e testes. E finalmente, na fase de Entrega, obtem-se a aprovação do cliente, configuram-se os servidores de conteúdo (o que aparecerá no app) e faz-se a publicação nas lojas (Ex: Googleplay, Appstore, Windows Store etc).

Em termos de Premissas e Restrições é importante definir que linguagem será utilizada, se o conteúdo será estático ou dinâmico e como será tratado e hospedado o conteúdo e a matriz de decisões inclui os principais papéis envolvidos neste tipo de projeto.

Entre os riscos, elencamos as mudanças (de visual e funcionalidade), muito recorrentes neste tipo de projeto e os devices, ou seja, em que aparelhos o app rodará. Por último, no Cronograma, definem-se os marcos e, idealmente, as datas, não adicionados ao exemplo por haver grande variação de datas, de acordo com a quantidade de tecnologias, telas e conteúdos.

Existem, obviamente, muito mais pontos a observar, mas para manter o exemplo didático, suprimi uma série de dados do Padrão.

Baixe aqui o padrão em Excel e monte o seu, de acordo com os tipos de projeto que sua empresa mais trabalha.

Leia também:

• Como fazer uma EAP/WBS

Espero ter ajudado,

Eli Rodrigues

—

Créditos: Imagem do aplicativo extraída do site Design Criativo (http://www.dcriativo.com/)

Agradecimentos: Jaqueline Silva, estagiária de computação que me auxiliou na construção do primeiro padrão e ao José Brandão Júnior, da TAP4Mobile, que me municiou com informações para montar esse padrão de apps.