Lo de llamarlas Leyes será por darles un nombre así, no sé, de peso, pero bueno, el caso es que tendrán sus excepciones pero… se dan en la gran y amplia mayoría de las ocasiones, son las Leyes de la Estimación, inicialmente de software, hoy aplicables a un montón de trabajos intelectuales, no sólo de desarrollo.
Todas las siguientes son bastante antiguas, sólo en el blog hay menciones a algunas de ellas en post de hace 5 o 6 años, pero que algo sea antiguo no implica que sea conocido, y cómo me he encontrado estos meses unas situaciones que han requerido de rememorarlas he aprovechado para sinterizártelas en este post.
Ahí van…
Ley de Parkinson, el trabajo se expande hasta agotar el tiempo disponible
Clasicazo para empezar, te dejo post sobre la Ley de Parkinson (2011), que viene a decir que si, por ejemplo, algo se puede hacer en un mes, pero estimamos mes y medio para hacerlo… nos llevará mes y medio terminarlo (aunque podría haberse terminado en un mes)
Ley de la Deuda Técnica, haciéndolo mal (a corto plazo) se tarda menos que haciéndolo bien
Hay un montón de post en el blog sobre Deuda Técnica, te dejo alguno:
Mide tu deuda técnica… ¡en 5 min!
La deuda técnica. Todo el mundo debería saber que la mala calidad software al final se paga
El concepto tiene más historia, pero para lo nuestro aquí, la estimación, la idea, donde se esconde el Lado Oscuro, es que hacerlo mal, saltando etapas, corriendo, etc., suele implicar menos tiempo que hacerlo bien. Aunque, a medio plazo, el cúmulo de cosas mal hechas lleve a que para todo tardemos mucho más que habiéndolo hecho bien en su momento.
Ley del Error, toda estimación tiene un error
Por defecto, sino… podrías estimar hasta en microsegundos. Por eso, aunque lo obviamos, una estimación siempre va acompañada de una probabilidad de cumplirse.
Y, relacionado o derivado de esto..
Ley de que el nivel de precisión de la estimación es distinto a medida que avanza la tarea (¿proyecto?)
Y a tareas mayores… mayor error.
Al principio, al comenzar, el error con el que se trabaja es mayor que cuando se va, por ejemplo, por la mitad. Una figura muy útil para entender esto es el famoso “cono de incertidumbre” (aunque no está demostrado que sea un cono puro), que muestra cómo las estimaciones son más precisas según progresa el proyecto, hasta el día de antes, donde ya tienes más claro cuánto va a durar 🙂
La Ley de la probabilidad de estimar y subestimar
Que viene a decir que, sabiendo que una estimación está acompañada de una probabilidad de cumplirse, subestimando, estimando por abajo, llega un punto que la probabilidad de cumplirse es cero, pasado un umbral no puedo hacer la tarea en menos tiempo (por mucho que me empeñe), pero, por contra, siempre hay una probabilidad, quizá mínima, de que la tarea termine mucho tiempo después o de que no termine (hay probabilidad de que dure infinito).
La Ley de que comparar estimaciones software con el trabajo de un albañil… es un absurdo (populismo tecnológico)
Que es un cobra-Kai, o una simplificación a un problema tan complejo como la estimación de algo intelectual, a lo que no aplican Leyes físicas, que nunca se ha hecho antes y cuyos «requisitos» cambian y/o no están claros , vamos lee El ejemplo del albañil y la estimación software y la ágil
Ley de Brooks, añadir gente a un proyecto software con retraso hace que se retrase más
Post retro, año 2007, sobre esta Ley, que contradice el «efecto fuerza bruta» de meter más personas para terminar antes.
Terminando…
Algunas se me habrá quedado por ahí, si tienes alguna Ley de estimación interesante dímelo. Y te dejo otro antiguo Post sobre 15 leyes de gestión de proyectos que se aprenden “en la calle”
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
Sobre el «cono de incertidumbre», suelo poner el ejemplo de la predicción del tiempo. Prever el futuro es imposible, pero la probabilidad de acertar es mayor cuanto más cerca está «ese futuro» del momento presente.