Es mucho más acusado en empresas de consultoría o servicios de informática que en departamentos internos de las empresas, puesto que en las primeras generalmente todo va contra un presupuesto y se exige, antes o después, una rentabilidad a los proyectos.

Se trata de un viaje de ida y vuelta, al que he llamado El Método Nadal.

¿Qué es exactamente El Método Nadal (EMN)?

Se trata de hacer que la pelota esté el mayor tiempo posible en el campo contrario, y que nuestro usuario-cliente deba realizar un esfuerzo en el proyecto igual o mayor que nosotros para garantizar el éxito.

¿Cómo se logra desplegar EMN?

Es sencillo. Cuando somos nosotros, ya sea en el papel de analistas, programadores, jefes de proyecto, etc los que tenemos la pelota en nuestro tejado, somos vulnerables a la presión por realizar las entregas a tiempo o por cumplir unas espectativas que no siempre están claras. Sin embargo, si un hito, una validación o concertar una reunión no dependen de nuestro trabajo, sino de que el usuario-cliente tome la iniciativa, entonces ganamos un tiempo valioso para poder tomar las acciones oportunas que beneficien tanto a la organización como al proyecto.

Si nos fijamos en la forma de jugar de Rafa Nadal, veremos que nunca da un tanto por perdido, pero la consecuencia más importante de ello es que siempre obliga a su compañero de partido a hacer un esfuerzo adicional para intentar pasar la pelota al otro lado de la red.

Aplicando esto a la gestión de proyectos, veremos que tenemos oportunidades de hacer participar e incluso responsabilizar a nuestros clientes de posibles retrasos en proyectos, indefiniciones, etc, con un doble objetivo: por un lado tratar de crearnos un marco seguro para el caso de que haya problemas y, por otro y mucho más importante, involucrar a todos los interesados con el fin de lograr el éxito de los proyectos.

Cuando un cliente solicita un proyecto y apenas recibe información del mismo, muchas veces se desentiende y eso afecta de manera directa a su percepción de calidad y a su grado de satisfacción.

Es nuestra obligación hacerle partícipe del proyecto, lanzándole tareas, hitos, etc, que deba realizar también y con los cuales sienta que es también responsable del resultado final.

Cuando hablamos de proyectos informáticos, son varias las propiedades que esperamos de ellos, como son: ausencia de incidencias, código fuente con comentarios, eficiencia en los procesos, velocidad de respuesta adecuada, usabilidad, estilos gráficos trabajados, etc. Cada uno damos más importancia a una u otra característica, pero buscamos todas ellas puesto que somos conscientes de que, si existen, las probabilidades de lograr un proyecto con éxito son mayores.

Sin embargo, son muchos los obstáculos a los que tenemos que enfrentarnos en el día a día del proyecto, y que provocan retrasos, errores, etc: falta de experiencia, plazos demasiado ajustados, baja productividad, requisitos imposibles… y un sinfín de problemas que todos conocemos.

¿Qué hacer entonces? ¿Nos rendimos y asumimos que es imposible obtener productos con la calidad suficiente? ¿Cambiamos de actividad? ¿Quemamos los ordenadores y volvemos a hacer muchas cosas manualmente?

Está claro que la respuesta a todas esas cuestiones debe ser negativa.

En mi opinión, hay dos factores que influyen notablemente en todos los problemas de calidad de los proyectos:

1. El factor humano: en el sector tecnológico, especialmente en la parte de desarrollo, es un factor fundamental puesto que muchas de las tareas dependen del conocimiento, de la motivación e incluso de la inspiración de quien las realiza.

Existe una radical diferencia entre poner un tornillo de un coche o desarrollar una pantalla para realizar una integración con algún sistema de producción. En la primera de las tareas apenas tiene influencia la motivación o la inspiración o la formación, pero en la segunda pueden marcar una clara diferencia entre el éxito y el fracaso.

2. El factor cultural: el ámbito tecnológico que nos rodea es relativamente joven, y más si tenemos en cuenta que fue realmente a finales de los 90 cuando hubo un verdadero boom con la expansión de internet, la compra masiva de ordenadores, y un auténtico desarrollo de tecnologías móviles.

Esta juventud implica, necesariamente, que ni nuestros clientes tienen asumido qué significa realizar un proyecto informático, ni nosotros tenemos unos procesos lo suficientemente alejados del trabajo artesanal.

Si comparamos nuestro sector con uno ya asentado y maduro (algunos dirán que demasiado maduro) como es el del automóvil, las diferencias son claras:

- cuando uno compra un coche, asume ciertas limitaciones, y que los añadidos son los que aparecen en el catálogo. Si deseas cosas extraordinarias, tendrás que “tunearlo” y pagar un alto precio por ello. Sin embargo, en un proyecto informático el cliente tiende a pensar que hay barra libre para hacer cambios y que apenas tienen coste.

