Compromiso Prematuro al Diseño

@nachobassino hizo una pregunta en Linkedin, que es la siguiente:

Busco algún buen artículo sobre el efecto en metodologías ágiles de hacer el diseño antes del desarrollo (“cascadear”). ¿Alguien tiene?

Pues bien, lamentablemente no tengo un artículo corto y al punto para compartir, y como me estaba quedando sin espacio en la sección de comentarios de Linkedin, decidí escribir esto y compartirlo. O sea, acá va un artículo corto al respecto :).

Dicho en una oración, el efecto de cascadear es partir de una solución subóptima porque no incorporó inputs necesarios en la construcción de la misma. Por lo tanto, o sale a producción y logra un impacto menor al posible (best case), o se tiene que volver para atrás porque algo no esta pensando, causando un gran desperdicio de tiempo, recursos y motivación (99% of the other cases).

Sección donde recomiendo un libro (o dos)…

Si bien no hay un artículo corto, existen dos libros muy buenos que describen los problemas que tiene el compromiso prematuro a un diseño sin estar validado. Los libros son: High Velocity Edge y Product Development Flow. Estos son libros fantásticos para entender mejor como el desarrollo tiene mucho que ver con procesos y como en nuestra industria estamos reinventando muchas veces la rueda que otros ya resolvieron. Si trabajan en producto y tienen problemas de ejecución y colaboración, leánlos.

Es subóptimo porque no ha sido validado

Imaginemos a un diseñador de autos, trabajando en un modelo nuevo. El piensa un auto hiper-moderno, con una curvatura de puerta que simplemente es imposible hacer con los metales existentes. El diseñador probablemente no lo sabe a priori, lo diseña de manera completa, gastando mucho esfuerzo y después va a tener que volver y corregirlo, produciendo desperdicio y un diseño que tal vez, si hubiese sabido al principio, no lo hubiera hecho así. Basic Lean Principles.

La pregunta es: cuando es correcto validarlo y por quienes?

Todo Designer tiembla ante la idea de tener que estar mostrando sus diseños a todos para que estén opinando todo el tiempo. Y tiene razón, porque en cuestión de diseño, TODOS tienen una opinión, siempre. Dicho esto, sí hay una forma de hacerlo y que tenga sentido para todos. Designers, worry not!

La validación del Diseño, y la solución en sí, debería ocurrir en dos instancias.

Primera Instancia — Validar la Solución

La primera instancia consiste en validar si el problema es real y si la solución realmente lo puede resolver. Para eso existen técnicas de Discovery como Design Sprints, que esencialmente juntan a muchas personas de muchas areas, y juntos entienden el problema, idean soluciones, las prototipan y las prueban con usuarios reales, todo en 5 días. Si esto les suena interesante, recomiendo fuertemente el libro: Sprint by Google Ventures.

En Restorando, esta etapa en general la manejan los Product Owners, Designers y Squad Leads, invitando a gente de distintas áreas (y por qué no Devs también?) para encontrar estas soluciones. El equipo entero de Desarrollo sin embargo, no debería estar involucrado porque es muy temprano todavía.

Segunda Instancia — Validar la Implementación

Una vez que tenemos una solución viable, que sabemos que a los clientes les va a aportar valor, vemos cómo implementarla. Esto se puede hacer en una instancia normal de Planning. Los leads (Squad Lead, PO, Designer) presentan al equipo la solución completa que debería incluir:

