archivo

Archivo de la etiqueta: Donald Norman

Me parece muy interesante la siguiente reflexión de Donald Norman: “Cuando las cosas simples necesitan instrucciones, es una señal segura de un diseño pobre”.

Los usuarios y los desarrolladores somos expertos en complicar los sistemas de información, en lugar de centrarnos en lo que realmente resulta relevante se invierte un gran esfuerzo en funcionalidades complejas que no son necesarias (y que en muchos casos tienen una utilidad discutible en términos de coste/beneficio) o en ir complicando progresivamente funcionalidades que ya resuelven de manera solvente una problemática.

En lugar de pensar dos veces la solución o iterar desde lo simple para ir adaptando la idea a un resultado interesante se tiende a tomar decisiones que no solo dan lugar a una solución complicada sino que generalmente llevan consigo una deuda técnica que hace costoso hacer reajustes.

A posteriori se ve más fácil en qué aspectos del diseño y desarrollo del sistema nos hemos equivocado tanto usuarios como desarrolladores pero tenemos herramientas para tratar de darnos cuenta de que se han tomado decisiones erróneas en el propio proceso de especificación de las funcionalidades o historias de usuario o en la propia evolución del producto, para ello se debe tender hacia un enfoque iterativo incremental en el que mediante retrospectivas y análisis de los productos resultantes vayamos haciendo las adaptaciones oportunas para que el resultado que se va obteniendo se aproxime cada vez más a las expectativas.

Para Donald Norman: “Los objetos bien diseñados son fáciles de interpretar y de comprender ya que contienen pistas visibles de su funcionamiento”.

Un código fácil de leer y de entender en entornos altamente colaborativos como son los equipos de trabajo ágiles resulta esencial. También lo es para otros tipos de enfoques.

No es sencillo, se requiere tiempo, conocimientos y experiencia, también nos podemos apoyar con herramientas que nos ayuden a aplicar buenas prácticas y también se requiere ser sistemático y creer en los beneficios que aporta hacer el trabajo de esta manera, de lo contrario se te pondrá muy en cuesta arriba refactorizar, tanto tanto, que no lo harás.

Hacer esto bien requiere dedicarle el tiempo que necesita, cuando estamos en proyectos ligados a plazos y los recursos disponibles son muy limitados, se convierte en objetivo ejecutar todo el trabajo posible y se deja de lado la calidad del código ya que en esos momentos conceptos como la deuda técnica no se encuentran entre las prioridades del desarrollador. Es cierto que es contraproducente ya que una deuda técnica elevada hace más pesado el proceso de desarrollo pero cuando el fuego te está llegando a los pies solo piensas en correr.

Por ese motivo creo mucho más en el valor del software que en las agendas, un buen software requiere del tiempo y de las personas necesarias para hacerlo, sin equilibrio la calidad del software sufre (también la cuenta de resultados del proyecto).

Uno de los problemas que nos podemos encontrar con frecuencia en un proyecto de desarrollo de software lo tenemos cuando el desarrollador piensa que sabe tanto del negocio como los usuarios y se olvida de que el producto no es para él sino para los usuarios.

Que un desarrollador conozca el negocio muy bien es algo muy interesante para el proyecto siempre y cuando no se caiga en el error de empezar a tomar decisiones sobre lo que le gustaría a él que hiciera el producto sin contar con la aprobación del usuario.

Siempre hay que contar con los usuarios. Un producto desarrollado a sus espaldas difícilmente se ajustará a sus necesidades reales. Generalmente cuando esto sucede es por culpa del área usuaria que se niega a dedicar al proyecto los recursos que son necesarios, dejando todo el peso a los desarrolladores. Esta situación es necesario revertirla cuanto antes y en caso contrario intentar cerrar el proyecto con el menor daño posible entre las partes, si bien, no siempre será posible una cosa o la otra porque el nivel de toma de decisiones al respecto se situará en otra escala de la organización que tendrán sus propias políticas y criterios.

Si contamos con la ayuda y dedicación del usuario y sin embargo tomamos decisiones funcionales por él, estamos cometiendo un grave error.

Al respecto me parece interesante la siguiente reflexión de Donald Norman: “Los diseñadores no son usuarios típicos. Llegan a ser tan expertos en el uso de los objetos que se han diseñado que no pueden creer que alguien más pueda tener problemas. Sólo la interacción y pruebas con usuarios reales en todo el proceso de diseño puede evitar eso”.

Llegado un punto resulta más costoso seguir mejorando un sistema de información que los beneficios que realmente produce esa mejora.

Si el producto está consolidado los cambios serán cada vez más complejos (rizar el rizo) y responderán generalmente más a caprichos que a necesidades reales. No se trata de oponerse a la evolución sino de entender cuándo produce beneficios y cuando no.

Cuanto más grande sea el producto más complejo será mantenerlo, probablemente mayor será su deuda técnica y más complicado será para el usuario (y eso es un problema).

Cuanto más cambios hagamos más posibilidad hay de que introduzcamos errores graves en la aplicación, los cuales pueden tener un efecto bola de nieve en el sistema porque si la aplicación ha tenido éxito y tiene un amplio grado de implantación se requerirá una rápida solución y todos sabemos qué pasa cuando se va demasiado deprisa: posiblemente no se corrigen todos los errores, se introducen otros y el código no tiene toda la calidad que debería.

Desde el punto de vista del usuario nunca vas a encontrar la perfección en un software, cuando creas que al usuario no se va a ocurrir nada nuevo le surgirá una nueva idea y cuando realmente se quede sin ideas aparecerá otro con un listado sin fin (cada persona tiene percepciones y necesidades distintas).

Tampoco la vas a encontrar desde el punto de vista del desarrollador, siempre tendremos la oportunidad de mejorar el código o la arquitectura, de automatizar nuevos tests, de abstraer funcionalidades, de modificar el comportamiento de una funcionalidad o de hacer nuevas propuestas.

Donald Norman realizó una reflexión que viene a refrendar lo que comento en el artículo: “Una vez que se ha alcanzado un producto satisfactorio, realizar más cambios puede ser contraproducente, especialmente si el producto tiene éxito. Tienes que saber cuándo parar”.