Quando lhe pedem para estimar datas de conclusão, existe uma forma especialmente educada ou inteligente de dizer “será feito quando estiver feito” ?
É a única forma de dizer “não posso dizer agora mesmo, verifique comigo em [hora determinada]” ?
Tenho sido um gestor no lado receptor do “será feito quando for feito”, e trata-se da resposta menos útil que é possível dar+. Dizer isso e nada mais o coloca em grave perigo de ser considerado não cooperante. Deve absolutamente dar mais informação.
Para explicar um pouco mais sobre o “porquê” disso, num projecto de software há muitas vezes acções que só podem ser feitas quando se termina, mas que têm de ser planeadas e programadas com antecedência. Se não se pode dizer algo sobre quando será feito, o projecto acaba por ser ainda mais tarde e muitas vezes custando mais dinheiro.
Dito isto, “Quando será feito?” nem sempre significa “Apresse-se”. Muitas vezes a pessoa que pergunta quer saber para que possa planear. É melhor assumir que, a menos que tenha uma razão para pensar o contrário.
Aqui estão algumas circunstâncias possíveis em que se pode encontrar:
Por vezes, é claro que se apercebe subitamente durante algum trabalho que vai demorar muito mais tempo do que pensa. Se o timing do seu trabalho é importante, normalmente é melhor sentar-se e tentar perceber quanto tempo vai realmente demorar, em vez de apenas arar. Por vezes (ou na verdade sempre, por causa da lei de Murphy) é-lhe pedido um orçamento enquanto ainda está a trabalhar nisso. Nesse caso, não há problema em dizer “Terei uma estimativa melhor para si em [algum tempo]”
A propósito, todas as respostas acima assumem que é um trabalhador de “nível superior” responsável pela sua própria programação. Se não, ou em caso de dúvida, envolva o seu chefe.
+Não é tecnicamente a resposta menos útil. Uma mentira ou uma data que não tem a intenção de manter seria pior. Mas “será feito quando estiver feito” é apenas um passo acima desses.
Quando lhe pedem para estimar datas de vencimento, existe uma forma especialmente educada ou inteligente de dizer “Feito quando está feito” ?
Sempre gostei de “quando as pessoas deixam de me interromper”, mas não sou especialmente educado.
É a única forma de dizer “não posso dizer agora, verifique comigo em [hora dada]” ?
Certamente que não. Há empresas/culturas onde “Quando estiver feito” é uma resposta aceitável Blizzard por exemplo , pelo menos externamente], e eu encorajaria você a trabalhar e mudar sua cultura em direção a isso.
“Não tenho certeza, depende da Alice e do Bob e… ” é uma resposta bastante passiva-agressiva que pode ser usada em algumas áreas para desviar a pessoa que faz a pergunta e, se bem feita, pode transformar essa pessoa num activo que a ajuda a remover bloqueios.
“Não tenho a certeza, quando é que me vai conseguir X? ” é uma resposta mais claramente agressiva quando alguém se intromete nos seus negócios mas não cuida dos deles. Pode ser útil salientar que as suas estimativas não vão ser melhores do que as deles, e mantê-lo a um nível mais elevado é uma tolice. Não recomendado.
“Não tenho a certeza, preciso de verificar com a minha equipa ” pode ser uma resposta sólida que lhe dá tempo para considerar, assim como retratar a si próprio como alguém que adere ao conhecimento especializado. Também ajuda se você actualmente verificar com a sua equipa, uma vez que normalmente eles podem fornecer um bom input, bem como ser comprados dentro do prazo a que você os está essencialmente a comprometer. Tenha cuidado, pois esta resposta pode ser mal utilizada e retratá-lo como alguém que nada mais faz do que ser um intermediário.
“Isso depende, o que precisa de fazer? ” Outra resposta sólida que pode ser passiva-agressiva, mas que, por vezes, pode apenas conduzir a uma agradável sessão de recolha de requisitos improvisada. Também funciona para manter o negócio honesto. Se está a comprometer-se a trabalhar, então eles precisam de se comprometer com o âmbito (e os recursos).
“Isso depende, até que ponto precisa de funcionar?”“ Semelhante à última pergunta, ajuda a refinar o âmbito e a preencher o terceiro lado do triângulo .
"Não sei. Este sprint é XYZ. ” Uma resposta limitada para pessoas que utilizam sprints (muitas vezes engenheiros de software). O bom aqui é que a empresa provavelmente comprou para fazer Agile com Sprints, então você tem esse suporte. Num ambiente ideal, as únicas coisas planeadas são para as ~2 semanas do seu sprint actual. Tudo o resto é propositadamente não planejado para que você possa estar bem… agile sobre o que recebe prioridade. Num mundo não ideal, as coisas são provavelmente planeadas até ao nono grau, e depois quebradas em pedaços de duas semanas, mas a pergunta oferece-lhe uma boa oportunidade para comentar de uma forma rude sobre esse absurdo.
Em suma, há muitas maneiras más de se esquivar à pergunta. É provável que seja melhor dar o número do pior cenário e depois voltar ao trabalho real.
Gosto de “ainda não há uma estimativa para isso”.
Dá a resposta que pretende, é bastante factual e neutra no tom, e sugere que em algum momento poderia ser feita uma estimativa, mas certamente não agora aqui na máquina de café sem uma imagem clara do que significaria fazer aquilo que está a perguntar.
Tem de estar preparado para a pergunta “o que precisaria para fazer uma estimativa”, pois isso tem de ser levado a sério.
Quando lhe é pedido para estimar datas de vencimento, existe uma forma especialmente educada ou inteligente de dizer “Feito quando estiver feito” ?
Normalmente não se pode safar de ser esperto e dizer “Será feito sempre que for feito”, independentemente da forma como o enquadrar. Quando lhe é pedido para estimar datas feitas, normalmente não é isso que o requerente quer ouvir.
Em vez disso, pode transmitir o seu orçamento, e dar um grau de precisão ao seu orçamento.
Algo do tipo “Com base no meu entendimento actual do projecto, o meu orçamento é de 3 meses. Mas como os requisitos ainda não estão escritos, poderei fornecer uma estimativa mais precisa assim que os ler”. (Fora do registo, chamo a estes “guesstimates”)
Se o seu ambiente de trabalho requer algo mais formal do que este tipo de estimativa falada ou enviada por e-mail, certifique-se de incluir todos os seus pressupostos na sua estimativa formal, juntamente com a sua avaliação da precisão com que é capaz de estimar nesse momento.
Pode fazer melhor, se lhe for concedido mais tempo para preparar a sua estimativa, e se lhe forem fornecidos mais dados sobre os quais pode basear a sua estimativa. Mas pode sempre fazer uma estimativa em qualquer período de tempo - desde que não se espere que a estimativa seja particularmente precisa.
Uma vez fornecidas as suas estimativas (independentemente da forma como são derivadas), mantenha as suas partes interessadas no circuito se acontecer alguma coisa que possa alterar a sua estimativa - especialmente à medida que os prazos se aproximam.
Presumo que seja a pessoa responsável pelo projecto ou tarefa que está a ser inquirida. Nesse caso, porque não pode dizer?
Todas estas são razões legítimas para não ter uma boa estimativa, mas são também problemas que precisa de levantar proactivamente com o seu gestor (ou, no primeiro caso, pode obter o reconhecimento deles de que a tarefa pode escorregar para permitir coisas com maior prioridade). “Feito quando estiver feito” irá simplesmente transmitir a impressão de que não sabe e não está a fazer nada para descobrir. Como tal, isto impede o seu gestor de planear o panorama geral.
Das suas respostas aos comentários e respostas, suspeito que a sua pergunta deve ser realmente:
O meu trabalho consiste em muitas pequenas tarefas, que posso receber em qualquer ordem, e que têm prioridades variáveis. Tenho uma fila constante de tarefas de menor prioridade que só posso fazer quando não há tarefas de maior prioridade a completar.
É-me frequentemente pedido que dê estimativas sobre quando é que as tarefas de menor prioridade estarão completas. A minha resposta actual, “Será feito quando estiver concluído” não está a ser bem recebida.
O que devo fazer?
Nesta perspectiva, a resposta é óbvia - precisa de fazer um melhor acompanhamento e gestão das tarefas. Isto não envolve uma mudança no seu processo/fila/prioritização - apenas um pequeno trabalho extra no seguimento temporal de cada tarefa.
O número 1 é provavelmente suficientemente fácil para um palpite aproximado. “Entre 6 e 10 horas” está bem, não precisa de se esforçar por ser exacto aqui, apenas uma estimativa aproximada. É provável que tenha uma boa noção da tarefa que pode dar uma estimativa decente aqui com um provável mínimo e máximo.
Número 2 vai exigir um pouco mais de trabalho a cada semana. Se você já rastrear tarefas e tempo não deve ser difícil, mas mesmo que você não mantenha apenas um bloco de notas, e cada vez que você terminar uma tarefa escreva o nível de prioridade e quantas horas você gastou nela. No final da semana, pode adicionar o tempo que gastou em cada prioridade, e depois de o ter feito durante algumas semanas deverá ter uma média de execução decente.
Quando alguém lhe pedir uma data de conclusão, junte todas as horas para a sua tarefa e as tarefas que tem pela frente a um determinado nível de prioridade, para os tempos mínimo e máximo, e depois divida pelo número médio de horas disponíveis para esse nível de prioridade por semana. Não lhes diga quantas horas você atribuiu por tarefa, ou quantas horas você atribuiu por semana, eles só precisam saber o dia em que isso não vai acontecer antes, e o dia em que isso deve ser feito. Há 3 tarefas anteriores a essa, e parece que o melhor caso é na próxima sexta-feira, e o pior caso é na quarta-feira seguinte. Verifique comigo dentro de alguns dias e terei uma estimativa melhor"_
Se há tarefas que precisam de ser feitas e que nunca são feitas, pode considerar a implementação de um aumento do nível de prioridade baseado no tempo. Tarefas de baixa prioridade, se não forem realizadas no prazo de N semanas, passe para o nível de prioridade seguinte.
Desta forma pode fornecer estimativas que irão gerir as expectativas dos seus colegas de trabalho e superiores.
Sem informação, “Será feito quando estiver feito” é pior do que informação indesejada, “Tarefas de alta prioridade estão a inundar-nos. Serão necessárias 8 semanas até que isto receba um upgrade automático de prioridade, e depois levará uma ou duas semanas nessa fila até estar terminado”
Isso é algo que nunca se deve dizer. Tudo o que fará é irritar o seu manager e fazê-lo parecer incompetente.
Diga-lhe o que pensa que vai ser necessário (se não consegue definir os passos e mais ou menos o que eles vão tomar, então provavelmente precisa de ter alguém que faça um trabalho melhor sobre os requisitos, por isso diga-lhe que os requisitos não são claros e por isso não consegue determinar o que vai ser necessário), quais os atrasos que geralmente tem devido ao trabalho de maior prioridade e depois dê-lhe uma data. Os clientes não aceitarão sempre que for necessário e, por isso, não lhes deve ser dada uma data. Quando as coisas acontecerem para mudar a prioridade e outras coisas forem adiantadas, envie um e-mail ao gerente e defina uma nova data com base no atraso. Muitas vezes, quando se aponta a mudança da data de vencimento, essas coisas de prioridade mais elevada são deslocadas para baixo. Quando acontecem coisas que fazem com que o trabalho demore mais tempo do que o estimado, certifique-se de que o gestor está imediatamente ciente do impacto que isso tem na data de vencimento.
Qualquer dev deve ser capaz de fornecer estimativas de tempo. Faz parte do que lhe está a ser pago, por isso pare de lidar com o “sempre que”. Se não for bom nisso, então melhore mantendo registos do que estimou e qual foi o tempo real. Inclua o tempo de atraso e o tempo para reuniões, comunicação por e-mail, requisitos de refinação, testes unitários, testes de apoio qa, etc. na sua estimativa para obter um número melhor. Se lhe for pedida uma data directa, assuma um máximo de 6 horas produtivas por dia quando converter as horas que pensa que vai levar em dias e coloque alguns dias para os inevitáveis atrasos.
Com base nos comentários de outras respostas, parece que o seu problema não é estimar o tempo, mas comunicar os atrasos com base na mudança de prioridades. O que você precisa é de ser mais, e não menos comunicativo quando isto acontece. Tem de informar as pessoas quando a sua tarefa tiver caído na lista de prioridades (e para quê) e será atrasada e quanto tempo se espera que seja antes de voltar a ela. Deixe-os ir combater as prioridades com os gestores. Diga-lhes que podem falar com o gestor se não concordarem com as prioridades actuais.
Mas é sua obrigação absoluta informá-los quando as coisas mudarem e que estará a trabalhar em algo antes do projecto deles. Isto não deve esperar até que eles tenham de lhe perguntar porque é que ainda não está feito. Em qualquer caso, “quando” não é uma resposta aceitável. Fingir que está demasiado ocupado para responder também não é aceitável.
Tem de compreender que os relatórios de progresso, as estimativas de tempo, etc. são todas as suas tarefas e são tão importantes ou ** mais importantes** do que as partes de desenvolvimento propriamente ditas. Isto não é uma interrupção desnecessária, isto faz parte do seu trabalho. Estas pessoas estão a pagar o seu salário com os seus projectos. Comece a tratá-las com respeito e respeitando as suas necessidades. Quando souberem que podem confiar em si para lhes dizer quando as coisas se atrasarão, vão incomodá-lo menos.
Deve responder com uma distribuição, não com um único número: algo do tipo: “Pode ser feito na próxima semana, se tivermos sorte”. Se tivermos azar, daqui a seis semanas. O melhor palpite é cerca de duas semanas". Essa resposta terá, muitas vezes, uma má reacção. Se isso acontecer, pode apontar para qualquer número de tratados de estimativa de custos de software que demonstrem que essa incerteza é comum e realista.
Trabalhei num projecto semelhante a este. Uma tarefa que pensei que demoraria duas semanas acabou por demorar um mês e meio.
Felizmente, sabia que não tinha uma noção adequada do tempo necessário para o projecto. Por isso, quando o meu chefe perguntava no standup (trabalhamos com o desenvolvimento Ágil) eu dava-lhe a minha melhor estimativa e explicava-lhe porque pensava isso. Embora as minhas estimativas acabassem por se revelar inexactas, dei-lhe o que achei que seria necessário por pedido, mas assegurei-me de que ele sabia que estava sujeito a alterações.
Em geral, a honestidade é o melhor, seja sincero e mantenha-o informado. Há momentos em que não há uma resposta clara e tudo o que podemos fazer é manter os nossos chefes o mais informados possível sobre o assunto.