Cómo creamos un sistema de gestión de productos para alinear a los equipos de Notion

Supimos que habíamos llegado a un punto de inflexión cuando, una noche cualquiera, empezamos a recibir cientos de tickets de atención al cliente. Los desarrolladores habían lanzado una nueva función sin comunicarlo al equipo de atención al cliente y tuvimos que pasar la noche entera respondiendo dudas de usuarios.

Pero ese no fue el único problema. En las semanas previas al lanzamiento, el equipo de marketing de producto había estado insistiendo a los ingenieros e ingenieras para que actualizaran semanalmente las notas de la versión. Los distintos equipos se reunían de manera aislada para supervisar un mismo lanzamiento. Descubrimos que habíamos malgastado mucho tiempo tratando de comunicarnos.

En ese momento, Notion estaba creciendo: contábamos con cinco equipos de desarrollo que trabajaban simultáneamente en múltiples proyectos, pero muy pocas personas eran capaces de comprender todo el trabajo en su conjunto. Nuestra empresa no podría crecer si no encontrábamos una manera mejor de coordinar a los distintos equipos.

Este es un problema común de las startups en crecimiento. He visto situaciones parecidas en equipos de producto de Twitter, Oculus, Robinhood y, cómo no, Notion. ¡Es algo inevitable! Por eso quiero contarte cómo conseguimos diseñar una solución para nuestro equipo.

En este artículo analizaremos los sistemas y procesos que empleamos para mantener al día a nuestros equipos sobre el trabajo de producto y desarrollo. También hemos incluido plantillas para que puedas comenzar a aplicar el sistema con tu equipo.

Cuando me uní a Notion, una de las primeras cosas que hice fue hablar con los equipos de ingeniería y diseño para saber cómo creaban y entregaban los productos. Algunos usaban sistemas formales de tareas y sprints, mientras que otros publicaban las actualizaciones en un gran documento colaborativo.

Lo he visto muchas veces: cuando las empresas empiezan a crecer, sus equipos desarrollan distintos hábitos que dificultan la coordinación del trabajo. ¡Es normal! Un equipo debe trabajar a su manera, sobre todo en el mundo del trabajo remoto. Pero necesitábamos estandarizar la forma de comunicar el trabajo de nuestros equipos.

Pero ¿qué aspectos podemos estandarizar cuando cada uno hace las cosas a su manera? La clave está en encontrar un proceso que todos hagan igual, o casi igual, y unificarlo.

Los grupos de ingeniería, producto y diseño de Notion se centraban en tres conceptos principales: equipos, proyectos y tareas (encontrarás nuestras definiciones más abajo). Así pues, dedicamos un tiempo a definir cada uno de estos componentes y codificarlos en un documento para toda la empresa. Nuestro objetivo era que los equipos crearan sus proyectos de la misma manera.

También es importante saber qué no se debe estandarizar. Por ejemplo, no dictamos cómo tienen que reunirse los equipos ni qué herramientas de maquetas deben usar. Lo mejor es fijar un par de reglas básicas y dejar que la gente trabaje libremente.

Identificar y estandarizar estos componentes nos ayudó a organizar nuestro trabajo en cada producto y equipo de desarrollo. Sin embargo, necesitábamos comunicar este trabajo al resto de la empresa de manera coherente y en lenguaje llano.

Para hacerlo de forma eficiente, diseñamos un sistema de comunicación con cuatro partes:

• Equipos: conjuntos de personas que trabajan en proyectos.

• Proyectos: conjuntos de trabajo discreto y entregable de forma independiente que puede dividirse en tareas.

• Tareas: elementos de trabajo asignados a una persona.

• Actualizaciones: resúmenes rápidos y sencillos de cada proyecto que se envían cada dos semanas.

Algunas de estas partes ayudan a los equipos de desarrollo a coordinarse entre sí, y otras, como las actualizaciones, son relevantes para el resto de la empresa. Cada una de las partes es una base de datos de Notion y todas están vinculadas para crear el sistema. Imaginamos este método como un sistema de cuatro capas: cada una proporciona un nivel de contexto diferente a los equipos.

Puede que tú uses un sistema diferente, por ejemplo, con hojas de cálculo o carpetas de documentos. Puedes organizar tu trabajo con sprints o hitos. Si quieres tener un punto de partida, en la siguiente plantilla encontrarás nuestra configuración exacta.

Te mostraré cada una de las partes del sistema, cómo las hemos estructurado y su función en los distintos grupos.

Una propiedad clara facilita la organización de los proyectos, pero crear una lista de equipos precisa es más difícil de lo que parece. No podemos definir el desarrollo de software mediante un organigrama cerrado. Al contrario, se compone de grupos virtuales en los que todos trabajan con un mismo objetivo. Estos grupos pueden estar compuestos por personas que, en apariencia, no trabajan en el mismo equipo: desarrolladores, diseñadores, especialistas de marketing de producto, abogados y más.

Una buena manera de definir estos equipos es consultando aquellos canales de Slack que se usan para coordinar el trabajo del proyecto. En estos canales podemos ver la composición de los equipos no oficiales.

Una vez hayas encontrado estos equipos, puedes crear una lista tan sencilla o tan compleja como quieras. Nuestra lista incluye el nombre del equipo, quién lo compone, una breve descripción de lo que hace y otro par de datos útiles, como su canal de Slack y las normas del equipo.

