El siguiente artículo fue escrito por Leisa Reichelt para UX Magazine . Me tome la libertad de traducirlo completo y con unas leves modificaciones para adaptarlo mejor al español.
Me parecío un artículo bastante interesante porque como diseñador yo prefiero muchas veces trabajar solo, en este artículo la autora presenta un interesante método de trabajo en parejas que es generalemente aplicado por ingenieros en sistemas pero que puede ser aplicado a la metodología de trabajo de los diseñadores.
Pair Design Pays Dividends
por: Leisa Reichelt
Artículo original en UX magazine
En las metodologías de desarrollo ágil, la programación en par es considerada un práctica clave.
La programación en par involucra a dos programadores (en cualquier combinación de novatos y/o expertos) trabajando juntos escribiendo el código en una sola computadora, uno escribe y el otro revisa, corrige o sugiere al mismo tiempo.
Los defensores de las metodologías de desarrollo ágil señalan una serie de ventajas de la programación en par, y yo siempre he creído que el diseño se beneficia bastante de este tipo de enfoque.
En mi experiencia, diseñar es muchas veces una actividad muy solitaria. Si eres el suficientemente afortunado como para integrar a usuarios reales en tu metodología de diseño entonces podrías cambiar un poco la rutina. Si estás trabajando con un grupo de diseñadores, tal vez podrías lograr que revisaran tu trabajo de vez en cuando y que te den sugerencias. Trabajar en un ambiente ‘diseño en par’ es aparentemente bastante raro.
He sido lo suficientemente afortunada trabajando en algunos proyectos donde hemos utilizado el enfoque ‘diseño en pares’, y he sido gratamente sorprendido que los beneficios que los ágiles defensores señalan para programación en par son una gran verdad para el diseño en par.
Siguiendo la lista de beneficios que se encuentra en la Wikipedia, aquí presento una descripción de lo que he encontrado.
Aumento de la disciplina. Compañeros vinculados tienen mayores posibilidades de ‘hacer lo correcto’ y es menos probable que tomen pausas prolongadas.
Aunque a mí me gusta pensar que yo ‘hago lo correcto’ cuando diseño solo, ciertamente he encontrado que trabajando con otro diseñador en verdad aumenta la concentración en la tarea presente, y aun mas importante, aumenta el tiempo que este nivel de concentración puede ser mantenido.También he encontrado que en diseño en par, uno tiende a diseñar lejos de la computadora mas menudo y en vez se utilizan pizarras, papel, lápiz, notas post it pegadas en todas las paredes.
Esta es una buena práctica de diseño pero, aun mejor, te mantiene lejos de las distracciones como el email, blogs y todas las otras clases de distracciones que puedas encontrar en tu computadora.
Te mantiene enfocado en el proceso de diseño. Esto hace tu diseño mejor y te hace más eficiente.
Mejor código. Los compañeros vinculados tienen menos posibilidades de ‘trabajar de más’ y los diseños realizados generalmente son de muchísima más calidad.
Cuando se diseña en pares muchas veces las decisiones se toman de manera más rigurosa.
Esto es porque tienes que explicar cada decisión que haces o enfoque de diseño que tomas en el momento que lo haces, no en retrospectiva.
Cada decisión tiene que ser justificada. Y, porque tienes a alguien diseñando contigo, llegas a discutir los beneficios de cada enfoque en vez de simplemente hacer lo que tú crees es mejor (o peor… lo que puedes hacer mas fácilmente en Visio porque ya tienes una plantilla creada de esa manera… Oh. Vamos. Tú sabes que lo has hecho.)
Con respecto al problema de ‘trabajar de mas’, si sucede que estas diseñando con tu cliente, entonces puedes asegurarte rápidamente si el enfoque que has tomado tiene esperanzas de ser adoptado por el cliente.
Esto significa que no perderás el tiempo diseñando algo que nunca será implementado y que tu diseño tiene más oportunidades de ser adoptado.
Con respecto a lo anterior – que diseñes con tu cliente significa que ellos entienden la racionalización detrás de cada decisión de diseño. Así que si eres un recurso temporal en el proyecto, dejas atrás a un evangelista para tu diseño – de nuevo, creando más oportunidad para que lo que diseñaste sobreviva la fase de desarrollo.
Flujo resistente. Programar en pareja lleva a un tipo diferente de flujo que programando solo, pero lleva a flujo. El flujo de trabajar en parejas sucede más rápido: un programador le pregunta a otro, “¿En qué estábamos trabajando?”. Este flujo es también más resistente a interrupciones: un programador se encargada de la interrupción y el otro continua trabajando.
Para mí, quedarme trabado mientras diseño ES flujo. Pero lee arriba re: aumento de la disciplina y debajo re: menos interrupción. Teniendo ambas cosas significa que tienes más tiempo de flujo, lo cual está muy bien.
Mejoramiento de la moral. Algunos ingenieros pueden disfrutar mucho más a la programación en par que programar solos.
Como lo mencione anteriormente, diseñar puede ser un negocio bastante solitario. Cuando resuelves un problema de diseño muy enredado no hay nadie con quien celebrarlo… bueno, nadie que en verdad lo entienda. Con diseño en par, tienes con quien celebrar. Esto es bueno :).
Código de propiedad colectiva.* Cuando todos en un proyecto están programando en pares, y los pares rotan constantemente, todos obtienen conocimiento de todo el proyecto.
Ok. Esto ha sido un poco menos relevante para mí, como consultante, pero lean arriba re: diseñando con tu cliente y ganando a un evangelista.
Tutoría. Todos, incluso los programadores junior, poseen conocimiento que otros no. Programación en par es una manera indolora de transmitir ese conocimiento.
Esto es casi verdaderamente cierto cuando tienes una pareja novato/experto, pero aun cuando tienes a dos diseñadores con experiencia similar hay bastante que aprender.
¿Qué tan seguido tienes la oportunidad de observar el proceso que otros diseñadores llevan o como enfrentan su trabajo? No muy a menudo, supongo.
Esta es una buena oportunidad para decir, ’entonces, así es como lo hago… ¿Cómo lo harías tu?’ y obtener unas útiles nuevas ideas o trucos para Visio.
Equipo más unido. Las personas llegan a conocerse más rápido cuando programan en pares.
De acuerdo. Diseñando en pareja es definitivamente un excelente rompehielos :].
Menos interrupciones. Las personas son más reacios para interrumpir a un par que para interrumpir a alguien que está trabajando solo.
Ahora, este punto es DEFINITIVAMENTE cierto, y no subestimes que tan importante es.
Puedes llegar a diseñar bastante en un par de horas si eso es TODO lo que estás haciendo. ¿Qué tan seguido puedes dedicarte solamente al diseño que trabajas?.
En mi caso no tan seguido. Dos personas en un cuarto te hacen mucho menos interrumpible.
Se necesita una computadora menos. Como dos personas utilizan una computadora, la otra computadora puede ser utilizada para otros propósitos.
Bueno, en nuestro caso abandonamos por completo a las computadoras y nos tomamos un estudio. Así que supongo que quedo un par de computadoras libres.
Escoger al co-diseñador ideal es bastante importante. Odiaría diseñar en par con alguien que no conociera nada sobre diseño de interfaces… sería demasiada tutoría e insuficiente diseño, lo cual no es práctico o apropiado para un diseño basado en un ‘proyecto’.
Sin embargo sugiero que si encuentras un cliente que tiene personal con las habilidades necesarias, haz lo que puedas para que se involucren.
Esto es mucho más probable si estas aplicando otros métodos ágiles que involucren diseño rápido y acciones repetitivas.
Ahora, sería poco realista sugerir que el diseño en par sea adoptado para todos los proyectos de diseño, eso nunca va a pasar, y en muchas situaciones seria innecesario. Pero, si tienes la oportunidad de aplicar este tipo de metodología a tu proyecto, entonces te animo para que la utilices. Creo que encontrarás una experiencia muy gratificante.
