Um software é constituído de funcionalidades. Ele faz algo. Estas funcionalidades foram construídas no software pelos desenvolvedores com base em requisitos. Estes requisitos são apontamentos imperativos daquilo que o software deve fazer, como deve fazer, quando deve fazer, etc.
O escopo é o conjunto de todos os requisitos que o cliente exige que estejam contemplados no software a quando da entrega final. E aqui está o problema: o que o cliente exigiu no inicio do projeto, não é o que ele exige no final. É preciso entender que o escopo não é aquilo que o software deve ser, o que o produto deve ser, mas sim o que o projeto irá realizar. O software pode ter muitos requisitos, tantos que pode levar levar vários anos até que todos tenham sido completados. Contudo, a realização de um software pode ser partida em vários projetos. Olhemos de outra forma. O software tem um conjunto de requisitos a serem completados e o projeto tem um subconjunto desse conjunto. Em particular, o projeto pode conter todos os itens do conjunto original (qualquer conjunto é subconjunto de si mesmo) , mas isso não é uma obrigação.
Está claro que o escopo do projeto é o conjunto de requisitos que serão realizados no âmbito (no escopo) do projeto, enquanto simultaneamente existe um conjunto maior de requisitos que compõem o escopo do produto que estamos construindo.
Quando o cliente lhe paga para você realizar um projeto de construção de software, ele lhe paga para realizar o escopo do projeto, não o escopo do produto. Se é por isso que ele lhe paga, como você cobra ? Escreva a sua forma num pedaço de papel que já voltamos a ela.
Se você constrói algo, você sempre tem algum tipo de insumo que é usado nessa construção: matéria prima. A matéria prima de um software são idéias, transformadas em requisitos (frases imperativas) e é sensato cobrar pela inclusão dessa matéria prima no produto. Não apenas o trabalho que a colocar lá, mas o trabalho da obter e usar. Matéria prima de melhor qualidade promove produtos de melhor qualidade, e matéria prima ruim promove um produto final ruim, não importa quanto esforço você coloque.
Quando uma noiva escolhe o tecido do seu vestido e entrega a uma costureira para o realizar , a matéria prima é provida pelo cliente. Isso não significa que seja possivel realizar um vestido de noiva com aquele tecido. Isso apenas é possível se a noiva teve a sensatez de escolhe um tecido adequado (vestidos de noiva de lã ? … talvez no frio… ). Da mesma forma, ao realizar um software a matéria prima é entregue pelo cliente. É ele que conhece os requisitos. Mas da mesma forma que o tecido, podem não se apropriados aos objetivos finais. A arte de adequar os requisitos aos objetivos finais é chamada “Analise”. Uma das ferramentas da analise é o Levantamento de Requisitos (também chamado Analise de Requisitos, embora esse nome não seja cronologicamente adequado pois a analise real acontece depois do levantamento). A Analise é um passo comum a todas as profissões que começam com a recepção de materia prima de outrém. Ha que avaliar a conformidade do que é recebido.
Para conseguir avaliar o quão adequado um requisito é com os objetivos finais é necessário, primeiro, conhecer os objetivos finais. Eles são como axiomas que guiam tudo o resto. Em software esses objetivos (goal em inglês) são mapeados logo no inicio durante a vida do produto. Repare que estamos falando na vida do produto ainda, não na do projeto. A Concepção (Inception em inglês) é a fase do ciclo do produto onde os objetivos são encontrados com base em um objetivo maior que é a causa da realização do software. Este objetivo maior é chamado Visão e os objetivos do produto conspiram para que esta visão seja possível. O famoso Documento de Visão descreve a Visão (objetivo ultimo) e os Objetivos (goals) do produto. Do produto.
Da posse do Documento de Visão (que pode ser um papel de pão , embora seja simpático que não seja) e da lista de requisitos para o Produto (Escopo do Produto), será feita uma triagem para agrupar os requisitos de forma a poder realizar um ou mais projetos que os realizarão, alcançando assim os objetivos, e por consequência a Visão.
Aqui podemos ter várias opções. Podemos realizar um único projeto , vários projetos ou um projeto com múltiplos sub-projetos. A decisão que realmente importa é concluir quantas entregas queremos/precisamos para finalizar todo o Escopo do Produto. Talvez se tivermos uma versão mais simples que possamos vender ou demonstrar no ajude a angariar fundos para as próximas. Existem decisões estratégicas, comerciais e de mercado envolvidas na decisão de como dividir o Escopo de Produto para formar um ou vários Escopo de Projeto, que poderemos então realizar.
Dado um Escopo de Projeto, depois de consciensiosamente analisado teremos que pensar em constrangimentos temporais, ou outros, que nos obrigarão a fazer ainda mais divisões. Esta decisão do escopo do Projeto, acontece no âmbito do Projeto e é utilizada para mitigar determinadas dimensões do projeto ( como custo, ou risco) e/ou para otimizar outras ( como prazo ou retorno de investimento). Estas divisões são chamadas Release (não ha uma boa palavra portuguesa para isto, talvez a mais próxima seja Publicação?). Os requisitos que serão completados no âmbito do Release formam o Escopo de Release. A união de todos os Escopos de Release formam o Escopo de Projeto. É claro que pode ser decidido que o projeto terá apenas um Release, mas isso é um caso particular e previsto no mesmo modelo.
Portanto, uma empresa que constrói software demanda Requisitos como insumo. Faz Analise para validar ou melhorar esses Requisitos. Forma o Escopo do Produto com esses requisitos. Ajuda o Cliente a separar o Escopo do Produto em um ou vários Escopos de Projeto e finalmente em um ou vários Escopos de Release. Esta empresa irá cobrar pelo trabalho que realizar o Escopo de Projeto, num certo Prazo, por um certo Preço, com uma ditada Qualidade, dentro de uma margem de Risco, para conseguir obter o Beneficio (Valor) descrito pelos Objetivos e pela Visão.
Voltamos então ao como cobrar o trabalho. Estamos pensando que o Preço deve incluir o Custo e o Lucro ( num modelo simplista). O que me custa dinheiro ? Os meus insumos:
O custo , C, é portanto composto do custo das instalações, I, que depende linearmento do tempo ( para simplificar), do “preço da equipe” W que também depende linearmente do tempo, mas que depende também da habilidade H do seus membros ( seniors são mais caros que juniors) e da velocidade V, que também depende da habilidade dos membros da equipe H, da frequencia r, e tamanho dos imprevistos e impedimentos , M.
C = I(t) + W(t, H) + V(H, r ,M)
Todos temos uma noção que um escopo maior (com a mesma equipe) demora mais que um escopo menor. Portanto o tamanho do escopo é um fator essencial do custo. O tempo que demora a realizar o escopo (t) é proporcional ao tamanho do escopo (E) e à velocidade em que podemos converter os requisitos do escopo em funcionalidades do software. Velocidade maior significa menor tempo.
t = E / V
O que nos dá o resultado:
C = I(E, V) + W(E, V, H) + V(H, r ,M) = >
C = f ( E , H , r , M )
Olhe a sua anotação que fez no inicio e verifique onde o tamanho do escopo entra na sua forma de calcular o custo.
Veja que o custo depende apenas do Escopo, da Habilidade da equipa, da freqüência de impedimentos e do tamanho dos impedimentos.
Se você é como a maioria você inclui o tamanho do escopo através de chutes que você obtém comparando com projetos anteriores ou simplesmente usando um modelo qualquer de ajustes. Ou seja, algo robotico, matemático e sem sequer ter olhado o que é o escopo realmente : quais são os requisitos; e qual é sua equipa, então não está olhando para o que interessa.
É portanto claro que necessitamos quantificar o Tamanho do Escopo do Projeto para poderemos comparar o escopo do projeto A com o do projeto B de forma objetiva : comparando números.
O que acontece, então, quando o cliente fixa um Prazo ? Ele está, basicamente, definindo o seu tempo máximo (tmax) para um certo valor P. Isto significa que ele está lhe dando um certo Escopo de Projeto, E para ser cumprindo em um certo Prazo, P
P = E / V => V = E/ P
Ou seja, ele está definindo a sua velocidade mínima. O que acontece se o escopo aumenta e o prazo continua igual ? A velocidade tem que aumentar. Isto, significaria automáticamente que a habilidade da equipa tem que aumentar ou a frequencia e/ou tamanho dos impedimentos tem que diminuir. E isso custa dinheiro. De fato um projeto de prazo fixo é mais caro que um de prazo aberto. Isto porque temos que contar com uma equipe mais capacitada ( individualmente e como equipe) e controlar riscos muito melhor ( para mitigar r e M )
O tamanho do Escopo do Projeto é essencial para planejar a execução do projeto, e esse tamanho tem que ser medido nas mesmas condições que a habilidade da equipe. É por isso que vários autores recomendam que seja a equipe que vai realizar o trabalho a estimar o tamanho do escopo. Assim o “fator de habilidade” está incluso no tamanho do escopo ( oque a equipa estima) e na velocidade( o que ela realiza de fato) , exatamente como a formula acima mostra que seria necessário.
A forma atualmente de maior sucesso para alcançar este objetivo de quantificar o escopo é o uso de uma escala de tamanhos relativos (Story Points) e Planning Poker (Poker de Planejamento) onde a equipe estima o tamanho usando a escala fixa, pré-determinada, o conhecimento nas suas habilidades e o esclarecimento dos requisitos que compõem o Escopo do Projeto, ou o Escopo do Release (quando o projeto é dividido em vários releases).
Um modelo de contrato de custo-alvo muito interessante que faz uso das relações anteriores. Neste modelo, após definido o Escopo do Projeto ele é estimado e se chega num Tamanho Inicial do Escopo do Projeto. Este tamanho é dado como imutável.
O Contratado de posse da velocidade por iteração da sua equipe , calcula o numero de iterações necessário para executar esse escopo. Por exemplo, em agile, usando sprints como iteração o contratado indicaria quantos Sprints são necessários. Num projeto tradicional é o numero de entregas intermediárias. O tempo não é realmente importante já que estará ligado à determinação da iteração. O que é importante é que no fim de cada interação haja uma entrega que funcione de fato. O contratado fixa um custo por iteração e traduz esse numero interações num valor de custo. Esse é o Custo-Alvo.
As partes acordam também um numero máximo de iterações para o projeto.
O contratante obriga-se a fazer o pagamento de um valor inicial igual a metade do custo-alvo mais uma parcela a cada iteração conforme metade do custo por iteração. O Contratante é livre de terminar o projeto no fim de qualquer iteração. O contratante obriga-se a pagar as iterações até ao numero de iterações previsto ou até que o escopo seja completado ( o que acontecer primeiro).
O que acontece com este contrato é muito interessante. Se o contratado ( a empresa de software) pensou direito e apresentou um custo-alvo com alguma margem de lucro, então é porque espera terminar antes do numero previsto de iterações. Se isso acontece ela ganha metade do valor do custo multiplicado pelo numero de iterações que sobraram pois já foi pago com antecedência. O mesmo se o cliente desiste do projeto e nesse caso o valor restante serve de “multa”. É claro que o cliente não vai parar antes, mas como o tamanho do escopo é finito o projeto acaba quando o escopo acabar não deixando que o cliente force o uso de todas as iterações previstas.
Se algo correr errado ou a empresa de software for “preguiçosa” e o projeto for além das iterações previstas no contratado o prejuízo é da empresa de software, mas só até ao limite das iterações máximas previstas. A partir dai o projeto é extinto ou foi completado. De qualquer forma existe um software funcionando com um conjunto substancial de funcionalidades, e todos ganham.
Repare-se que este contrato fixa o tamanho do escopo, e não o escopo em si. Ou seja, os requisitos podem mudar, ir e vir, desde que o tamanho total não seja alterado. A adição de novas funcionalidades obviamente irá aumentar o tamanho do escopo, e por consequência alterar o contrato que terá que ser recalculado ( na realidade será calculado o custo extra em numero de iterações extra). O que é simples e deixa claro as alterações de escopo evitando o aumento “invisível” do tamanho do escopo sem o aumento do custo que vemos em outros tipos de contratos. Portanto, embora parece inflexível, este tipo de contrato é mais flexível que o tradicional contrato de escopo fixo + preço-fixo, pois prmite alterar o que o cliente vai querer no software desde que isso não interfira no tamanho.
É preciso dizer que este tipo de contrato não é desenhado para ser usado apenas com disciplinas ágeis com scrum ou XP. Ele pode ser usado em qualquer modelo que seja iterativo e que estime o tamanho do escopo do projeto numericamente. Ou seja, sempre que você saiba o tamanho do problema …