Blog

Atrás

Mejora de la productividad o Mejora de procesos de desarrollo ¿quién guía a quién?

Escrito por José Antonio Ortega, Director de Soluciones para la Gestión de Aplicaciones de Tecnocom.

A propósito de la última entrada que he puesto sobre Mejora de la productividad, una persona realizó un comentario en el Grupo de Linkdin de “Calidad en el software y en los sistemas de información”.

Javier Garzás comentó: ” También sería comentable y pieza clave el mejorar el proceso de construcción software (que como resultado puede tener los efectos que comentas). Si logramos un mejor método - proceso que además de reducir futuros problemas y costes de mantenimiento permite hacer el doble de trabajo con el mismo esfuerzo, la productividad queda clara”.

He querido mencionar el comentario de Javier Garzás, ya que hace hincapié en un punto fundamental, y es que en la mejora del proceso de desarrollo de software está el origen de los problemas y de los mayores quebraderos de cabeza. Las actividades de mejora de la productividad, tal y como mencionaba en mi entrada, tendrán sentido siempre y cuando estén guiadas por una estrategia de mejora del proceso de desarrollo. Me explicaré.

En mi labor profesional trabajo de lleno en el mundo del Outsourcing de desarrollo de software (nosotros le llamamos Application Management), y estos últimos años hemos tenido la gran fortuna de trabajar conjuntamente con grandes clientes en reforzar los procesos de desarrollo de los contratos de Outsourcing. Esto unido a la estrategia que tenemos en CMMi, que para nosotros es una herramienta fundamental, y nos sirve de hoja de ruta para la mejora del proceso de desarrollo.

Esta experiencia nos ha llevado, a que cuando una organización nos pide ayuda para iniciar algún proceso de transformación, por ejemplo, cómo cambiar el modelo de Outsourcing de Time&Material a un modelo gestionado, cómo hacer efectivo el uso de una factoría de software etc… siempre empezamos con un diagnóstico del proceso de desarrollo y evaluar el estado de madurez de sus procesos en la organización. Esto nos permite conocer la organización del cliente y nos da visibilidad sobre qué hay que hacer para lograr la transformación que el cliente nos pide. Es muy usual, por ejemplo, que una organización quiera comprar servicios de factoría de software y no está preparado para ello.
 

Estos diagnósticos son auténticas máquinas de dar sustos. Es como ir al médico para que te hagan algunas pruebas  como una radiografía o ecografía, y en el momento de ir a buscar el diagnóstico, vas con el alma en vilo, y de repente el médico te habla de enfermedades que no sospechabas tener. Incluso aquel dolor de cabeza, que solucionabas con aspirina, escondía un problema bastante mayor.Por lo tanto, está claro, basado en nuestra experiencia, cuando un cliente te pide ayuda para enfocar su modelo de transformación, primero empezamos por entender la madurez de sus procesos de desarrollo. Esto será un punto importante de partida para fijar siguientes pasos.
 
Recientemente, en uno de estos diagnósticos que ejecutamos en un cliente (que además estaba certificado CMMi2), vimos que el proceso de desarrollo que tenían definido era “papel mojado”. Nadie lo empleaba salvo contadas excepciones. Pensaban que con la certificación estaban por encima del bien y del mal, sin embargo reconocían que las cosas no les iban bien, y no sabían por qué. Eso sí, dedicaban un esfuerzo importante en medir los procesos que tenían. Con esas mediciones lograban disponer de un gran conjunto de indicadores, pero como sus procesos definidos no contemplaban todas las operaciones que realizaban, ni tampoco estaban realmente institucionalizados, la variabilidad en la ejecución de los mismos era muy alta, por lo tanto los indicadores no aportaban realmente visibilidad sobre cómo mejorar.
 

Recordando mi entrada anterior al blog, los análisis de indicadores para mejorar la productividad, empezarán a tener sentido si el proceso de desarrollo arroja indicadores que tengan una variabilidad controlada. Dicho de otra forma, si en mi organización se trabaja en modo “cada maestrillo con su librillo” la variabilidad de mi proceso será muy alta.

En el ejemplo que he puesto ¿por dónde tenían que empezar?

  • Asegurarse de disponer de procesos que diesen respuesta a todas las casuísticas operativas. Por ejemplo un error muy común, es utilizar los mismos ciclos de vida para un proyecto de 1000 horas que para una actividad de mantenimiento de 40h. Esto que parece una obviedad es un error muy común. Otro ejemplo de error frecuente: no es lo mismo gestionar un proyecto que gestionar una incidencia, tendremos que tener definido qué se hace en cada caso.
  • Al desarrollar un proceso sencillo y ajustado a las necesidades operativas y de negocio, hay que asegurarse de cómo se va a institucionalizar. Es decir, cómo lograr que en mi organización todo el mundo use el mismo proceso definido.

Agradezco el comentario de Javier Garzás. Pero aprovecho para agradecer el resto de comentarios.

Comentarios
URL de Trackback:

No hay ningún comentario aún. Sea usted el primero.