Agile FAQ #3: O que você prefere? Uma mentira ou software funcionando no início de um projeto?

Inicialmente o título dessa FAQ seria algo como “E o Prazo?”, porém, mudei para esse título cima (O que você prefere? Uma mentira ou software funcionando no início de um projeto?) que representa bem a minha opinião sobre esse assunto que é muito recorrente nas listas, nas palestras que faço e até mesmo em clientes, portanto, vamos discutir um pouco sobre como a famosa questão do “prazo” é tratada sob a ótica sugerida pelas Metodologias Ágeis de desenvolvimento de Software.

Nesse texto parto do princípio de que esse raciocínio de questionarmos se preferimos uma mentira (ilusão) para nos apoiar no início do projeto ou se desejamos realmente ter entregas de software com valor logo no início do mesmo, deve ser o principal balizador quando somos questionados sobre o prazo, principalmente se assumirmos com consciência a incerteza, intangilibidade e imprevisibilidade que é desenvolver software, ou seja, a resposta para essa pergunta irá direcionar toda a sua forma de trabalho e principalmente os resultados gerados pelo projeto.

A questão principal não é só ter um prazo para fim do projeto, mas sim que normalmente em função dessa necessidade, a cultura corporativa no qual estamos inseridos nos exige os famosos “cronogramas detalhados” com cada item de requisito ou de atividade, contendo sua respectiva estimativa de esforço, sua devida data de início e de fim da execução. E para gerar esse cronograma detalhado, torna-se necessário um conhecimento também detalhado, que acontece muitas das vezes através de uma espécie de congelamento de escopo logo no início do projeto.

Esse tipo de situação estimula uma série de efeitos indesejáveis a um projeto de software, mas para explicar melhor isso, acompanhe a figura abaixo (clique nela para ampliar), que mostra um raciocínio bem simples (baseado em TOC – Theory Of Constraints) sobre as causas e efeitos (ler inicialmente de cima para baixo) relacionados à cobrança de prazos detalhados num projeto de software (inclusive você também poderá nos ajudar a evoluir essa árvore de raciocínio).

ARA - Com causas e efeitos sobre prazos detalhados

ARA - Com causas e efeitos sobre prazos detalhados

A questão principal não é usar ou não usar metodologias ágeis, mas sim uma questão de racionalidade, pois ora, se sabemos que a visão de tempo, esforço e escopo mudará ao longo do projeto, por qual motivo vamos desperdiçar recursos tentando gerar uma ilusão no início do projeto? Ou seja, sinceramente não vejo ser muito inteligente para uma organização, gastar um grande volume de dinheiro para gerar essa falsa idéia de controle e gerenciamento acerca do desenvolvimento de software.

Acredito fortemente que essa falsa idéia de controle imposta nos projetos, acontece em função da carência de confiança entre a empresa contratante (cliente) e a empresa contratada (fornecedora). Isso na verdade não é algo apenas do mundo dos projetos, mas sim é uma questão cultural e sistêmica muito forte que vivemos em maioria dos modelos sociais conhecidos.

Claro que quebrar esse estigma da falta de confiança não é algo simples de fazer, e principalmente leva muito tempo até equalizar relações comerciais pautadas em confiança entre as partes (Ver o excelente artigo de Felipe Rodrigues sobre Confiança na 5ª edição da Revista Visão Ágil).

Note então que as Metodologias Ágeis não oferecem uma solução definitiva acerca desse tema, mas sim, promovem a construção de forma paulatina de relações confiáveis e também estimula uma reflexão dessa racionalização de recursos quando se trata da criação de um software para uma organização.

Essa reflexão é fortemente apoiada nos pilares de visibilidade, inspeção e adaptação de processo, bem como, iniciamos esse exercício cultural através das práticas e idéias como entregas constantes de alto valor agregadoescopo interativo e incremental, baby steps, simplicidade e melhoria contínua.

