#Agile – Como lidar com escopo de projeto? Aberto vs Fechado

Nov 21, 19 • Home, TecnologiaNo Comments

Houve um tempo, na prática de desenvolvimento de software, onde quaisquer projetos eram pensados em sua totalidade desde o princípio. Se houvesse um desafio, uma proposta, uma ideia, isso já era suficiente para despertar a necessidade de pensar em tudo, isto é, princípio, meio e fim antes mesmo de começar. Esse modus operandi está ligado a um mindset de um mundo mais contido, com maior noção do todo, mais fixo em suas estruturas de funcionamento, está ligado a crenças e desejos de permanência, algo que fazia muito mais sentido até há pouco tempo. Assim nasceu a ideia de Escopo Fechado, mesmo sem ser chamado por este nome.

Basicamente toda metodologia (ou toda forma de trabalho) que concebe o desenvolvimento de um produto ou de um projeto desta forma, isto é, tratando a necessidade de pensar em cada detalhe do escopo antes mesmo de começar, pode ser enquadrada como uma metodologia de escopo fechado, modo cascata ou gestão de projetos clássica. Em geral isso vem acompanhado também de implicações financeiras como um orçamento fixo e pré-determinado, sem muito espaço para avaliação de cenário, critérios de qualidade pareados ao valor investido e apreciação constante de expectativa.

Felizmente esse cenário mudou já há algum tempo, embora possa estar presente em muitas iniciativas. Trabalhar com Escopo Fechado tem sido um dos principais entraves de muitos gestores, em geral stakeholders que ou não compreenderam as desvantagens desta forma de pensar um projeto ou simplesmente dispõem de uma quantidade inicial de recursos bem limitada e não enxergam novos horizontes para além daqueles que precedem o início da iniciativa. O primeiro cenário, em tese, é mais fácil de lidar porque depende de um entendimento da questão. O segundo, isto é, aquele que lida com projetos e orçamentos bem limitados, talvez seja mais difícil porque em alguns casos a natureza intrínseca seja mesmo de um escopo fechado. O que ocorre e deve ser evitado, no entanto (e daí a motivação para essa escrita), são projetos complexos, com perspectiva aberta de continuidade, lidando com orçamento e projeto de maneira fechada, sem qualquer margem de manobra. É sobre isso que quero tratar.

O que é #Escopo?

Um passo para trás, amigos. Afinal, o que significa escopo? Sem rodeios: escopo é o conjunto de objetos-alvo de um projeto. É o que se quer entregar no fim das contas. Escopo é o produto, é o que se pretende, é a soma e a síntese dos desejos das partes interessadas. O escopo é o objetivo. O escopo é a meta. É a definição detalhada do que deve ser feito. O escopo é a linha de chegada de uma maratona, embora possam existir muitas corridas e pequenos milestones até chegarmos lá.

O Escopo pode ser representado de muitas formas: desde um parágrafo-síntese até um documento grande com detalhes de cada entregável desejado. Pode também ser organizado em camadas com temas mais amplos no topo e especificidades e micro-regras de operação em camadas abaixo. Essas camadas podem e muitas vezes são uma lista de desejos mais ou menos organizada. A quantidade de camadas, o nível de organização delas e a forma de organizá-las vai depender bastante do tamanho do projeto e do tempo de dedicação preterido para fase inicial de estruturação de um projeto. E isso também pode mudar ao longo do desenvolvimento.

Vamos apreciar um exemplo do que estamos chamando de Escopo em Camadas trazendo um produto digital, uma plataforma de cursos por exemplo. Aqui começamos por algo bem amplo como um “Módulo de Relatório”. Dentro desse tema eu posso ter diversos tipos de relatórios, como por exemplo um “Relatório de Escolas”. Para o relatório de escolas eu quero alguns tipos específicos de filtros, quero ter a possibilidade de download dos dados e quero algumas visualizações por gráficos. Para as visualizações em gráficos eu precisarei “Definir o tipo de gráfico”, “Criar legendas”, etc. Deste modo eu tenho níveis mais altos do escopo como a camada superior que podem ser chamada de épico ou temas e que muitas vezes interessam ao macro-planejamento dos stakeholders, até níveis mais baixos como a camada de tarefas ou tasks que interessam e organizam a ação prática de trabalho dos desenvolvedores.

O processo de criação de um #Escopo

E quem define o Escopo? Em geral o escopo começa nas mãos de um sonhador. Começa com alguém que enxerga uma situação problema e quer transformar em solução. Às vezes começa com uma visão de oportunidade. A [boa] definição de Escopo diz que esse é o território dos ousados, dos criadores, dos criativos, é o espaço dos que querem ir além.

