{"id":4072,"date":"2022-06-20T22:14:37","date_gmt":"2022-06-21T01:14:37","guid":{"rendered":"https:\/\/nearjob.com.br\/?p=4072"},"modified":"2022-06-20T22:15:35","modified_gmt":"2022-06-21T01:15:35","slug":"projetos-limitados-por-estimativas-estao-fadados-ao-fracasso-ou-os-beneficios-de-metodos-verdadeiramente-ageis","status":"publish","type":"post","link":"https:\/\/nearjob.com.br\/es\/projetos-limitados-por-estimativas-estao-fadados-ao-fracasso-ou-os-beneficios-de-metodos-verdadeiramente-ageis\/","title":{"rendered":"Projetos limitados por estimativas est\u00e3o fadados ao fracasso \u2013 ou os benef\u00edcios de m\u00e9todos (verdadeiramente) \u00e1geis"},"content":{"rendered":"

As estimativas formam a base de muitos projetos de TI. Estimamos organizar um projeto, estimamos estabelecer um cronograma, estimamos determinar uma data de entrega, estimamos comprometer e contratar… e acima de tudo, usamos essas estimativas preliminares para julgar o sucesso ou o fracasso de um projeto. Um projeto \u00e9 considerado bem-sucedido quando o prazo \u00e9 cumprido, \u00e9 considerado fracassado quando o prazo \u00e9 excedido. No Web2day, Fr\u00e9d\u00e9ric Leguedois, Agile Evangelist do Cloud Temple, oferece outra leitura. E se todos os projetos j\u00e1 estivessem fracassando quando uma estimativa \u00e9 feita?<\/p>\n\n\n\n

As justificativas preferidas pelos gerentes de projeto<\/h2>\n\n\n\n

Muitas vezes acontece que os projetos com prazo n\u00e3o s\u00e3o entregues no prazo. Nesse caso, os gerentes geralmente encontram desculpas.<\/p>\n\n\n\n

\u201cMeu planejamento foi bom, mas o cliente mudou de ideia\u201d<\/h3>\n\n\n\n

Esta primeira justifica\u00e7\u00e3o \u00e9 dif\u00edcil de justificar. O fato de o cliente mudar de ideia n\u00e3o \u00e9 uma coisa ruim em si. Ele refletiu, seu projeto amadureceu, ele acredita que uma modifica\u00e7\u00e3o pode ser \u00fatil para os usu\u00e1rios. \u00c9 potencialmente bom, mas n\u00e3o \u00e9 compat\u00edvel com os hor\u00e1rios.<\/p>\n\n\n\n

\u201cMeu planejamento foi bom, mas os desenvolvedores est\u00e3o atrasados\u201d<\/h3>\n\n\n\n

No segundo caso, dizer que os desenvolvedores est\u00e3o atrasados \u200b\u200bcoloca em d\u00favida sua compet\u00eancia. Eles est\u00e3o atrasados: entendem mal ou com defeito. No entanto, Fr\u00e9d\u00e9ric Leguedois acredita que a culpa \u00e9 de quem faz o planejamento, n\u00e3o de quem faz o trabalho. \u201cAtraso \u00e9 uma diferen\u00e7a de tempo entre o que \u00e9 esperado e o que realmente aconteceu. \u00c9 a diferen\u00e7a entre um sonho e a realidade. A realidade n\u00e3o pode estar errada, mas o planejamento n\u00e3o pode. \u00c9 como as previs\u00f5es do tempo: elas t\u00eam uma certa confiabilidade, enquanto o tempo \u00e9 necessariamente exato\u201d<\/em> .<\/p>\n\n\n\n

\u201cMeu planejamento foi bom, mas houve imprevistos\u201d<\/h3>\n\n\n\n

Os imprevistos t\u00eam a capacidade de justificar todos os problemas que os projetos podem enfrentar. Se o prazo n\u00e3o foi respeitado, muitas vezes \u00e9 porque as varetas ficaram presas nas rodas dos membros que trabalham em um projeto. Podemos ver esses eventos como imprevistos, tamb\u00e9m podemos aceit\u00e1-los e considerar que \u00e9 imposs\u00edvel prever e planejar tudo. \u201cPlanejamento \u00e9 uma profiss\u00e3o: a de clarividentes, a de or\u00e1culos e, \u00e0s vezes, a de gerentes de projeto\u201d<\/em> .<\/p>\n\n\n\n

A receita milagrosa para a agilidade autoproclamada<\/h2>\n\n\n\n

Para acabar com esses atritos e projetos imperfeitos, \u201ctodo mundo est\u00e1 falando em agilidade\u201d. Assim que usado, tamb\u00e9m banal. Embora os princ\u00edpios de agilidade e o pensamento que envolve esses conceitos sejam bons, muitas vezes tendemos a colocar termos relacionados \u00e0 agilidade em todos os lugares, para provar sua modernidade. \u201cPegamos o gerente de projeto, ele se torna o propriet\u00e1rio do produto, instalamos o Jira, colocamos a palavra Agile no folheto de vendas: e de repente, todos os problemas desaparecem, como que por m\u00e1gica\u201d<\/em> .<\/p>\n\n\n\n

Claro que a realidade \u00e9 bem diferente. Sem forma\u00e7\u00e3o em m\u00e9todos \u00e1geis, sem explica\u00e7\u00e3o do seu interesse pela gest\u00e3o de projetos e, sobretudo, sem uma mudan\u00e7a de mentalidade na gest\u00e3o eficaz dos projetos, estes \u00faltimos n\u00e3o podem ser melhor geridos. \u201cQuando voc\u00ea muda a terminologia e n\u00e3o muda a realidade, as mesmas causas levam \u00e0s mesmas consequ\u00eancias. As liga\u00e7\u00f5es causais s\u00e3o imut\u00e1veis. Voc\u00ea tem que repensar a forma de operar e n\u00e3o fazer mais planejamento s\u00f3 porque \u00e9 tradi\u00e7\u00e3o, porque sempre fizemos assim\u201d<\/em> .<\/p>\n\n\n\n

\"post-it-612x405.jpg\"
post-it-612×405.jpg<\/figcaption><\/figure><\/div>\n\n\n\n

O impacto das estimativas na produtividade do desenvolvedor<\/h2>\n\n\n\n

Segundo Fr\u00e9d\u00e9ric Leguedois, as estimativas t\u00eam pelo menos duas consequ\u00eancias nefastas. Primeiro, quando feito, eles s\u00e3o o \u00fanico indicador do sucesso de um projeto (quando, na realidade, um projeto pode ser entregue no prazo e falhar). A segunda consequ\u00eancia diz respeito \u00e0s equipes de desenvolvedores. Digamos que a equipe tenha um prazo na quinta-feira \u00e0 noite. No final da tarde, eles entendem que n\u00e3o conseguir\u00e3o entregar as funcionalidades finalizadas no prazo. Eles ent\u00e3o t\u00eam a escolha:<\/p>\n\n\n\n

  • Adiar a produ\u00e7\u00e3o para uma data posterior<\/li>
  • Colocado em produ\u00e7\u00e3o na data acordada, apesar dos bugs<\/li><\/ul>\n\n\n\n

    Os desenvolvedores escolher\u00e3o com base nas consequ\u00eancias de sua escolha. Se n\u00e3o entrar em opera\u00e7\u00e3o a tempo os expor a culpa significativa do gerente de projeto, gerenciamento ou cliente, eles entrar\u00e3o em opera\u00e7\u00e3o \u2013 apesar dos riscos inerentes ao MEP. Caso contr\u00e1rio, se o product owner e os demais elos da cadeia entenderem que esse atraso \u00e9 mais prudente, n\u00e3o hesitar\u00e3o em falar sobre isso, adiar o in\u00edcio da produ\u00e7\u00e3o se necess\u00e1rio e continuar\u00e3o trabalhando at\u00e9 que as funcionalidades estejam conclu\u00eddas. \u201cParar de estimar \u00e9 entregar funcionalidades que funcionam. O prazo leva ao medo\u201d<\/em> . Alguns continuar\u00e3o esta observa\u00e7\u00e3o especificando que\u201co medo leva \u00e0 raiva, a raiva leva ao \u00f3dio, o \u00f3dio… leva ao sofrimento\u201d<\/em> .<\/p>\n\n\n\n

    O planejamento tamb\u00e9m resulta na gera\u00e7\u00e3o de d\u00edvida t\u00e9cnica. \u201cPara quem n\u00e3o conhece o assunto, d\u00edvida t\u00e9cnica corresponde a um empr\u00e9stimo feito ao banco. Voc\u00ea n\u00e3o tem recursos para comprar um carro, voc\u00ea faz um empr\u00e9stimo, voc\u00ea paga seu carro e uma d\u00edvida em v\u00e1rios meses. A d\u00edvida t\u00e9cnica \u00e9 exatamente o mesmo princ\u00edpio: voc\u00ea n\u00e3o tem tempo para fazer um bom trabalho, voc\u00ea faz um trabalho ruim, os usu\u00e1rios n\u00e3o o veem, mas todas as altera\u00e7\u00f5es feitas posteriormente ser\u00e3o mais longas, mais arriscadas e, portanto, mais caras.<\/em><\/p>\n\n\n\n

    O fato de for\u00e7ar os desenvolvedores a prazos mais ou menos aleat\u00f3rios tamb\u00e9m tem o efeito de rebaix\u00e1-los ao papel de simples executores. A mensagem \u00e9: \u201cvoc\u00ea tem que fazer isso para esta data\u201d. Um desenvolvedor precisa de tempo para tomar iniciativas, projetar, discutir com seus pares. Ao basear sua organiza\u00e7\u00e3o em prazos, voc\u00ea for\u00e7a os desenvolvedores a uma fun\u00e7\u00e3o restrita, seu valor agregado \u00e9 limitado, sua motiva\u00e7\u00e3o \u00e9 de fato<\/em> degradada.<\/p>\n\n\n\n

    \"team-612x400.jpeg\"
    team-612×400.jpeg<\/figcaption><\/figure><\/div>\n\n\n\n

    O problema dos m\u00e9todos de estima\u00e7\u00e3o<\/h2>\n\n\n\n

    O principal problema com os m\u00e9todos de estimativa \u00e9 que eles nunca s\u00e3o confi\u00e1veis. Os gerentes de projeto estimam os prazos relendo as especifica\u00e7\u00f5es v\u00e1rias vezes (o famoso m\u00e9todo do dedo molhado).<\/p>\n\n\n\n

    Os clientes apresentam suas necessidades muito brevemente para que uma estimativa coerente seja feita. \u201cPrimeiro queremos saber o or\u00e7amento necess\u00e1rio, depois especificaremos nossas especifica\u00e7\u00f5es. Experimente este m\u00e9todo com o seu merceeiro, v\u00e1 v\u00ea-lo e simplesmente pergunte-lhe quanto vai custar-lhe sem lhe dizer exatamente o que quer comprar. \u00c9 apenas em TI que esse tipo de m\u00e9todo persiste\u201d<\/em> .<\/p>\n\n\n\n

    Outros m\u00e9todos como o COCOMO (COnstructive COst MODel) tentam prever o imprevis\u00edvel com f\u00f3rmulas mais ou menos cient\u00edficas. Aqui, o n\u00famero de linhas de c\u00f3digo esperado permite saber o tempo necess\u00e1rio para o desenvolvimento do projeto. Mas o n\u00famero de linhas de c\u00f3digo n\u00e3o \u00e9 conhecido antecipadamente e nem todas as linhas de c\u00f3digo requerem o mesmo tempo de desenvolvimento. Fr\u00e9d\u00e9ric Leguedois tamb\u00e9m acredita que os processos para facilitar as estimativas no m\u00e9todo SCRUM (como o planning poker) tamb\u00e9m apresentam falhas. No in\u00edcio do sprint, voc\u00ea gastar\u00e1 tempo estimando o imprevis\u00edvel; no final do sprint, voc\u00ea passar\u00e1 algum tempo tentando descobrir por que seu palpite inicial n\u00e3o se confirmou.\u201cPlanejar o p\u00f4quer \u00e9 uma pr\u00e1tica de adivinha\u00e7\u00e3o pseudo-\u00e1gil extremamente demorada e complexa e, portanto, cara, destinada a adivinhar informa\u00e7\u00f5es que ningu\u00e9m precisa. Traduz a desconfian\u00e7a de quem a coloca em pr\u00e1tica, pois um prazo est\u00e1 sempre atrelado \u00e0 desconfian\u00e7a\u201d<\/em> .<\/p>\n\n\n\n

    Que solu\u00e7\u00e3o, al\u00e9m das estimativas?<\/h2>\n\n\n\n

    A confer\u00eancia de Fr\u00e9d\u00e9ric Leguedois na Web2day, que quase assumiu os c\u00f3digos do one man show, foi oferecida com o objetivo de fazer pensar as pessoas que participam dos projetos. Segundo ele, para permitir que os projetos sejam verdadeiros sucessos, \u00e9 preciso come\u00e7ar parando com a gest\u00e3o por medo. \u201cTemos que parar de dizer que temos que fazer tal e tal coisa para tal data. Devemos deixar os desenvolvedores discutirem, trocarem, encontrarem solu\u00e7\u00f5es. As pessoas n\u00e3o precisam de um prazo para compartilhar, basta motiva\u00e7\u00e3o. Voc\u00ea tem que criar uma emula\u00e7\u00e3o para que os desenvolvedores se orgulhem de seu trabalho e compartilhem com a equipe\u201d<\/em> .<\/p>\n\n\n\n

    Mas como vender um projeto para um prospect sem depender de estimativas, quando os clientes est\u00e3o acostumados a comprar especifica\u00e7\u00f5es associadas a um pre\u00e7o e um prazo?\u201cNa realidade, os clientes escolhem os projetos em que confiam. Se queremos parar de fazer estimativas, temos que ir aos clientes, explicar o interesse de nossos m\u00e9todos para gerar confian\u00e7a. Aqueles que experimentaram projetos de pre\u00e7o fixo insatisfat\u00f3rios o entender\u00e3o. A vari\u00e1vel de ajuste deve ser sempre o escopo de um projeto e n\u00e3o sua qualidade, custo ou prazo. Nada \u00e9 indivis\u00edvel, tudo \u00e9 um conjunto de caracter\u00edsticas. Quando come\u00e7amos com as funcionalidades priorit\u00e1rias, quando confiamos nos desenvolvedores, quando deixamos de fazer promessas, quando nos adaptamos ao contexto, estamos realmente em agilidade e os projetos d\u00e3o certo\u201d.<\/em><\/p>","protected":false},"excerpt":{"rendered":"

    As estimativas formam a base de muitos projetos de TI. Estimamos organizar um projeto, estimamos estabelecer um cronograma, estimamos determinar uma data de entrega, estimamos comprometer e contratar… e acima de tudo, usamos essas estimativas preliminares para julgar o sucesso ou o fracasso de um projeto. Um projeto \u00e9 considerado bem-sucedido quando o prazo \u00e9 cumprido, \u00e9 […]<\/p>","protected":false},"author":1,"featured_media":4073,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[369],"tags":[602,370],"amp_enabled":true,"_links":{"self":[{"href":"https:\/\/nearjob.com.br\/es\/wp-json\/wp\/v2\/posts\/4072"}],"collection":[{"href":"https:\/\/nearjob.com.br\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/nearjob.com.br\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/nearjob.com.br\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/nearjob.com.br\/es\/wp-json\/wp\/v2\/comments?post=4072"}],"version-history":[{"count":1,"href":"https:\/\/nearjob.com.br\/es\/wp-json\/wp\/v2\/posts\/4072\/revisions"}],"predecessor-version":[{"id":4075,"href":"https:\/\/nearjob.com.br\/es\/wp-json\/wp\/v2\/posts\/4072\/revisions\/4075"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/nearjob.com.br\/es\/wp-json\/wp\/v2\/media\/4073"}],"wp:attachment":[{"href":"https:\/\/nearjob.com.br\/es\/wp-json\/wp\/v2\/media?parent=4072"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/nearjob.com.br\/es\/wp-json\/wp\/v2\/categories?post=4072"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/nearjob.com.br\/es\/wp-json\/wp\/v2\/tags?post=4072"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}