Quebra de Tradição

Em posts anteriores já falei de como acho importante dar importância ao valor do software, como é ruim cotar o desenvolvimento em horas e como o cliente quer tudo de uma vez só.

A questão para mim era: como?

Os métodos atuais utilizados na maioria das empresas partem de princípios construídos durante a era Ford de fazer automóveis.  Mas para quem não sabe a Ford não está funcionando tão bem assim e as suas concorrentes que não utilizam esses princípios tradicionais (leia-se velhos e obsoletos) têm muitos mais lucro (ex.:  qualquer companhia asiática). Se isso ainda não o convenceu, pense nos problemas que enfrenta projeto após projeto e em quantos projetos não vingaram…

O outro problema é a tradicional (leia-se velha) cobrança por hora. Isto é um tiro no pé por muito que lhe digam o contrário. Afinal o objetivo das empresas é ter lucro (certo?) se eu cobro por hora significa que o único jeito de ganhar mais é trabalhar mais. Certo? Errado. Qualquer pessoa com noção de economia vai-lhe dizer que o ganho não advém do preço que o cliente paga mas sim da margem que você tem. Ou seja, da diferença entre o que ele paga e o que custa a você. O objetivo é portanto ter uma margem maior.  Trabalhar por hora significa que a margem é fixa. Você não pode aumentar a margem porque não pode haver disparidades entre o esforço e o tempo. E esse é o real problema.

Se a margem é fixa não ha como trabalhar as funcionalidades de maior valor de forma diferente que as de menor. Às vezes uma funcionalidade sem valor demora muito mais do que uma de menor.  Se eu cobrar por hora estarei cobrando muito por algo inútil e pouco por algo imprescindível.  Isto não faz nenhum sentido, mas atualmente tanto empresas como clientes caem nesta falácia.

Existem duas formas de reverter isto: a) as empresas aprendem a fazer certo e os clientes tem que seguir a onda ou; b) os clientes exigem o que é certo e as empresas têm que seguir a onda.

Portanto o objetivo é evangelizar tanto empresas quanto clientes. (bom, às vezes é necessário evangelizar os desenvolvedores também)

Clientes querem sempre tudo e estão acostumados a receber tudo. Mas estão satisfeitos? Não. Ninguém pode estar, em perfeita sanidade, satisfeito por pagar mais por algo inútil. Então a forma de trabalhar o cliente é não aceitar tudo o que ele pede. Mas claro, de um jeito educado.

A forma de fazer isto é óbvia. Cria-se um pacote  fixo. Este pacote pode ser de tempo , custo, esforço, valor, etc… o que importa é que seja fixo. Claro que alguns serão mais fáceis de estimar e controlar, normalmente  esforço ou custo. Deixe o cliente pedir o que ele quiser. Estima o tamanho de acordo com o critério fixo (tempo, esforço ou custo). Até aqui tudo bem. O problema é quando você converter esse tamanho em dinheiro. Ai o cliente vai dizer que ” ’tá muito caro” e que você precisa fazer um desconto e blá, blá , blá … Como norma não dê desconto! Principalmente se é um cliente novo.

Dar desconto para ganhar o cliente é uma outra prática tradicional (leia-se velha) que está errada. É que ao fazer isso você passa a idéia de que: a) o valor que você está falando não é honesto e b) você não sabe o real valor do que está fazendo (valor, não custo). Isso significa que cada vez que você falar um valor daqui para a frente o cliente vai interpretar como não sendo verdadeiro. Isso detona a confiança que ele tem em si. Quando o cliente quiser um preço menor você simplesmente diz: “Tudo bem, corte algumas funcionalidades”. Isso diz duas coisas ao cliente: que você sabe o esforço de cada funcionalidade e que o seu preço é honesto. O valor da funcionalidade cabe ao cliente decidir não a você. Ao ser forçado a retirar algo da lista ele vai repensar nas funcionalidades com mais atenção (coisa que ele nunca faz da primeira vez) e priorizar umas em realção às outras. Durante esse processo ele vai pensar em outras funcionalidades ou descobrir que afinal não precisa daquilo tudo.  Repare que você não está proibindo o cliente de fazer o que ele quer, você está impedindo que ele tire vantagem de si ou que pense que o seu trabalho não tem valor para ele (já que o dele não tem valor para você).

