Cómo empezar a centrarse en el valor

Puedes leer este post en inglés aquí.

Me hago la misma pregunta todos los días: Mi trabajo aporta valor? Porque quizá estoy moviendo rocas cuesta arriba sólo para dejarlas caer y empezar de nuevo. Soy como Sísifo? Los filósofos del siglo XX tampoco han podido parar mi deseo de crear productos que realmente aporten valor y que al mismo tiempo me hacen crecer personal y profesionalmente.

Los buenos Ingenieros de Software de Producto tienen un alto sentido de ownership. Están involucrados en todas las fases de la construcción de un producto. Desde la identificación del problema, la investigación de soluciones y la evaluación de negocio hasta la implementación iterativa, el depliegue continuo y la medición del valor. Se centran en aumentar el valor sobre cualquier otra cosa. Y no es fácil porque esp implica comprender al usuario, el negocio, el producto, la marca, el equipo, la empresa y su política, etc.

Sin embargo, los Ingenieros de Software de Producto sin experiencia se centran en la tecnología. Sí que encuentran soluciones a los problemas, pero no cuestionan si vale la pena resolverlo siquiera. No conocen el valor que están aportando, por lo que tampoco encuentran la solución más adecuada.

Puedes suscribirte a mi newsletter With a grain of salt y recibir un email con novedades cada cierto tiempo.

Qué es el valor?

El Diccionario de Cambridge lo define como:

  1. la cantidad de dinero que se puede recibir por algo.
  2. la importancia de algo para alguien.
  3. cuán útil o importante es algo.
  4. un número o símbolo que representa una cantidad.

En la RAE podemos encontrar algo muy parecido.

Personalmente prefiero la definición de Ron Jeffries en The Nature of Software development:

En el desarrollo de software ágil, como en muchos otros ámbitos, hablamos de la noción de valor. Tomamos decisiones sobre qué hacer o qué no hacer, en función del valor. Hacemos las cosas antes si son de mayor valor, y hacemos las cosas después si su valor es menor. ¿Qué queremos decir con valor? El valor es, simplemente, “lo que queremos”.

Los equipos de Ingeniería de Producto con experiencia pueden pronosticar con bastante precisión el valor que van a agregarar. Toman decisiones basadas en la confianza que tienen en ese pronóstico. Idealmente pueden cuantificarlo. Pueden ponerle un número porque la estadística y el análisis de datos forman parte de su cultura. Pero a los inexpertos les cuesta mucho hacer eso. Esto es así porque en sus equipos el valor ni es explícito ni se visualiza.

Si el valor es lo que queremos, entonces puede ser para cualquier persona y puede tomar cualquier forma. El valor puede ser para el usuario cuando implementamos una nueva feature. Puede ser para el equipo de Production Engineering cuando mejoramos nuestro pipeline de CI/CD. Puede ser para un Business Developer cuando automatizamos un informe semanal.

Empieza con el lenguaje

Atomic Habits de James Clear me ha enseñado cómo los cambios pequeños, pero importantes, pueden tener un impacto gigante. Básicamente, si tu vida es demasiado caótica y quieres recuperar el control, empieza por hacer tu cama en la mañana.

El lenguaje importa y da forma a nuestra forma de pensar. Por eso, el primer paso es enfocar nuestro lenguaje en el valor. La mayoría de nosotros trabajamos con historias de usuario, así que las vamos a usar de ejemplo. Normalmente las historias de usuario se escriben así:

Como tipo de usuario, quiero algún objetivo para que alguna razón.

El valor se coloca al final de la frase. Se supone que debemos tomar decisiones basadas en el valor, pero lo tratamos como lo menos importante. Un ejemplo ayuda:

Como Business Developer, quiero tener el informe semanal automatizado para poder ahorrar tiempo.

Nos centramos en el Business Developer, pero no nos centramos necesariamente en su problema. Resolver esto es simple. Pon el valor primero:

Valor agregado para alguien, de alguna manera.

De nuevo, un ejemplo ayuda:

Para ahorrar tiempo al Business Developer, automatizar el informe semanal.

Cuando nos centramos en el valor, el equipo comienza a hacerse preguntas que no se hubieran hecho. ¿Cuánto tiempo? En este caso el valor es cuantificable. Quizá 2 horas para escribir ese informe semanal. Incluso podemos cuestionar la solución. ¿Podríamos hacer algo para ahorrar aún más tiempo para el Business Developer?. A veces, lo que el usuario quiere no es lo que necesita.

Continúa con los datos

Un equipo de Ingeniería de Producto jóven no puede pronosticar el valor agregado con gran precisión, pero empezar a medir es la forma de centrarse en el valor.

Normalmente, antes de llevar algo a producción, estamos en una superposición. No podemos estar seguros de que lo que hemos construido agrega valor, hasta que el usuario, el equipo de Ingeniería o el Business Developer interactúa con lo que hemos construido. Y la única forma de colapsar esa función de onda es medir. Algunas veces será de forma cuantitativa y otras veces será de forma cualitativa. Medir el valor conduce a una organización basada en datos.

Medir es solo otro paso hacia delante. Pero sin visualizar el valor, da igual. Por eso es importante:

Wrapping up

Sin visualizar el valor, es difícil empezar a hacer preguntas. Incluso es difícil sentir que nuestro trabajo sirve de algo.

Pero ten paciencia. Hacer crecer un equipo de Ingeniería de Producto desde la infancia hasta la madurez lleva tiempo. No se trata de cambiar procesos sino de cambiar personas y evolucionar la cultura. Y eso, amigos, es difícil.

Muchas gracias a undraw.co por las ilustraciones. Puedes suscribirte a mi newsletter With a grain of salt y recibir un email con novedades cada cierto tiempo.