Software Project Survival Guide

Software Project Survival Guide de Steve McConnell, tiene en la tapa el siguiente subtitulo: "How to be sure your first important project isn't your last". Este libro salio en 1997 y creo que es el libro que mas tiempo me llevo leer en mi vida. Tendría que haberlo dejado de leer, pero no puedo hacer eso con libros.

Basta de emociones, este libro cuenta paso a paso como administrar un proyecto exitoso, describiendo todos los procesos, todas las etapas del mismo. El proceso de desarrollo por iteraciones que propone es muy rígido, con mucha documentación, poco practico en estos días, pero mucho mejor que el proceso de desarrollo en cascada que se utilizaba antes de la edición del libro. Muchas de las practicas siguen siendo buenas y son recomendables, y vale la pena recordarlas.

El problema es que el autor no encontró una forma amena de redactar este libro, no lo pude disfrutar. Podría atribuirse que es un escritor de libros técnicos, como Code Complete, aunque eso seria un insulto a los escritores técnicos, hay muchos que son mas entretenidos. Además de eso, no estoy de acuerdo con su rigidez en su visión de la administración de proyectos, pero seguro que para la época estaba bien.

1$:1$

Continuando con mi articulo de 1:1 de hace unas semanas, les traigo una visión distinta sobre este tipo de reuniones. Alguien con mucha experiencia piensa que hay que evitar a toda costa charlar a solas con la gente, para evitar la oportunidad de que reclamen un aumento salarial.

Esto tiene cierto sentido, y realmente pasa, lo vivo día a día, pero manejar estos pedidos es parte del trabajo del project manager. Si la empresa tiene un proceso salarial definido, el trabajo consta en guiar a la gente en ese proceso. Si no, hay que manejar estos pedidos escalándolos y haciendo seguimiento de los mismos.

Hay muchas formas de encarar el trabajo, yo prefiero hablar todo y evitar las sorpresas, pero todos los puntos de vista son validos y suman.

Mi nombre en los créditos de un juego!

Por mi participación en el desarrollo del juego Need For Speed World, de Electronic Arts, salio mi nombre en los créditos, todo un hito para mi carrera profesional!

Mi nombre aparece bajo el rol de Development Director, dentro del "External Development Team", que se pueden ver en la sección creditos de la de página web del juego.

Un articulo para alimentar mi ego :)

Asunciones no cumplidas en Proyectos de Costo Fijo

En el contrato de un proyecto de costo fijo sano se listan diversas asunciones. Muchas de estas son técnicas, otras operativas. Por ejemplo, una asunción técnica puede ser la lista de navegadores web donde tiene que funcionar la aplicación. Una operativa podría ser que el cliente esta a cargo del traspaso de la aplicación a los ambientes de producción. Cuando una asunción no se cumple por el lado del cliente y afecta al equipo, eso es un cambio. En un proyecto con un adecuado control de cambios se elevan estas situaciones, y esto lleva a replanificar los costos y la duración del proyecto si es necesario.

Por ejemplo, hace unos días me paso que el cliente hizo un cambio en el código y nos hizo perder toda la mañana, hasta que llego y lo arreglo. Esto son muchas horas de trabajo en un equipo numeroso. En el contrato existe una asunción que indica que el cliente no puede hacer ningún cambio en el código a utilizar durante la iteración actual. Debido a eso, calcule el tiempo perdido en dinero y arme un documento de cambios, y para explicárselo al cliente, se me ocurrió la siguiente analogía:

Let me explain how this broken assumption thing works with an analogy: Let's say we have to host a concert. I'm the leader of the team who does the setup of the speakers in the arena. Kiana is the person who contracted me, she's the band's manager. The concert is on Saturday, that cannot be moved, the whole audience has tickets and the band has a gig in another town the next day, so the concert needs to happen that day. Let's say that we left the arena at 6pm the Thursday before the concert, and we're slated to continue working at 5am on Friday, as there's a lot of work left. When we get in on Friday's morning to the Arena, we look for the cables to connect the speakers but we can't find them! One of Kiana's guys locked them in a storeroom and we do not have the key. I cannot reach Kiana, and we have to wait until her people get in the Arena to resume our duties, as we cannot test the speakers without power. We have to stay later than planned to finish our jobs, and I have to compensate that to the guys somehow, either with money or by giving them time off in the future, which costs me money as well.

Espero que este ejemplo les de ideas para manejar este tipo de situaciones.