febrero 28, 2008

Los grandes programadores

Hace unos años me regalaron (a mi y a Virginia, fue un regalo compartido de un jefe) un libro que leí con mucho interés. Ahora el autor del regalo, escribe sobre él en esta entrada del CES Digital:
Los maestros programadores.

El hoy arquitecto jefe de software de Microsoft, Ray Ozzie, se explayaba así: “los proyectos complejos de programación dirigidos por directores que no son programadores están frecuentemente condenados al fracaso, porque ellos no comprenden los intricados entresijos de los componentes del proyecto, ni las personalidades de los trabajadores. Los directores de proyectos de software han de comprender a las personas que trabajan para ellos. Yo conozco lo mejor que puedo la situación familiar, el estilo de vida y los hábitos de trabajo de cada una de las personas que trabajan conmigo. Sé que no podemos trabajar jornadas de nueve a cinco y sacar el proyecto adelante. También sé que no puedo presionar a la gente para que trabaje 24 horas durante todo el proyecto. Pero sé que, cuando llega el punto decisivo, puedo contar con ellos para trabajar día y noche si es necesario. Ahora, también tengo que saber cuándo hay que aflojar”.

No voy a sacar el recurrente tema de si los jefes de proyecto deben tener un perfil técnico o basta con un perfil de gestión. Lo que me interesa destacar son dos puntos:
  • Hay que planificar los proyectos para que la gente los pueda hacer "de nueve a cinco", durante todo el proyecto. Ya vendrán problemas que no se te habían ocurrido. Seguro.
  • Al tomar la responsabilidad de dirigir proyectos me he dado cuenta que esto no es realmente la informática. Dejas de enfrentarte a problemas matemático-lógicos, para enfrentarte (otras veces, afortunadamente, para colaborar) con las personas.
Ahora tengo encima de la mesa este artículo sobre "A scalable concurrent malloc implementation for FreeBSD". Un artículo que desde luego no tiene nada que ver con la gestión de proyectos, ni siquiera con la programación que hago actualmente. Pero es interesante.
La informática intenta resolver problemas de la gente, mejorar sus procesos, automatizar trabajos,... etc... pero los problemas realmente interesantes para un informático-programador son los que la propia informática genera a bajo nivel. Esos que nos empeñamos en dejar cada vez más abajo y dejarselos a los frikis de las universidades, o de las grandes empresas.
Ahora que busco desesperadamente mi marca personal, he pensado muchas veces en que los problemas que más me gusta resolver son los que no resuelven problemas de personas, si no problemas de computación. Aunque ya no tengo la experiencia necesaria.
Me gusta ser responsable de proyecto, decidir estrategias, implantaciones, tácticas, técnicas... enseñar todo lo que sé al equipo, hacer que trabajemos todos coordinados... pero... me gusta programar.
Si no podeis conseguir leer el libro Programers at Work, al menos leete el artículo de C. Urtasun.

febrero 27, 2008

Scrum y XP desde las trincheras castellanas

No puedo dejar de recomendar y agradecer la traducción que se han trabajado en Proyectalis del magnífico libro publicado en InfoQ Scrum and XP from the Trenches. Ahora tenemos este libro en un primer borrador traducido a castellano en: Scrum y Xp desde las trincheras .
Si eres de los que le da pereza leer en inglés, ya no tienes excusa.

febrero 15, 2008

El producto es el equipo!

He empezado a leer "Software for your Head" siguiendo la recomendación de Mario, y la verdad es que promete. Lo recomendó comparándolo con "Peopleware", así que tiene el listón muy alto.
Pero la idea básica que da en las primeras páginas, ya te lleva a reflexionar. Se plantean una investigación con equipos de desarrollo de software, y su estudio bajo esta sencilla premisa:
Equipos = Software

Y buscan los patrones que hacen funcionar a un buen equipo para desarrollar software de calidad y en plazos. Ahora bien, la primera idea interesante es cuando sben de nivel en la jerarquía. Ahora que soy responsable de proyectos, o eso que llaman mando intermedio también, he seguido pensando que mi trabajo es desarrollar software. Con más responsabilidad, más radio de acción, etc... pero que básicamente me encargo de desarrollar software con un equipo de personas.
Pero es por que no me he dado cuenta que ahora para mi, mi producto como resultado de mi trabajo, no es el software.
Mi producto es el equipo
Y plantearte eso te hace cambiar bastante algunos conceptos. El primero y más obvio, ¿qué narices sé yo de fabricar buenos equipos? El segundo un poco , un poco desasosegante... si hasta ahora lo que me gustaba es producir software... ¿qué hago yo aquí? Aunque, ¿puedo producir equipos que produzcan software si yo no sabría hacerlo? Juraría que no, y por ahí también intuyo que va el libro cuando habla de que el equipo debe tener las características que le pedimos al software que fabrica: estabilidad, escalabilidad, que no tenga/cometa errores,...
Otra idea me lleva a apoyar aún más con estos argumentos a las metodologías ágiles de desarrollo. "La persona sobre el proceso", ¿no implica el equipo sobre la gestión?.

Creo que me va a gustar mucho el libro, por que ya os digo que no he leido más de una pequeña introducción... y me ha dado mucho para pensar, aunque afortunadamente para vosotros, lo dejo para otros posts ;)