Mas…com certeza que o cliente vai querer mudar de opinião (vai dizer que isso nunca lhe aconteceu?) e querer mudar as funcionalidades   no meio do projeto. Tradicionalmente (leia-se “da forma antiquada”) isso é mau. É mau porque se partiu do princípio errôneo que o cliente sabe o que quer antes do projeto começar. Ele sabe o que quer, mas o que ele quer muda com o tempo. Então, para satisfazê-lo você aceita mudar as funcionalidades. O ponto é que do jeito antigo isso é uma exceção, com o jeito certo isso tem que ser a regra. Então, basta que o cliente possa modificar a lista de funcionalidades que criou no início do projeto. Sempre tendo em atenção o tamanho fixo. Isto inevitavelmente obriga a um trade-off por parte do cliente. Esse trade-off nem sempre pode ser feito pelo seu interlocutor e obriga a um processo interno no cliente para que haja uma decisão. Isso é bom porque: a) deixa o cliente consciente do que está pedindo e pelo que está pagando; b) deixa o resto da empresa-cliente consciente das mudanças que irão acontecer quando o software for introduzido.

Isto é suficiente para mudar a atitude do cliente sem mudar muito aquilo que você pode fazer por ele.Tanto antes como agora você irá fazer um levantamento das funcionalidades. Tanto antes como agora, você vai deixar que ele mexa na lista de funcionalidades. A diferença é que agora fazer essa alteração tem um efeito muito bem delimitado e visível. Clientes adoram visibilidade e adoram que você se preocupe com as necessidades deles. É exatamente isso que está fazendo. Você está conversando com o cliente e aprendendo o que ele quer. A diferença é que você não está partindo do princípio que pode aprender tudo num certo momento do projeto. Isso não é real. Isso não é possível.  Pensar o contrário é ingenuidade e persistir nesse pensamento, quando você  já passou, por isso é imbecilidade.

Bom, temos agora de tratar a empresa. Empresas de software adoram cotar as coisas em horas. Pior, em horas-relógio (por oposição a horas-homem). Adoram pedir que você dê estimativas de quanto demora a fazer. Tudo um desperdício de tempo, paciência e capacidade mental, em suma, de recursos. E o pior é que : nunca dá certo.

O primeiro conceito a aceitar é que é impossível adivinhar quanto vai demorar a fazer algo, ou quanto vai custar algo com certeza absoluta (i.e. sem erro). Tem que se aceitar que para cada estimativa há uma margem de erro associada. O erro depende de muitas coisas, mas o ponto é que ele existe. Isto é desconhecido de muitos gerentes. Quando se fala que vai demorar “3 horas”, eles sequer cogitam que você quis dizer de “2 a 4 horas”. E o pior é que você quis , realmente, dizer 3 horas exatamente.

Ok, precisamos estimar, mas precisamos que a estimativa seja útil. A única forma dela ser útil é conter a informação do erro. Descobrir esse erro não é simples. A forma de o encontrar é fazer muitas estimativas, comparar com os resultados reais e ver quanto erro, em média, existe. O bom é que alguém já fez isto e chegou ha conclusão que existe um padrão de desvios. Ele é chamado: cone de incerteza (incerteza é a palavra oficial e técnica para o conceito de erro).
É claro que o cone típico é genérico, você pode criar o seu se tiver dados para isso.