• Rationale: Por qué estamos haciendo esto y no otra cosa, y cómo sabemos que esto tiene chances reales de éxito? Market Research, Design Sprints realmente ayudan en explicar el porqué. Si los Devs no lo compran, no verán lo importante que es sacarlo en tiempo y forma.
• Diseño: Tenemos que tener diseños maquetados de todas las partes de la solución. Si no hacemos esto, todos pasamos a interpretar lo que el otro quiere decir, y terminamos haciendo cualquier cosa. Nunca subestimen la capacidad del ser humano de imaginarse algo y “jump to conclusions”.
• Business Logic: La lógica de negocio también debería estar definida a esta altura. Por último, si no sabemos a ciencia cierta algo (cuantos pushes por semana por usuario puedo enviar?), plantear desde el vamos un experimento. De cualquier manera, no hay motivo para deferir esta decisión a los Devs. Por qué razón un Dev sabría cuantos Push podemos enviar por semana por usuario?
• Rollout Plan: Un plan es fundamental porque estamos en un negocio. Hay que definir fechas para que estemos alineados entre todas las áreas. Hay que priorizar mercados y plataformas (Mobile Web > Desktop Web), etc. Dicho esto, al tener las fechas definidas, la variable de ajuste pasa a ser el Scope. Deberíamos poder desafiar el Scope siempre. Un plan fijo, con un scope fijo garantiza cosas mucho peores.
• Metrics and KPIs: Como vamos a medir esto? y que esperamos que ocurra? Son preguntas que tienen que estar definidas desde el primer día. Si no, no aprendemos como negocio. Además, los Devs también comienzan a entender el negocio, y gracias a eso toman mejores decisiones en el día a día y en la ejecución del proyecto. Estoy seguro que algunas cosas del inesperadas van a surgir, y acá es donde tener un Dev que entienda porque hace lo que hace vale oro.

Hablando más específicamente sobre Diseño, la pregunta que siempre surge es: Acaso a los Devs no les desmotiva que les bajen la solución ya pensada?

Es necesario que todos podamos ver la solución porque si no, todos interpretamos algo distinto. Si yo digo, “dashboard”, para mi es una cosa, pero para otros es otra totalmente diferente, y hasta que no lo dibujamos, o vemos un diseño, realmente no entendemos lo mismo. Por lo tanto, como puedo confiar en alguna estimación? Que la solución este completa en su definición, no quiere decir que este escrita en piedra.

En realidad a los Developers les gusta ver este nivel de detalle porque les permite pensar bien CÓMO desarrollar la solución. Es un error pensar que a todos los Devs les gusta estar pensando la solución en una planning. Ellos saben que no tienen toda la data como para saber quien tiene razón y quien no. No hay nada peor que una Planning de Brainstorming llena de opiniones, y de todos discutiendo soluciones.

Dicho esto, un Developer si debería poder desafiar partes de la solución. Tal vez hay partes pensadas que genuinamente son muy díficiles, y tal vez no tenga sentido a nivel costo/beneficio. Acá se ve la cancha de los líderes en saber argumentar porqué es tan importante cada parte de la solución. Si no lo pueden hacer y es una opinion nada más, entonces el Dev tiene razón en cuestionarlo. Los mejores líderes saben escuchar y darse cuenta si están encaprichados o no. Yo en particular siempre prefiero reducir el scope, ya que logra más foco y compromiso de parte de los Devs.

El objetivo de la validación constante del diseño es obtener el mejor plan posible (cómo) de la solución mas completa posible (qué). Sólo introduciendo los inputs necesarios en cada parte de la construcción de la solución nos garantizamos las chances de éxito, logramos el alineamiento y foco para desarrollar lo más rápido posible. Además, no hay nada más costoso que arrancar un proyecto de Desarrollo sin entender bien que queremos hacer y por qué. Después, cambiar de rumbo es terrible para la motivación de los equipos.

Seguramente, para algunos, esto les puede parecer mucho trabajo. Deben estar pensando: “Si yo ya sé lo que al cliente le gusta, para que voy a hacer todo esto?”

A ellos, les pregunto: “Cuando fue la última vez que confirmaste con datos que lo que hiciste les gustó a los clientes?” O, siendo más humilde, “cuando fue la última vez que confirmaste que estabas equivocado?”

Si no estas validando tus suposiciones, probablemente no recuerdes la última vez.