Muchas veces nos encontramos con que tenemos que resolver problemas y trabajar en equipo (desarrollando soluciones de software) y no tenemos la estructura o metodología necesaria para hacerlo. En este artículo y en el siguiente vamos a hablar sobre cómo hemos de componer y organizar a nuestro equipo de trabajo, tanto desde un punto de vista puramente funcional como filosófico.

La idea es dedicar hoy a la teoría, y el siguiente episodio a la práctica. Como sé que la teoría siempre es algo más aburrida, prometo ir rápido durante hoy para que no se nos atragante mucho.

Todo lo que diga de aquí en adelante está pensado para lograr soluciones de desarrollo de software, aunque realmente podría llegar a ser aplicable a otro tipo de negocios o estructuras. 

Lo primero es decir que me gusta trabajar bajo el paradigma de Lean UX. No voy a entrar en profundo detalle sobre cuál es la filosofía y marco de Lean UX, pero los que me leéis habitualmente sabréis que uso metodología Lean en casi todos los proyectos y ya os imaginaréis la principal virtud de este sistema: evitar el desperdicio, es decir, dedicar todo nuestro esfuerzo en la mejora y aporte de valor del producto.

Así que, volviendo a Lean UX, vamos primero a hablar de sus tres pilares. Esto es un poco más filosófico, pero quiero que pilléis de dónde viene y hacia dónde va Lean UX antes de que nos metamos en el meollo de hoy, que es hablar de cómo podemos organizar a nuestro equipo para resolver un problema.

Primer pilar: design thinking

El diseño de pensamiento o design thinking tiene muchas definiciones. Si buscáis en internet vais a encontrar muchas maneras distintas de explicar en qué consiste. Como siempre trato de ser práctico y no perderme demasiado en conceptos, lo voy a definir de forma sencilla: design thinking es una manera de crear soluciones usando la sensibilidad y los métodos de los diseñadores.

Aquí lo dejo, al menos de momento. Que me perdonen los puristas, pero mi intención en un post es tratar de explicar las cosas de manera sencilla y rápida, que se entienda bien. Sé que el design thinking da para un curso entero, pero no es mi intención el abordarlo ahora.

Segundo pilar: metodologías de desarrollo ágil de software

Al igual que con el primer pilar, me voy a limitar a hacer una definición sencilla. Las metodologías de desarrollo ágil son una serie de métodos o prácticas que nos permiten crear soluciones de software con equipos multidisciplinares. Estas soluciones están pensadas para adaptarse a entornos cambiantes y priorizan comunicación sobre documentación.

En palabras comunes: son técnicas para crear software que nos permiten no ser rígidos a la hora de cambiar los desarrollos, adaptándonos a las necesidades del proyecto según éstas van apareciendo.

Tercer pilar: Lean Startup

Lean Startup es una metodología para el desarrollo de negocios y productos que busca reducir el riesgo y el desperdicio a través de ciclos rápidos de creación, medición y aprendizaje. Se basa en la idea de lanzar un producto mínimo viable (MVP) lo antes posible para validar hipótesis con usuarios reales, obteniendo retroalimentación continua que permita iterar y ajustar el producto de forma ágil. El enfoque promueve la experimentación controlada, la adaptación constante y la toma de decisiones basada en datos, en lugar de suposiciones, lo que lo convierte en una herramienta clave para emprendedores y empresas innovadoras.

Bien, estos pilares nos dan una idea del origen de todo lo que vamos a contar a continuación. Vamos a ver los principios que van a regir la organización y estructura de trabajo que defiende Lean UX.

Principio uno: equipos multidisciplinares

Normalmente tenemos divididos a los equipos por disciplinas. Desarrolladores, diseñadores, marketing, dirección, control de calidad… Es muy importante dejar de pensar en esos términos y considerar a todos aquellos que van a intervenir en el desarrollo de una solución como un único equipo. 