Tudo muito bom, mas então como estimar o tamanho das funcionalidades se não podemos usar horas?
Para responder a isso, precisa-se de saber exatamente o que se está tentando fazer e o que os números que encontrar representam. Eles representam “tamanho”, mas em que unidade? Será que importa unidade? Digamos que você tem uma funcionalidade “A” que estima em 3 horas de trabalho. E uma “B” que estima em 1 hora. O que 1 e 3 significam além de “A”” é 3 vezes mais demorado que “B”?  Nada mais. Repare que não significam que você irá demorar exatamente 1 ou 3 horas, e sim que se para “B” você demora “X” para “A” você demora 3 vezes mais (o problema das empresas é assumir que 1 hora e 3 horas são realmente isso na realidade). Use-se, então, um conjunto de números sem unidade (adimencionais), afinal o que interessa é a relação de proporção entre eles e não o que o número realmente significa.  São simplesmente pontos em um jogo de proporção.

E o que eu faço com isso? Eu pego a lista de funcionalidades e estimo todas elas com base em proporções. Quando a proporção for muito díspar, parto a funcionalidade em mais funcionalidades de maneira a ter uma boa granularidade. Qual é a melhor granularidade? Tipicamente uma tal que o número da menor seja menos de 10 vezes o da maior. Isto porque os seres humanos tem uma pré-disposição a entender intuitivamente números de uma ordem de grandeza (de 1 a 10). Além disso eles entendem apenas matematicamente e não têm um felling do significado real (você sabe quanta área ocupam 50550 pessoas colocadas ombro a ombro? E 3 pessoas?)

Ótimo, agora tenho um tamanho para a lista de funcionalidades. Mas como isso me ajuda a cobrar o preço certo pelo projeto como um todo? E pior, como fazer essa estimativa antes do projeto começar?

A idéia é que o projeto estará pronto quando todas as funcionalidades da lista estiverem prontas. E prontas significa terminadas mesmo, implementadas, testadas e implantadas (deployed). Isto é óbvio. Mas quanto isso demora? A pergunta neste ponto é: importa quanto demora?

Certos projetos têm datas limite para o cliente. A data em que o projeto tem que estar pronto é fixada e imutável. Outras vezes o cliente não está nem aí, ele quer é o projeto pronto. Certo?

Errado. O Cliente sempre quer o projeto na data que você lhe disser que vai estar pronto. Acontece que às vezes se essa data não for antes de uma data pré-determinada pelo cliente, ele não vai sequer tentar fazer o projeto. Então, você sempre tem que saber a data em que vai terminar, mas às vezes isso é um constrangimento, outras não. Ou seja, à vezes pode-se ultrapassar a data, outras não.  Quando é um problema, a data acaba limitando o tamanho da lista de funcionalidades em vez do custo ou do esforço.

Bom, então, precisamos de uma data. A conta é simples. Se o projeto tem “N” pontos de tamanho e  consigo fazer “D” pontos por dia, eu morarei N/D dias. Acontece apenas que em um dia é pouco provável que eu consiga terminar alguma funcionalidade. O bom senso aconselha a ter um tempo maior. Bom, então se eu fizer “P” pontos por período, demorei N/P períodos. Claro que isto tem um erro associado porque “P” não é “P” é P±p, portanto demorarei entre N/(P+p) e N/(P-p). (Sim, o “N” também não é “N”, é N±n)

E qual período escolho?

Você tem que escolher um período que lhe permita um certa flexibilidade. Já sabe-se que o cliente vai querer alterações e você quer lhe mostrar progresso. Isso implica reuniões. O período tem que ser tal que ambas as coisas sejam possíveis sem que se tornem empecilhos. Por outro lado o período depende da equipe. Nem todas as equipes fazem os mesmos pontos por período. Além disto você quer criar um sentimento de pressa na equipe sem que ter que estar todo o momento pedindo para “dar um gás”.

