Aunque hay cientos de libros, y teorías, sobre cómo gestionar de proyectos, en la mayoría de ellos echaremos en falta mucha experiencia y realidad del día a día. Esas realidades que muchas veces no son lo suficientemente “políticamente correctas” para salir en un libro o artículo, pero que si han dado para decenas de leyes, frases y axiomas “de la calle”.
Algunas con mayor o menor toque de humor, no todas del mundo software, pero todas dejándonos muchas verdades de lo que pasa en los proyectos.
Y por ello que en este post he querido dejaros 15 principios y leyes que se “aprenden en la calle”. Esos principios tras los que, como sucede los buenos refranes españoles, no hay teoría científica pero si mucha sabiduría:
– La paradoja del Pesticida: Cada método utilizado para prevenir o detectar errores deja otro residuo de errores contra los que estos primeros métodos son ineficaces. (Bruce Beizer). No sé por qué, al leer esto, me ha venido a la cabeza la automatización de pruebas.
– Ley de Nathan: El software es como el gas, se expande hasta llenar aquello que lo contiene.
– Ley de Lister: La gente bajo presión no piensa más rápido.
– Ley de Parkinson: El trabajo se expande hasta agotar el tiempo disponible.
– Ley de Brooks: Añadir gente a un proyecto software con retraso hace que se retrase más (esta si es una ley de un libro, y muy bueno, por cierto).
– Axioma de Flon: No hay, ni habrá, un lenguaje de programación en el cual sea un poco menos fácil escribir malos programas.
– Ley de Hartree: Cualquiera que sea el estado de un proyecto, el tiempo que un jefe de proyecto estima para su finalización es constante.
– Ley de Hoare: Dentro de cada gran problema hay un problema pequeño que lucha por salir.
– Ley de Murphy: Si hay dos o más formas de hacer algo, y una de esas formas puede acabar en una catástrofe, entonces alguien la elegirá.
– La navaja de Occam: La explicación más sencilla es la que con mayor probabilidad es correcta.
– Principio de Pareto: 20% del esfuerzo genera el 80% de resultado.
– Principio de Peter: En una jerarquía, todo empleado tiende a ascender hasta su máximo nivel de incompetencia.
– Ley de Spector: El tiempo que tarda una aplicación en completar una determinada tarea se duplica con cada nueva versión.
– Ley de Tesler sobre la conservación de la complejidad: No puedes reducir la complejidad de tarea más allá de un punto. Una vez has llegado a ese punto lo único que puedes hacer es pasarle el problema a otro.
– Ley de Wirth: El software se vuelve lento más rápidamente de lo que el hardware es capaz de ser más rápido. También lo he escuchado como… el hardware es aquello que con el tiempo deja de funcionar y el software es aquello que con el tiempo funciona.
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.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Pingback: Bitacoras.com
Inapelable!
Hola!
Tenía pendiente hace tiempo leer este post.
Quería comentar el siguiente principio:
«– Ley de Brooks: Añadir gente a un proyecto software con retraso hace que se retrase más (esta si es una ley de un libro, y muy bueno, por cierto).»
Siempre nos habían dicho que es así y así lo defenderé también, pero … como no todo es blanco o negro, tengo que decir que si es posible meter a una persona más en un proyecto y que este no se retrase más, incluso, para una «sangría».
Dado un equipo de «n» personas en un proyecto que va mal, es posible añadir una persona al proyecto si existe una tarea independiente y que no afecte al resto. (Vale, esto es muy ideal, pero se puede dar).
Un saludo y aprovecho para darte las gracias por este y cada uno de los post que publicas en tu web.
De nada 🙂
Principio de Pareto: 20% del esfuerzo genera el 80% de resultado.
Debemos aprender a hacer lo que efectivamente corresponde hacer y dejar los adornos. Así como ese 20% genera el 80% del resultado, también se hace con el 20% de los recursos reales, incluyendo al humano. Triste pero cruda realidad.