Sé que esto parece complicado, pero puedo dar fe de que funciona. Normalmente estos equipos van por “libre”, pareciendo incluso que tienen objetivos distintos entre ellos. Casi se ven como el enemigo o los rivales. He oído millares de veces aquello de “estos diseñadores no se dan cuenta de lo difícil que nos lo ponen” o “estos desarrolladores limitan mi creatividad”… Cuando cada uno tira hacia un lado, al final se resienten tanto el producto como los integrantes de los diferentes equipos.

Tenemos que sentar a todos y hacerles entender que ellos, son en realidad, el mismo equipo. Un equipo compuesto por personas con diferentes especialidades pero con el mismo fin. Los problemas a solucionar han de evaluarse y atacarse en conjunto, no por departamentos. Esto daría para un curso entero y no me voy a explayar más aquí, pero es necesario que quede claro que hay que trabajar conjuntamente, entendiendo todos que es necesario satisfacer las necesidades del producto, y que las mismas tienen varias patas: usabilidad, diseño, programación, marketing, control de calidad, etc, etc. 

Principio dos: pequeños y dedicados.

Es inteligente limitar el tamaño de los equipos que trabajen en exclusiva en un proyecto. El tamaño no debería superar las 10 personas, aunque esto es flexible según el producto o servicio que ofrezcamos.

Lean UX también considera que los miembros deberían estar coubicados, es decir, en el mismo lugar. Mi experiencia me dice que esto es lo ideal, pero que no es absolutamente imprescindible si tenemos las herramientas, predisposición y responsabilidad necesarias para trabajar en remoto.

Principio tres: progreso es igual a resultados, no a entregas de documentación

La documentación exhaustiva es cosa del pasado. Cuando yo empecé en el mundo del desarrollo seguíamos metodologías muy poco flexibles (como Métrica 3) que se basan en tener muy documentado y analizado todo el proyecto y seguir el guion a pies juntillas. En el desarrollo moderno, salvo en casos muy concretos, esto ya no tiene sentido. 

Es mejor progresar entregando trabajo que entregando documentación. Este trabajo nos ayudará a aprender y afectará a desarrollos futuros, por lo que tratar de tenerlo todo documentado es especular demasiado.

Principio cuatro: un equipo centrado en los problemas y otro en las soluciones

Vamos a crear dos equipos de trabajo. Uno de ellos se va a centrar en los problemas y el otro en las soluciones. 

Equipo de problemas: este equipo necesita identificar problemas a solucionar dentro del mercado. Serían las personas que tienen contacto con los clientes, con los entrevistados o los early adopters. De ahí aprenderán sobre sobre los problemas que se encuentran éstos y, por tanto, serán los encargados de transmitir al equipo de soluciones qué temas hay que abordar, así como su urgencia.

Un equipo de problemas detecta necesidades en el mercado, así como necesidades de sus clientes. Esas necesidades necesitas ser resueltas, pero no es el equipo de problemas el encargado de elegir cómo se resuelven, sino simplemente debe encontrarlas y transmitirlas al equipo de soluciones.

Equipo de soluciones: este equipo recibe hipótesis sobre los problemas detectados y es el encargado de idear las soluciones y ejecutarlas. Normalmente aquí tenemos a los desarrolladores, diseñadores, expertos en marketing…

No es raro que haya algunas personas que estén en ambos equipos, dependiendo de cómo tengamos estructurada la plantilla de trabajo y sus cometidos.

Hay personas a las que no les gustan las denominación de equipo de problemas y equipo de soluciones, ya que consideran que puede haber malentendidos. Ya sabéis, puede parecer que el equipo de problemas es un Problema y que el equipo de soluciones es la Solución al mismo. Personalmente creo que esto se arregla simplemente explicando bien qué funciones tiene cada equipo, pero también podéis cambiar las denominaciones a cualquier otras, como Equipo 1 y Equipo 2.

Principio cinco: eliminación del despilfarro

Ya sabéis que Lean se tiene como filosofía el no desperdiciar los recursos del negocio, ni en tiempo ni en dinero. La mentalidad de nuestro equipo deber ir en consonancia. No debemos abordar nada que no sea realmente útil a la hora de aportar valor a nuestro producto.

