archivo

Archivos diarios: marzo 14, 2012

Decía Henry Ford que la calidad es “hacer las cosas bien, incluso cuando nadie mira”.

Steve Jobs sentía una especial admiración por Ford lo que unido a su sentido de que la calidad y la innovación son el principal argumento contra la competencia, hace que no resulte extraño que aplicase la calidad hasta el último detalle, hasta aquello que nadie ve.

Y no le fue nada mal aplicando esa idea.

Cuando se le presentó a Jobs la placa base del Macintosh, no le gustó la disposición de los chips de memoria, a lo que un componente del equipo le contestó que nadie iba a verla, que lo importante era que funcionara.

La respuesta de Jobs fue contundente “La voy a ver yo […] Nunca oirás a un buen carpintero, decir que utiliza madera mala en el fondo de un armario con el pretexto de que nadie la va a ver”.

Y por supuesto que se hizo lo que Jobs dijo.

Evidentemente no somos Apple, ni la actual ni la de 1981 y los límites los tenemos muchos más próximos de los que los tenía Jobs, sin embargo no es con eso con lo que debemos quedarnos sino con el mensaje.

El mensaje de querer hacer las cosas bien, que un producto es de calidad si todos sus componentes son de calidad, lo que se ve y lo que no se ve.

En el caso (utópico, me atrevería a decir) de que un software se entregue sin errores no quiere decir que satisfaga las expectativas del usuario. Esto, que es una obviedad, puesto en el contexto de un proyecto de desarrollo de software con mucho dinero por medio deja de serlo, sobre todo si se pierde de vista el objetivo del desarrollo de un sistema y solo se miden patrones meramente económicos.

Dos variables fundamentales para satisfacer las expectativas del usuario son la implementación adecuada de las funcionalidades que requiere del sistema y su experiencia de uso. Cuanto más nos alejemos de ellas, más lejos estaremos de cumplir sus expectativas.

Cuando esto sucede puede ser culpa del cliente (no ha especificado de manera adecuada lo que necesita, no ha priorizado correctamente las funcionalidades del sistema, etc…), del proveedor (no ha respetado las especificaciones del área usuaria, no las ha interpretado adecuadamente, no ha tenido en cuenta aspectos que inciden en una buena experiencia de usuario, etc…), de los dos o de ninguno (cambios contínuos del proceso que se informatiza o cambios significativos cuando se está acabando el presupuesto).

El profesos de ingeniería del software y experto en testing Cem Kaner, resume todo lo anterior en la siguiente cita: “Un programa que responde perfectamente a una especificación pésima es un programa pésimo”.