Cambiando de perspectiva (1)

Es mi intención incluir material que pueda resultar interesante para otros en este espacio. Que es lo que puede ser interesante no me queda muy claro muchas veces y es así que pasa el tiempo sin nuevos contenidos. Sin embargo, ahora pienso que hay algo de mi experiencia que podría tener valor para otros.

Dejenme escribir algunas palabras sobre mi experiencia para poner todo lo que sigue en perspectica. Hace varios años me dedico al desarrollo de software. Más allá que siempre me gusto programar, desde el inicio de mi actividad profesional tuve un interés por el desarrollo de software desde una visión global, considerando ciclos de vida, fases, practicas diversas, relaciones humanas y varias cosas más. Debido a esto, o a pesar de ello, he ocupado roles de liderazgo y mis actividades se han ido formalizando en este sentido en el último tiempo. Es así que mi rol principal en los proyectos ya hace más de dos años es el de lider de proyectos.

Esta transición no se ha dado de manera planificada y preparada, más bien fui realizando nuevas tareas y adquiriendo los conocimientos a medida que los necesitaba. Es claro que las habilidades y conocimientos requeridos para gestionar un proyecto no son los mismos que para diseñar un framework o implementar un elegante algoritmo.

Este cambio de responsabilidades, de técnicas a de gestión, es algo que se repite en muchos colegas. Por eso pienso en contar sobre algunos articulos, libros, experiencias que me han ayudado en esta transición, y que pienso pueden ser útiles a quienes estén es situación similar.

¿Con que puedo empezar? La gestión de proyectos es muy amplia y es eso algo que la hace muy interesante.
Creo que un buen punto de partida es comenzar a entender que puede salir mal en un proyecto. Cuando uno gestiona un proyecto hay aspectos a considerar que van más allá de los tópicos técnicos en los que uno podría enfocarse en un rol más técnico.
Cuando el enfoque técnico era lo central de mi trabajo, me preocupaba por la factibilidad de un diseño, en que sea mantenible, en la complejidad o en analizar el balance entre costo y valor de cada alternativa técnica.
Desde la perspectiva de gestión los frentes se multiplican. Steve McConnell escribe sobre esto en Rapid Development, donde lista los errores clásicos categorizados en personas, proceso, producto y tecnología. Un capitulo del libro está disponible en internet:

Classic Mistakes Enumerated
http://www.stevemcconnell.com/rdenum.htm

Es una lista exhaustiva y muy útil.

Como ven en el título, esta es la primera entrega de una serie de artículos relacionados a este cambio de perspectiva. Más artículos en breve.

Libro sobre Inspecciones de Código

SmartBeart, una empresa que desarrolla productos para realizar inspecciones de código, publica en su sitio capítulos de un libro sobre inspecciones. En el libro obviamente existen contenidos asociados a los beneficios de sus herramientas pero no por esto deja de tener algunos puntos interesantes.
Por ejemplo, se presentan algunos estudios sobre inspecciones de código donde se intenta demostrar que las reuniones para concretar las inspecciones de código son innecesarias y hasta perjudiciales para la relación costo/beneficio de la práctica.

"Las inspecciones no necesitan ser en persona

Para el lector sensible acostumbrado a inspecciones formales institucionales descendientes de la herencia de Fagan, Gilb, y Wiegers, esta afirmación es herejía. Tradicionalemente la reunión de inspección en persona dirigida por un moderador es considerada el eje de un proceso exitoso. La sinergia que surge de una reunión dirigida apropiadamente produce resultados que no pueden ser obtenidos por ningún inspector individualmente, aún con entrenamiento.
En los últimos 15 años ese efecto ha sido cuestionado en muchos estudios y desde muchas perspectivas. Multiples conclusiones sobre este punto son claras desde todos los estudios en este trabajo y en muchos otros."

Best Kept Secrets of Peer Code Review de Jason Cohen

Planificación Detallada Atractiva e Inservible

Hace ya bastante tiempo que trabajo liderando proyectos de desarrollo de software, no desde una perspectiva técnica como en el pasado. Esa es la razón por la cual el contenido de este sitio girara en torno a temas como planificación, estimaciones, pero manteniendo mi interés en la importancia de las personas en nuestra actividad.