Principio seis: lotes pequeños

Es más fácil ser eficiente cuando nos proponemos objetivos pequeños. Puede que se nos presenten problemas que, en apariencia, pueden ser grandes, pero lo más normal es que seamos capaces de dividir ese problema grande en otros más pequeños. Si tenemos lotes de trabajo grandes, eso implica mayor tiempo de implementación, de diseños y de un largo etcétera. Es mejor compartimentar.

Principio siete: descubrimiento continuo

Tenemos que tener conversaciones regulares con nuestros clientes/usuarios, descubrir qué hacen y cómo lo hacen. Eso nos da la oportunidad de aprender de forma contínua, lo que nos facilitará el realizar mejoras sobre el producto (recordemos que en Lean el producto no es lo que vendes únicamente, sino también el modelo de negocio que lo rodea). También esto nos aporta otras ventajas, como la oportunidad de validar nuevas ideas sobre nuestro producto o servicio.

Principio ocho: entendimiento común

Demos toda la información a nuestro equipo de trabajo. Cuanto más sepan, cuanto más puedan intervenir en la toma de decisiones, más considerarán el producto como propio, y más eficiente serán. Además, mejorará las relaciones entre departamentos, ya que todos estaremos en el mismo barco y con los mismos conocimientos y objetivos.

Principio nueve: antimodelos

Ya hemos hablado de la importancia de tener un grupo unido y con objetivos comunes. Es importante no tener en el equipo a personas que consideran estar a un nivel distinto a los demás. Normalmente a estas personas se las denomina gurús, estrellas o ninjas. Aquí no tienen cabida porque tienen tendencia a no compartir ideas o conocimientos. Tenemos que ser como una colmena, todo se trabaja en equipo y las individualidades no tienen cabida aquí.

Principio diez: exteriorización del trabajo

Nos referimos a poder presentar de alguna forma nuestras ideas a los demás. Tenemos que poder trabajar con herramientas que nos ayuden a que nuestros pensamientos o ideas sean fácilmente representables para el resto del grupo. Pizarras, post its, folios, herramientas online como Miro, Figjam… Da igual. Lo que buscamos es que nuestra idea sea compartible con los demás, para que puedan opinar e inspirarse.

Principio once: aprendizaje en lugar de crecimiento

Esto es algo que me cuesta hacer comprender a mis clientes. Cuando concibes una idea de negocio, es muy difícil hacerla crecer a la vez que aprendes sobre ella. En las primeras fases de un negocio, hay que centrarse en aprender. Luego, ya vendrá el crecimiento.

¿Imagináis lo arriesgado que es escalar una idea de la que aún no tenemos suficiente información? Es necesario aprender sobre nuestro producto, sobre nuestros clientes, sobre el modelo de negocio entero… Con esa información podremos crecer de forma más sólida en el futuro.

Principio doce: permiso para equivocarse

Esta es uno de los principios que más me gustan. Es muy habitual que tu equipo se sienta cohibido a la hora de expresar posibles soluciones a los problemas porque piense que, quizá, se está equivocando. ¡Pues claro que puede estar equivocándose! ¡Faltaría más!

Todos nos equivocamos, desde el primero hasta el último. El miedo a equivocarse no debe amedrentarnos, tenemos que tener confianza y exponer todas aquellas ideas que creamos que pueden llevarnos a la resolución de un problema. Quizás nuestra propuesta solucione el problema, o quizás no lo haga pero inspire a otro para dar con la solución adecuada. O quizás nos ayude a ver el problema desde otra perspectiva… Todas las opiniones son valiosas, por muy absurdas que puedan parecer al principio.

Trabajar en equipo: a continuación…

Bien. Ahora que tenemos los principios claros, podemos pasar a la parte divertida: qué técnicas grupales usar para solucionar problemas. Como os comentaba al principio del artículo, esto lo contamos en el siguiente. Si no queréis esperar, podéis seguir leyendo sobre metologías de trabajo y cómo gestionar el estrés en el sector tech aquí.