Escopo de software: o que é e como definir o escopo para o meu produto?

Por Giovanni Salvador

6 minutos de leitura

Definir o escopo de um projeto parece simples. O que preciso? O que quero? Como implemento? Mas não é simples assim. Existem frameworks de trabalho, metodologias e diferentes abordagens de como fazê-lo da melhor forma.

O fato é: a definição do escopo do seu produto ou do seu projeto são etapas cruciais que podem definir o sucesso ou o fracasso de onde você quer chegar com ele. O escopo de um produto consiste nas funcionalidades e requisitos necessários para crumprir seus objetivos por meio desse produto. Escopo do projeto é o trabalho que deve ser realizado para chegar a esse produto.

Aqui, o objetivo é falar de escopo de produto. Afinal, o escopo de projeto é uma consequência do que você precisa aliado ao formato em que irá desenvolver essa solução: time interno, freelancers, squads remotos ou empresas tradicionais de desenvolvimento de software.

Então, antes de partir para as User Stories (Histórias do Usuário) pense em qual é o objetivo do produto. Pode ser:

1. Validar modelo de negócio da Startup X, com objetivo de entender o market-fit da solução.

2. Implementar aprendizados documentados após rodar MVP para criar um produto escalável, metrificável e automatizado.

3. Criar produto para base de usuários engajados no marketplace da Startup Y com objetivo de resolver o problema X.

Se você for do tipo mais técnico é interessante ter objetivos de produto ainda mais específicos, o que ajudará muito a definir o escopo do seu produto com assertividade. Por exemplo:

4. Criar WebApp em React.js e Ruby on Rails que suporte 50K usuários com nível de processamento 200% maior que o atual que está em X

Bom, compreendido seu objetivo principal, vamos ao que interessa. Como seus usuários irão cumprir o fluxo idealizado por meio da sua aplicação? Com as tais User Stories.

User Story é uma descrição informal, com linguagem natural, de uma ou mais funcionalidades de uma aplicação. Geralmente são descritas do ponto de vista de um usuário final. Utiliza-se post-its para a documentação dessas histórias. E seguem uma estrutura: eu como (X) gostaria de poder (Y) para (Z). Exemplos:

Eu como usuário do blog gostaria de poder visualizar todos os textos

Eu como usuário do blog gostaria de poder ler os textos que gostei

Eu como usuário do blog quero poder compartilhar e dar notas ao texto lido

Eu como usuário do blog quero saber em que momento do texto estou

No caso descrito, temos a visão de um usuário final deste blog. Em ordem, as funcionalidades que resultam dessas User Stories são: home do blog, blog post (texto em si), botões de compartilhamento, estrelas de nota ao texto e barra de progresso de leitura.

Esse é um formato extremamente simples.

Vamos nos aprofundar um pouco, levando em consideração os seguintes passos:

1) User Persona

Mapeie as personas do seu produto. Entenda seus objetivos, dores, necessidades, comportamento e como generalizar isso para entender seus potenciais clientes. Da mesma forma que deve ter feito isso para se aprofundar no seu modelo de negócio ou para chegar ao ponto que está agora, tentando compreender como passar seu conhecimento sobre seu público para um escopo de software. Uma forma interessante de pensar é “Job to be Done”.

2) User Goals

Agora descubra o que seus potenciais clientes querem resolver por meio do seu produto. Você sabe o que seu produto será capaz de fazer e todos os atributos principais e incrementais dele. Agora tente resumir em poucos objetivos o que seus usuários querem. Sim, são coisas diferentes. Cada persona pode comprar seu produto por motivos muito diferentes. Por exemplo, no BossaBox vendemos produto de software. Há quem compre pelo design, há quem compre pela metodologia, há quem prefira a agilidade e transparência do acompanhamento e há quem compre pela abordagem inovadora de squads remotos de alto nível. Portanto, temos personas que preferem segurança. Outras inovação. Mas todas têm algo em comum: precisam de um produto de software. Quer saber como descobrir? Valide com elas. Pergunte. Vá à rua e compreenda a fundo atributos objetivos e subjetivos das suas personas.

3) User Steps

Agora entenda os passos e mapeie a jornada do usuário. Qual é o fluxo necessário para ela ou ele cumprir o objetivo? Para evitar erros de fluxo, por exemplo, ausência de passos/tarefas importantes, use post-its e coloque-os lado-a-lado. Assim, achar a peça que falta fica mais fácil. Voltando ao exemplo do blog, se o objetivo (goal) for achar um texto os steps poderiam ser: visitar página principal, adicionar filtro de escolha, ver opções, escolher e ir para página do texto escolhido. Ter um verbo de ação é muito importante!

4) User Stories

Nesse framework mais detalhado em termos de passo-a-passo, as histórias do usuário passam a ter uma característica mais de funcionalidade que irá completar esse fluxo e compreensão das tarefas. Quais são as funcionalidades que ajudarão seu usuário a cumprir os goals e passos descritos anteriormente? Completando o exemplo de forma visual:

5) Organize as tarefas conforme prioridade

Agora que está tudo melhor organizado, pense no que é prioridade para versão que será desenvolvida do seu produto. Se ele já existe, serão features mais avançadas, evoluídas, automatizadas, que melhorem a experiência de uso e facilitem o cumprimento das tarefas. Se for uma versão inicial, pense em tempo, custo, complexidade e recursos diversos que podem estar envolvidos. Se você fez um brainstorming com seu time, deve ter tido uma explosão de boas ideias para a versão inicial. Mas também é fato que devem estar apressados para o produto novo estar no ar, certo? Então é nesse sentido que deve orientar seu pensamento. As ideias são boas. Mas quanto mais ideias, maior o escopo, maior o prazo, o custo e a complexidade. Pondere bem para ter algo enxuto no ar rápido. Lembre-se: seu objetivo não deve ser um produto extremamente robusto, mas sim um produto que trará mais conhecimentos e aprendizado sobre seus usuários. De que adiantam várias funcionalidades sensacionais se elas não tiverem valor para ela ou ele lá atrás da tela usando sem que você tenha visto como usará, por que, se para ele/ela vale investir tempo usando aquilo para resolver seu problema naquele momento. Na internet os momentos são micro e as oportunidades infinitas. Seja enxuto!

6) Faça um corte em uma estrutura de Releases

Em primeiro lugar, faça um corte do que seria a menor parte necessária desse produto, o famoso Mínimo Produto Viável. No universo de startups e tecnologia, muito se fala em MVP. Mas poucas empresas sabem como trabalhar em cima desse termo importante e por vezes banalizado. Mínimo viável significa ser enxuto. Quais são as funcionalidades necessárias para validar as principais hipóteses que você tem sobre seu modelo de negócio e usuário? Se você fizer um produto com elas ele ficará extremamente satisfeito? Sim? Então pense novamente. O objetivo não é satisfação, é validação. O usuário ficará satisfeito em resolver seu problema em parte se o fizer dessa forma objetiva e prática como está sendo sugerido. Tudo que é melhoria, incremento, deixe para depois. E tenha certeza de que o conhecimento que esse produto enxuto trará a você será mais valioso do que ideias mirabolantes com algoritmos de recomendação, automação, perfeição e etc. Se a ideia for evoluir seu produto a abordagem é outra. Nesse caso, trata-se de usar esse framework de forma que possa implementar de forma estruturada e validada quais foram os aprendizados que rodar sua versão mínima trouxeram.

Releases são estágios de implementação de funcionalidades. Devem ser decididos conforme a quantidade de tempo e recursos envolvidos em cada versão. O próximo release é um aprofundamento do anterior.