A prática do “Enquadramento 360”: Como começar um projeto da maneira certa!

É muito comum em projetos de software investirmos muito tempo em análise de requisitos e inúmeras páginas de documentação, que requer muito tempo (as vezes até 6 meses!) e ao final quase sempre são apenas “engavetadas”.

Me deparei muitas vezes com essa situação e comecei a me questionar a respeito de até onde vale a pena focar tanto tempo e esforço construindo inúmeros diagramas e especificações.

Foi quando, conheci uma técnica muito utilizada pelas empresas na França, onde o principal foco é alinhamento entre as expectativas do negócio, desenvolvimento da solução e pessoas. Essa técnica é conhecida como Enquadramento 360^o (em francês Cadrage 360^o). 360 justamente porque essa técnica não abrange somente os aspectos funcionais mais também técnico e organizacional de um projeto de desenvolvimento de software.

Por definição, o Enquadramento trata-se de “um estudo, feito em um curto espaço de tempo, durante o qual um número sucessivo de workshops e atividades são realizados para alinhar todos envolvidos em torno de um mesmo tema, que permita criar um resumo global para validação e iniciar um projeto de software”.

Para ser produtivo e eficiente o Enquadramento deve ser feito em um curto espaço de tempo, algo em torno de 3 a 4 semanas. Se despendermos muito tempo com esse processo, acabamos com os mesmos problemas ocasionados utilizando técnicas tradicionais de entendimento e concepção de projetos de software. O ideal é encontrar um modelo que componha as informações necessárias para tomar decisões assertivas e que não demande tempo desnecessário para que o projeto possa efetivamente começar a ser construído. Nesse aspecto, o enquadramento 360 é inspirado em metodologias ágeis, considerando não ser necessário especificar em muitos detalhes o projeto, já que as necessidades vão evoluindo no tempo.

Como o próprio nome diz, conforme realizamos as atividades e workshops, o intuito é construir um “quadro” ou visão, que abranja as diferentes faces do projeto candidato a concepção.

Essa visão é estabelecida em uma estrutura baseada em 3 eixos: Produto, Projeto e Equipe.

• Adotar uma visão do produto

  • Definir  “como” a solução vai suportar a estratégia de negócios;
  • Definir primeiro sua aplicação, características e benefícios, e não o projeto;
  • Estabelecer um roadmap para a construção inicial e melhorias posteriores;
  • Analisar as integrações de TI com seu núcleo e/ou sistemas de back-office.

• Definir o projeto sobre a visão de produto

  • Criar uma estratégia de projeto baseada no produto;
  • Definir projetos com dependências mínimas;
  • Estabelecer controles intermediários para reduzir os riscos de integração.

• Conceber e desenvolver a equipe que vai criar o produto
  • Analisar os impactos organizacionais, definir projetos de gestão de demandas;
  • Estabelecer critérios para selecionar e contratar fornecedores.

A concepção dessas visões é feita através da realização de workshops temáticos, conforme quadro abaixo:

É primordial que o tempo dos workshops sejam previamente estipulados (2h ~ 4h) e que não o ultrapassem, para garantir a disponibilidade das pessoas e não permitir que outros assuntos não relevantes, sejam discutidos nesses encontros. Em alguns casos, onde os projetos levem a necessidade de abordar outros temas mais específicos (projetos de inovação tecnológica, arquiteturas complexas com diversos sistemas integrados, etc...) não será possível atingir o resultado esperado em um único workshop. Caso isso aconteça, aconselho a não estender o tempo do workshop, pois isso pode gerar desconforto, cansaço e desinteresse nos participantes, nesses casos, é melhor agendar um segundo workshop, no menor espaço de tempo possível, para concluir as atividades e atingir o resultado esperado.

A técnica de workshop, prove um maior alinhamento entre as diferentes partes envolvidas no projeto. Uma mesma visão de cada tópico é compartilhada entre patrocinadores, técnicos, funcionais, operadores e gestores.

Toda documentação consolidada após a execução dos workshops, deve ser validada e aprovada pelos tomadores de decisão no projeto: patrocinadores, gestores e arquitetos. Conforme nossa experiência, podemos citar os pontos mais importantes, os quais merecem uma atenção especial:

• Time: Certifique-se que os papéis e responsabilidades estão distribuídos conforme o posicionamento dos atores do projeto. Ex: Product Owner, Scrum Master, Gerente de Projetos, Arquiteto técnico, ...
• Orçamento e recursos: Valide se o orçamento e recursos estão claros e de acordo com as necessidades do projeto. Um projeto mal orçado, pode gerar falsas expectativas e trazer consequências drásticas.
• Arquitetura: Certifique-se que a arquitetura da solução segue os padrões estabelecidos pela organização e que todas integrações (internas e externas) foram mapeadas.

O resultado da compilação das informações obtidas nos workshops, irá compor o quadro do projeto, conforme figura abaixo:

Outro documento importante resultante do Enquadramento 360, é o DAG (Documento Geral de Arquitetura) que especifica a arquitetura da solução a desenvolver, assim como, as integrações com o SI.

O Enquadramento 360 é uma forma dinâmica e rápida de especificar e começar do jeito certo um projeto de desenvolvimento de software, cria uma visão consolidada e compartilhada dos objetivos e propósitos do projeto de software, possibilitando mitigar riscos com muita antecedência, evitando o desperdício de investimento em projetos que por muitas vezes não estão condizentes com as diretivas de negócio ou estratégia das empresas.

Os agilitas dirão que o Enquadramento 360 é a Iteração 0 do projeto, o que de uma certa forma é certo, só que o Enquadramento 360 pode ser aplicado também a projetos realizados de formas mais tradicionais, como waterfall. O Enquadramento 360 se justifica, mais que tudo, para projetos de inovação ou para os que tenham uma restrição muito forte de tempo.