Como precificar projetos e gerenciar fluência de escopo

Tenho certeza de que você leu artigos irreais que sugerem que há alguma abordagem científica para preços que magicamente permitirá que você crie uma cotação precisa. Você também pode ter sido levado a acreditar que a fluência do escopo deve ser evitada a todo custo, mas no mundo real, isso sempre acontecerá.

É hora de pararmos de jogar esse jogo ridículo e começarmos a executar projetos de uma maneira que seja menos como jogos de azar e mais como seguir um processo robusto e confiável.

Estou exagerando? Possivelmente, mas vamos ver onde as coisas costumam dar errado com projetos digitais.

Os problemas com nosso processo de projeto

Na minha experiência, a maioria das organizações de qualquer setor executa projetos aproximadamente da mesma maneira:

1. Alguém na gerência solicita que um projeto seja concluído. Infelizmente, essa solicitação geralmente carece de detalhes em termos de entregas e tende a ter apenas objetivos vagos.
2. Um comitê de partes interessadas é montado para definir o projeto em detalhes e decidir sobre o escopo.
3. O escopo detalhado é então levado à equipe que o construirá, e eles são solicitados a estimar quanto tempo levará e quanto custará.
4. O projeto é entregue conforme a especificação, enfatizando a entrega no prazo e dentro do orçamento. Como resultado, a fluência do escopo se torna o inimigo.
5. O projeto é entregue e todos passam para o próximo projeto em sua lista de tarefas.

Essa abordagem está longe de ser ideal, especialmente para projetos digitais. O digital nos fornece um feedback sem precedentes sobre o comportamento do usuário e torna relativamente fácil implementar mudanças (em comparação com produtos físicos). No entanto, uma vez que o escopo foi definido e uma cotação fornecida, o projeto fica bloqueado, com todos relutantes em fazer alterações à medida que o projeto avança.

No entanto, inevitavelmente, o escopo acaba mudando, principalmente porque as partes interessadas têm interpretações variadas do que será construído ou porque percebem no meio do projeto que os elementos críticos estão errados.

Na verdade, não há nada de errado com o scope creep . Permanecer flexível e se adaptar à medida que você aprende mais é fundamental para criar excelentes serviços digitais. O problema não está no escopo, mas na maneira como executamos os projetos.

Infelizmente, como os prazos e custos foram acordados, tentamos entregar essas mudanças dentro dessas restrições, levando a cortes de custos.

Não que os prazos e os custos fossem precisos em primeiro lugar. Projetos digitais são complicados, geralmente envolvendo especialistas e partes interessadas trabalhando juntos. Como resultado, eles são notoriamente difíceis de estimar com precisão.

Li muitos artigos que propõem metodologias para estimar com precisão. No entanto, eles são impraticáveis ​​no mundo real em quase todos os casos, principalmente porque são muito demorados para serem aplicados. Estimar um projeto se resume à intuição, experiência e um palpite!

Como qualquer pessoa que tenha trabalhado no campo por algum tempo lhe dirá, a maioria das estimativas é uma obra de ficção . Geralmente não sabemos o suficiente para determinar qual é a solução certa ou como os usuários podem responder a ela. Portanto, é impossível estimar com precisão um projeto inteiro antecipadamente.

Infelizmente, essa ambiguidade muitas vezes leva à distribuição injusta da culpa quando o projeto inevitavelmente perde seu prazo e ultrapassa o orçamento.

Felizmente, existe uma maneira de fornecer estimativas precisas e gerenciar desvios de escopo que envolvem alterar os projetos executados. O segredo está em dividir projetos em pedaços menores. Essa abordagem evita assumir projetos grandes e complexos.

Divida os projetos em uma série de compromissos menores

Eu preciso ser claro neste momento. Não estou sugerindo que programas ambiciosos de trabalho estejam errados. Eu trabalho para grandes clientes em sites substanciais e programas de trabalho extensos. No entanto, raramente trato esses compromissos como um único grande projeto. Em vez disso, eu os divido em projetos mais gerenciáveis ​​que eu escolho um de cada vez.

Quando um cliente me aborda querendo realizar um projeto digital (seja ele grande ou pequeno), eu normalmente o divido em quatro etapas que acontecem na seguinte ordem:

