Blog

La escena es siempre la misma. El equipo entrega, el usuario prueba, y dice que así no era. Uno saca el documento donde decía que el sistema debía ser "rápido y fácil de usar", y ahí se acabó la discusión técnica y empezó la discusión de percepciones. Que es una discusión que no se gana nunca. Y lo peor es que las dos partes tienen razón. El equipo entregó lo que entendió. El usuario esperaba lo que él entendió. La palabra "rápido" les dio permiso a ambos.

El PMI hizo algo interesante en la 8va edición del PMBOK ya que subió la “calidad” a la categoría de “principio”, incorporándola en los procesos y entregables, especificando que NO es una etapa al final, sino que es una condición que se define desde el inicio. Y la manera concreta de incorporarla es definiendo y escribiendo criterios que alguien más pueda verificar sin necesidad de opinar.

Te comparto tres ideas para que la calidad se convierta en uno de tus principios cuando este liderando un proyecto:
1.- Un criterio verificable se puede probar y da el mismo resultado sin importar quién lo pruebe. Esa es toda la prueba de fuego. "El sistema debe ser rápido" no pasa. "La consulta de saldo debe responder en menos de dos segundos con quinientos usuarios simultáneos" sí pasa, porque dos personas distintas corriendo esa prueba llegan al mismo veredicto. Lo mismo con "amigable": lo que se puede medir es que un usuario nuevo, sin capacitación previa, complete el registro en menos de tres minutos. Ahí ya no hay opinión, hay un cronómetro.
2.- Los adjetivos no son el enemigo, son el punto de partida. Cuidado con que asumas que hay que prohibir que el cliente diga "quiero algo robusto". El cliente y/o usuario tiene todo el derecho de expresarse así, porque está describiendo una expectativa real. El trabajo del gerente de proyecto es traducirla. Cuando alguien dice robusto, tu debes preguntar ¿robusto significa que soporta cuántas transacciones por hora?, ¿que se recupera de una caída en cuánto tiempo?, ¿que funciona, aunque se caiga el enlace principal? Esas respuestas son el criterio. El adjetivo era solo la puerta de entrada.
3.- Y si nadie sabe cómo se prueba, entonces el criterio no está terminado. Un criterio de aceptación tiene tres partes: qué se mide, cuál es el umbral, y cómo se demuestra. Esta tercera parte es la que casi siempre falta y es la que causa los problemas. Porque a veces el criterio está perfectamente escrito y, aun así, cuando llega el momento, nadie preparó el ambiente, nadie construyó los datos de prueba y/o nadie exploró quien debía ser la persona autorizada para certificar la prueba. Definir el método de verificación al mismo tiempo que el criterio evita esa sorpresa.

Un detalle quienes trabajan con proveedores: los criterios de aceptación son la base del pago. Si el contrato dice que se paga contra aceptación y la aceptación depende de un adjetivo, acabas de crear una disputa comercial con fecha diferida. En cambio, un criterio medible protege a ambas partes. A ti porque le garantiza lo que pediste y al proveedor porque le define exactamente dónde termina su obligación.

Reto de hoy: Abre el documento de requisitos de tu proyecto y subraya cada adjetivo que encuentres. Rápido, intuitivo, seguro, confiable, flexible. Toma los tres más importantes y conviértelos en una frase con número y método de prueba. Esos tres van a ser, casi seguro, los tres que te iban a dar problemas en la aceptación.

Nadie discute un número. Todos discuten un adjetivo. Y esa discusión siempre llega cuando ya se gastó el presupuesto.

¡Hasta que sea asombroso! 🚀❤️
PMI Capítulo Panamá. Vicepresidencia de Educación y Desarrollo Profesional