Por qué los detalles matan los proyectos

La calidad resultante de un proyecto es inversamente proporcional al número de personas que opinan durante su ejecución.
Una calculadora mecánica cortada por la mitad desvela un complejísimo mecanismo con miles de piezas metálicas conectadas entre sí.

Qué poco valoramos las complejidades que nos hacen la vida más fácil. En la imagen, el interior de una calculadora mecánica.

En una empresa se organiza una reunión para aprobar el anteproyecto para la construcción de una central nuclear y decidir el color del cobertizo para guardar las bicicletas con las que algunos ingenieros irán a trabajar a dicha planta.

Como la construcción de la central nuclear es un tema complejo e importante, todos asumen que alguien serio y profesional se ha preocupado de estudiar cada detalle y el asunto se despacha en dos minutos.

El color del cobertizo es diferente. No importa lo buena que sea la argumentación de quién propone su construcción, todo el mundo intuye cómo se construye uno, así que nadie pierde la oportunidad de aportar su granito de arena. Siempre hay alguien que quiere demostrar que está haciendo su trabajo y prestando atención. Se trata de intervenir, de dejar huella, de no pasar desapercibido. Unas veces hay que justificar un máster, otras es para, dentro de un tiempo, decir “¿Ves?, eso lo hice yo.”

En la mayoría de la ocasiones la culpa la tiene la incomodidad que nos produce el silencio.

C. Northcote Parkinson usó esta historia en su libro de 1957, La Ley de Parkinson (Parkinson’s Law) para ilustrar por qué no deberías intervenir en algo sólo porque puedas hacerlo.

Parkinson deja en evidencia algo que todos los que hemos trabajado en (o con) multinacionales hemos experimentado: alguien puede llegar a una junta y conseguir la aprobación para construir un proyecto multimillonario, pero si quieres hacer algo sencillo mejor olvídate, te verás envuelto en una interminable discusión.

En una ocasión un cliente necesitó dos semanas de debates y pruebas para decidir la posición de la sombra de un botón de su web, un proyecto que por su complejidad técnica había requerido casi seis meses de programación. Una vez acabado el proyecto esta persona vendió su participación a su socio y abandonó la empresa. Dado que el socio no era nada amigo de la tecnología el sitio web nunca se publicó.

La anécdota de la central nuclear y el cobertizo para bicicletas se ha hecho tan popular en el mundo informático que existe un verbo para referirse a ello, bikeshed (combinación de las palabras inglesas bike –bicicleta– y shed –cobertizo–) y una web dedicada a la historia.

Viñeta que muestra a dos personas sentadas en una mesa hacer comentarios a una tercera persona de pie, delante de una pizarra.

—”Me gusta tu código pero, ¿puedes usar ‘Q’ como nombre de variable en lugar de ‘N’?”
—”Sí, ‘Q’ resalta más.”
(Si trataran a los ingenieros como diseñadores.)

Otro caso donde se aprecia la Ley de Parkinson es en el diferente trato que reciben, por parte de clientes o directores de proyectos, los diseñadores y los desarrolladores. En mis años en Clever Consulting nadie ha osado a poner en duda los nombres que los programadores ponen a las variables, cómo comentan el código fuente o el diseño de una base de datos. Pese a tratarse de la parte más compleja y con más repercusión en los resultados del proyecto todo el mundo asume que sabemos lo que hacemos. Sin embargo, pocos son los que no ponen en duda las decisiones de los diseñadores, pese a que éstos están tan preparados y toman las decisiones con tantos argumentos objetivos como los programadores.

Casi siempre, cómo se construye el cobertizo es menos importante que tomar una decisión y avanzar.

Comenta

Todos los campos son obligatorios: