Como posso fazer com que um chefe (ou colega) seja mais cuidadoso ao estimar a complexidade de uma tarefa / projeto?

Sou desenvolvedor de software e trabalho em uma pequena empresa de desenvolvimento web. Parece ser um tema recorrente que um gerente de nível intermediário me pergunte quanto tempo levará algo e, quando eu der uma estimativa, eles acham que é muito alto. Se for um gerente mais técnico ou outro desenvolvedor, eles geralmente já terão em mente uma estimativa própria e começarão a tentar implementá-la à sua maneira, porque acham que podem fazê-lo mais rapidamente.

Há uma tendência, no entanto, em que os outros desenvolvedores acabaram gastando muito mais tempo do que os citados. Eles terão metade do orçamento e perceberão que há alguma necessidade comercial que seu plano de implementação não pode atender adequadamente. Mais vezes do que não, meu plano teria abordado essa necessidade, mas foi descartado como um recurso " Você não vai precisar ".

Pior ainda, quando atingem esta parede, geralmente vêm a mim para ajudá-los a sair do canto em que se pintaram, mas há apenas tantas horas no meu dia.

Melhor caso : essas interrupções cortam o tempo que eu aloquei para o meu próprio trabalho de desenvolvimento, resultando em atraso em outros projetos ou em que eu precise trabalhar horas extras porque sou "o único que pode executar o X".

Na pior das hipóteses : acabo tendo que assumir a tarefa / projeto como meu, e a essa altura não resta tempo no orçamento para fazê-lo "do meu jeito". Eu tenho que tentar terminar o que eles começaram da maneira que começaram, para que "a empresa não perca mais dinheiro". Isso sempre volta a me morder, porque então se torna "meu" código hacky, e quando ele quebra as pessoas me perguntam por que ele foi criado do jeito que era (afinal, eles não têm idéia de quem realmente o criou.)

Portanto, minha pergunta é : como posso ajudar esses colegas a entender quando as coisas não são tão simples quanto imaginam e precisam reavaliar sua compreensão das necessidades do cliente?

Diferentemente dessa pergunta semelhante sobre convencer a gerência a lidar com a dívida técnica [existente] , minha pergunta busca estratégias para ajudar a equipe a realizar [proativamente] antes de começar a incorrer em dívida técnica, na tentativa de impedir que isso aconteça no início. Essas duas coisas andam de mãos dadas, mas são distintamente diferentes em minha mente. As respostas da outra pergunta sugerem a adição de tempo de refatoração nas estimativas para recursos futuros. Isso nunca funcionará se outros desenvolvedores (e, portanto, gerentes) sempre pensarem que o recurso futuro levará menos tempo do que realmente será, e não posso convencê-los de que minha estimativa é mais realista.

Adoro essa pergunta, porque todos os dias estou lidando com uma nova estimativa ou sofrendo de uma estimativa anterior.

A resposta depende do tamanho de um projeto / tarefa que você está falando. Existem livros e métodos para lidar com estimativas. A estimativa de projeto para uma equipe de desenvolvimento de 50 pessoas com um orçamento de 1 milhão de pessoas adota uma abordagem diferente do trabalho em pequenos projetos de '80 horas' - aqui estão alguns pontos da 'vida real' para os seguintes:

• Estimativa "de baixo para cima" - Quanto menor a divisão das tarefas, melhor a estimativa. Você pode estimar as partes menores independentemente, o que tem o benefício adicional de identificar funções ausentes. Digamos que você receba modelos de um site e solicite uma estimativa. Não vá pelo número de páginas, vá pelo número de recursos. Por exemplo, um carrinho de compras pode ser '1 página', mas pode ser composto por 10 recursos diferentes.

• As estimativas de "três pontos" significam fazer três estimativas como um intervalo. Você pode responder com "40 a 80 horas, dependendo da complexidade dos recursos xxx". Essa é uma boa maneira de introduzir riscos em sua estimativa. Também é uma boa ideia obter estimativas de outras pessoas da sua equipe; portanto, se alguém disser 50 horas e alguém disser 100 horas, você poderá discutir a diferença.

• Conheça o orçamento / também conhecido como definir expectativas - se você sabe que o orçamento é de 100 horas e acha que é um projeto de 200 horas, você pode ajudar a definir as expectativas antes de se comprometer. "Tudo o que você pediu é um projeto de 200 horas; se limitarmos o recurso-x, podemos fazê-lo em 100 horas".

• Tempo de desenvolvimento x tempo de teste x tempo de projeto x tempo de calendário - tudo isso é diferente e, se você é um time, é fácil misturar tudo. Se você precisar gastar 8 horas para definir os requisitos e, em seguida, 72 horas para o desenvolvimento, levará muito mais que duas semanas de calendário para concluir o projeto. Especialmente se você precisar equilibrar outras tarefas, interagir com uma equipe, aguardar clientes ou passar horas escrevendo por e-mail. Nesse caso, diga ao seu chefe "100 horas, que são x-horas de tempo de desenvolvimento, y-horas lidando com o cliente e z-horas de suporte inicial". Isso ajudará a mostrar que você está incluindo outro horário além do seu código.

IMPORTANTE - Não acho que a estimativa seja o seu principal problema, acho que é a comunicação externa e interna. Se o recurso X era tão importante, o cliente deveria tê-lo comunicado no início. Quando a solicitação chegou para o recurso X, seu gerente de projeto deveria ter dito "está fora do escopo, mas podemos realocar o horário atual ou expandir o orçamento".

Internamente, você precisa se comunicar para que seus superiores estejam cientes de que você excedeu o orçamento / cronograma muito antes que seja "tarde demais". Quando uma tarefa está sendo entregue a você, você deve saber o horário (como em horas) e o horário (como em um calendário) em que você precisa trabalhar nessa tarefa. Se a tarefa não se encaixar nessas restrições, é necessário conscientizá-las - "O recurso A e B exigirá que eu faça C. Isso não deixará tempo para X ou Y".

Sem surpresas - Você também precisa se comunicar novamente ao longo do projeto. Certifique-se de relatar as coisas boas, mas se algo estiver demorando mais do que o esperado, diga-o imediatamente. Cinquenta por cento do caminho do projeto, é responsável dizer:

"O recurso X está me demorando mais do que o esperado, talvez eu não consiga o recurso Y".

Na data de vencimento, não é responsável dizer:

"Eu não fiz o recurso Y porque fiquei sem tempo"

Momento pessoal - tudo isso pode ser realmente difícil quando os gerentes ainda querem se tornar codificadores e quando todos querem agradar o cliente.

Faça o bem e faça com que seja conhecido.

Se você precisar corrigir os problemas de outras pessoas porque elas não ouviram o que você disse antes ou porque são inexperientes demais para entender o que você estava dizendo, certifique-se de que essas pessoas e seus chefes saibam qual era o motivo quando o esperado falta de tempo e que tipo de falha de planejamento foi feita. E seja paciente, se seus colegas não forem totalmente resistentes a aprender com os erros, a situação provavelmente se tornará melhor com o tempo.