Al calcular el plazo del proyecto, tradicionalmente evaluamos la duración de los pasos intermedios, luego los resumimos y agregamos un amortiguador para todo tipo de accidentes. Entonces el liderazgo nos corta este período a la mitad. Como parte de esta nota, el autor estará interesado en nuestros cálculos, porque incluso un gerente de proyecto con amplia experiencia a menudo entiende que el período calculado es demasiado corto y demasiado, a veces en ocasiones, en desacuerdo con su evaluación personal experta. Sí, corregirá las estimaciones de los términos del proyecto y los pasos intermedios para su evaluación experta y, con verdadero dominio con cierto procesamiento, cumplirá el plazo con una precisión del 15%, pero el sedimento permanecerá.
Esta nota explica la razón de la discrepancia entre las estimaciones expertas y las calculadas teóricamente. También se considera por qué la evaluación experta "exagerada" generalmente se subestima si no se realiza sobre la base de estadísticas sobre la implementación de proyectos similares. Al final, se revela cómo calcular correctamente el plazo del proyecto y explicar la situación a las partes interesadas antes del inicio del proyecto o durante el mismo.
La raíz del error.
Cuando evaluamos el período de implementación de un trabajo, determinamos la cifra más probable. Puede ser una evaluación experta en un punto o en tres puntos, como en PERT. En un proyecto complejo, esto puede ser modelado paramétrico. En todos los casos, cometemos el mismo error. El hecho es que en todos los métodos de estimación clásicos se supone que tenemos una distribución normal del valor estimado, según Gauss. Los teóricos son muy aficionados a esta distribución.
La distribución normal significa que un proyecto con una duración estimada correctamente de 6 meses es igualmente probable que se complete en 9 meses o 3 meses. A distancias iguales del centro de distribución, la probabilidad de finalización del proyecto es igual: esta es una característica de la curva de Gauss. Por otro lado, en la práctica, pocos han visto un proyecto de TI que se complete el doble de rápido (después de 3 meses), pero los proyectos que se retrasan una y media veces en términos (9 meses) lo vemos regularmente. Además, con una distribución normal, la mitad de nuestros proyectos terminarían antes del tiempo estimado, y la mitad después. Pero esto tampoco se observa en la práctica. Esto sugiere que la distribución normal para estimar plazos no es aplicable. Es decir, no tenemos una distribución normal, sino alguna otra, con diferente probabilidad de finalización antes de la fecha más probable y posterior.
Considere la distribución lognormal como un ejemplo de tal distribución. Nos mostrará las características de esta clase de distribuciones. Para la distribución lognormal, la expectativa mediana y matemática está significativamente más allá del pico:
En el gráfico presentado, el pico muestra la mayor probabilidad de la fecha de finalización del proyecto. Esta cifra generalmente incluye esta cifra más un cierto margen. La mediana indica un punto de separación en el que la mitad de los proyectos se completarán antes de este plazo y la segunda mitad después. La expectativa matemática indica el valor promedio de la duración del proyecto. Para un fragmento de trabajo, la distribución tendrá las mismas características: una gran diferencia entre el período de tiempo más esperado para la implementación del fragmento de trabajo (los planes se basan tradicionalmente en él) y el valor promedio del término.
Para predecir la duración del proyecto, determinamos la cadena más larga en el tiempo y agregamos la duración de sus fragmentos. Si sumamos los valores distribuidos según Gauss, entonces, en promedio, se debe obtener el término final correcto. De hecho, la mitad de los fragmentos del trabajo se completarán antes de lo previsto, la mitad más tarde y estas heterogeneidades se cancelarán entre sí. Cuantos más fragmentos, más exactamente se compensan las inhomogeneidades. Además, podemos calcular el error y cambiar ligeramente la fecha límite por una sigma o dos, dependiendo de las consecuencias de la fecha límite.
Pero no tenemos una distribución gaussiana. En nuestro país, alargar el tiempo de ejecución de cada trabajo es mucho más probable que acortarlo en la misma cantidad. Como resultado, si agregamos los plazos para la finalización más probable de cada trabajo, las heterogeneidades en términos de finalización no se compensan, sino que se amplifican. Además, se intensifican en la dirección de alargar el plazo promedio real del proyecto en comparación con la estimación. Lo que observamos en la vida real: si el primer término está vencido, todos los demás términos estarán vencidos, mientras que la demora solo crecerá. Solo aplicando esfuerzos adicionales se puede detener el retraso del proyecto.
Una característica de este método de cálculo es un hecho bien conocido: cuanto menor es la fragmentación del trabajo para evaluar la duración del proyecto, menos precisa es la estimación. Aunque en teoría debería ser exactamente lo contrario. La razón de esto es que nuestra evaluación experta para todo el trabajo y sus partes constituyentes se toma de la experiencia. La experiencia evalúa cada elemento de forma independiente, y no en función de la aritmética, según la cual la duración del trabajo debe ser la suma de las duraciones de sus partes constituyentes. La aritmética no funciona aquí, ya que la suma de los plazos más probables para completar partes no proporciona el plazo más probable para completar todo el trabajo; solo las expectativas matemáticas se pueden sumar correctamente.
Si tratamos de cambiar ligeramente el término estimado para todo el proyecto o sus partes por una sigma o dos, considerando que la distribución es normal, entonces esto no ayuda mucho, ya que la cola de distribución es mucho más gruesa que la curva gaussiana. Como resultado, debido a tal aumento en la estimación del término, uno ni siquiera puede alcanzar la mediana, sin mencionar el valor promedio de la duración del proyecto en forma de expectativa matemática.
Que hacer
Por un lado, se deben agregar expectativas matemáticas. Por otro lado, no somos matemáticos. Somos de la vida real y entendemos el problema de calcular los parámetros de los gráficos, incluso cuando hay tiempo para esto y algunas estadísticas acumuladas. Pero hay otras formas. Al final, el problema de evaluar el tiempo de más de una docena de años, y la práctica ha aprendido a trabajar con él.
Método Brooks : consideramos el período de implementación del programa "de frente" (el usuario es el programador) y lo multiplicamos por 3 para el producto de software (el usuario es un círculo ilimitado de personas) o el complejo de software (en las realidades actuales - un conjunto de microservicios) y 9 para el producto de software del sistema ( en las realidades actuales, un conjunto de componentes de infraestructura relacionados). El origen de estos coeficientes está bien justificado teóricamente en el primer capítulo del libro Mythical Man-Month de Brooks, y esta descripción de 1975 está bien desplazada a las realidades actuales.
Método Scrum : presentamos una unidad intermedia abstracta de la complejidad de implementar lo funcional, observamos las estadísticas de la implementación de lo funcional medidas en las unidades dadas de lo funcional, le pedimos al equipo que evalúe la complejidad de las tareas del proyecto, traduzca las unidades a la iteración Scrum (sprints) de longitud conocida y obtenga una estimación de los términos para este equipo de desarrollo. Dado que trabajamos con estadísticas realmente recopiladas y el equipo es responsable de sus estimaciones de la complejidad, la unión de la duración a la unidad de trabajo es una expectativa matemática y, por lo tanto, la mitad de los sprints terminarán un poco antes, la mitad un poco más tarde. En la práctica, en la mitad de las iteraciones de Scrum, el equipo tendrá que tomar parte de las tareas, y en la mitad agregar otras no planificadas, de modo que la longitud del sprint permanezca constante.
La tarea de transferir la Evaluación Scrum de un equipo a otro equipo es un arte. No se pueden transferir simplemente introduciendo un factor de conversión para las unidades laborales de un equipo en las unidades laborales del otro equipo. El hecho es que un equipo tiene un buen front-end en su composición, pero no tiene un buen especialista de base, y el otro equipo tiene un buen especialista de base, pero las tareas de primera línea son de mayor complejidad. Las diferencias en la especialización de los desarrolladores conducirán al hecho de que con respecto a las tareas de back-end, un equipo tendrá un exceso de complejidad hacia las tareas en la base de datos y el otro en el frente. Además, el equipo mismo determina el nivel necesario de la calidad interna del producto y los diferentes equipos lo determinan de una manera ligeramente diferente a los equipos vecinos, lo que también dificulta el recálculo de las unidades de trabajo. Es decir, es posible traducir las unidades intermedias de un equipo en las unidades intermedias de otro equipo mediante la comparación de estimaciones de tareas similares, pero estas tareas deben tomarse de diferentes tipos de actividades, teniendo en cuenta las fortalezas y debilidades de los equipos y teniendo en cuenta las peculiaridades de configurar su Scrum.
Método de elementos funcionales : introducimos una unidad intermedia de entrada de trabajo, compilamos una lista de elementos funcionales (pantallas en un navegador, microservicios, elementos de infraestructura personalizados, etc.), estimamos la laboriosidad del trabajo en cada elemento funcional en unidades intermedias. Después de eso, en base a nuestra experiencia experta trabajando con un equipo de desarrollo específico, evaluamos el factor de conversión de la unidad intermedia a lo largo del tiempo. Personalmente, todavía evalúo independientemente los factores de conversión para diferentes tipos de actividades: análisis, diseño, redacción de declaraciones de tareas, escritura de código, diseño, pruebas, integración, etc. Después de esto, se debe tener en cuenta el orden de las operaciones, el tiempo de retraso característico entre la finalización de la operación anterior y el inicio de una nueva y la duración del proyecto debe determinarse por el método de ruta crítica.
Hasta ahora, hemos trabajado con los factores internos del proyecto. Pero también tenemos externos: contratistas externos, departamentos relacionados, proveedores y el cliente. Los problemas con ellos son exactamente los mismos: responden dos veces o más rápido o con menos frecuencia una vez y media más que el valor más probable. Es decir, tampoco existe una distribución de temporización normal. Esto también debe establecerse y tenerse en cuenta sobre la base de estadísticas sobre el trabajo con clientes, contratistas y unidades relacionadas y, si es posible, protegerse con la ayuda de sanciones.
Justificación de tiempo
Y así, estimamos la duración proyectada del proyecto. ¿Cómo justificar el plazo recibido? Basado en los cálculos realizados. Por ejemplo, el autor de una nota para proyectos que no son Scrum generalmente hace una gran tabla visual de varias líneas en Hojas de cálculo de Google con un cálculo detallado por el método de elementos funcionales. El cálculo se basa en la práctica, todos los coeficientes y parámetros son visuales, y la práctica para las partes interesadas suele ser un argumento fuerte y bueno, incluso si resulta ser un período incómodo para ciertas personas. Especialmente la práctica es visual y se obtiene en el marco de la empresa actual.
¿Las partes interesadas, como la gerencia, estarán de acuerdo con una evaluación de línea de tiempo bien hecha y bien informada? No siempre, incluso si las partes interesadas entienden completamente y se dan cuenta de que la evaluación es correcta. A veces, la evaluación es inaceptable por razones externas, pero esto ya es un dolor para las partes interesadas, lo que resulta en una decisión difícil por parte de la administración sobre el momento. Sin embargo, al ver los cálculos basados en la experiencia, la administración y otras partes interesadas tienen la oportunidad de influir previsiblemente en el término final del proyecto mediante la asignación de recursos y poderes adicionales. A veces, la gerencia que comprende la situación del momento continuará reduciendo los plazos sin asignar recursos y autoridad adicionales. Cómo vivir con esto es el tema de una nota separada.