Cuando hayas identificado a tus equipos, puedes registrar los proyectos en los que trabajan. Para nosotros, los proyectos son «cosas» que pueden entregarse; además, suelen ser los aspectos que más importan a las personas de la empresa.

Aquí es donde entran en juego los equipos de ventas, legal y otros subequipos de desarrollo. Aunque no se implican activamente en el proyecto, necesitan estar al tanto de su progreso para poder trabajar correctamente. Todos los equipos quieren tener el mismo nivel de contexto:

• Qué resuelve el proyecto.

• Cuál es su estado.

• Cuándo va a entregarse.

• Cómo consultar su desarrollo y decisiones.

Nuestra base de datos de proyectos está optimizada para responder a estas preguntas. Incluye información como el nombre del proyecto, una descripción «tl;dr», su estado, su fecha de lanzamiento y enlaces a documentación más detallada. Los datos se presentan en un formato de tabla. Así, cualquiera puede consultar rápidamente la lista de proyectos activos y obtener la información que necesita de inmediato.

Una vez identificados correctamente los proyectos, sus desarrolladores, diseñadores y responsables de producto pueden desglosarlos en tareas factibles. Estas tareas, que representan el trabajo cotidiano del equipo del proyecto, deben ser específicas y lo suficientemente detalladas para guiar a las personas que las llevan a cabo. Si intentas que las tareas sean comprensibles para todo el mundo, se volverán ambiguas e inútiles.

Con el fin de que las tareas sean comprensibles para las personas que las ejecutan, usamos propiedades específicas para rastrear la prioridad, el estado de control de calidad, el desarrollador asignado, el proyecto relacionado y cualquier otra información que ayude al equipo de desarrollo a hacer su trabajo.

La última capa es para quienes no saben qué proyectos son interesantes para ellos. Un proyecto se compone de muchas tareas. Del mismo modo, una actualización se compone de muchos proyectos. Nadie va a leer una lista de cincuenta proyectos, pero todos quieren conocer los detalles importantes.

Nuestras actualizaciones semanales van dirigidas a toda la organización, por lo que las escribo en lenguaje llano y legible. Extraigo el contenido de las actualizaciones de producto individuales que introduce cada equipo de desarrollo. A continuación, las escribo en páginas de Notion para facilitar la búsqueda de actualizaciones antiguas. También se pueden enviar en otros formatos, como correos electrónicos o documentos.

Actualmente, estructuro las actualizaciones semanales en tres grupos:

• Qué se entrega: una sencilla lista de todo lo que se ha entregado a clientes externos durante esa semana.

• Anuncios: progresos (buenos o malos) en los proyectos. Por ejemplo, nueva documentación de requisitos de producto o retrasos significativos en un proyecto.

• Información: lecciones aprendidas de los proyectos recientes o cambios generales en la organización de desarrollo y producto.

Pero es de esperar que esta estructura cambie a medida que cambian las prioridades de la empresa. Ahora mismo, en Notion nos centramos en las entregas y en asegurarnos de que todos los equipos estén al tanto de los planes. Si tu equipo trabaja en tres grandes aspectos, puedes centrar tu actualización en el progreso de cada uno de ellos.

El sistema que acabo de mostrarte no sirve de nada si nadie lo usa. Para asegurarnos de que nuestro sistema tuviera éxito, quisimos mostrar a los equipos su valor.

Nuestro objetivo era mantener a todo el mundo informado sin aumentar su carga de trabajo. Es un equilibrio difícil de conseguir. Para lograrlo, nos esforzamos en conectar entre sí todas las partes posibles del sistema. Así, la introducción de información en una de las partes aumenta el valor de las otras partes. Esto incentiva al equipo y anima a contribuir al sistema.

Un ejemplo: decidimos insertar el monitor de proyecto al final de cada actualización semanal. Así, cualquiera que desee saber más sobre un proyecto concreto puede encontrar esa información fácilmente. Este sencillo gesto es un incentivo para que el equipo de desarrollo mantenga actualizada la lista de proyectos.

Los equipos de desarrollo individuales también insertan una vista filtrada de la base de datos de tareas en cada documento de proyecto. Esta vista muestra únicamente las tareas relacionadas. De este modo, cualquiera que abra la página del proyecto puede ver de inmediato el desglose del trabajo y su progreso.

El vínculo con los sistemas de otros departamentos ayuda a reforzar el valor. Por ejemplo, el equipo de marketing de producto consulta las fechas de un lanzamiento externo en el monitor de proyectos para rellenar el calendario de lanzamiento.

Al finalizar este proceso, conseguimos crear un sistema para supervisar todos nuestros productos y trabajos de desarrollo en un único lugar. Además, podíamos compartir la información con toda la empresa sin complicaciones. Esperamos que este marco te resulte útil para implementarlo en tu equipo.

¡Las cosas cambian muy rápido en las startups! A medida que crezcamos, nuestro sistema cambiará, y el tuyo también.

Hemos descubierto que, cuando nuestros sistemas evolucionan, lo más importante es comprender qué información necesitan los distintos equipos. Se necesita a toda una empresa para crear un producto. Y tener en cuenta las necesidades de todos es lo que nos ha ayudado a mantener la transparencia durante nuestro crecimiento.