Eu sou um otimista, mas aprendi tanto na faculdade, quanto no mercado de trabalho a "dividir pra conquistar". Tudo, até uma pequena feature deve ser dividida e calculada item a item. E quando eu digo dividir, eu falo sobre não ter mais como dividir o item. Por exemplo, vamos pegar o "U" de um CRUD. Se ele tiver mais de uma forma de Update, ele ainda pode ser dividido, e cada divisão pode ser calculada com mais precisão. No final, soma-se tudo e se obtém um prazo razoavelmente mais assertivo.
Na minha visão o problema esta na expectativa em cima das estimativas em si por parte do cliente e/ou do gerente do projeto. Estimativas deveriam ser tratadas como o que realmente são, uma aproximação, uma suposição com base nos requisitos do sistema, nas regras de negócios. Não pode ser tratado como algo escrito em pedra, que tem que ser cumprido a todo custo, existem n fatores que podem influenciar tanto pra mais como pra menos na estimativa. Eu prezo muito mais pela transparência, por estar o mais próximo possível do desenvolvimento, por feedbacks constantes, ao meu ver são MUITO mais efetivos e trazem menos dor de cabeça pra todas as partes envolvidas.
Eu crio mais de uma estimativa. Normalmente crio a estimativa feliz (que não vou encontrar nenhuma barreira técnica, nenhum retrabalho no meio do caminho, nenhuma ausência durante o desenvolvimento). A estimativa intermediária (acrescento uma gordura de 50% da estimativa feliz) e a estimativa pessimista que é o dobro da feliz. E digo ao cliente que o objetivo é fazer na estimativa feliz, mas, assim como numa obra em que depende do tempo bom, há a possibilidade de acontecer a estimativa ruim que ninguém quer.
Recomendo muito a leitura do livo Scrum, esse livro desbloqueou várias técnicas de planejamento, e inclusive sobre estimativas. Mas mesmo assim, sou otimista demais kkkkkk
Acredito que o problema do otimismo pode ser resolvido apenas investindo um pouco mais de energia no auto conhecimento. Se você é um desenvolvedor otimista que já trabalhou em alguns projetos e percebeu que geralmente falta X tempo do prazo que você deu para finalizar suas tarefas, talvez seja válido adicionar esse tempo que geralmente falta aos seus prazos futuros, ou até um pouco a mais. Não acredito que gere algum problema se você entregar suas demandas um pouco antes, por passar um prazo um pouco maior que o que realmente era necessário, porém, o contrário pode ser bastante prejudicial. Também é válido ressaltar que um prazo UM POUCO maior do que o que realmente é necessário pode ser saudável, mas muito maior, pode gerar problemas até mesmo tão graves do que prazos otimistas demais.
Sou pessimista até olhando rua de mão unica, dai olho pros dois lados. Mas esse otimismo eu vejo bastante no código de algumas pessoas, porque não pensam em nada fora o "happy path". Algo que me ajudou a estimar melhor é a tecnica PERT. Mas dependendo do escopo, pode ser horas ou dias só pra entender o problema e então estimar. O ruim é que o número parece gigante e por mais que seja acurado... a gente quer falar um número que tem menos de 50% chance de ser atingido... só que eu chego e falo: são essas as estimativas e a chance de fazer dentro do prazo... você (gestor) tem que usar essa informação pra se preparar seja pro melhor ou pior cenário.
Eu sou um otimista, mas aprendi tanto na faculdade, quanto no mercado de trabalho a "dividir pra conquistar". Tudo, até uma pequena feature deve ser dividida e calculada item a item. E quando eu digo dividir, eu falo sobre não ter mais como dividir o item. Por exemplo, vamos pegar o "U" de um CRUD. Se ele tiver mais de uma forma de Update, ele ainda pode ser dividido, e cada divisão pode ser calculada com mais precisão. No final, soma-se tudo e se obtém um prazo razoavelmente mais assertivo.
Na minha visão o problema esta na expectativa em cima das estimativas em si por parte do cliente e/ou do gerente do projeto. Estimativas deveriam ser tratadas como o que realmente são, uma aproximação, uma suposição com base nos requisitos do sistema, nas regras de negócios. Não pode ser tratado como algo escrito em pedra, que tem que ser cumprido a todo custo, existem n fatores que podem influenciar tanto pra mais como pra menos na estimativa. Eu prezo muito mais pela transparência, por estar o mais próximo possível do desenvolvimento, por feedbacks constantes, ao meu ver são MUITO mais efetivos e trazem menos dor de cabeça pra todas as partes envolvidas.
Eu crio mais de uma estimativa. Normalmente crio a estimativa feliz (que não vou encontrar nenhuma barreira técnica, nenhum retrabalho no meio do caminho, nenhuma ausência durante o desenvolvimento). A estimativa intermediária (acrescento uma gordura de 50% da estimativa feliz) e a estimativa pessimista que é o dobro da feliz. E digo ao cliente que o objetivo é fazer na estimativa feliz, mas, assim como numa obra em que depende do tempo bom, há a possibilidade de acontecer a estimativa ruim que ninguém quer.
Recomendo muito a leitura do livo Scrum, esse livro desbloqueou várias técnicas de planejamento, e inclusive sobre estimativas. Mas mesmo assim, sou otimista demais kkkkkk
Um grande problema e ter ideias e não saber como executalas.
Acredito que o problema do otimismo pode ser resolvido apenas investindo um pouco mais de energia no auto conhecimento.
Se você é um desenvolvedor otimista que já trabalhou em alguns projetos e percebeu que geralmente falta X tempo do prazo que você deu para finalizar suas tarefas, talvez seja válido adicionar esse tempo que geralmente falta aos seus prazos futuros, ou até um pouco a mais.
Não acredito que gere algum problema se você entregar suas demandas um pouco antes, por passar um prazo um pouco maior que o que realmente era necessário, porém, o contrário pode ser bastante prejudicial.
Também é válido ressaltar que um prazo UM POUCO maior do que o que realmente é necessário pode ser saudável, mas muito maior, pode gerar problemas até mesmo tão graves do que prazos otimistas demais.
Sou pessimista até olhando rua de mão unica, dai olho pros dois lados.
Mas esse otimismo eu vejo bastante no código de algumas pessoas, porque não pensam em nada fora o "happy path".
Algo que me ajudou a estimar melhor é a tecnica PERT. Mas dependendo do escopo, pode ser horas ou dias só pra entender o problema e então estimar.
O ruim é que o número parece gigante e por mais que seja acurado... a gente quer falar um número que tem menos de 50% chance de ser atingido... só que eu chego e falo: são essas as estimativas e a chance de fazer dentro do prazo... você (gestor) tem que usar essa informação pra se preparar seja pro melhor ou pior cenário.
metodologia agil so serve para gerente de projetos ter um cargo, pra dev serve para criar burnout.
Sou otimista porem não crio muitas expectativa para não se frutrar kkkk
Abraço meu conterrâneo
😂😂😂
eu acho que nao conheço isso. pq nunca dei prazo para ninguem sobre entrega. kkkkkkk eu so corrigo bugs. kakaakakka
hahahha