En el equipo de ingeniería de Compass teníamos un problema. Creábamos funciones sólidas desde el punto de vista técnico, pero nos faltaba algo: conseguir que los clientes estuvieran realmente satisfechos. Éramos buenos programadores, pero ¿resolvíamos los problemas adecuados?
En mi trabajo con Compass como director sénior de ingeniería de Atlassian llevo años lidiando con este problema. Mi equipo y yo nos encargamos de crear herramientas que ayudan a los equipos de desarrollo a gestionar sus componentes y recursos de software a escala. Cuando llegué, me di cuenta de que había un problema común a muchas organizaciones de ingeniería: se nos daba muy bien crear funciones, pero a veces no conseguíamos ofrecer valor.
He podido comprobar personalmente que la cultura de ingeniería puede hacer que un producto sea un éxito o un fracaso. En Atlassian, no solo creamos herramientas para los equipos de software; también tenemos que lidiar con los mismos problemas que sufren nuestros clientes a diario. Esto nos da una perspectiva única sobre la transformación de la cultura de ingeniería y por eso tengo tantas ganas de contaros lo que hemos aprendido.
La desconexión de la ingeniería tradicional
Veamos el caso de un hipotético equipo de producto cuya experiencia puede que te resulte familiar.
Tina es una desarrolladora sénior conocida por su gran capacidad técnica. Si bien su programación era impecable, había entrado en un ciclo de trabajo muy habitual que hacía que se sintiera atrapada: recibía peticiones, escribía código e implementaba funciones. "Programaba de forma aislada", admite Tina. "No tenía ni idea de si lo que estaba creando resolvía problemas reales de los clientes". Quería tener más información sobre el cliente, pero se sentía limitada porque su trabajo se centraba únicamente en la implementación.
Rita, la diseñadora de producto del equipo, también tenía que hacer frente a algunas contrariedades. Aunque se pasaba semanas creando diseños con un pixelado perfecto, no recibía los comentarios importantes hasta que llegaba la fase de desarrollo, lo que la obligaba a hacer grandes revisiones. "Muchas veces, cuando los desarrolladores indican que hay limitaciones técnicas ya es demasiado tarde para mantener la idea original del diseño", explica. Rita necesitaba una manera de poder integrar mejor su trabajo en el proceso de desarrollo y lograr que se validaran los diseños antes.
Paul, el director de producto, es quien intentaba que todo fluyera. Dedicaba muchísimas horas a redactar documentos para detallar los requisitos, pero siempre se perdía algo en la traducción. "Es como el juego del teléfono", cuenta. "Cuando las funciones llegan a los clientes, ya se han transformado en algo diferente de lo que imaginábamos inicialmente". Quería desesperadamente mejorar la colaboración entre los equipos de ingeniería y diseño, pero el proceso tradicional de traspaso seguía creando barreras.
Rick, el director de programas, fue probablemente quien tuvo el papel más difícil. Coordinar las dependencias entre los distintos equipos y, al mismo tiempo, encontrar el equilibrio entre la velocidad de entrega y la calidad era algo que le quitaba el sueño. "Cuando los equipos trabajan de forma aislada, los cambios simples pueden provocar semanas de retraso", señala Rick. Necesitaba una forma de fomentar una mejor colaboración y visibilidad entre los equipos.
La encargada de supervisarlo todo era Anna, la responsable de ingeniería, que luchaba por transformar la forma en que operaban sus equipos. Si bien valoraba la excelencia técnica, era consciente de que faltaba algo. "Tenemos ingenieros con un talento increíble", señala, "pero no siempre ofrecemos el valor que necesitan nuestros clientes". Anna quería cambiar la cultura del equipo, pero el modelo de desarrollo tradicional dificultaba la combinación de la excelencia técnica con el valor para el cliente.
La experiencia de este equipo refleja una situación más general en el desarrollo de software. Si bien el enfoque secuencial tradicional es organizado y predecible, crea desconexiones naturales entre quienes crean el producto y quienes lo utilizan.
La cultura es la clave de la transformación
"La cultura se come a la estrategia" Si bien esta cita se atribuye a menudo al gurú de la gestión Peter Drucker, cobró protagonismo cuando Mark Fields la exhibió permanentemente en la sala de operaciones de Ford en 2006. El mensaje no era solo una frase pegadiza, sino que reflejaba una evidencia que hemos visto repetidamente en el sector tecnológico: por más brillante que sea una estrategia, si entra en conflicto con la cultura de la organización, fracasará.
Cuando en Compass decidimos transformar nuestra cultura de ingeniería, descubrimos algo muy importante: la excelencia técnica por sí sola no era suficiente. Teníamos que cerrar la brecha entre nuestros ingenieros y nuestros clientes. Las cifras lo confirman: las empresas con una cultura sólida obtienen cuatro veces más ingresos que sus competidores.
Nuestra estrategia de transformación en Compass lo ilustra a la perfección. Pasamos de un proceso tradicional del ciclo de vida de las funciones, que normalmente tardaba de 6 a 8 semanas en completarse, a un proceso de descubrimiento iterativo que nos acercaba mucho más a los problemas de los clientes. No se trataba solo de un cambio de proceso, sino de una transformación fundamental que implicaba pasar de la idea de que lo sabemos todo a la idea de que lo aprendemos todo, y donde cada función nos brindaba una oportunidad para aprender de nuestros clientes.
La evolución de la ingeniería de productos
La ingeniería de software ha consistido tradicionalmente en convertir los requisitos en código funcional mediante el diseño, el desarrollo y las pruebas sistemáticos. Los ingenieros se centran principalmente en la ejecución técnica: hacer programaciones eficientes, mantener los sistemas y garantizar la calidad.
Sin embargo, la ingeniería de productos representa un cambio fundamental en nuestra forma de concebir la creación de software. Si bien mantiene el rigor técnico de la ingeniería de software, añade un elemento crucial: una comprensión profunda del cliente y un aprendizaje continuo. Los ingenieros de producto no se limitan a programar, sino que participan en la detección y la solución de los problemas de los clientes, aportan conocimientos técnicos a las decisiones sobre los productos y se responsabilizan de los resultados de su trabajo.
El modelo tradicional de ingeniería de software
En el modelo tradicional, el desarrollo sigue una trayectoria lineal. Los requisitos van desde la gestión del producto hasta los equipos de ingeniería que lo implementan, pasando por el diseño. Es como una carrera de relevos, en la que cada equipo pasa el testigo al siguiente.
El antiguo flujo de trabajo de nuestro equipo se caracterizaba por este enfoque lineal:
- Los documentos de requisitos tardaban meses en crearse y aprobarse.
- Los arquitectos y diseñadores trabajaban de forma aislada.
- Los ingenieros programaban según especificaciones exactas.
- Las pruebas y las implementaciones se hacían al final.
- Los comentarios de los clientes se filtraban a través de varios niveles.
Este enfoque funcionaba bien cuando los requisitos eran estables, y cambiarlo resultaba caro. Pero en los mercados actuales, en cambio constante, necesitábamos algo más adaptable y centrado en el cliente.
El ciclo continuo de ingeniería de productos
Nuestra transformación se centró en reemplazar este proceso lineal por un ciclo de aprendizaje continuo. En lugar de tratar el desarrollo como una carrera de relevos, ahora nuestro funcionamiento es más parecido al de un equipo de fútbol: nos movemos todos juntos, nos adaptamos a las condiciones cambiantes y nuestra meta es ofrecer valor a los clientes.
En este nuevo modelo:
- Los ingenieros participan en las entrevistas con los clientes y en las sesiones de descubrimiento.
- El desarrollo y el diseño se realizan de forma colaborativa, con prototipos y pruebas rápidos.
- Las decisiones técnicas se validan en función de las necesidades del cliente.
- La implementación se convierte en una oportunidad de aprendizaje, no solo en un objetivo de entrega.
- Los equipos no solo miden el éxito a partir de métricas técnicas, sino también a través del impacto en los clientes.
De la implementación al control
Para ingenieros como Tina, esta transformación significó pasar de la implementación pura y simple al control verdadero. Ahora los ingenieros:
- Participan en la definición de problemas y en la búsqueda de soluciones.
- Aportan perspectivas técnicas a las primeras conversaciones.
- Validan las suposiciones directamente con los clientes.
- Se responsabilizan de otros aspectos de las funciones, además de la calidad del código.
- Hacen un seguimiento de las métricas empresariales y del impacto en el mercado.
Los resultados hablan por sí solos: las organizaciones que adoptan este modelo tienen un tiempo de comercialización más rápido y tasas de adopción de funciones más altas que aquellas que utilizan los enfoques de ingeniería tradicionales. Y lo que seguramente es aún más importante: hemos observado una mayor participación del equipo, decisiones técnicas más acertadas y una mayor correspondencia entre nuestras soluciones técnicas y las necesidades de los clientes.
Cómo hicimos posible la transformación
Transformar la forma en que trabajan los ingenieros requería algo más que un cambio de mentalidad: necesitábamos una base adecuada. Para nuestro equipo, una pieza crucial de esta base era Jira Product Discovery, una herramienta que, de forma natural, incorporó el contexto del cliente a nuestro flujo de trabajo diario.
La primera cuestión que teníamos que resolver era que la información de los clientes estuviera al alcance de todo el mundo. Antes, los comentarios de los clientes y los requisitos de los productos figuraban en los documentos de Confluence, los hilos de Slack y los tickets de Jira. Jira Product Discovery incorporó todo este contexto directamente a nuestro flujo de trabajo de desarrollo. Ahora los ingenieros pueden ver las entrevistas con los clientes, las sesiones de comentarios y los patrones de uso junto a su trabajo de desarrollo, lo que hace que las necesidades de los clientes sean tangibles e inmediatas, en lugar de abstractas y distantes.
Esta accesibilidad ha cambiado radicalmente la forma de colaborar de nuestros equipos. Cuando una diseñadora como Rita crea nuevos diseños, puede vincularlos directamente con los puntos débiles de los clientes para que los ingenieros puedan verlo y comprenderlo. Cuando Paul prioriza las funciones, puede conectar fácilmente el impacto en el cliente con la complejidad técnica y, así, tomar decisiones más fundamentadas. Y lo que es más importante, nuestros ingenieros pueden ver por fin el proceso completo, no solo lo que estamos creando, sino también por qué es importante para nuestros clientes y cómo afectará a su trabajo.
Para los equipos que estén considerando una transformación similar, recuerda que no se trata de elegir entre la excelencia técnica y la orientación al cliente, sino de unir ambos enfoques para crear productos que los clientes adoren de verdad. Cuando los ingenieros entienden a fondo las necesidades de los clientes, toman mejores decisiones técnicas, diseñan soluciones más elegantes y encuentran más significado en lo que hacen porque pueden ver el impacto directo.
¿Quieres obtener más información sobre cómo logramos esta transformación? Consulta nuestro seminario web: The Magic Behind Product Engineering: Turning Customer Problems into Features They Love (La magia detrás de la ingeniería de productos: convertir los problemas de los clientes en funciones que les encantan), en el que profundizaré en nuestro recorrido y compartiré estrategias y rutinas prácticas que puedes implementar en tu propio equipo.