Mas, em geral, há um problema aí. Na definição de escopo as pessoas se preocupam mais com “quando?” e “quanto?” do que com “porquê?”, “como?”, “para quê?”. O que ocorre, em muitos casos, é o levantamento em alto nível de uma lista de funcionalidades e depois perguntas e afirmações como:

  • Isso vai resolver o problema!
  • A gente tem certeza que isso vai ser um sucesso!
  • Essa ideia não parece genial?
  • Quanto tempo leva para desenvolver/construir isso?
  • Quanto custar desenvolver isso?

Na prática, em caso de projetos novos, algumas perguntas seriam mais úteis como:

  • Nós temos certeza que essa é uma boa ideia? Qual a base que temos para fazer afirmações?
  • Qual mínimo produto viável dessa ideia? Esse MVP geraria valor?
  • O que esse produto ou serviço vai resolver?
  • Temos uma noção realista de quantos recursos são necessário para construir a primeira parte desse projeto?
  • [Em caso de projetos que visam retorno:] Quais são as fontes de receitas geradas pelo projeto? É possível fasear sua construção em correlação a entrada de novos recursos?

Em caso de projetos legados, as perguntas poderiam ser:

  • Onde queremos chegar?
  • O quanto nós precisamos disso?
  • Qual impacto isso terá no estado de coisas atual?
  • Qual tamanho desse projeto?
  • Como eu dividiria esse projeto em pequenas partes?
  • Quanto tempo eu tenho ou quero dispor com isso?
  • Quanto, em termos de recursos, estamos dispostos a investir nesse projeto?
  • Quanto de retorno eu vislumbro com esse projeto?

Do que o projeto precisa?

“Somos seres desejantes destinados a incompletude e é isso que nos faz caminhar”

Jacques Lacan

O atual processo civilizatório do mundo criou uma psique profundamente desejante nos sujeitos. Na prática isso quer dizer que há um tendência nas pessoas em querer, querer e querer… e nem sempre aquilo que é quisto é funcional ou necessário. Pode ser apenas um fetiche que tem como alvo algo que o sujeito não sabe ao certo expressar. Não vou aprofundar-me muito aqui, mas quero dizer que o problema tem muito mais a ver com a forma como vamos conduzindo nossa expectativa em relação a realizações do que com algum critério essencialista de necessidades.

É comum encontrar sujeitos em posição de liderança institucional indicando a necessidade de algo para um projeto. Muitas vezes isso compromete não só a ideia de prioridade como também a própria noção de sucesso do projeto como um todo.

Uma história baseada em fatos reais para ilustrar o que estamos dizendo aqui: um diretor começa a conceber um projeto para melhorar a performance dos alunos de algumas escolas públicas no vestibular. A ideia inicial é que uma ação possa ser feita durante 1 ano e como resultado os alunos de x escolas possa ter performances melhores no vestibular ao final do período estipulado. O orçamento desse projeto é de 500k (quinhentas mil unidades de valor) e ele pretende impactar 10 escolas.

Ok, não vamos entrar aqui nos méritos ou desafios impostos. Vamos apenas considerar que seja possível, com esse orçamento e neste prazo, atingir a meta final que é melhorar a performance dos alunos no vestibular. No entanto, ainda que essa possibilidade seja factível, a dinâmica e as ações do projeto vão delimitar o sucesso ou fracasso da meta, certo? Não importa que um desafio seja possível e realizável, a forma e as condições de fazê-lo é que vão construir o êxito ou a falência da iniciativa.

Sendo assim, imagine a seguinte forma de execução:

  • 10% do recurso do projeto (50k) são direcionado para construção de uma plataforma nova de e-learning com vistas a ampliar o repertório de conhecimento destes alunos. A plataforma é inspirada nos grandes players de e-learning do mundo (udemy, udacity, coursera, etc);
  • 80% dos recursos (400k) são destinados a contratação de professores auxiliares que irão desenvolver projetos dentro das escolas, no contraturno das aulas;
  • 10% restantes dos recursos (50k) serão destinados a pequenos custos de material, como livros e cartilhas;

