Uma grande ideia não salva um escopo ruim. E independente do projeto, o escopo é um dos pontos fundamentais para o sucesso do produto. Nessas horas, não importa quão boa seja a ideia ou a proposta de valor, sempre haverá um risco muito grande associado ao projeto caso não sejam especificados claramente os requisitos que compõem o produto.

Escopo do produto

“De acordo com o Guia PMBOK, escopo do produto são os recursos e funções que caracterizam um produto, serviço ou resultado.”

Vamos fazer um pequeno exercício, digamos que o nosso produto é um edifício residencial. Seria possível iniciar a construção dele sem antes saber com clareza informações como:

• localização;
• dimensões;
• quantidade de andares;
• quantidade de blocos
• total de apartamentos;
• total de apartamentos por andar;
• número de cômodos por apartamento;
• número de vagas de garagem;
• quantas e quais serão as áreas comuns (internas e externas)
• haverá algum espaço para lojas comerciais;
• etc.

Você não precisa ser arquiteto ou engenheiro para saber que sem um escopo detalhado, o risco dessa construção dar problema é bem grande. Isso porque no nosso exercício focamos apenas nos aspectos estruturais do nosso produto “edifício residencial”, nem entramos no mérito do escopo de projeto, como materiais necessários e equipe, por exemplo.

Perceba que criar uma plataforma segue quase a mesma lógica, e que, assim como no universo da construção civil, sem as especificações necessárias fica quase impossível fazer qualquer tipo de estimativa, seja ela de esforço, tempo e até mesmo investimento.

Mapeando um produto digital

Existem diversas técnicas que podem ser utilizadas para mapear uma plataforma, e cada uma pode ser utilizada conforme as características do projeto, e também do time que está aplicando.

Times de design e engenharia de software, por exemplo, podem tanto trabalhar em conjunto utilizando os mesmos métodos para fazer mapeamento iniciais, quanto se dividir e utilizarem métodos específicos de acordo com o que cada um precisa para estimar tempo e esforço de trabalho.

Aqui na ateliware, por termos um processo muito próximo entre os dois times, nossa abordagem se baseia em alguns métodos principais:

• mapeamento de jornadas
• mapeamento de fluxos
• mapeamento de requisitos funcionais
• mapeamento de requisitos técnicos

A realização desses mapeamentos vai depender muito do que já foi levantado a respeito do produto. Na prática, ao final desse processo a expectativa é chegar com uma visão de escopo do produto. Algo como na imagem abaixo:

Representação simplificada dos elementos que compõem um produto digital.

O levantamento acima representa uma visão do todo, embora ainda estejam faltando os requisitos técnicos, como o que irá compor o back-end e detalhes sobre a infraestrutura, já é possível dimensionar o tamanho do produto.

Perceba que criar uma plataforma segue quase a mesma lógica que usamos para exemplificar o “nosso produto edifício residencial”. E da mesma maneira, aqui também precisamos especificar os elementos que compõem o produto como:

• total de áreas e páginas;
• total de funcionalidades e suas características;
• tipos de perfis de usuários e níveis de permissionamento;
• regras de negócio que podem influenciar a arquitetura do produto;
• infraestrutura técnica;
• entre outros.

Sem essas especificações fica muito difícil fazer qualquer tipo de estimativa a respeito do produto.

Reduzindo riscos de projeto

“Risco é um evento futuro incerto com probabilidade de ocorrência e potencial de perda.”

Muito embora, seja praticamente impossível prever todos os possíveis problemas que podem ocorrer durante uma fase de desenvolvimento de produto, com um bom levantamento em mãos estamos muito mais próximos de um projeto saudável e bem-sucedido, evitando riscos relacionado à:

• mudanças no meio do projeto;
• atrasos no cronograma;
• aumento significativo do orçamento inicial;
• problemas técnicos.

Um escopo mal estruturado impacta diretamente no desempenho do projeto. Ignorar esses riscos pode acabar inviabilizando o produto como um todo.

• Leia também: Dimensionando requisitos: o que seu produto realmente precisa ter?

Referências

• Product Scope Vs Project Scope | PM Study Circle
• Risk Management In Software Engineering: Types & Assessment | Software Testing Help