Tudo isto somado leva a um tempo de entre 2 a 4 semanas. Sendo possível ser mais ou menos em casos particulares. É claro que a primeira vez que fizer isto você não vai sequer ter noção de quantos pontos a sua equipe pode fazer por período, mas você pode fazer algumas tarefas durante um ou (preferencialmente) dois ou três períodos para ter uma noção e em cima disso fazer uma estimativa. (Claro que se fizer 10 ou mais periodos você pode fazer uma estatística melhor, mas ai já terá, provavelmente, acabado o projeto).

Tudo isto para concluir que é possível sim – existem pessoas fazendo isso , sim! – propor  sistemas, vende-los e construí-los: a) sem fazer todas as vontades ao cliente; b) sem cobrar e/ou estimar por hora de trabalho e; c) sem desprezar o valor que o software tem para o cliente.

A minha surpresa é que estas idéias simples e óbvias são o coração de todas as metodologias ditas “ágeis”. Elas não estão propondo nada que não seja intuitivo ou que seja inconcebível. O período de tempo é chamado Iteração, o número de pontos por período é chamado Velocidade. Os pontos usados são chamados de Story Points e a lista de funcionalidades (features) é chamada de Backlog. Os conceitos importantes têm nomes próprios.

Alguns  chamam a este processo Scrum, mas  Scrum é um pouco mais que isto. Outros chamam XP, mas XP é um processo de desenvolvimento e não de “gerência”, mas todos concordam que é o jeito ágil.

“Ágil” é portanto uma palavra que se opõe à “Tradicional”, sendo que a palavra “ágil” advém exatamente de usar o princípio contrário ao tradicional que parte da idéia de que tudo pode ser conhecido com antecedência e portanto é possível fazer um plano sem imprevistos. A idéia ágil é que se parte do princípio que nada será imutável durante o processo. O tamanho do backlog tende a ser fixo (porque é o rumo do projeto) mas mesmo ele pode ser alterado. Basta que o contrato seja revisto.
Falamos então em freqüência de mudança e não se a mudança vai existir ou não.

Falta apenas uma coisa: se o backlog está cotado em pontos como saber quanto cobrar? Obviamente chegaremos em algum fator de moeda/ponto mas como?
Se você não tiver nenhuma idÉia,  e está habituado a cotar por hora, pode converter o backlog em perÍodos, contar os dias dos períodos e converter em horas. Mais ou menos assim:

Custo = N/V * I * 6* H

“N” significando o total de pontos do backlog, “V” a velocidade  da equipe por iteração, “I” é o número de dias por iteração, “H” é o custo por hora  e 6 são as horas por dia.  Repare que não é 8 horas por dia, porque um dia de trabalho tem 8 horas, mas não todas são horas úteis. Na média de 5 a 6 horas são úteis.

Digamos que o projeto tem 200 pontos, a 20 pontos por iteração de três semanas (15 dias) e a 100 reais por hora teríamos : 200/20 * 15 * 6 * 100 = 90.000

Pensemos que este é um valor médio. O ponto aqui é que o valor do custo depende da equipe. Logo o preço depende da estimativa  da equipe e da velocidade da equipe: depende da equipe. E a margem?  Digamos que colocamos 10.000 de margem e chegamos no valor de 100.000 de preço final.

Equipes mais produtivas serão mais rápidas, certo? Certo.  Pensemos que a equipe é duas vezes mais rápida: Teremos o valor do custo cortado pela metada. Se o preço é o mesmo a nossa margem que era de 10.000 é agora de 55.000 tivemos um ganho de 550 % porque a velocidade da equipe aumentou para o dobro. E tivesse aumentado para o triplo? o resultado seria uma margem de 90.000 (900%) . Disto se aprende que uma pequena mudança na velocidade melhora a margem de lucro.  Você consegue mais lucro se não vincular o preço ao esforço de forma tão rígida como o preço por hora. Isto é óbvio. Sempre que você compra um serviço, deve-se perguntar um preço e um prazo, e não só um deles para calcular o outro. É pela flexibilidade entre os dois parâmetros que há lugar a margens maiores.

