viernes 12 de marzo de 2010

El Principio de Peter

En 1969 mientras la nave Apolo llevaba al Hombre a pisar la Luna, Laurence J. Peter publicaba el libro The Peter Principle. Estos dos acontecimientos para nada relacionados entre si me permiten contar una historia que siempre me ha interesado.

La llegada a la Luna que ha sido uno de los mayores desafíos de la Humanidad se llevó acabo entre otras cosas gracias a la informática y en concreto gracias al ordenador que llevaba la nave Apolo. Lo curioso es que este ordenador tenía las siguientes características 1kb de RAM (ni siquiera es 1 Mb !!), 12 Kb de Rom y 1Mhz de Proceso, probablemente mi lavadora tenga más capacidad actualmente.

Mientras tanto Peter marcaba en este libro una sentencia arrasadora sobre el mundo empresarial, "En una jerarquía todo empleado tiende a subir hasta su nivel de incompetencia". Lo que se explica, si haces bien tu trabajo te ascienden hasta que llegas a un nivel en que lo haces mal y ahí te puedes quedar para siempre. En un sistema piramidal indica cual puede ser el nivel de una dirección de una empresa, siempre que Peter tenga razón.

La carrera empresarial en el mundo TI es totalmente piramidal y marcada por niveles de Junior y Senior, lo cual esta llevando a que los grandes programadores acaben siendo jefes de proyecto, un trabajo para el cual probablemente no estén preparados y ni siquiera les guste. El problema es que un programador brillante tiene muy pocas oportunidades de vivir de la programación, y la hipoteca e hijos aprietan.

Evidentemente la mayoría de los programadores no se enfrentarán nunca a retos como el de hacer un SW para llegar a la Luna y claro, hacer 20 veces aplicaciones que son técnicamente iguales no es nada atractivo. Por lo cual es mejor ser un mal jefe de proyecto que un buen programador, con lo cual Peter tiene razón.

Desde el otro lado del prisma, tengo que decir que hay grandes JP que no han sido grandes programadores lo cual quiere decir que hay que tener algo más y que el problema se detecta. ¿Pero cuantos nunca llegarán a JP por no ser un gran programador? Por tanto el truco debe estar en atenuar las jerarquías, potenciar el trabajo transversal y la comunicación entre diferentes niveles..

La idea puede venir de potenciar puestos técnicos que aporten valor (en euros) a los proyectos, y no solo pensar que es el JP el único arma para velar por la rentabilidad..

viernes 5 de marzo de 2010

Comprometido o Involucrado

Cerdo o Gallina

Sin ser fan de las Metodologías Ágiles, o al menos de verlas como solución a todos los problemas y no viendo en Scrum una varita mágica, hay cosas que de Scrum que me encantan.

Una de ellas es el modo que tiene al describir los participantes en el proceso sw como Cerdos o Gallinas. Me parece admirable alguien que describe un método de trabajo de una manera tan original basada en un chiste.

Me quedo sobre todo con el mensaje que podemos aplicar a los proyectos en los que participamos, tenemos que darnos cuenta que en nuestro proyecto tenemos dos tipos de participantes los Comprometidos y los Involucrados.

Si hacemos esta reflexión en un proyecto y contamos que en nuestro equipo de desarrollo tenemos pocos comprometidos y muchos involucrados probablemente el proyecto fracase. Por tanto mira al rededor e identifica cerdos y gallinas, si tienes una piara las cosas van bien, si tu equipo picotea el suelo.. medita.

Moraleja: En el Software como en la vida, debemos rodearnos de personas Comprometidas..