Então como resposta a esse pseudo “controle financeiro” que a visão de prazos fornece a uma organização, as práticas e idéias expostas acima, são fortemente baseadas na solução de ao invés de fixar primeiro o escopo e qualidade, para em seguida fixar tempo e custo no início de um projeto, fixamos apenas o custo, o tempo e a qualidade, mas isso você pode ler melhor nesse artigo histórico do meu amigo Vinícius Manhães Teles sobre Contrato de Escopo Negociável, lá você verá na verdade que a resposta de “Quando Terminará?” e “Quanto Custará?” um projeto não é o problema, pois nesse modelo, fixamos exatamente a duração e o custo, o que deixamos deslizante é exatamente o que caberá como escopo de valor agregado nesse tempo contratado.

Na verdade as Metodologias Ágeis sugerem uma maneira mais honesta de tratar o prazo, onde temos a coragem de assumir que as mudanças no escopo são importantes para o cliente; E principalmente temos a coragem e humildade de admitir que não somos capazes de aprender, estimar e planejar tudo relacionado ao escopo  logo no início de um projeto, então diante dessa incapacidade, por qual motivo devemos gastar dinheiro para tentar dominar o escopo no início de um projeto (e com isso gerar uma ilusão), a fim de gerar estimativas de prazos e custos?

Mas para finalizar, voltemos ao título desse singelo artigo, que sem querer fazer apologia à Maquiavel, a grande realidade que eu trago para você, é que a esmagadora maioria das pessoas irá preferir a mentira dos prazos detalhados no início do projeto; Talvez isso ocorra devido à natureza humana de necessitar das ilusões (até mesmo para justificar nossa existência), ou seja, apesar de belo e factível, infelizmente esse modelo gerencial estimulado por Agile não está ao alcance de todas as empresas, por isso, da próxima vez que for perguntado sobre o prazo de um projeto, faça essa pergunta mágica: O que você prefere? Uma mentira ou valor agregado no início de um projeto?


Sobre o autor:

Manoel Pimentel, CSP

Manoel Pimentel Medeiros, É Engenheiro de Software, com 15 anos na área de TI, atualmente trabalha como Coach em Agile, Lean e TOC para empresas do segmento de serviço, financeiro e bancário. É Diretor Editorial da Revista Visão Ágil e Editor Chefe da InfoQ Brasil, Já escreveu sobre agile para importantes portais e revistas do Brasil e exterior e Também palestrou em eventos nacionais e internacionais sobre agilidade. Possui as certificações CSM e CSP da Scrum Alliance e foi um dos pioneiros na utilização e divulgação de métodos ágeis no Brasil.

Contatos: manoel@visaoagil.com

