É fato que projetos e horas extras tem uma relação próxima. Estar numa equipe de um projeto é tido por muitos como sinônimo de trabalho além das horas normais. Muitas vezes por todo o período da empreitada. Mas será que isso realmente precisa ser assim?
Acho útil analisar esse tema por meio de três das razões pelas quais tantos projetos acabam incorrendo em jornadas de trabalho estendidas.
<div id="toc_container" class="toc_white no_bullets">Sum&aacute;rio<ul class="toc_list"><li><a href="#Razao-1-Somos-pessimos-em-prever-o-futuro">1 Razão 1: Somos péssimos em prever o futuro</a></li><li><a href="#Razao-2-Tendemos-a-subestimar-as-tarefas">2 Razão 2: Tendemos a subestimar as tarefas</a></li><li><a href="#Razao-3-Projetos-sao-desafiadores-ou-8220E-assim-mesmo8221">3 Razão 3: Projetos são desafiadores (ou &#8220;É assim mesmo&#8221;)</a></li><li><a href="#O-que-fazer-entao">4 O que fazer então?</a></li><li><a href="#O-que-fazer-se-o-projeto-ja-nasce-desafiador">5 O que fazer se o projeto já nasce desafiador?</a></li><li><a href="#Conclusao">6 Conclusão</a></li></ul></div>
<h2>Razão 1: Somos péssimos em prever o futuro</h2>
Uma forte razão pela qual precisamos trabalhar tanto a mais em um projeto é simples. Seres humanos não foram feitos para prever o futuro. Não é difícil constatar que somos péssimos nisso. Basta ver como nossos antepassados imaginaram a época presente em filmes como &#8220;De Volta para o Futuro&#8221; e &#8220;Exterminador do Futuro&#8221; para se deliciar com previsões erradas de todos os tipos.
Mas o que isso tem a ver? Ora, todo o projeto começa com uma fase de planejamento na qual uma das principais tarefas é prever todas (ou parte delas, como veremos) as atividades necessárias no projeto e estimar o trabalho que será gasto em cada uma delas. Em outras palavras, todo projeto começa como um exercício de previsão do futuro (que, ironicamente, costuma demorar mais do que o previsto).
<h2>Razão 2: Tendemos a subestimar as tarefas</h2>
Ora, se erramos tanto em nossa previsão do futuro, estatisticamente era esperado que errássemos em igual medida &#8220;para mais&#8221; e &#8220;para menos&#8221; nas previsões, certo?
Em outras palavras, era de se esperar que cada projeto começasse com 50% de chance de atrasar ou de adiantar, não é? Mas a realidade não é essa. No geral, projetos tendem muito mais a serem subestimados do que o contrário. [1][2]
Porque isso acontece? Consigo pensar em pelo menos duas causas.
A primeira delas talvez seja cultural. Otimismo. Tendemos a descartar experiências ruins anteriores e riscos ao estimar tarefas e considerar que dessa vez será diferente.
A outra causa não é fácil de ser descrita com uma palavra só. É o fato de que nós tendemos a ficar constrangidos em dar uma estimativa que possa ser interpretada como preguiçosa. Em outras palavras, nos preocupamos que nossa estimativa seja interpretada pelos demais membros do time e da gestão como contendo folga desnecessária, como que para fugir de trabalhar duro para cumpri-la.
Quem está acostumado a passar estimativas de horas diretamente a clientes se identificará imediatamente. Questionamentos constantes quanto à idoneidade de uma estimativa acabam por gerar uma tendência a estimativas menores do que o necessário. Essa é, infelizmente, uma pratica muito comum.
<h2>Razão 3: Projetos são desafiadores (ou &#8220;É assim mesmo&#8221;)</h2>
A terceira causa é também a mais &#8220;cruel&#8221; delas, no sentido de ser a menos tratável. É o fato de que, em muitas companhias e em muitas situações, os projetos são feitos para serem desafiadores.
Em outras palavras, muitas vezes já é sabido desde o nascimento do projeto que o prazo disponível em situações &#8220;normais&#8221; não seria suficiente. Acredita-se que os ganhos esperados, no timing esperado, compensarão o esforço adicional necessário para a entrega. Oportunidades comerciais são exemplos de motivadores por trás de iniciativas assim. A favor dessa abordagem estão os estudos que mostram que, de fato, um certo nível de estresse, durante períodos limitados de tempo, leva as pessoas a entregarem a resultados melhores e mais criativos do que os obtidos na chamada &#8220;zona de conforto&#8221;.[3]
<h2>O que fazer então?</h2>
Todas as causas citadas levam à necessidade de trabalho maior para cumprir os prazos assumidos. Mas há o que fazer para<a href="https://dtidigital.com.br/blog/unindo-a-procrastinacao-e-a-execucao-agil-para-obter-criatividade-e-originalidade/"> diminuir as chances</a> de que isso ocorra.
Em primeiro lugar, é possível reduzir o impacto de nossa incapacidade inata de prever o futuro. Através da diminuição do horizonte desse futuro. É fato que, embora sejamos ruins em previsões, somos &#8220;menos ruins&#8221; nisso quando se trata de um futuro próximo. Embora sejamos péssimos em prever como será o mundo daqui a 50 anos, somos regulares em prever o que acontecerá nos próximos dias.
O Planejamento em ondas sucessivas, por exemplo, é uma maneira de se planejar o projeto que leva isso em conta ao planejar em detalhe somente as atividades que já estão claras o suficiente para tal e que, consequentemente, acontecerão em um horizonte de tempo mais curto.
As demais fases do projeto são estimadas também, mas somente em alto nível. A medida que o projeto progride, novas &#8220;ondas&#8221; de planejamento vão sendo feitas, detalhando a porção seguinte das atividades (para os conhecedores de PMBOK, você vai descendo de nível na EAP). Como cada onda planeja somente o futuro próximo, a tendência é que os erros de estimativa sejam menores.
Outra prática para delimitar o horizonte das estimativas faz parte do DNA do mundo ágil: divisão do projeto em Sprints. O projeto é divido em períodos de tempo fixo, em geral com não mais do que duas a quatro semanas de duração, e o foco do planejamento detalhado, feito coletivamente, é somente a sprint a ser iniciada.
O progresso da sprint é acompanhado diariamente e ao seu final é feita uma avaliação (retrospectiva) onde é possível verificar as razões de possíveis divergências entre o trabalho previsto e o efetivamente entregue. Mesmo que aconteçam erros grosseiros de estimativa, o impacto no projeto como um todo não é maior do que o prazo de uma Sprint. Além disso, a experiência mostra que a assertividade das estimativas aumenta consideravelmente como o desenrolar do projeto.
Em relação ao medo da repercussão de estimativas altas também há o que fazer. Uma prática recomendável no mundo do gerenciamento tradicional é fazer as estimativas com o método Delphi. Esse método, em linhas gerais, envolve obter estimativas independentes de vários especialistas de forma isolada, geralmente por e-mail. As estimativas e justificativas obtidas podem ser realimentadas para o grupo, sem que se saiba quem as forneceu, até que haja uma convergência. Dessa forma, as estimativas ficam menos viciadas e menos sujeitas à pressão do grupo por diminuição.
<img fetchpriority="high" decoding="async" class="aligncenter wp-image-3590 size-full" title="projetos" src="https://dtidigital.com.br/wp-content/uploads/2018/08/planning_poker.jpg" alt="projetos" width="700" height="480" srcset="https://www.cms.dtidigital.com.br/wp-content/uploads/2018/08/planning_poker.jpg 700w, https://www.cms.dtidigital.com.br/wp-content/uploads/2018/08/planning_poker-300x206.jpg 300w" sizes="(max-width: 700px) 100vw, 700px" />
O <a href="https://dtidigital.com.br/blog/como-desenvolver-a-abordagem-agil/">mundo Agile</a> tem uma versão &#8220;resumida&#8221; do método Delphi chamada Planning Poker®[4]. Bem mais simplificado, esse método também estimativas simultâneas, independentes e secretas, que são reveladas simultaneamente, como num jogo de pôquer. Caso haja discrepâncias acima de um patamar combinado novas rodadas são feitas até que se encontre a estimativa de consenso.
Tanto o Delphi quanto o Poker tem a desvantagem de exigir a disponibilidade de várias pessoas capacitadas a estimar as tarefas, além de poder exigir um tempo maior para obtenção de uma estimativa inicial do projeto. No geral, no entanto, considero que seus benefícios superam de longe seus custos.
<h2>O que fazer se o projeto já nasce desafiador?</h2>
Nesse caso as horas extras deverão ser uma realidade, mas as técnicas acima contribuirão para diminuir o sofrimento. É importante frisar, no entanto, que não é produtivo nem saudável que uma organização conduza seus projetos sempre assim.
As lições aprendidas precisam ser levadas em consideração, além das inúmeras pesquisas que demonstram impactos negativos tanto em produtividade quanto em saúde quando se submete equipes a períodos prolongados de jornadas estendidas. Projeto não é sinônimo de masoquismo!
<h2>Conclusão</h2>
Certamente muito mais pode ser dito sobre o esforço adicional necessário para a entrega de um projeto. Não foi tradado, por exemplo, a diferença entre trabalhar &#8220;bem&#8221; e trabalhar &#8220;certo&#8221;. Ou seja, não foram abordadas técnicas de aumento de produtividade, que permitem um aproveitamento melhor do tempo disponível e acabam contribuindo para um prazo resultante menor.
Outro ponto não tratado foi a necessidade frequente de recuperação de atrasos decorrentes da materialização de riscos: mudanças de equipe, de especificação, etc. Nesse artigo dei foco somente em alguns erros que tem característica mais universal (acontecem em várias disciplinas) e que são, a meu ver, perfeitamente evitáveis.
Com alguma disciplina e deixando de brigar contra nossa natureza é possível melhorar o quadro de horas trabalhadas em projetos. Todos temos a ganhar.
E você? Qual sua experiência com horas extras em projetos? Tem mais alguma boa prática para recomendar?

Projetos e Horas Extras: Sinônimos até quando?

Desbloqueie o futuro do seu negócio

Confira outros artigos