Os prazos em si não são uma coisa ruim, eu diria mesmo, em algum lugar bom. Pessoalmente, meu trabalho acaba sendo mais produtivo se eu me concentrar mentalmente em algum período de tempo, e quando um projeto não tem nenhum período de tempo, pode acabar prejudicando-o. O principal aqui é pensar de forma realista e manter o equilíbrio.
O prazo deve ser justificado. “Porque porque” não é justificação. Essa é uma prática ruim de definição de horário que afeta empresas e desenvolvedores. Tive a sorte de que a maioria das empresas para as quais trabalhei não tinha o hábito de escolher prazos. Mas houve exceções. Quero falar sobre uma situação desse tipo como exemplo neste artigo.
Eu estava trabalhando em uma startup naquela época; Nossa equipe de front-end era formada por três pessoas e havia também uma equipe de back-end do mesmo tamanho. Estávamos trabalhando em uma versão atualizada do aplicativo móvel e tínhamos que cumprir o lançamento antes de um dia claramente marcado. Um problema: este dia foi escolhido arbitrariamente por um simples diretor, ou por um técnico sem qualquer razão para tal decisão.
Bem, isto é, não totalmente sem justificativa - na hora da escolha foi levado em consideração a duração aproximada da obra declarada pelos desenvolvedores. Se você trabalha com código ou com as pessoas que o escrevem, provavelmente já entende qual é o problema. As datas aproximadas são sempre aproximadas, ou seja, são muito diferentes do que realmente sai. E não se trata da incompetência dos desenvolvedores, é simplesmente incrivelmente difícil estimar a quantidade de trabalho em um projeto inteiro. Existem muitas coisas que podem alterar os prazos e que são impossíveis de prever.
De uma forma ou de outra, nossa estimativa aproximada foi o resultado de reuniões de dois dias: primeiro, uma visão geral das novas funções, depois uma análise detalhada de cada uma separadamente, depois uma análise ainda mais detalhada ... Por fim, para cada etapa do trabalho , estimamos o número de horas, verificamos novamente, correlacionamos com UX e design de IU, eles juntaram tudo, jogaram algumas horas no topo - e esse era o prazo para o trabalho.
Você provavelmente agora está pensando: bem, uma vez que seus designs de UX e UI já estão prontos, e ainda mais horas foram reservadas, então, provavelmente, tudo deve correr bem? Na maioria dos casos, as condições são piores ao definir as datas. Bem, em geral, não. Nada deu certo.
A duração do trabalho foi fixada em três a quatro semanas - não muito tempo se falamos sobre o lançamento de um novo produto com uma pequena equipe. Claro, depois das primeiras duas semanas, já estávamos atrasados. Não porque trabalharam devagar ou gastaram poucas horas no projeto, mas porque tudo sempre dá errado.
O back-end estava debruçado sobre a implementação da API para o aplicativo, quando de repente descobriu-se que o sistema não podia interagir normalmente com um simples complemento, o que significa que era necessário reescrever o fragmento de API já preparado levando essa circunstância para conta. Demorou dois dias não programados para finalizar o endpoint.
Devido a essa pequena mudança, a API começou a funcionar de maneira um pouco diferente do que se pretendia na fase de discussão, o que levou à necessidade de reescrever partes individuais do aplicativo - um trabalho de várias horas. Reescrever assim é comum em aplicativos móveis de todos os tamanhos e não deve surpreender ninguém. Mas temos um prazo apertado. E agora não podemos caber.
Então o que você pode fazer? No dia seguinte, fomos informados de que teríamos de trabalhar quatro horas extras para progredir novamente. Quatro horas além de um dia de trabalho típico de oito horas. Bem, sim, fomos alimentados, é claro, mas não há nada de útil para o cérebro nesses turnos de doze horas e não pode ser. Mesmo assim, conseguimos acompanhar o cronograma.
Uma semana depois, o aplicativo foi lançado. Ficamos felizes, alguém trouxe alguns cupcakes para comemorar, e cinco minutos depois todos já estavam sentados nos monitores e fingindo que nada havia acontecido.
Não havia nada tão importante na atualização que motivasse a necessidade de um lançamento nesta data específica e não um dia depois. Nenhum dos usuários sabia que uma nova versão estava sendo preparada, ninguém (nem clientes, nem investidores) fazia planos com base em uma data. Sim, os recursos são úteis, mas alguém se sentiria pior se eles fossem lançados um dia depois? Afetaria alguém?
Mas os desenvolvedores afetados. Aqui e ali as pessoas expressam seu descontentamento umas com as outras; a relação entre a equipe e a gerência foi claramente prejudicada. E este não é um caso isolado, isso aconteceu muitas vezes enquanto eu estava trabalhando lá - com uma frequência de uma vez a cada vários meses.
E qual é a conclusão de tudo isso? Desistir completamente a qualquer momento? Bem, claro que não. Conforme mencionado no início do artigo, os prazos são realmente úteis e eu mesmo acho mais fácil trabalhar com eles. Mas eles devem ser tomados como diretrizes, não como compromissos rígidos. Se o produto for lançado alguns dias depois, não deve ser considerado o fim do mundo. Qual é o objetivo de colocar pressão desnecessária sobre os desenvolvedores? Ou você acha que a qualidade do código não sofre com essas marchas?
Quando trabalhamos horas adicionais depois de um dia de trabalho tarde da noite sob a bandeira de força maior, o clima geral era: "Então, precisamos terminar o mais rápido possível." Freqüentemente, foram introduzidos todos os tipos de soluções de suporte que funcionariam por um tempo e então exigiriam refatoração. Em alguns casos, a refatoração correspondente foi agendada imediatamente, em outros foi esquecida com segurança. E aconteceu que os próprios desenvolvedores não perceberam realmente que estavam fazendo algo muleta, porque estavam cansados e queriam ir para casa.
Quando se trata de refatoração (de onde veio), provavelmente é mais um recurso do que a própria força maior. Bugs começaram a aparecer em pedaços de código escritos com pressa. Como o aplicativo já havia sido lançado, irritou a todos especialmente.
De acordo com minhas estimativas (não coletei estatísticas, portanto não posso atestar), esse processamento foi útil apenas no curto prazo. Bem, sim, lançamos o aplicativo no prazo. E o próximo lançamento já teve que ser adiado, pois muito estava sendo reescrito. Os desenvolvedores estavam insatisfeitos (e, você adivinhou, eles estavam desistindo ativamente), a atmosfera na equipe ficou tensa. E ainda não levamos em consideração as consequências dos bugs que os usuários encontraram após o lançamento.
Como você precisa disso?
Se você quer que tudo seja feito de forma eficiente, não fique com febre, ouça os desenvolvedores e certifique-se de acompanhar o progresso. Se a equipe não se encaixa e não há motivo para urgência, avance o prazo! Não arbitrariamente, mas por enquanto isso não é suficiente no estágio atual. Incentive os desenvolvedores a comunicar as possíveis causas de atrasos e riscos. Se alguém vir algo que claramente não se enquadra no cronograma geral, vale chamar a atenção de quem está planejando, para que tenha a oportunidade de corrigir as datas estimadas.
Você fez tudo antes do tempo? Bem, em tal situação, todos apenas ganham. E o teste pode ser feito de maneira adequada e dá aos desenvolvedores a oportunidade de melhorar algo na base de código. Se você é um desenvolvedor ou se comunica com desenvolvedores para trabalhar, então você mesmo sabe: sempre há lugares no código que você gostaria de aprimorar. Às vezes, leva apenas uma hora e às vezes leva vários dias. É melhor não perder tempo tornando o código melhor e mais preciso - como todos nós podemos confirmar, existem deficiências suficientes nos aplicativos que nenhum usuário irá apreciar.