0

6 problemas típicos en proyectos UX – Parte 2: Deadline Creep, por Sergio Nouvel

Éste es el segundo capítulo de la serie sobre los 6 problemas típicos en proyectos UX que hemos encontrado en Continuum.

En esta ocasión hablaremos del Deadline creep, o cómo los plazos (y los costos) de un proyecto se desbordan, muchas veces agotando todos los recursos disponibles sin llegar a tener un producto lanzado.

Deadline creep, o la fantasía de que tenemos todo el tiempo del mundo

La primera y más obvia causa de que los proyectos se estiren como chicle en verano es el feature creep, del que ya hablamos en el artículo anterior de esta serie. La ansiedad de “agregar un par de cositas más antes de salir” va prolongando el tiempo en el que se invierte en un proyecto sin tener feedback de usuarios.

La segunda causa, no tan obvia, es cuando el equipo cree que “este momento es tan bueno como cualquier otro para plantear mi idea y hacer cambios”.Esto trae un continuo tira y afloja, donde la ansiedad de que todo quede perfecto ocasiona que las decisiones se deshagan y rehagan una y otra vez. Otros actores se suman tarde a la mesa, y usualmente son quienes tienen más poder dentro del equipo y por ende son capaces de descarrilar un trabajo completo.

El Deadline creep agota al equipo

Además de las consecuencias obvias (fallar en los plazos y gastarse más plata de la presupuestada), el Deadline creep deja tras de sí a un equipo exhausto, que se ha pasado los últimos meses en:

  • Pelear porque no se sigan añadiendo funcionalidades antes de lanzar
  • Perder la pelea por no tener el poder de decisión suficiente
  • Implementar esas funcionalidades a toda prisa
  • Sufrir la presión del project manager o del cliente, que (por supuesto) sigue trabajando con los plazos originales
  • Correr en círculos solucionando las quejas de usuario por las funcionalidades mal implementadas
  • Perder plata (y por ende motivación) en el proceso

¿Cómo evitas esta espiral?

Mostrar la guagua fea

En Continuum tenemos el dicho de “no tenerle miedo a mostrar la guagua fea”. Esto significa que necesitamos reconocer que, en realidad, nunca nos sacaremos del todo la sensación de que el producto no está perfecto, en especial cuando es un producto digital que en teoría puede evolucionar eternamente.

Decidirse a lanzar requiere carácter y disposición a “dejar ir” una discusión o una idea en pos de obtener feedback de usuarios más temprano. La imperfección no tiene nada de malo; al contrario, muchas veces se convierte en el motor que mantiene un producto vivo. El problema es el estancamiento y el exceso de perfeccionismo que bloquea las mejoras.

Pragmatismo versus perfeccionismo

¿Cómo concilias entonces pragmatismo con perfeccionismo? ¿Cuándo sabes si es demasiado temprano o demasiado tarde para lanzar? Si lanzamos productos imperfectos al mercado, ¿esto significa que nunca los mejoraremos realmente?

La clave está en pintar las cosas claras al principio del proyecto: las ideas y suposiciones que traemos en la cabeza al empezar son sólo eso, suposiciones, y debemos deshacernos de ellas lo más pronto posible. Esto quiere decir que hay una cierta ventana de tiempo en la que podemos darnos el lujo de divagar, hacer brainstormings y debatir ideas; esa ventana se cierra y debe darle paso a las decisiones sustentadas en la experiencia en terreno, ya sea directamente de usuarios o a través de datos (analytics, métricas de negocio, etc).

Cuando entendemos que no tenemos todo el tiempo del mundo para divagar, nuestra misma mente se ordena y prioriza. Los seres humanos funcionamos mejor cuando tenemos la cancha rayada.

Cómo rayamos la cancha

Cuando comenzamos un proyecto de Lean UX en Continuum, lo primero que hacemos es explicarle al cliente la dinámica del proceso y comunicarle la necesidad de efectuar due dilligence. Las reglas son sencillas:

  • Como mencioné arriba, las decisiones tienen un cierto tiempo límite de ser tomadas si queremos cumplir con los plazos. Pasados esos límites, cualquier cambio de rumbo queda postergado hasta después de lanzar y obtener feedback de usuarios.
  • Además, las decisiones se toman en vivo en la mesa de trabajo. Esto requiere que estén las personas que realmente toman las decisiones en la mesa. Si la persona que toma la decisión es alguien que acostumbra ausentarse de las sesiones y delegar con sus subalternos, dejamos en claro que las decisiones de ese subalterno serán consideradas como definitivas.

Este último punto es especialmente delicado, dado que muchos clientes acostumbran a dejar a sus subalternos a cargo de asistir a las reuniones y tomar las decisiones; y cuando el cliente original llega a chequear todo al final del proyecto, se encuentra con cosas que no le gustan, y —dado que es quien manda— intenta cambiarlas. Y así volvemos a fojas cero.

En muchas empresas es costumbre que los proyectos vayan pasando por etapas de aprobación sucesivas, de creciente autoridad. De esta forma, la persona con el verdadero poder de decisión termina siendo la última en enterarse del proyecto.Nosotros hacemos exactamente lo inverso: las personas clave toman las decisiones importantes al principio y señalan el rumbo general del proyecto. Una vez que el proyecto está encauzado, las decisiones menores pueden efectivamente ser delegadas.

La técnica del aikido

Una de las bases del aikido y artes marciales similares es que nunca opones tu fuerza a la del atacante; por el contrario, rediriges la fuerza del ataque a un lugar en el que no pueda hacer daño. ¿Qué tiene que ver esto con evitar el Deadline Creep?

La idea es que cuando el cliente plantea “hey, pero sería bueno si añadimos esta última cosa antes de lanzar”, en lugar de oponernos respondiendo “no, no lo haremos” (que con toda seguridad comenzará una pelea), replicamos con: “Es una idea interesante, considerémosla para implementarla en la próxima iteración, cuando ya tengamos feedback de nuestros usuarios”.

No hemos dicho que no será implementada; sólo estamos diciendo que no todavía. Esto permite que ideas que surgen tarde en el proceso — ¡y que muchas veces son valiosas!— no se pierdan en el camino, evitamos que alguien sienta que sus ideas no son escuchadas, y al mismo tiempo reforzamos la idea de que tenemos un plazo que cumplir si queremos que esto avance.

***

Rayar la cancha requiere mucha confianza con el cliente… y también requiere mucha autoconfianza. No es fácil, pero el costo de no hacerlo a tiempo es perder la capacidad de cobrar estos acuerdos más tarde. Ésta es sólo una de las razones por las que un Líder de UX requiere carácter, diplomacia y habilidades de negociación.

Pero dejar claras las reglas del juego (con respeto, humildad y buena onda) es impagable, dado que construimos una dinámica de trabajo que va en favor de los mismos intereses del cliente: el proyecto se termina a tiempo, dentro de los costos, listo para ser hecho realidad. Las fricciones se minimizan: muchas veces el cliente sugiere ideas o cambios al final del proyecto porque nunca nadie le explicó que ya era demasiado tarde. Comunicarse en tiempo real y trabajar codo a codo reduce la cantidad de documentación y registros del proceso y permite que el equipo se enfoque en lo que realmente importa: crear valor.


Post original de Sergio Nouvel (@sesho) en el blog de Continuum, que nos ha permitido reproducirlo aquí. 

Fatal error: Uncaught Exception: 12: REST API is deprecated for versions v2.1 and higher (12) thrown in /web/htdocs/www.uxinperu.com/home/wp-content/plugins/seo-facebook-comments/facebook/base_facebook.php on line 1273