Como responder "Quando isso será feito?"

Todos nós temos problemas que são difíceis de corrigir e resolvem através de código obscuro e bizarra funcionalidade inesperada. Lentamente, trabalhando logicamente tentando encontrar padrões, erros, erros. Esse processo leva tempo e os problemas geralmente não são facilmente entendidos pelo cliente.

Como alguém responde ao fazer a pergunta "Quando isso será feito?", Especialmente quando o cliente pode não entender as complexidades inerentes ao desenvolvimento de software?

Você responde a pergunta honestamente.

Você diz a eles que é um problema difícil, a solução não é óbvia e não tem certeza de quanto tempo levará para resolver. Prometa atualizá-los sobre seu progresso a cada [intervalo de tempo], para que eles saibam que você está trabalhando nele e, é claro, envie as atualizações a eles.

Os desenvolvedores abordam um problema complexo decompondo-o em problemas menores e resolvendo-os separadamente.

Em um mundo ideal , resolver um problema seria um problema complexo A e, em um determinado momento, você seria capaz de decompô-lo em uma pequena lista de pequenos problemas A ₁ a A _n , pois cada avaliação do tempo é direta, dada a que o tempo necessário para resolver o problema complexo inicial seria:

sendo D o próprio processo de decomposição.

No mundo real , o único problema é que t ( D ) seria realmente maior do que o tempo gasto na solução de pequenos problemas. Em outras palavras, para chegar a esse nível de decomposição do problema, você praticamente precisa resolver o problema em si.

Você ainda pode:

• Separe a tarefa especificada (resolvendo o problema) em partes menores, sendo cada parte ainda um problema complexo,

• Avalie o tempo esperado para cada parte e o risco correspondente.

  Por exemplo, a tarefa 1 requer aprox. 5 horas, mas o risco de ser bloqueado é alto; portanto, dê 12 horas como sua expectativa para o cliente.

• Avalie as dependências e como elas afetam o tempo.

  Por exemplo, a tarefa 19 requer 2 horas e o risco é tão baixo que você pode dizer que são 2 horas com certeza. Não 1. Não 3. Mas a tarefa 19 depende da tarefa 24: a tarefa 24 pode afetar a tarefa 19 de uma maneira que você precisaria reescrever completamente o código da tarefa 19 usando uma abordagem diferente.

• Dê todos esses detalhes ao seu cliente. Não dê a soma.

O último ponto é importante. Se você der a soma, digamos 192 horas, o cliente acredita que é uma métrica muito precisa, e o tempo que você gastará será de, digamos, 189 a 195 horas.

Se, em vez disso, você fornecer os detalhes,

• O cliente que se importa entenderá que não são 192 horas. São 192 horas se tudo der errado, dado o risco determinado durante a avaliação. Também são 238 horas se tudo piorar. Também são 85 horas se tudo estiver bem.

• Quanto ao cliente que não se importa, ele não lerá sua resposta em todos os casos. Tudo o que ele quer é um número, para poder culpar você mais tarde. Ao dar uma resposta muito detalhada que ele nunca lerá, você sabe que ele não pode pedir o tempo que levará novamente: você já respondeu. Ele também não pode culpar você mais tarde, pois não leu a resposta para calcular a soma.

O que você estima, não se esqueça de incluir a lei de Hofstadter : sempre leva mais tempo do que o esperado, mesmo quando você leva em conta a lei de Hofstadter.

Normalmente, uso uma fórmula modificada do CPM / PERT. É algo como isto:

Mn + Mx + C(T) / 2 + C, where
Mn is the minimum number of hours you think it will take,
Mx is the maximum number of hours you think it will take,
T is the typical number of hours it takes,
and C is a confidence factor from 1 - 3 based on how much you've done similar things.

(Não tenho certeza de como fazer toda a formatação matemática sofisticada; se alguém quiser editar isso para isso, fique à vontade.)

So, if you think:
Mn = 60  hours
Mx = 180 hours
T  = 100 hours
C  = 2
Then: 60 + 180 + 2(100) / 4 = 110 hours.

Eu enfatizaria que isso pode variar significativamente, dependendo de como o projeto vai. Se você reavaliar seu projeto a cada poucos dias, poderá fornecer uma atualização semanal. Ele ajuda bastante a satisfazer clientes irritáveis. :)

É difícil explicar prazos vagos para usuários não técnicos. Isso é verdade tanto nas fases criativas de um projeto quanto no rastreamento de um bug irritante. Nos dois casos, o tradicional "decompõe o trabalho em pedaços menores" não funciona tão bem.

A tarefa original se concentra no último caso, então vamos nos concentrar nisso. Se você não puder fornecer uma linha do tempo, informe ao usuário o que tentará e quando voltará para ele. Quando você atingir o ponto intermediário na linha do tempo autoimposta, faça uma atualização curta e honesta por e-mail. Pelo menos uma hora antes do prazo, dê sua resposta formal. Agora você tem credibilidade. Se o problema não for resolvido, pelo menos você estará brilhando. Pode parecer uma perda de tempo, mas não é.

Como você não pode explicar os obstáculos desconhecidos e surpresas imprevistas, pode ser um desafio estimar com confiança. Ideias:

• Experimente um intervalo - "Tenho certeza de que levará pelo menos N dias (por exemplo, 3), mas pode levar até 4N".
• Procure o apoio de mais engenheiros seniores na estimativa e defesa de estimativas.
• Trabalhe em iterações mais curtas (estilo Agile / Scrum) para produzir código mínimo que agrega valor comercial (ganhando confiança e confiança) e repita.
• Aprenda habilidades de negociação em um livro como o clássico Getting to Yes (http://www.amazon.com/gp/aw/d/0143118757).

Para novos desenvolvimentos, especialmente Agile:

"A perfeição é alcançada, não quando não há mais nada a acrescentar, mas quando não há mais nada a ser levado". - Antoine de Saint-Exuper

Se você está estimando o esforço e o tempo para consertar alguns erros quase impossíveis de reproduzir em um sistema extremamente complexo, com pouquíssimos desenvolvedores com conhecimento profundo do sistema, a única resposta correta é "Quando está consertado".

Normalmente, eu apenas diria a verdade. Eu diria a eles que não conheço agora e posso ter uma melhor visão em uma semana. Depois, entregaria a eles um parque de bolinhas com o máximo de rabiscos possível para colocar no papel para indicar que é um palpite baseado no sentimento. Se eles começarem a zombar de você, comece cada frase com "É possível ..." Normalmente, qualquer pessoa para quem eu faço alguma coisa fica feliz com a mensagem "Volte em mais ou menos uma semana, mas agora tudo o que posso dizer são cerca de 2 meses" ou algo assim.

O Personal Software Process (PSP) se concentra em melhorar as estimativas. Isso é obtido pelo registro disciplinado de tarefas. Em essência, isso "acelera" a parte da "experiência" da estimativa, pois você terá dados reais sobre tarefas típicas. Obviamente, essa profissão ainda exige soluções exclusivas para muitos problemas, mas, na minha experiência, as estimativas são melhores após o uso do PSP.