Interessante? Parece uma execução plausível. Sem entrar muito em detalhes, quero chamar a atenção para um ponto: porque a decisão de empregar 10% dos recursos na construção de uma plataforma e-learning foi tomada? Esse seria meu primeiro questionamento como gerente de projetos. Veja que o Escopo foi colocado com tendencia fechada para esse ponto: 1 ano, 50 mil reais, desejo uma plataforma tão boa quanto os grandes players como Coursera, Udemy, Udacity, etc. Isso parece realista? Algumas questões que podem colocar em cheque essa ideia:

  • Quanto recurso foi investido ao longo dos anos nessas plataformas “Concorrentes” as quais tenho inspiração? (Milhões, certamente) Porque os stakeholders que tomaram essa decisão de cenário acham que investindo 50 mil reais ao longo de um ano será possível obter uma ferramenta mais competitiva ou tão interessante quanto as citadas? Estamos falando de um esforço de criação de algo novo para competir com algo que já existe;
  • Não caberia convergir esforços para usar ferramentas que já resolveram bem a proposição inicial? Certamente poderia custar menos tempo e recursos financeiros. Há impeditivos para isso?
  • Haverá investimento na construção da ferramenta, mas e os conteúdos? De que forma eles serão obtidos? De que se compõem? Isso delimitará e muito a forma de disposição dos conteúdos na ferramenta;
  • O público-alvo (os alunos) têm comprometimento ou condições objetivas para consumir conteúdos dessa pretensa ferramenta? Isto é, estes alunos terão tempo, acesso a internet e orientação suficiente para lidarem com essa expectativa de consumo e interação com conteúdos digitais? Aqui temos uma prerrogativa sem explicitar se há ou não estudos relevantes quanto a proposição de impacto;
  • O que acontecerá quando o tempo do projeto terminar? A plataforma sairá do ar uma vez que não há recursos para mantê-la para além do período inicialmente estipulado?

Esse é apenas um exemplo de quão problemáticas podem ser delimitações de projeto com tendências de escopo fechado partindo de pressupostos mal arranjados. Provavelmente pautado pela ânsia de um aspecto digital, querendo que o projeto tenha uma dimensão “moderna” e “inovadora”, o stakeholder estabeleceu que a iniciativa deve ter uma plataforma e-learning, mas não fez uma avaliação realista quanto ao tempo e ao valor necessário para empreender isso, sobretudo dentro de uma proposta de escopo fechado.

Não sabemos prever as coisas!

Um dos maiores equívocos que podemos cometer ao conceber um projeto é acreditar fortemente na nossa capacidade de previsibilidade. Esse equívoco se torna pior quanto maior for o tamanho do projeto e quanto menor for o grupo de pessoas centralizando a tomada de decisão, baseando princípios na previsão de cenários pre-concebidos. Veja bem, não estou dizendo que previsões são impossíveis. Não é isso. Previsões devem ser feitas. Mas existe uma diferença entre fazer uma previsão municiado de argumentos, estudos, projeções e conhecimentos e fazer uma previsão baseada na capacidade intuitiva de algumas pessoas envolvidas. A razão probabilística de acertos quando estreitamos a capacidade de multiplos olhares é pequena. No fim, das duas uma: ou estamos lidando com gestores que são absolutamente mestres nos temas de projetos em que estão envolvidos ou estamos todos no terreno do achismo e da previsão marcada pela vontade.

Se assumirmos que nossa capacidade de previsão é limitada, podemos adotar uma postura mais aberta em relação a ouvir quem de fato irá colocar a mão na massa.

Ouça quem sabe pôr a mão na massa e depois tire conclusões

Esse artigo começou falando de escopo e parece que mudou totalmente de assunto. Não era essa a intenção, mas de fato acredito que muita coisa está interligada e é difícil falar estritamente de escopo aberto ou escopo fechado sem pontuar as razões pelas quais um escopo é concebido, desenhado e realizado.

Se você é um gerente de projetos, um diretor, um investidor, um empreendedor de qualquer natureza, independente do seu conhecimento do negócio ao qual está inserido, um dos passos mais inteligentes que você pode dar é ouvir aqueles que têm capacidade ou que simplesmente foram designados para executar o projeto.

Busque ouvir as lideranças experientes na execução e procure entender com elas quais são as prioridades e, na visão delas, quais são os tempos de operação.

Se você estiver trabalhando com metodologias ágeis, sem dúvida um dos primeiros passos é a definição de grandes marcos ou tópicos, ou nos termos do #scrum, dos épicos do projeto. A partir disso será mais fácil priorizar e estimar tempos de execução. No entanto é importante ressaltar que essas estimativas são prognósticos e que a real realização disso depende de muitos fatores como época do ano, disponibilidade da equipe, tamanho do time, grau de conhecimento dos envolvidos, tecnologias empregadas, entre outros detalhes.

