Jose María González López
Project manager y Fundador de Habilis Software http://www.habilissoftware.com/
Continúa la serie de artículos que forman el decálogo para hundir proyectos no sin antes referenciar la 4ª parte del mismo:
Torpedo 6. Gestión de la calidad
"Nunca hay tiempo para hacer las cosas bien pero sí para hacerlas dos veces" Anónimo
Nota aclaratoria: Dado que acabamos de pasar por el ecuador del decálogo me gustaría recordar al lector que el objetivo real del decálogo no es otro que el de exponer las malas prácticas que se realizan en las tareas cotidianas de un proyecto y que simbolizan las causas más comunes de fracaso en los proyectos, con el ánimo de, mediante psicología inversa y algo de humor, tratar de paliar en lo posible dichos errores.
Y ahora sí, comencemos con un tema vital a la hora de hacer que un proyecto fracase: la gestión de la calidad. Es importantísimo destacar que una de las consecuencias más graves que una incorrecta gestión de la calidad puede tener, a largo plazo (quizás incluso a medio plazo) es la pérdida de la confianza del cliente, del cliente mismo y de sus futuras oportunidades de negocio. Pocas cosas influyen más en la percepción que se tiene sobre el trabajo de una empresa/personas (por lo menos en el área de las nuevas tecnologías) que la falta de calidad en sus productos o en su trabajo. Normalmente suele poder entenderse casi todos los problemas que pueden surgir a lo largo de un proyecto pero, la falta de calidad, es determinante a la hora de prescindir de los servicios de una empresa/personas.
Imaginemos que quiero comprar algo de ropa. Supongamos que me interesa un pantalón en específico por sus características, por su estilo, color, por su marca de una manzana mordida y porque me gusta ir a la moda. Suponiendo que es un producto exclusivo y que sólo lo tendría disponible en una tienda, estoy seguro que en la mayoría de los casos, todo el mundo podría llegar a pasar por alto que la tienda no disponga de stock, que tarden en reponerlo y tenga que esperar varios días, que incluso tenga que hacer colas interminables, que me atiendan rápido y mal o que el pantalón me salga más caro de lo que pensaba si, cuando al fin lo compro y me lo pongo, me sienta como un guante, se nota que está bien manufacturado y quedo contento con la compra. ¿Cierto? Probablemente, y pese a los inconvenientes, continúe comprando ese tipo de productos en esa tienda.
Eso es lo que busca la calidad: satisfacer la necesidad del cliente y, cuando no lo hace, el cliente no suele perdonar.
¿Cómo llevamos esto a nuestro proyecto? ¿Cómo podemos conseguir no satisfacer las necesidades de nuestro cliente? La respuesta es bien simple: NO CONOCIENDOLAS DEMASIADO BIEN.
Eso sí, la auténtica profesionalidad (nunca me cansaré de decirlo) radica en que ese desconocimiento no se note y parezca fruto del azar o incluso culpa del cliente. Además, si al mismo tiempo que hundimos el proyecto conseguimos acabar con la reputación de nuestra empresa, entonces amigo, eres todo un lobo de mar.
Para poder ser un buen desconocedor de las necesidades de nuestro cliente es necesario, como primer paso, no tomarse demasiado en serio la captura y análisis de requisitos de nuestro proyecto, así como mantener un nivel mediocre de retroalimentación y comunicación con el cliente. Ignorar totalmente este tipo de información conlleva que no demos solución alguna a las necesidades funcionales que el cliente dispone para el proyecto y eso no nos interesa del todo. Es más práctico ser ineficiente en el desarrollo de las soluciones, mostrando indiferencia por los detalles, no profundizando en las necesidades y no contrastando los resultados.
La calidad no siempre se refiere al producto final y sus características, también podemos aplicarla al desempeño de nuestro equipo, al control del proyecto e incluso a los entregables intermedios del mismo. Teniendo en cuenta esto y teniendo en cuenta que no hay nada mejor que conocer e ignorar, es recomendable interesarse por las normativas de calidad que el cliente pueda tener como activo de su negocio para poder ignorarlas y no realizar un aseguramiento de las mismas en nuestro proyecto. Estos activos pueden ser tan sencillos como la obligación de mantener cierto orden, estructura o nomenclatura en los modelos lógicos (o desarrollos) o la realización de una documentación in-line progresiva. Podrían ser algo más elaboradas como por ejemplo la aplicación de estándares o la realización de refactorizaciones programadas para facilitar ciertos procesos de auditoría o pueden ser normas más complejas (incluso no escritas) que se refieran a rendimientos de trabajo, métricas específicas, requerimientos de cierre o procedimientos de seguridad.
En cualquier caso, el arma que todo Project manager tiene a su alcance y que te ayudará sin duda a gestionar pobremente la calidad en tu proyecto o producto son las suposiciones. Señores y señoras, cuando hablamos de la calidad (bueno, en realidad cuando hablamos de casi cualquier cosa) no hay nada mejor que suponer que lo estamos haciendo bien y que cumplimos para que aparezcan los problemas.
Hay que tener en mente que, en la mayoría de ocasiones, hay determinados factores de calidad que afectan directamente al momento clave de todo proyecto. Dichos factores debemos tenerlos bien identificados para gestionarlos adecuadamente y para que sean la carga explosiva de nuestro torpedo. Obviamente, el resultado de una mala gestión de la calidad se vuelve evidente para el cliente en las fases finales del proyecto/fase, es decir, en los procesos de validación de entregables, en los cambios de entornos o en los procesos de pruebas. Apuntar nuestro torpedo a esos momentos es garantía de hundimiento.
Nota: El autor del presente artículo no se responsabiliza del mal uso de la información aquí recogida ni del hecho científico probado de que, en determinados cerebros, la psicología inversa no funciona...