- en la industria del automóvil existen robots que hacen multitud de trabajos de manera exacta y programada. Lo más parecido que tenemos en el mundo tecnológico son herramientas automáticas que nos permiten simplificar parte de las tareas: generación de código, pruebas, test de cargas… pero tienen muy poca implantación y son reinventadas una y otra vez.

- las pruebas de calidad que se realizan sobre los automóviles son intensivas y se invierte mucho dinero en seguridad y en confort. En cambio, en muchos de los proyectos informáticos, las pruebas se realizan si se puede, la palabra seguridad apenas se oye, y temas como usabilidad o accesibilidad pertenecen a esa extraña lista de deseos que se suelen pedir por Navidad.

Obviamente, hay muchas más diferencias, pero creo que éstas son las más significativas.

Necesitamos ganarnos la confianza de nuestros clientes/usuarios, y tenemos que lograr procesos cada vez más industriales. No debe ser admisible que construir un sistema informático sea más parecido a elaborar una cuchara de madera por el artesano del pueblo que un automóvil en una fábrica.

Para lograr este objetivo se pueden tomar varias medidas, la mayor parte de ellas muy sencillas, que comentaré en un próximo artículo. Sin embargo, cualquier sugerencia, anécdota y aportación será bien recibida.

¿Cuál es el problema general de todas ellas? Muy simple, hay que mantenerlas actualizadas, de manera habitual y no sólo cuando se realiza una revisión o una auditoría o cuando nos acordamos.

Este hecho, tan simple, es el culpable de que a menudo no se conozca el estado general de un proyecto, o que la idea que tenemos del mismo sea vaga e inexacta. Consecuentemente, en un momento u otro aparecen los retrasos, las desviaciones en costes, y los problemas.

Personalmente soy fiel a dos herramientas: una buena hoja Excel, y una herramienta simple para tener catalogadas las tareas, las mejoras y las incidencias.

Las hojas Excel de gestión que yo manejo contienen numerosos datos, y son el cuadro de mando general del proyecto.  A modo de ejemplo, suelo mantener una pestaña para: listado de módulos y estado de avance para cada uno de ellos; listado de personas involucradas en el proyecto, especialmente los analistas, los programadores y los “stakeholders”, así como el posible organigrama; listado de hitos del proyecto, crucial para un control efectivo de las desviaciones; funcionalidades previstas por entrega, en el caso de que haya diferentes versiones del proyecto; y evolución de diversos indicadores como son: grado de cumplimiento de hitos, número de incidencias/tareas/mejoras por versión o mes o cualquier otro periodo.

Obviamente, a esta lista se le puede añadir cualquier otra información que se considere interesante, y es sólo una base sobre la que ir montando un sistema de control más avanzado. Cualquiera puede intentar extrapolar esta idea a los posibles proyectos de los que es responsable para saber qué datos adicionales deberían reflejar.

Por otra parte, la mayor parte de los datos que se reflejan en el documento general de gestión deben extraerse de alguna fuente de información actualizada. Hay que buscar dos cualidades: simplicidad y completitud.

La herramienta que nos sirva para tener controladas las tareas/mejoras/incidencias (en adelante tareas, de manera general) debe ser, ante todo, simple de usar. El principal objetivo de la gente involucrada en un proyecto debe ser realizar las tareas que le han sido asignadas, y no rellenar datos burocráticos. Considero que cuando una persona emplea más de un 2% de su tiempo en actualizar el estado de sus tareas (1 hora a la semana aproximadamente) entonces es dinero que se está perdiendo.

Hay numerosas opciones en el mercado, tanto gratuitas como de pago. No voy a recomendar ninguna en concreto, pero he usado Mantis, JIRA, Project, Bugzilla… en cualquiera de ellas es posible catalogar las diferentes tareas, conocer su grado de avance, el número de horas empleadas, e incluso agruparlas por versión. La mayor parte son sencillas de utilizar pero los informes suelen ser tediosos y no siempre dan la información que se requieren.

¿Cómo solucionarlo? Fácil: Excel. Si permiten exportar a Excel los datos en bruto, extraer informes a medida suele ser relativamente sencillo, y si se conecta con otras fuentes de datos, toda la información está en nuestra mano.

Al final, el objetivo de toda herramienta que se utilice es muy sencillo: saber en qué estado se encuentra el proyecto, empleando el menor tiempo posible en esta tarea.

Por ahora, y tras haber probado numerosas opciones, estas son las que he considerado más útiles. Sin embargo, como en cualquier aspecto de la vida, es importante seguir mejorando y aprendiendo.

¿Qué herramientas utilizáis vosotros? ¿Hay alguna que sería necesario añadir a la lista?