1. Descoberta,
2. Alfa,
3. Produto com minima viabilidade,
4. Iteração e otimização contínuas.

Cada estágio é um compromisso separado com resultados claros. Portanto, não me comprometo com todo o projeto, mas apenas com a primeira fase. Isso facilita muito a estimativa e o gerenciamento do escopo.

Por exemplo, você só precisa definir o escopo da próxima etapa. Isso permite que você gerencie melhor o aumento do escopo porque você pode acomodá-lo ao definir o próximo estágio , assim que o estágio anterior for concluído.

Em vez de estimar um programa inteiro de trabalho, você está estimando o próximo projeto desse programa. Além disso, você pode usar o estágio anterior para ajudá-lo a estimar com mais precisão.

Cada estágio ajuda a definir e estimar o estágio seguinte, começando com a descoberta.

1. Descoberta

Na fase de descoberta, trabalho com as partes interessadas para validar o projeto. Dependendo do tamanho geral do projeto, isso pode ser tão simples quanto algumas reuniões ou pode ser um programa de trabalho completo.

Normalmente inclui elementos como:

• realizar pesquisas de usuários;
• analisar a concorrência;
• identificação de indicadores-chave de desempenho;
• definir como é o sucesso;
• compreensão das restrições;
• recolher as opiniões das partes interessadas.

A ideia é que a fase de descoberta forneça uma definição mais informada do projeto, incluindo as necessidades do usuário, objetivos de negócios e o que precisa ser criado.

Mais importante, ele validará que o projeto entregará o valor necessário.

Podemos então usar essa entrega para definir e estimar o trabalho necessário em uma fase alfa. Isso torna nossas estimativas mais precisas e também ajusta o escopo com base no que aprendemos.

2. Alfa

A fase alfa é onde definimos como o serviço digital (seja um aplicativo da web ou site) funcionará e garantimos que os usuários tenham uma experiência positiva ao usá-lo.

Isso normalmente é feito através da criação de um protótipo. Em projetos menores, isso pode ser nada mais do que alguns modelos de design. Em projetos maiores, pode ser um protótipo funcional que as pessoas possam experimentar.

Seja qual for o caso, a ideia é visualizar o serviço digital que você está construindo.

Fazemos isso por três motivos.

• Primeiro, uma visualização garantirá que todas as partes interessadas tenham uma visão compartilhada do que você está criando. Um documento pode ser interpretado de muitas maneiras diferentes, mas isso é muito mais difícil de fazer com um protótipo.
• Em segundo lugar, um protótipo tornará muito mais fácil identificar qualquer coisa que possa ter passado despercebida , de modo a evitar o deslocamento do escopo mais adiante, quando for mais caro resolver.
• Finalmente, se tivermos algo tangível, podemos testá-lo com os usuários para garantir que seja adequado ao propósito antes de irmos às custas de construir a coisa real.

Se o teste for ruim, ainda temos espaço antes da próxima fase para nos adaptarmos sem quebrar o orçamento ou atrapalhar o cronograma.

Assim como na fase de descoberta, podemos usar o alfa para estimar o trabalho necessário no próximo estágio. Ter uma visualização do que precisa ser construído torna a estimativa do trabalho necessário muito mais fácil para todas as partes interessadas envolvidas. Eles podem ver o que estão sendo solicitados a construir.

Além disso, podemos usar as lições aprendidas com o teste do alfa para adaptar o que vamos criar, mais uma vez criando espaço para mudanças no escopo sem atrapalhar o projeto.

Assim que tivermos o alfa, podemos avançar com confiança para a compilação, sabendo que criaremos a coisa certa e que os usuários responderão positivamente a ela.

3. Produto Mínimo Viável

Eu costumava me referir a esta fase como a 'construção'. No entanto, descobri que as partes interessadas associavam a conclusão da construção à conclusão do projeto. Na realidade, os serviços digitais nunca terminam, pois precisam ser constantemente repetidos para garantir que sejam o mais eficazes possível.

Para evitar esse problema, comecei a me referir a essa etapa como o produto mínimo viável (MVP). Nesta etapa, construímos e lançamos a versão inicial do serviço digital.