Nesta apresentação do Jeff  Sutherland você entende realmente que compensa e que é assim que empresas grandes ganham dinheiro.  Você quer ganhar dinheiro? Tenha equipes produtivas, seja ágil.

Anúncios

3 opiniões sobre “Quebra de Tradição”

  1. “Alguns chamam a este processo Scrum, mas Scrum é um pouco mais que isto. Outros chamam XP, mas XP é um processo de desenvolvimento e não de “gerencia”, mas todos concordam que é o jeito agil.”

    Sergio,

    As pessoas tem pouca especialidade para essas novas adoções, elas conhecem tecnologias mas não conhecem ciência, essas mesmas não procuram outra extensões de sua área a aprimorar em Matemática, Administração, Fisíca, Quimica ou qualquer outra matéria que lhe dê maior suplemento em sua área, elas preferem se especializar em if, else, goto, e outras futilidades TDD, DDD, BDD etc….

    “Pensar em dominio é pensar na interface principal que é seu cliente, o que abriga um Mundo abstrato maior do que esses que injetamos em conceitos e teorias em nossas mentes”

    Recomendo a leitura deste Post do Fabio Akita( http://www.akitaonrails.com/2008/12/16/off-topic-m-todo-cient-fico-vs-cargo-cult/comments/4639#comment-4639 ), onde ele discute Método Científico vs Cargo Cult, muito bem colocado, acho que isso vai lhe esclarecer muita coisa e ampliar o foco da questão.

  2. Sérgio,

    Gosto muito do seu blog. Deixa eu te contar um pouco de como eu trabalho, tentando modificar um pouco essa realidade que você relatou. Eu faço uso de uma variação do que você relatou, mesmo que continue sendo essencialmente valor por hora.

    Eu estabeleço perfis (de papeis/responsabilidades) onde eu considero: esforço, grau de dificuldade e tempo estimado (e as vezes tecnologia / metodologias / ideologias como “equalizador ” ). Cada perfil possui uma faixa ou um valor hora definido). No orçamento eu compatibilizo esses perfis com as tarefas que serão executadas, mesmo que sejam pelas mesmas pessoas, consegue se obter um custo médio que é mais justo para ambas as partes.

    Obviamente deve existir um escopo, que normalmente é o objeto da consultoria que precisa ser bem detalhado e caso ele peça algo não informado nesse escopo, orçamos um aditivo com os mesmos critérios usados para a proposta inicial.

    As faixas de valores horários são atualizados de acordo com pesquisas salariais feitas par cada região (aqui no Brasil) pois apresentam uma disparidade muito grande entre um mercado de uma região e outra e isso implica que os custos são maiores também. Então essa variação me permite compensar as perdas, praticar um preço de mercado competitivo e cobrar um valor médio justo para o cliente.

    Jeff

    1. Jeff,

      Obrigado por ler o blog.
      Suponhamos que vc tem um perfi de AJAX e que os seus programadores mexeram com isso em um unico projeto (aquele que deu origem ao perfil). A experiencia deles é minima. O risco é muito grande. Imaginemos que vc tem outro perfil webservices que os programadores estão cansados de usar porque todos os seus sistemas têm interface de webservices. O risco é minimo , a experiencia é grande.

      Para um novo sistema que precisa de webservices vc cobra o mesmo em todos os sistemas independentemente da experiência dos programadores ? e para o de ajax ?

Deixe uma Resposta

Please log in using one of these methods to post your comment:

Logótipo da WordPress.com

Está a comentar usando a sua conta WordPress.com Terminar Sessão /  Alterar )

Google+ photo

Está a comentar usando a sua conta Google+ Terminar Sessão /  Alterar )

Imagem do Twitter

Está a comentar usando a sua conta Twitter Terminar Sessão /  Alterar )

Facebook photo

Está a comentar usando a sua conta Facebook Terminar Sessão /  Alterar )

w

Connecting to %s