¿Cómo puedo estimar proyectos cuando necesito incluir una curva de aprendizaje para nuevas tecnologías?

A veces, hay proyectos de investigación y desarrollo en los que no se sabe nada de antemano sobre la tecnología, los conceptos y el cliente. Sin embargo, el gerente todavía necesita estimaciones de tiempo. ¿Qué puedo hacer para producir estimaciones útiles?

Honestamente, como Nassim Nicholas Taleb escribe en su libro The Black Swan: "simplemente no podemos predecir". Principalmente debido a las incógnitas desconocidas. En general, es mejor comunicar este hecho, el hecho de que no se puede predecir, en lugar de comunicar una estimación.

Como escribe Taleb: es mejor tener una razón general, que estar equivocado. Así que asegúrese de comunicar el hecho de que tiene dificultades para estimar, y use cosas como 'curvas de aprendizaje en nuevas tecnologías' como uno de los argumentos. Esto significa que el rango de su estimación será grande: 'este proyecto costará entre 100k y 500k'.

Al decir tal cosa, el que le pide que calcule algo se da cuenta de que las cosas no son tan simples.

Lo primero que necesita absolutamente es una idea del alcance. Cuanto más concreto, mejor, pero se puede utilizar cualquier forma de requisitos para producir estimaciones iniciales. Los requisitos del cliente, la visión y el alcance, y los documentos conceptuales se pueden utilizar desde el principio. A medida que los requisitos y el entorno operativo comiencen a ser más claros, las estimaciones mejorarán. Una mayor comprensión del cliente (especialmente las interfaces entre el cliente y la organización en desarrollo), el equipo que realiza el trabajo, las tecnologías que se utilizarán, la arquitectura del sistema y un diseño detallado contribuirán a una estimación más precisa. Esto es visible en el Cono de Incertidumbre.

Si está utilizando una herramienta de modelado paramétrico, como SLIM o COCOMO (solo intermedio o avanzado, ya que Basic no tiene en cuenta los generadores de costos), entonces debería haber factores de ajuste para la falta de familiaridad de la tecnología. Como ejemplo, COCOMO tiene una gran cantidad de generadores de costos , incluidos algunos que están específicamente orientados a familiarizarse con la plataforma objetivo, así como con el lenguaje y las herramientas que se utilizan para desarrollar el sistema. SLIM también da cuenta de la experiencia general del equipo de desarrollo, que debe incluir consideraciones sobre las herramientas y tecnologías que se utilizan.

Con esta técnica, el resultado de las herramientas de modelado generalmente se valida porque se han utilizado con éxito para estimar proyectos de software anteriores durante muchos años en muchas organizaciones. Sin embargo, la salida es tan buena como la entrada a la herramienta.

Si no está utilizando modelos paramétricos para la estimación, simplemente tendrá que considerar estos factores al producir sus estimaciones. Se convierte en una cuestión de juicio, pero puede considerar actividades como leer la documentación, configurar el nuevo entorno de desarrollo y desarrollar aplicaciones de muestra en la plataforma de destino o con los idiomas de destino.

En estos casos, deberá desglosar sus estimaciones por tarea y poder utilizar su criterio profesional para respaldarlo. Con suerte, tiene datos históricos y otras pruebas concretas en las que basar sus estimaciones. De lo contrario, es más una batalla cuesta arriba.

Separe la capacitación principal y el tiempo de investigación del tiempo de desarrollo. Divida el proyecto en múltiples subproyectos que tengan finales felices. Asegúrese de crear una prueba de concepto después de la capacitación.

Si es nuevo en la tecnología, nunca se acercará al tiempo de desarrollo real. Plantee esto como un riesgo al comienzo del proyecto y sea generoso en su estimación. Esto se aplica a las tecnologías principales con las que usted y su equipo no están familiarizados.

Depende, usé FPA ( Análisis de puntos de función ) la mayor parte del tiempo, pero estábamos en este "desarrollo web empresarial", quiero decir, ya sabes, las compañías web de Forbes 500.

Allí, la tarea siempre se puede dividir en dos partes: una, que se ajusta muy bien a FPA: tiene interfaces de entrada, interfaces de salida, archivos lógicos internos (también conocidos como tablas / tipos de bases de datos que se exportarán) y tiene estos sistemas complejos y desconocidos .

En la versión fácil, la tarea compleja es un componente ya escrito, es difícil y desconocido interactuar con él.

La versión difícil es cuando necesita ser escrita, luego estimaciones basadas en piloto, COCOMO, lo que sea.

Sin embargo, hay dos cosas importantes:

1. Cada tipo de sistema de estimación debe tener un tiempo de calibración para su organización. Nunca se desarrolla solo, al menos hay un cliente esperando su código (o no estaría tan desesperado por esto, escribiendo código por su propio bien). La pregunta no es "¿qué tan rápido se puede desarrollar?", Sino "qué tan rápido se puede desarrollar con todos ustedes".

2. Una vez tuve un gerente que leyó esa novela de Black Swan y estaba loco por eso. Nos estaba diciendo que es imposible estimar, y yo estaba haciendo mis precisas estimaciones habituales a + -10% sin descanso ...

Hago proyectos que se ajustan a esa descripción de forma regular y todavía no lo he descubierto. Afortunadamente, donde trabajo tengo la libertad de hacer lo que necesito y no tengo límites de tiempo inútiles. Los proyectos no siempre son exitosos y eso es solo una parte del trabajo con tantas incógnitas. Sin embargo, la compañía adquiere conocimiento cada vez.

Lo siento, eso no ayuda en absoluto.

Calcule cuánto tiempo llevará hacer un proyecto similar utilizando tecnología familiar. Multiplique por 4. Agregue algo de tiempo de aprendizaje.

Si la estimación es demasiado corta, parecerá ingenuo y arrogante. Si la estimación es demasiado grande, parecerá ignorante e incompetente. Elegir sabiamente.