Ao nos referirmos a ele como o produto mínimo viável, enfatizamos que haverá uma iteração pós-lançamento. Isso nos fornece uma maneira de lidar com o aumento do escopo e a complexidade imprevista, adiando-o até o pós-lançamento. Isso garante que o projeto permaneça no caminho certo e mantenha seu ímpeto.

Inevitavelmente, durante a construção, vamos arquivar algumas coisas até o pós-lançamento. Esses elementos tornam-se então a base para definir nossa etapa final, permitindo-nos fazer uma estimativa inicial para a otimização pós-lançamento.

4. Iteração e Otimização Contínuos

A fase de pós-lançamento lida com a funcionalidade, complexidade e outros problemas que não abordamos no MVP. Esta lista de melhorias é relativamente fácil de alcançar neste ponto e pode ser estimada com precisão razoável.

No entanto, além desse trabalho, deve haver um processo contínuo de monitoramento, iteração e teste que refina ainda mais a eficácia dos serviços digitais.

A estimativa de quanto desse trabalho você realiza deve basear-se no tamanho e na complexidade do serviço digital. Sua estimativa também deve ser proporcional ao investimento no restante do projeto.

Ao dividir seus projetos nessas quatro fases e concluir cada uma separadamente, você removerá muitos dos desafios que enfrentamos ao usar as abordagens tradicionais de gerenciamento de projetos.

Por que a divisão de projetos funciona

Quatro benefícios significativos resultam da divisão de projetos dessa maneira:

• Cada fase é melhor definida .
  Como as entregas da fase anterior definem cada etapa, isso significa que há uma visão clara de direção. Isso ajuda as partes interessadas a entender para onde as coisas estão indo e evita surpresas desagradáveis ​​mais tarde.
• Os projetos são estimados com mais precisão .
  Por exemplo, em vez de ter que adivinhar quanto tempo levará para entregar um projeto significativo e nebuloso com um número substancial de incógnitas, você está apenas estimando a próxima fase e fazendo isso com base nas entregas da fase anterior.
• Isso resulta em melhores serviços digitais .
  Como as ideias do projeto são validadas e testadas com os usuários, você pode ter mais certeza de que o produto final atenderá à finalidade. Também permite espaço para adaptar o escopo e a funcionalidade entre as fases para garantir que você forneça o melhor resultado possível.
• É uma abordagem menos arriscada .
  A empresa que contrata o serviço digital não precisa se comprometer com todo o projeto antecipadamente. Se a fase de descoberta não validar a viabilidade do projeto, ele pode ser descartado com pequenas perdas. Da mesma forma, se o protótipo alfa não testar bem com os usuários, ele pode ser adaptado antes que as coisas se tornem muito caras.

Este ponto final é tranquilizador se um fornecedor externo estiver sendo usado pela primeira vez. Em vez de inscrever uma agência para um projeto substancial sem saber se eles podem entregar, o cliente pode envolvê-los em uma fase de descoberta para ver como eles são. Se eles são bons, eles podem continuar trabalhando com eles. Caso contrário, eles podem levar as descobertas para outra agência sem perder nada.

Se você administra uma agência ou é freelancer, pode achar que isso parece uma má ideia. Compreensivelmente, você preferiria inscrever um cliente para todo o projeto. No entanto, evitei muitas licitações competitivas com essa abordagem porque o cliente não sentiu que estava assumindo um risco com um investimento inicial tão pequeno. Além disso, eles não sentiram a necessidade de falar com vários fornecedores porque se não gostassem de mim, poderiam trocar facilmente.

Além disso, usar essa abordagem em fases facilitará muito o escopo e o preço do seu próximo projeto de preço fixo. Claro, isso não fornecerá magicamente uma estimativa ou impedirá o aumento do escopo. No entanto, isso tornará a estimativa mais gerenciável, porque você está delimitando apenas uma parte de cada vez. Também permitirá que você trabalhe com o aumento do escopo, em vez de tentar suprimi-lo.

Portanto, meu conselho, se você trabalha internamente ou externamente, em sites grandes ou pequenos, é parar de tentar estimar e definir o escopo dos projetos sem dividi-los em fases. Em vez disso, enfrente uma fase de cada vez e use o que você aprendeu para informar a próxima . Se fizer isso, você estimará com mais precisão, terá espaço para adaptação com base no que aprender e descobrirá que o gerenciamento de projetos é mais direto.