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.