Como posso estimar projetos quando preciso incluir uma curva de aprendizado para novas tecnologias?

Às vezes, existem projetos de pesquisa e desenvolvimento em que nada é conhecido antecipadamente sobre a tecnologia, os conceitos e o cliente. No entanto, o gerente ainda precisa de estimativas de tempo. O que posso fazer para produzir estimativas úteis?

Honestamente, como Nassim Nicholas Taleb escreve em seu livro O Cisne Negro: 'simplesmente não podemos prever'. Principalmente devido ao desconhecido-desconhecido. Geralmente, é melhor comunicar esse mesmo fato, o fato de que você não pode prever, em vez de comunicar uma estimativa.

Como escreve Taleb: é melhor estar amplamente certo do que precisamente errado. Portanto, certifique-se de comunicar o fato de que você tem dificuldades para estimar e use coisas como 'curvas de aprendizado em novas tecnologias' como um dos argumentos. Isso significa que o alcance da sua estimativa será grande: 'esse projeto custará entre 100 mil e 500 mil'.

Ao dizer uma coisa dessas, quem pede para estimar algo percebe que as coisas não são tão simples.

A primeira coisa absoluta que você precisa é ter uma idéia do escopo. Quanto mais concreto, melhor, mas qualquer forma de requisitos pode ser usada para produzir estimativas iniciais. Os requisitos do cliente, visão e escopo e documentos conceituais podem ser usados ​​desde o início. À medida que os requisitos e o ambiente operacional começarem a ficar mais claros, as estimativas melhorarão. Uma maior compreensão do cliente (especialmente as interfaces entre o cliente e a organização em desenvolvimento), a equipe que executa o trabalho, as tecnologias a serem usadas, a arquitetura do sistema e um design detalhado contribuirão para uma estimativa mais precisa. Isso é visível no cone da incerteza.

Se você estiver usando uma ferramenta de modelagem paramétrica, como SLIM ou COCOMO (somente Intermediário ou Avançado, pois o Basic não leva em conta os fatores de custo), deve haver fatores de ajuste para o desconhecimento da tecnologia. Como exemplo, o COCOMO possui um grande número de direcionadores de custos , incluindo alguns especificamente voltados para a familiaridade com a plataforma de destino, bem como o idioma e as ferramentas usadas para desenvolver o sistema. O SLIM também responde pela experiência geral da equipe de desenvolvimento, que deve incluir considerações sobre as ferramentas e tecnologias que estão sendo usadas.

Com essa técnica, a saída das ferramentas de modelagem geralmente é validada porque elas foram usadas com sucesso para estimar projetos de software anteriores ao longo de muitos anos em muitas organizações. No entanto, a saída é tão boa quanto a entrada da ferramenta.

Se você não estiver usando modelos paramétricos para estimativa, basta considerar esses fatores ao produzir suas estimativas. Torna-se mais uma decisão, mas você pode considerar atividades como ler a documentação, configurar o novo ambiente de desenvolvimento e desenvolver aplicativos de amostra na plataforma de destino ou com os idiomas de destino.

Nesses casos, você precisará dividir suas estimativas por tarefa e poder usar seu julgamento profissional para fazer o backup. Felizmente, você tem dados históricos e outras evidências concretas para basear suas estimativas. Caso contrário, é mais uma batalha difícil.

Separe o tempo principal de treinamento e pesquisa do tempo de desenvolvimento. Divida o projeto em vários subprojetos que tenham finais felizes. Certifique-se de criar uma prova de conceito após o treinamento.

Se você é novo na tecnologia, nunca chegará perto do tempo real de desenvolvimento. Aumente isso como um risco no início do projeto e seja generoso em sua estimativa. Isso se aplica às principais tecnologias com as quais você e sua equipe não estão familiarizados.

Depende, eu usei o FPA ( Function Point Analysis ) na maioria das vezes, mas participamos desse "desenvolvimento da web empresarial", ou seja, você sabe, 500 empresas da Web da Forbes.

Lá, a tarefa sempre pode ser dividida em duas partes: uma, que se encaixa muito bem ao FPA: você possui interfaces de entrada, interfaces de saída, arquivos lógicos internos (também conhecidos como tabelas / tipos de banco de dados a serem exportados) e possui esses sistemas complexos e desconhecidos .

Na versão fácil, a tarefa complexa é um componente já escrito, é difícil e desconhecido fazer interface com ele.

A versão mais difícil é quando ela precisa ser escrita e, em seguida, estimativas baseadas em piloto, COCOMO, qualquer que seja.

Duas coisas, no entanto, são importantes:

1. Todo tipo de sistema de estimativa precisa ter um tempo de calibração para sua organização. Você nunca se desenvolve sozinho, pelo menos há um cliente esperando pelo seu código (ou você não estaria tão desesperado com isso, escrevendo o código por si mesmo). A questão não é "quão rápido ele pode ser desenvolvido?", Mas "quão rápido ele pode ser desenvolvido com todos vocês?"

2. Certa vez, tive um gerente que leu o romance Cisne Negro e ficou louco por isso. Ele estava nos dizendo que é impossível estimar, e eu estava fazendo minhas estimativas habituais precisas para + -10% implacavelmente ...

Eu faço projetos que se encaixam nessa descrição regularmente e ainda não descobri isso! Felizmente, onde trabalho, tenho a liberdade de fazer o que preciso e sem limites de tempo fúteis. Os projetos nem sempre são bem-sucedidos e isso é apenas parte do trabalho de tantas incógnitas. A empresa ganha conhecimento a cada vez.

Desculpe, isso não ajuda em nada.

Estime quanto tempo levará para fazer um projeto semelhante usando tecnologia familiar. Multiplique por 4. Adicione algum tempo de aprendizado.

Se a estimativa for muito curta, você parecerá ingênuo e arrogante. se a estimativa for muito grande, você parecerá ignorante e incompetente. Escolha sabiamente.