11 thoughts on “Agile FAQ #3: O que você prefere? Uma mentira ou software funcionando no início de um projeto?

  1. Pingback: links for 2009-06-18 « pabloidz

  2. Bom artigo.

    Complementando o que foi escrito sobre a necessidade humana de uma ilusão, vejo também a necessidade de querer “tudo na mão”, ou seja, tudo sob controle, sabendo com precisão cirurgica o que vai acontecer naquele dia, naquela hora com o projeto.
    Sabemos bem que escopo de software não é assim. Precisamos estar focados sim, nas tarefas de iteração, mas com a mente aberta para as mudanças.
    XP ou outra ágile não vão solucionar, como foi escrito, estes problemas. Mas ágile com pessoas comprometidas com os valores e princípios sim, vão fazer a diferença.

  3. Existem casos e casos, acredito que em muitos deles a cobrança por um prazo bem especifico no inicio do projeto pode não ser prioritário, mas há casos em que o prazo é importantissimo.

    Exemplo: Adequação de um sistema para NF-e.

    A empresa tem um prazo para se adequar, voce tem que entregar uma solução em um prazo hábil. Portanto, sendo ágil ou não, voce deverá dar um prazo ao cliente que mais se aproxime do real, independente das interperes que venha a acontecer durante o decorrer do projeto.

    Muitas vezes a fixação ou não de prazos fixos, depende muito do projeto.

    • Concordo, mas no caso de demandas (projetos) de origem mandatória (legais), veja o trecho que falo sobre:

      a resposta de “Quando Terminará?” e “Quanto Custará?” um projeto não é o problema, pois nesse modelo, fixamos exatamente a duração e o custo, o que deixamos deslizante é exatamente o que caberá como escopo de valor agregado nesse tempo contratado.

      O seja a questão de prazo final não é necessariamente um problema, o problema maior que temos são os prazos detalhados (com esforço e datas) em cada item do escopo, pois é nesse caso que vemos os maiores problemas conforme o texto abordou.

      Abs,

  4. Concordo com a linha geral e os argumentos do seu artigo Manuel, mas acho que existe um elemento importante que vc não desenvolveu o suficiente.

    O detalhamento do cronograma funciona não só como elemento de controle das atividades de desenvolvimento de sw. Ele funciona também como elemento limitador de recursos. Explico melhor: Existem determinadas situações onde o prazo de entrega e o escopo não são negociáveis. São casos comuns em indústrias altamente regulamentadas como a indústria financeira. Nestas indústrias existem as demandas mandatórias derivadas de legislação e regulamentação que devem ser entregues em um prazo determinado. São demandas claramente definidas, ou seja, possuem escopo delimitado.

    Quando do início do desenvolvimento desta demanda os prazos devem ser corretamente previstos e cumpridos. Mesmo com informações insuficientes para determinar a duração de cada atividade, as mesmas devem ser previstas e realizadas obedecendo-se rigidamente o cronograma. Nestes casos não é incomum a existência de horas extras para realização das atividades ou até de ajustes no cronograma em momento de execução devido a atividades que duraram menos do que foi o planejado. Mas aqui o conograma funciona de forma limitadora de tempo. Ele envia a seguinte mensagem à equipe: “Não sabemos muito bem qto tempo esta atividade irá durar, mas ela tem que estar pronta até o dia X. Se virem.” Nestas situações normalmente são permitidas horas extras (o custo se torna variável).

    O cronogama neste caso não assume o papel de uma ilusão, ele assume o papel de um target que deve ser buscado pela equipe e que representa o target que a organização está submetida pelo mercado.

    Enfim, eu acho que as suas considerações são importantes, mas elas somente são aplicáveis nas situações que vc destacou. Qdo o tempo e o escopo não são negociáveis o cronograma se faz necessário. Mas não no sentido de representar uma realidade/previsão, mas como um elemento que deverá influenciar esta realidade e as ações da equipe.

    • Gustavo

      Em parte, concordo que esse tipo de cronograma sirva para colocar “metas” de prazos. Pode ter alguma utilidade…

      Mas é muito ruim seguir o costumeiro: “(…) tem que estar pronta até o dia X. Se virem. (…) horas extras”.
      Situações assim podem funcionar por algum tempo, mas muitas vezes deixam de ser exceção e viram regra… aí a qualidade cai e gera prejuízos depois da entrega “no prazo” (isso quando é no prazo): coisas mal testadas, bugs ocultos, interfaces ruins, etc.

      Outro raciocínio relacionado costuma ser: então vamos colocar umas “folgas” (“gorduras”) no cronograma… E isso claramente também é ruim: está inflacionando o custo, para gerar a “ilusão” sobre a qual o Manoel escreveu. Isso sem falar em efeitos como a “síndrome do estudante”, que cronogramas com muitas folgas podem incentivar.

  5. Olá, Manoel. Ótimo post para reflexão.

    Adorei a parte que você diz: “… temos a coragem e humildade de admitir que não somos capazes de aprender, estimar e planejar tudo relacionado ao escopo logo no início de um projeto…”

    É isto mesmo. Não temos hoje ainda esta condição de planejar / estimar tudo no início do projeto.

    A nossa engenharia (de software) é muito nova. Tem pouco mais de 50 anos. Ou seja, é um bebê comparada com outras engenharias. Então, teremos um longo caminho pela frente. Virão o Scrum 2, 3, o XPTO, Web 35.64…

    Hoje, vejo a engenharia de software como um grande laboratório, onde existem vários cientistas buscando a cura para o mal. A crença na fórmula mágica já foi concedida ao ISO, depois ao PMI, depois ao CMM, agora com mais força ao movimento Ágil. Mas, tudo isto são experiências, que buscam a cura. A cura da imaturidade.

    Pegando um gancho do seu post, eu há 2 semanas disse exatamente isto para um grande cliente da consultoria que atuo: você (cliente), quer que eu estime pra você em APF, monte um cronograma de 100 tasks… sabendo nós que tudo isto tem 99% de chance de estourar em mais de 100% prazos, custos etc etc. Bom, se você quiser, eu faço. Sou especialistas em FPA, PMI… Mas, se já sabemos que não dará certo, porquê não tentarmos algo novo? E foi aí que propûs o Scrum com algumas outras práticas ágeis.. Vamos ver no que vai dar.

    Abraço,

    Ubiratan Padilha
    Project Manager, CSM, Especialista em Usabilidade
    http://www.linkedin.com/in/ubiratanpadilha
    http://twitter.com/ubiratanpadilha

  6. Excelente artigo Manuel, me estimulou a adquirir uma assinatura da revista😉.

    O grande problema é procurar a tal bala de prata. É usar sempre os mesmos critérios para comprar qualquer coisa: prazo de entrega, preço e custos pré-definidos. Você pode usar essa tríplice pra comprar um carro, encomendar um bolo na confeitaria, fazer um corte de cabelo ou contratar um pintor para a reforma da sua casa.

    Projetos de software resolvem problemas específicos, únicos e complexos. Usar critérios “comuns” para contratar um projeto de software é realmente buscar uma ilusão confortável no início que só trará dores de cabeça no futuro: “isso não é bem o que eu queria” e “vai custar muito caro pra mudar isso?”.

    Desculpe minha simplicidade de argumentos, mas na minha opinião, aceitar ilusões (mentiras como no título do artigo) é a pura e simples preguiça.

    Lucas Oleiro
    Desenvolvedor, CSM e Humano

  7. Concordo com suas considerações Manoel.

    Na verdade, acho que existem pessoas que acreditam realmente que os prazos serão executados exatamente como foram descritos no cronograma.

    E algumas vezes, eles são. O problema é a quantidade de horas extras que serão trabalhadas pelos profissionais para que tudo fique no pronto no “momento certo” (entre outras coisas). Agora, isso é sustentável? Todos sabemos que, pelo menos, não é bom…

    Para quem paga as horas-extra o custo não é praticamente nada, na maioria das vezes. Mas, para quem está trabalhando, suportando a pressão e virando noite. Ah sim, é muita coisa e não consigo pensar que isso não vá impactar na qualidade de um trabalho que é caracterizado como intelectual.

    Claro, que cada caso é um caso e não dá para aplicar Agile como solução para tudo. Até porque, se alguém acreditasse nisso, voltaríamos àquela velha história da “bala de prata”…

    A[]´s
    Marcelo Zeferino

  8. Manoel

    Achei o artigo bem interessante, pois uma das primeiras coisas que me perguntei ao começar a me inteirar sobre metologias ágeis foi a questão de prazos e custos. Prestei serviços para empresa pública e privada, fiz propostas técnicas de projetos e gerenciei projetos e uma das maiores dificuldades era estimar prazos e custos porque sei de todas as variáveis que existem no desenvolvimento de software. Acho que a maioria das empresas, principalmente públicas, pedem essas estimativas porque precisam estimar orçamentos, alocar recursos e portanto ter idéia dos gastos financeiros por vir. Além disso, existe a questão de licitação, onde as empresas concorrentes precisam ter uma noção do tamanho do projeto para precificá-lo.
    Apesar de vc colocar que se fecha prazo e custo com um escopo grosseiro inicial, sendo aceitável mudá-lo durante o tempo, não consigo enxergar isso na prática principalmente em contratos com o governo. Consegue exemplificar uma situação em que funcione?
    Obrigada e parabéns!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s