O Tamanho do Problema 

Sep/10
26

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.

Escopo de Projeto vs Escopo do Projeto

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.

Insumos

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.

Cobrando pelo Trabalho

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:

  • As instala√ß√Ķes da equipe (incluido equipamentos, cafezinho, faxineira, tudo o que proporciona o ambiente, inclusive a energia gasta e despesas de comunica√ß√£o e transporte) .
  • A velocidade. O qu√£o depressa o escopo tem que ser convertido em funcionalidade. Veja que para que o escopo seja feito mais depressa isso √© mais caro do que ser feito devagar (andar de avi√£o √© mais caro que andar de carro√ßa, n√£o apenas pelo veiculo, mas pela economia de tempo). E este fator n√£o tem que ver com o item anterior e sim com a habilidade das pessoas envolvidas e o numero de imprevistos e impedimentos que possam ocorrer
  • A equipe. Os sal√°rios e pr√©mios das pessoas que realizar√£o o trabalho.

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.

O Tamanho do Escopo

√Č 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).

Contrato de Custo-Alvo (Target-Cost Contract)

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 …

Comente

Enquete

Sobre quais assuntos gosta de ler neste blog ?

View Results

Loading ... Loading ...

Artigos