En esta ocasión la motivación de estas lineas se relaciona con situaciones que se repiten al querer planificar y realizar el seguimiento de proyectos medianamente complejos.
Considerando que estoy en el medio de mi preparación para el examen de certificación PMP y trabajando en una organización CMMI nivel 5 es difícil evitar algunas prácticas, como la planificación detallada y el uso de herramientas como los diagramas de Gantt.

En esencia, existe una idea generalizada que la manera correcta de planificar un proyecto es identificar paquetes de trabajo, identificar actividades, identificar las dependencias entre las actividades, estimar las actividades y armar una planificación detallada donde el camino crítico se verá nítido y radiante como el sol de una mañana despejada.

Completando estos pasos, periódicamente se puede revisar el avance en cada actividad y ver si existen retrasos o no, medir el impacto de retrasos en dependencias externas y conocer las fechas de fin. Es algo que todos esperan ver, mis gerentes, mis clientes, mis compañeros. No planificar así en mi empresa es como ir con un guardapolvo rosado el primer día de clases en una escuela nueva.

Es por eso que trabajo para que mis planes se vean bien: para evitar la condena social... bueno, y por otras razones. El punto es que con dedicación y empeño logró que la planificación de mis proyectos luzca así:

Actividad A. 3 días. Pepe
Actividad B. 1 día. Paco
Actividad C. 2 días. Paco

con una precendencia

A -> C
B ->

El plan es prolijo y ordenado, la vida es bella, mis compañeritos me van a aceptar...

Pero cuando me tengo que sentar a ver el avance, mi plan se desmorona. La realidad es que al primer día se ejecutan 3 actividades en paralelo, como una dependencia externa no se cumple se decide reasignar gente a una tarea B', se crea una nueva actividad para investigar formas de resolver los problemas que surgieron (actividad D), alguien decide partir su actividad en dos (actividad A1 y A2) y la tarea B ya no tiene sentido.

Esto me intranquiliza, mi plan está desordenado e inservible. En estos casos me siento y actualizo nuevamente las actividades, dependencias, asignaciones y estimaciones en mi sofisticada herramienta de gestión de proyectos. No es algo sencillo pero después de un poco de trabajo, mi diagrama de Gantt luce muy bien nuevamente. No puedo evitar que una sonrisa se me escape en ese momento. Me gustaría imprimirlo en colores y pegarlo en mi box. Pero lo triste es que lo mismo vuelve a suceder.

Con la investigación de la actividad D se descubrió una forma de hacer todo de manera más sencilla pero todas las actividades anteriores no sirven, además hay que sumar una persona adicional que necesita dos semanas de entrenamiento y Paco se enfermo un par de días por lo que hay que quitar un requerimiento del alcance predefinido.

Entonces actualizo la planificación otra vez... y una vez más. Pero cuando lo mismo se repite por cuarta vez, un destello de lucidez cruza mi cabeza como un rayo encantado:
"¿No estaré haciendo algo mal? ¿No será que esta planificación no sirve?"

Pienso que es momento de sacar de la biblioteca algunos libros y refrescar algunos conceptos: Scrum, Agile Project Management, burn-down charts, planificación en extreme programming, lean development.

¿De qué manera se puede cambiar la manera de gestionar proyectos en una organización algo "rígida" como la mía? Bueno, definitivamente no tengo la respuesta a esa pregunta, pero buscarla puede ser entretenido.

Entrega vs. Conformidad

"Demasiados administradores de proyectos, demasiados miembros de oficinas de proyectos, demasiadas organizaciones han derivado hacia la conformidad como su, si a veces implícito, foco primario. Las actividades para la conformidad, a lo sumo, intentan mitigar el riesgo de errores, fraude, desempeño pobre, y excesos financieros. Los managers quieren reportes. Los contadores quieren números. Los auditores quieren firmas de aprobación. Las agencias gubernamentales quieren documentos. Los grupos de estándares (ISO, SEI y otros) quieren pruebas de conformidad. Los departamentos de Legales quieren todo. Fallar en diferenciar entre entrega y conformidad resulta en un trabajo de conformidad cada vez mayor - produciendo documentos para reguladores, abogados y management - mientras completar productos cae a una segunda prioridad"

