Cuando hablamos de calidad, el primer paso es el consenso. Es sencillo: todos los que calificamos un producto debemos tener los mismos criterios para medir la calidad. ¿Obvio? Tal vez sí… pero, ¿realmente tienes resuelto el tema cuando construyes productos digitales?
Pongo un caso hipotético como ejemplo. El Director de Operaciones reúne a su equipo para preguntar sobre algunos detalles del desarrollo web para su cliente:
- Del 1 al 5, donde 1 es Muy malo y 5 es Excelente trabajo… ¿Qué calificación le darían al sitio Web?
- ¡5 puntos! – contesta el Líder de Proyecto mientras todos balancean su cabeza de arriba abajo, apoyando la respuesta del líder.
- ¿Cuál es su criterio de evaluación? – pregunta el Director.
- ¡El cliente está contento con la página! nos ha felicitado porque hemos hecho la entrega en el tiempo acordado. Le ha gustado el diseño y considera que las funcionalidades del sitio dan una buena experiencia su consumidor.
Un cliente contento NO es sinónimo de una buena calidad de los productos, es cuestión de la percepción
La percepción de los clientes es parte de la evaluación ya que, una buena calificación, nos demuestra que hay alineación con sus objetivos. Sin embargo, en todos los casos de negocios, ¿el cliente está capacitado para calificar la calidad de los productos? En especial, cuando hablamos de plataformas de marketing digital, ¿el cliente tiene el conocimiento y las herramientas para calificar la calidad de un sitio web o una aplicación? Si ha contratado a alguien es porque no tiene ese conocimiento.
Regresemos a la conversación. Después de escuchar la respuesta del Líder de Proyecto, el Director pregunta al equipo
- ¿Ejecutaron pruebas de seguridad para los accesos a contenido restringido?
- Por temas de tiempos de entrega, decidimos postergar el análisis para más adelante. El cliente estuvo de acuerdo en asumir el riesgo. – contestó el Líder.
- ¿Cumple con los criterios de la Ley Federal de Protección de Datos Personales en Posesión de Particulares? – interroga nuevamente el Director.
- Para ahorrar tiempo, quitamos el sistema automático de actualización y baja de datos. Ahora el usuario debe enviar un correo al cliente para solicitar cambios. El cliente también estuvo de acuerdo con este punto. – contestó el programador responsable de la integración de bases de datos.
- ¿Cuándo el usuario se registra, recibe la confirmación de su registro por correo? – pregunta el Director.
- Sí, sin embargo, no incluimos los diseños y dejamos un envío en texto plano para poder ahorrar tiempos de entrega. El cliente aprobó esta medida también.
Lo que está pasando en esta situación es que el desarrollo tiene deficiencias en el funcionamiento. Al ser aprobadas por el cliente, el equipo considera que el proyecto tiene la calidad suficiente. Sin embargo, esta es una forma incorrecta de evaluar la calidad.
La forma adecuada es comparando contra los estándares y mejores prácticas de la industria, considerando estructura de lenguaje de programación, seguridad de la información, documentación completa, apego a temas regulatorios y un correcto desempeño de la interface.
¿Te sientes identificado con esta situación? Es muy común entre los equipos de desarrollo. Sólo recuerda: un cliente contento no es sinónimo de buena calidad.
Comparte esta historia con tu equipo de trabajo. Discutan el tema y revisen sus criterios de calidad. ¡Mucha suerte con el diálogo!
