Cultura de ownership

La responsabilidad en el desarrollo de software se puede manifestar de muchas formas. Los desarrolladores podemos ser responsables de los incidentes que nuestro código causa, de los malentendidos en cuanto a los requisitos que tiene lo que estamos desarrollando o los posibles problemas de rendimiento que puedan tener nuestros sistemas. Sin embargo, nuestra responsabilidad no debería cesar ahí. Deberíamos tener un ownership completo de nuestro producto o del proyecto en el que trabajamos. Un ownership de extremo a extremo que garantice la máxima calidad y viabilidad de la solución desarrollada.

Un ownership compartido dentro del equipo obviamente, y con alcances y responsabilidades bien definidas entre sus miembros, pero un ownership que todo el equipo asuma y por el que vele a diario.

Cultura de ownership

Por lo tanto, nosotros como desarrolladores deberíamos cultivar también una cultura de ownership sobre aquello que desarrollamos.

Antes de continuar dejar claro que no me refiero a que seamos responsables de todas las decisiones sobre el producto, sino que deberíamos involucrarnos y sentirnos responsables de su éxito. Dentro de un equipo remamos todos en la misma dirección y aunque parte de las decisiones no sean nuestra responsabilidad, deberíamos velar por el éxito del proyecto y la satisfacción del usuario.

Esto significa que tenemos un ownership colectivo de la calidad del producto que desarrollamos, de cómo se ajusta a las necesidades que estamos cubriendo y de su capacidad de adaptarse y evolucionar.

Ownership sobre el desarrollo

Como desarrolladores tenemos responsabilidades claras y un ownership explícito sobre el código que escribimos y los sistemas que desarrollamos. Como parte del ownership colectivo del proyecto debemos asegurarnos de que nuestras contribuciones individuales siguen nuestros criterios de calidad y aportan al objetivo del producto.

Esto significa pensar en la imagen completa y desarrollar haciendo foco en nuestro producto y el problema que queremos resolver. Significa velar por la calidad y que la solución que estamos desarrollando se ajuste lo máximo posible a las necesidades y contexto del producto.

Este involucramiento más allá del propio desarrollo de tareas me recuerda a un ejemplo que muestra claramente como los desarrolladores podemos aportar tomando ownership de nuestro producto.

En un equipo con los que he trabajado en Mercadona Tech estaban implementando una iteración sobre una funcionalidad de conteo de cajas en uno de nuestros almacenes. Involucraba cambiar de cierta manera el proceso físico y la herramienta informática que le acompañaba. El problema fue que los datos no mostraban ser muy positivos, el conteo de las cajas se desviaba en ocasiones del real y no estaba dando buenos resultados.

Entonces diseño y producto idearon una segunda iteración para ajustar más los procesos y que estos problemas no se dieran. Sin embargo, una compañera mía que estaba involucrada pensó que no tenía sentido, que tenía que ver algo más detrás de esas desviaciones en el conteo de cajas. Entonces se puso a revisar logs, comprobó el flujo completo de extremo a extremo y cómo los trabajadores estaban usando la herramienta.

Finalmente, descubrió que el nuevo conteo que idearon tenía un problema de base en cuanto lo hacían dos personas en momentos diferentes. Comentó esto con el resto del equipo y se dieron cuenta del problema y encontraron juntos una solución sencilla de implementar.

Esto muestra que al sentirse responsable también del producto, investigó y se interesó por los resultados que estaban obteniendo. Aunque el equipo había concluido prematuramente que el problema se arreglaría con una segunda iteración, no se rindió y buscó la causa. Gracias a eso el producto ganó y el equipo resolvió el problema de la mejor forma posible.

Ownership es ser responsable

Tener ownership también es ser responsable: responsable de nuestros fallos y los de nuestro equipo.

Cuando trabajamos en equipo no tenemos que vernos como diferentes piezas separadas que forman parte de algo más grande. Somos una única entidad que trabaja unida para construir un producto.

Esto quiere decir, por ejemplo, que si hay un problema técnico no es cosa del “Tech Lead” (que es el último responsable) si no que debería ser un problema del equipo. Si hay un problema en la conceptualización del producto no es cosa del diseñador, sigue siendo un problema del equipo (aunque recalco que esto no quiere decir que no haya un responsable, sigue habiendo una persona responsable pero el equipo entero debería sentir ownership sobre la solución y velar por su éxito).

Por esta filosofía, este ownership requiere algo muy importante: una cultura blameless. Como equipo no debemos señalar culpas individuales, sino que debemos de trabajar unidos en solucionar los problemas que hayan podido surgir.

Ownership es comunicarse

Por lo tanto, el hecho de que tengamos una cultura de ownership compartido requiere que nos comuniquemos constantemente. No trabajamos aislados, trabajamos en equipo y eso significa trabajar juntos y en la misma dirección.

Aquí recalco lo importante que es tener una buena costumbre de feedback donde estemos acostumbrados a dar y recibirlo. Cómo he comentado antes, al final las responsabilidades individuales del equipo estarán repartidas entre diferentes personas y roles, pero es importante que nos demos feedback entre nosotros para poder ver otros puntos de vista y enriquecer nuestras decisiones.

Por ejemplo, una de las partes que más me gustan de mi trabajo es hablar con el diseñador de mi equipo sobre las soluciones que estamos planteando, pensar en casos de uso y hacerle challenge sobre lo que a lo mejor no he acabado de entender. Lo hago porque me gusta y porque al final tengo esa sensación de ownership sobre el producto: no solo lo implemento, sino que velo por su éxito.

Ownership es conocer el problema

Y finalmente, como he comentado en artículos anteriores, los desarrolladores tenemos que saber más del negocio que negocio mismo. Y esto está muy relacionado con el tema del ownership.

Para desarrollar las mejores soluciones, hemos de conocer lo mejor posible el problema. Y eso significa bajarse al barro, conocer al usuario, empaparse del proceso físico o de las necesidades que estamos cubriendo y sentirlo en nuestras propias carnes.

Cultivar una cultura de ownership nos permitirá crear un producto de la mayor calidad posible y hará que además estemos orgullosos de él.

TL;DR

Cultivar una cultura de ownership va más allá de asumir responsabilidad por los errores o problemas específicos del código y se extiende a un compromiso completo con el éxito del producto desarrollado.

Un ownership compartido dentro del equipo es clave, donde cada miembro asume responsabilidades bien definidas, pero comparte la responsabilidad general del éxito del proyecto. Este ownership no implica tomar todas las decisiones sobre el producto, sino sentirse responsable de su éxito global.

Como desarrolladores, debemos tener también un ownership claro sobre el desarrollo, asegurándonos de que las contribuciones individuales cumplan con criterios de calidad y contribuyan al objetivo general del producto.

Tener ownership es ser responsable, tanto de los éxitos como de los fallos. Es importante ver al equipo como una entidad unificada, donde los problemas técnicos o conceptuales son problemas del equipo en su conjunto, no asignados a roles específicos.

Los desarrolladores debemos conocer el negocio tan bien como el propio negocio. Es importante que nos sumerjamos en el conocimiento del usuario, que entendamos los procesos y las necesidades para desarrollar las mejores soluciones.

Cultivar una cultura de ownership no solo conduce a la máxima calidad del producto, sino que también genera un sentido de orgullo en el equipo por su contribución al éxito del proyecto.