"Prueba la siguiente encuesta en tu organización, pero prepárate para una sorpresa. Pregunta a todo el personal o los miembros de tu equipo de proyecto, incluyendo managers, cuánto tiempo emplean ellos haciendo tareas de desarrollo o ingeniería - cuánto tiempo emplean ellos generando valor para cliente? Cuantas de sus iniciativas de "mejora" (CMM, ISO, Six Sigma, TQM, BPR) sólo han agregado capa tras capa de formularios, procedimientos, reuniones, y aprobaciones a equipos tratando desesperadamente de producir algo útil?"

Agile Project Management de Jim Highsmith

Idea valiosa 3: Contar, Computar, Juzgar

Por lo general, los libros de Steve McConnell valen cada peso (o dólar) invertido. Software Estimation: Demystifying the Black Art no es la excepción. Si tienes la posibilidad de comprarlo, no lo dudes.

Esta idea valiosa sale de este libro y está relacionada a las estimaciones.

Permitanme tomarme la libertad de sacarlos del ámbito del software violentamente para ilustrar la idea. Cualquier argentino no vegetariano ha participado de un promedio de un asado por mes de vida aproximadamente. Organizar el asado requiere que alguien haga las compras, alguien encienda el fuego, etc. Aunque esto parezca difícil de creer para el grupo de personas que siempre llega al asado cuando todo está listo, todos estos detalles organizativos mundanos no los traen los Reyes Magos o un hada madrina, hay gente que lo hace. Pongámonos en la situación de quien hace las compras.

- Mmm, ¿cuánta carne tendré que comprar para que no sobre mucho y no falte? - se pregunta, cuidadoso del dinero ajeno. - 10 kilos es mucho y uno muy poco. Mmm, supongo que 5 kilos más o menos, aunque parece mucho. Nunca fui a un asado con tanta carne. Mejor 4 kilos que no parece tanto. Si, voy a comprar 4 kilos.

¿Es esta la mejor manera de estimar cuanta carne hace falta para el asado? ¿Cuál es el detalle que está faltando en este cálculo? ¡Por supuesto! ¡La cantidad de personas! Nunca se puede saber si la carne es mucha o poca si no sabemos cuantas personas van a comer.

Esto es realmente intuitivo para la gente de estas tierras con abundancia de vacas, y no hace falta certificación del PMI para que alguien lo haga. Puedo estar seguro que uno le pregunta a 10 personas en la calle, doctores, taxistas, albañiles, profesores de educación física, cañillitas, “¿Cuanta carne compro para el asado?” y todos responderán con el teorema cárnico elemental: “Papá, calculale medio kilo de carne por pera”.

Eso es contar, y es algo fundamental para estimar. Por alguna razón no resulta tan intuitivo a la hora de estimar cuestiones relacionadas al software. Muchos tenemos la tendencia a saltar este paso esencial, queremos comprar la carne para el asado sin saber cuanta gente va.

¿Pero qué podemos contar cuando estimamos software? Considerando que “el definidor más importante en una estimación de software es el tamaño del software siendo construido porque hay más variación en el tamaño que en cualquier otro factor.”, la respuesta a la pregunta es “encuentra algo para contar que esté fuertemente relacionado al tamaño del software que estás estimando”. Casos de uso, ventanas, clases, páginas web, puntos de función, entre otros.

Bien, ya contamos. ¿Cómo sigue la historia? Para el asado es simple, multiplico la cantidad de personas por 0.5 y obtengo la cantidad de kilogramos de carne a comprar. Cambiemos de plato para hacerlo más entretenido, quiero hacer arroz para 80 personas. ¿Cuanto arroz compro? ¡Aja!, aquí es donde tenemos que computar, para convertir la cuenta (80 personas) en estimaciones (kilos de arroz). Para ello hay que saber cuanto arroz puede comer una persona. Yo no lo sé, ¿250 gramos tal vez?

Entran en escena entonces, los datos históricos. El medio kilo de carne que se calcula por persona para un asado es un dato histórico que he podido confirmar personalmente. En el caso del software los datos históricos nos dirán, por ejemplo, que cada ventana requiere aproximadamente 300 líneas de código Java. Entonces necesitaremos otro dato histórico que nos indique el esfuerzo requerido para escribir esas líneas es de, por ejemplo, 1 staff/month para una empresa muy madura y posiblemente bastante menos para una empresa de software “artesanal”. (Desconozco otros ámbitos donde las fábricas tarden mucho más que los artesanos en completar un producto).

