Darcy

Siguiendo con el post anterior, les dejo aquí la segunda parte de la traducción del artículo escrito por Anthony Colfelt llamado Bringing User Centered Design to the Agile Environment que expone aspectos negativos y positivos acerca de integrar el diseño centrado en el usuario al desarrollo ágil, particularmente en Scrum.

“…
El campo minado

En sí mismas, las metodologías de desarrollo ágil hacen un buen trabajo en cuanto a su flexibilidad frente a los cambios. Pero es necesario preguntarse si ésta fue diseñada para tratar un gran síntoma de las organizaciones: la empresa no sabe lo que quiere. Aunque el equipo de desarrollo ágil podría hacer frente de mejor forma a esto, en otras ocasiones no se resuelve el problema y en la mayoría de los casos crea otros nuevos.

Mina 1: El papel del diseño es poco claro

Las empresas contratan a los desarrolladores para crear programas, sitios, aplicaciones o sistemas, algunos de los desarrolladores pueden tener habilidades de diseño, pero eso no es un escenario muy común. Muchos desarrolladores también han tenido malas experiencias con los diseñadores, por varias razones (no son apropiados, no conocen el negocio, etc).

Ha tomado tiempo lograr enfrentar el diseño (como profesión) y el diseño de sistemas complejos, pero todavía hay un déficit de conocimientos en este campo. Más complejo se torma el escenario cuando uno de los principios del desarrollo ágil dice que “la gente de negocios y los desarrolladores deben trabajar juntos diariamente a lo largo del proyecto”. Entonces ¿dónde encaja acá el diseñador?.

Mina 2: El proceso de recopilación de requisitos no se define

El desarrollo ágil acoge las actividades de diseño desde la perspectiva de un desarrollador, tiende a recibir las especificaciones desde el punto de vista del requirente (empresa o cliente que se supone que todo lo saben) y da por sentado que éstos son apropiados.

Según Ken Schwaber, SCRUM tiene la intención de ser una metodología de gestión integral y deja espacio para otras actividades (para que la programación se produzca en el marco de los ciclos iterativos).

Pero cuando las organizaciones adoptan SCRUM, con frecuencia desechan las buenas partes del desarrollo en cascada como la investigación y la formación de un plan de alto nivel para el diseño general, arrojando por la borda la documentación.

Como el Manifiesto del Desarrollo Ágil dice que el software es más importante que la documentación completa, muchos apelan a esto y no quieren hacer ningún tipo de documentación, algo que puede ser muy valioso para presentar un esbozo de la visión institucional, aunque sea en un sentido rudimentario.

Mina 3: La presión para cortar las esquinas

Las implementaciones de desarrollo ágil ubican las actividades de diseño dentro de las mismas iteraciones que el desarrollado, para garantizar o asegurar que el diseño se realice y se desarolle al momento de hacer el código. Esto también impone una enorme presión sobre el equipo de experiencia de usuario, el de “alimentar la máquina de desarrollo” en el tiempo suficiente para que se pueda poner en práctica su visión.

Esto puede llevar (y de hecho así ocurre) a diseñar impulsivamente. ¿Qué hay de malo en eso? Nada si el trabajo está basado en los principios del diseño centrado en el usuario. Desde esta perspectica se sugiere que se debe probar las ideas con los usuarios finales antes de comprometerse a desarrollar el código.

Sin duda, nos permite ahorrar mucho tiempo y recursos, y levanta una importante duda ¿cómo sabemos si la maqueta funciona de la misma forma como si ya estuviera programada, en un contexto diferente, sin haber probado antes con el usuario? ¿Cómo podemos innovar copiando lo que ya existe?

Antes de que Google reinventara las búsquedas en Internet, otros motores de búsqueda suponían que le correspondía al usuario aprender a buscar de manera adecuada.

La mayoría de los resultados de búsqueda eran pobres, entonces Google llegó y se dio cuenta de lo que ahora es evidente: La gente sólo quiere encontrar lo que necesita, no quiere aprender a usar un motor de búsqueda.

No estoy sugiriendo que los otros motores de búsqueda no podría haber hecho lo que Google hizo antes, sólo estoy señalando con el dedo la pérdida de oportunidad por no considerar las necesidades de los usuarios.

Curiosamente, Google no es conocido por sus diseñadores. Es principalmente una casa de desarrollo, pero muchos de los desarrolladores claramente tienen cierta sensibilidad con la experiencia de usuario, particularmente cuando se trara del diseño centrado en el usuario.

No hay nada de malo en usar la matodología de desarrollo ágil para producir resultados rápidamente, si tiene la intención de hacer pruebas de usabilidad con anterioridad. Sin embargo, no hay que dejarse engañar pensando que esto podría ahorrar mucho tiempo, dado que ante el desconocimiento y el apuro los resultados pueden ser más costosos.

Mina 4: La tentación de llamarlo “suficientemente bueno”

Invariablemente, cuando se ha terminado el código a finales de cada ciclo, se corre el riesgo de liberarlo aunque no sea lo suficientemente bueno. A veces, eso involucra hacer lo que sea para terminar el ciclo y comenzar con otro, pero en definitiva puede que no sea lo mejor para el usuario.

¿Hay que gastar tiempo en la próxima iteración u ocupar tiempo en arreglar sobre la que se está trabajando? Demasiado a menudo, el re-proceso va en favor de comenzar el nuevo desarollo y resulta un producto con ciertas características que probablemente no van a satisfacer a los usuarios.

Mina 5: Insuficiente tiempo para explorar el riesgo

La iteración “cero” (es decir, una planificación y diseño de la iteración anterior a la iteración del primer desarrollo) se puede utilizar para hacer esto y otras actividades de planificación.

Sin embargo, dependiendo de cuánto tiempo se demora esta iteración, el nivel de rigor aplicado a la exploración puede ser insuficiente.

Un argumento utilizado por algunos profesionales de metodología de desarrollo ágil es que hacer un ejemplo práctico (ir entregando productos programados) es la mejor manera de validar si es adecuado a las necesidades del cliente.

El “suck it and see” omite la conceptualización, las actividades donde se dedica tiempo a esbozar soluciones diferentes a un nivel alto y validarlos con los usuarios antes de excavar en el diseño detallado o hacer el código. Con el “Suck it and see” habría solamente que construir, lanzar y ver si se tuvo suerte y cumplió con satisfacer a los usuarios. De esta forma, se pierde tiempo de producción en desarmar o reconstruir.

El argumento contrario es que si se tomó el tiempo para construir, habría que considerar el tiempo para investigar y diseñar antes de hacer una línea de código.

Tiene que haber cierto nivel de diseño independientemente de la metodología se utiliza, y esto suma días a la línea de tiempo.

Mina 6: Marca daños

Digamos que el diseño y la investigación toman la misma cantidad de tiempo que el desarrollo. En el peor de los casos, se pierde por completo la marca o la visión por no hacer una investigación y diseño de la solución, en ese caso se debe comenzar todo de nuevo. Entonces a final de cuentas se gasta el mismo tiempo (teóricamente), pero en caso de comenzar otra vez, sin definiciones de diseño, no hay ninguna garantía de que resulte.

La razón de éxito de muchas empresas es producir productos de forma consistente y servicios adecuados. Por el contrario, la creación de un producto o servicio defectuoso afecta negativamente la marca y la percepción de los usuarios. Se requiere mucho más tiempo para reparar los daños a la marca que hacerlos.

Continuará…

Post relacionados:

• Llevando el Diseño Centrado en el Usuario al desarrollo ágil I