A mensagem que queremos passar aqui é: será muito mais complicado, para não dizer contraproducente, tentar conceber um prazo e um escopo super estabelecido a partir de um referencial autocentrado. É muito difícil acertar sem muitos percalços quando o escopo é apenas um projeto fechado e quando a estimativa de preço e prazo é dada por quem quer e não por quem fará. Faz sentido?

Outro aspecto importantíssimo a ser considerado é a natureza do projeto que está sendo tratado. Os processos e maneiras de conceber um produto digital são muito diferentes daqueles que envolvem a construção de edificações por exemplo. Não dá pra igualar o projeto de um prédio de apartamentos para moradia com o projeto de uma nova ferramenta web, ambos tem naturezas muito distintas. A construção de um prédio possui orçamento muito mais definido e uma fonte de entrada de recursos muito mais mapeável do que um serviço digital. O prédio um dia será entregue e, mesmo que sejam feitas reformas e modificações futuras, suas fundações quando bem feitas durarão por décadas. No entanto a venda destes imóveis (apartamentos do prédio) não gerará fontes de recursos recorrentes, como acontece com frequencia em produtos digitais pensados como serviço. Neste caso, só seria possível algum exercício de equiparação se pensássemos um prédio em constante construção e melhoria e cuja primeira versão, sem grandes acabamentos, já pudesse gerar recursos advindos de locação de seus espaços. A falta de percepção dessa enorme diferença também causa muitos contratempos e isso é um tema tão sensível que mereceria até um novo artigo só para tratar desse ponto.

Aberto vs Fechado

Em síntese elencamos abaixo os prós e contras de cada modelo. Essas são generalizações e isso pode mudar um pouco dependendo do contexto, mas no geral esses tópicos respeitam e consideram bem a lógica de cada tipo de esquema.

#Escopo Fechado – Contras 👎

  • Está pautado numa ideia ilusória de controle;
  • Tem forte tendência de não performar em projetos de médio e grande porte;
  • Exige forte documentação, em geral antes mesmo de começar qualquer etapa produtiva;
  • Existe risco de frustração na entrega final pois o projeto não teve espaço para adaptações necessárias;
  • Gera atrasos nas entregas porque as incertezas não estão mapeadas e nem podem ser previstas;
  • Gera frustrações em todas as partes: os stakeholders descobrem no final das contas que não era bem isso e o desenvolvedores acabam trabalhando muito mais do que o inicialmente imaginado;

#Escopo Fechado – Prós 👍

  • Pode funcionar para projetos pequenos, com escopo bem delimitado e documentado;
  • Em caso de projetos que geram recursos, Escopo Fechado seria mais adequado e funcionaria melhor para projetos com data de inicio e fim definidos e cujo objetivo também se encaixe nesse formato. Exemplo:o projeto de um hot site promocional de natal de uma determinada marca ou produto, o site/sistema de inscrição de um evento, entre outros;
  • Pode custar menos, sobretudo se o projeto tiver Stakeholders, Product Owners e Scrum Masters totalmente alinhados com os modelos de negócio e com as soluções que pretendem levantar;

#Escopo Aberto – Contras 👎

  • Pode custar mais caro se a expectativa for crescendo e o escopo for sendo ampliado a medida que o tempo passa. Também pode custar mais caro se erros de condução forem sendo repetidos (sprints que não geram mudança de rota);
  • O projeto pode fugir do objetivo inicial se não houver compromisso com seus objetivos e a geração de valor. Se a fuga propiciar bons resultados e uma guinada interessante, ótimo. Mas se a perda de foco for apenas o resultado do descontrole do escopo aberto, isso pode ser ruim para o projeto;

#Escopo Aberto – Prós 👍

  • Está pautado numa ideia mais madura de avaliação constante e assume que podemos controlar algumas coisas, mas imprevistos sempre podem surgir;
  • Lida melhor com surpresas, adaptações, mudanças;
  • Entrega valor constantemente, tem um foco na geração de resultados de curto, médio e longo prazo;
  • A entrega de valor é sempre revista e busca estar sempre alinhada com as expectativas dos stakeholders;

Mensagem Final

Tenho me envolvido e realizado projetos ao longo dos últimos 15 anos com foco em desenvolvimento de soluções, implementação de metodologias ágeis, consultoria para transformação digital e criação de produtos. Tenho um enorme entusiasmo e compromisso com parceiros que querem melhorar a performance de suas equipes e planos. Se você nos acompanha ou encontrou algum conteúdo e quer conversar, entre em contato. Ficarei animado em discutir ideias e identificar sinergias.

Tags: , , , ,

Deixe uma resposta

O seu endereço de email não será publicado. Campos obrigatórios marcados com *

Felipe Cabral

↓ More ↓