¿Y que pasó con juzgar? Este es el último recurso. Si tenemos que preparar sushi para 200 personas y no tenemos idea de cuanto pescado comprar, bueno, el consejo de un primo que tiene un amigo con parientes japoneses que nos dice que el pescado crudo es más llenador que el pollo puede ser útil para estimar, pero...

En definitiva para estimar hay que contar, computar y como último recurso juzgar.

Sweet and simple.

Procesos útiles

El tema de hoy tiene que ver con procesos de desarrollo de software.
En Agile Software Development, Alistair Cockburn comenta que uno de los criterios que él utiliza para considerar exitosa la aplicación de una metodología en un proyecto es que las personas del proyecto piensen que trabajarían de la misma manera otra vez. Por otro lado, Scott Berkun en The Art of Project Management lista los atributos de buenos procesos, aquellos que benefician la ejecución de un proyecto e incluye el siguiente:

“Las personas impactadas por los procesos están a favor de ellos. A las personas les gustan los procesos útiles. Un buen proceso sera visto como algo deseable por aquellos que lo necesitan. Si se está proponiendo un nuevo proceso que impacta a testers y programadores, y el proceso es valioso para el proyecto, no debería ser muy difícil convencerlos de probarlo.”

Mi experiencia en proyectos utilizando procesos definidos no cumplen esos criterios en general.
Quiero decir que las personas no trabajarían de la misma manera si pudieran elegir y en gran parte no estaban a favor de los procesos al momento de aplicarlos. Déjenme plantearlo de manera más personal: hoy estoy trabajando de una manera que en esencia no volvería a utilizar si pudiera elegir y, en muchas ocasiones, no estoy a favor de los procesos que debo aplicar.

Detallando un poco más, me refiero a procesos que no agregan valor, a la generación de documentación que nadie lee, a la producción indiscriminada de evidencia con poco sentido practico, a los pasos que pretenden brindar seguridad sobre los resultados y mas bien obstaculizan su concreción. Mi sensación es que mi experiencia no es aislada, parece ser más la regla que la excepción. Si esto es así, ¿qué es lo que está mal entonces?

Cuando se usan procesos definidos en una empresa, existen personas que se encargan de definirlo. Calidad, Proceso, Organización y Métodos son nombres usualmente asignados a este tipo de grupos. Es raro que estas personas dediquen su tiempo a crear procesos para torturar al resto de la gente. Todos apreciamos el respeto de nuestros compañeros y poseemos un sentido de logro. Por más incómodo, incoherente o inadecuado que parezca un proceso, alguien en algún momento lo creo con objetivos valorables y con buenas intenciones.

Mi impresión es que una de las razones de estos males es que la ejecución de los proyectos de creación de procesos adolecen de muchos de los problemas de los proyectos de software mal gestionados. Se define una fecha de fin para la definición del proceso, posiblemente atada a una auditoria o assesment que permita una certificación o evaluación de una norma de calidad. A las personas encargadas de llevarlo adelante les encantaría poder charlar con las personas que ejecutan proyectos para relevar necesidades, estudiar distintas herramientas o técnicas para incluir en el proceso, investigar practicas aplicadas en otros lugares, elaborar propuestas para ver como será este nuevo proceso.

Pero sucede que las personas que debían hacer todo este trabajo tienen otras asignaciones, las personas de los proyectos no tienen tiempo para discutir sobre estos temas y la fecha de entrega se acerca. Así los planes para hacer procesos útiles, valiosos y prácticos se diluyen, y se ve reemplazados por un esfuerzo para generar documentos para tapar huecos en el proceso que puedan afectar los resultados de la auditoria o assesment.

Es como esa pequeña funcionalidad implementada contra reloj que requiere que el usuario haga 3 clics adicionales en una lugar completamente inesperado, y que internamente requirió agregar el metodo CalcularInteres en la clase ConexionBaseDatos y la declaración de tres variables globales. Uno siente que un cosquilleo recorre la espina dorsal cada vez que piensa en como soluciono el problema pero es lo que se podía hacer con el tiempo disponible.

De todas maneras siempre hay tiempo para mejorar. Mientras esas mejoras llegan, uno debe lidiar con una realidad algo frustrante, muchas veces llamada madurez.