Gánate a todo el mundo con tu hoja de ruta

Ficha de ayuda: los 10 principales consejos para conseguir la participación del equipo técnico

Martin Suntinger Martin Suntinger

La presentación de una hoja de ruta puede resultar enervante tanto para los desarrolladores como para los gestores de productos; una parte se ha esforzado para presentar una visión mientras que la otra espera a ver cómo aquello que ocurre y desconocen está afectando a su trabajo.

Sentí esa tensión cuando trabajé como desarrollador y, a menudo, me sentía insatisfecho con las hojas de ruta que el equipo de gestión de productos establecía. No me creí todas las decisiones y, con bastante frecuencia, salía de las reuniones de planificación con una sensación de "Bueno, esto no tiene sentido, pero si así lo creen...", o aún peor, pensando que "Tendremos que resolver los problemas nosotros mismos y lograr que parezca que lo que hacemos encaja con lo establecido en la hoja de ruta".

Podrías argumentar que el problema era que yo sufría el síndrome de "No inventado aquí" y quizás tengas razón. Como desarrollador, tenía una opinión muy clara sobre qué era lo correcto. Sin embargo, ahora, como gestor de productos, veo qué es lo que ha provocado esta desconexión y qué lecciones pueden aprender los gestores de productos de dicha situación para salir por la puerta grande en la presentación de tu próxima hoja de ruta. Después de todo, si el equipo técnico está de acuerdo con ello y comprende la situación general, las decisiones diarias de diseño e implementación se realizarán teniendo en cuenta el contexto apropiado, y tú obtendrás el producto que imaginaste.

1. Elige la esencia en lugar de palabras de moda

Aunque expresiones como "análisis de big data", "aprendizaje automático" o "iniciativa del Internet de las Cosas (IoT)" pueden resonar entre las partes interesadas empresariales como puntos de anclaje de alto nivel, estos elementos no son útiles ni procesables para los equipos técnicos. El departamento de ingeniería tiene que saber exactamente qué es lo que están desarrollando, cómo se relaciona con los productos actuales, cómo debe entregarse, y quién lo utilizará finalmente y con qué propósito.

Definir temas generales es genial para estructurar la hoja de ruta y el contexto, pero asegúrate de que no te detienes ahí y de que tienes buenas respuestas para lo que se esconde detrás de cada elemento general. Por ejemplo, si has denominado a un tema "servicios inteligentes", asegúrate de desglosarlo en las iniciativas clave y épicas que son necesarias para entregar dicho tema.

2. Establece el contexto adecuado

Los equipos técnicos necesitan conocer el contexto de por qué estás creando algo en una hoja de ruta. Ningún equipo técnico va a decirte jamás "Dime lo que quieres y yo lo creo". Al contrario, los ingenieros necesitan ver evidencias de por qué requieres una funcionalidad. Deja que los datos hablen, pero cuenta también una historia impactante desde el punto de vista de tus usuarios. Utiliza personas y habla sobre algunas alternativas que hayas excluido y por qué. Para ayudar a todo el equipo a comprender la hoja de ruta, piensa que el "porqué" importa tanto como el "qué".

3. Piensa bien en los compromisos

Si una funcionalidad no parece bien elaborada o realista, pero sigue en la hoja de ruta, deberían saltar todas las señales de alarma. No querrás que el equipo técnico tenga la impresión de que ha creado algo simplemente porque se lo prometiste a alguien. Podría ser un compromiso con un cliente o porque el "departamento de gestión lo quiere". Así que, sé prudente a la hora de comprometerte. Incluso si tienes una función forzada detrás de ti que requiere un cambio particular, asegúrate de que comprendes y transmites la justificación al equipo, y de que tú mismo la apoyas.

4. Haz planes realistas

Una visión es buena, pero es aún mejor si todo el mundo tiene la confianza de que puede lograrse. El plan no tiene que ser preciso, pero si lo primero que ve tu jefe de desarrollo al mirar la hoja de ruta es un enorme cuello de botella (por ejemplo, si la hoja de ruta tiene un diseño fuerte y centrado en el frontend, pero el equipo solo tiene a un diseñador y ha tenido problemas con cuestiones del frontend en los últimos meses), entonces tendrá problemas con la hoja de ruta durante el resto de tu presentación.

Asegúrate de que realizas una comprobación inicial de la realidad con el equipo y juega con situaciones hipotéticas. Tienes que tener respuestas, un plan de acción claro y una breve consideración sobre "cómo puede realizarse" antes de pedir el compromiso de todos. 

Presenting product roadmaps | Atlassian agile coach

5. Piensa en grande, comienza poco a poco

Tienes que tener en cuenta en qué lugar están el producto y las habilidades de equipo frente a dónde quieres que estén. Es fantástico avanzar hacia nuevos campos, lo que puede requerir nuevas habilidades en el equipo o alejarse de la tecnología existente, pero no te limites a escribir los sueños de dónde te gustaría estar en un año. En su lugar, piensa en cómo conseguirlo de forma realista. La adquisición de talento lleva tiempo, la adopción de nuevas tecnologías lleva tiempo y abandonar los productos existentes requiere compromisos claros y un plan de transición.

6. Elabora un plan de negocio

¿Un plan de negocio? Sí. Los equipos técnicos se preocupan por los planes de negocios. Quizás no tanto como a un responsable sénior, pero un equipo de desarrollo al completo se preocupa de por qué algo es importante para el negocio, si produce verdaderos resultados y cómo van a medirse. Aprovecha la inteligencia empresarial de tu equipo técnico. Todo el mundo tiene un interés personal en que el negocio tenga éxito en su conjunto, y puede ser una gran fuente de feedback o de ideas adicionales.

Además, una claridad total sobre el impacto del negocio y ver cómo ocurre puede ser una gran motivación; impulsar los resultados resulta satisfactorio más allá de simplemente haber creado y presentado una funcionalidad.

7. Compensa lo rutinario con motivación

Los ingenieros quieren desarrollar productos innovadores y exclusivos de los que puedan sentirse orgullosos. Si resulta ser la misma vieja historia que otros les han contado antes, puede resultar desmotivante. Asegúrate de constatar que tu historia es tan innovadora como piensas. Aparte de desmotivar a los desarrolladores, el impacto empresarial de la falta de innovación es incluso peor.

Dicho esto, incluso las hojas de ruta serán siempre un equilibrio entre funcionalidades nuevas y fascinantes, y requisitos imprescindibles no demasiado interesantes desde un punto de vista técnico que, sencillamente, hay que hacer. Trata de asegurarte de que incluso lo rutinario es motivador en tu hoja de ruta. 

8. Piensa más allá del MVP y la v1

Crear un producto viable mínimo (MVP, por sus siglas en inglés) y después una versión 1 es una cosa, pero también está todo lo que ocurre tras el lanzamiento: operaciones, mantenimiento, solicitudes de funcionalidades de los usuarios, mejoras continuas y nuevas versiones de otros productos o plataformas que se integran. Una rápida reflexión sobre cuáles son los desafíos y obstáculos que se pueden encontrar tras el lanzamiento los sacará a la luz sin demasiado esfuerzo, y los ingenieros estarán agradecidos de que no hayas ignorado estas realidades. Las estimaciones aproximadas sugieren que el esfuerzo inicial de crear una nueva funcionalidad solo supone de un tercio a la mitad del esfuerzo total destinado a ello durante todo el proceso. En otras palabras: las consecuencias son más costosas que la creación inicial, y, a la larga, algunas "pequeñas cosas rápidas" salen muy caras.

9. Aprende a lidiar con los obstáculos

Las estimaciones son algo bueno. Te orientan y se crean según el leal saber y entender de un gestor de productos en cada momento determinado. Sin embargo, muchas suposiciones hechas para las estimaciones salen muy mal una vez que se procede a la implementación o el ajuste de un diseño. Asegúrate de preparar y presentar la hoja de ruta de modo que sea flexible a los cambios.

10. Sé claro y honesto

Una hoja de ruta tiene como objetivo servir de orientación. No es un plan detallado para su ejecución y cualquier miembro del equipo de software lo sabe. No es necesario que lo vendas como algo distinto a eso. Así pues, si aún no tienes todos los detalles de un tema, sé claro. Comparte lo que tienes, cuál es la intención, cuáles son las cuestiones sin resolver y los mayores riesgos que aún quedan por abordar. Destaca áreas que requieran experimentación y más investigación para concretar el "qué". Simplemente, recuerda tener en cuenta el tiempo de experimentación durante la planificación.

¿El resultado?

Tu equipo se merece una hoja de ruta que ofrezca una imagen global clara, pero que no descuide las realidades. Asimismo, se merece una hoja de ruta que resulte motivadora, fascinante, y que tenga suficientes detalles como para que todo el equipo de software sepa qué hacer en los próximos 1 o 2 sprints con la seguridad de que obtendrán grandes resultados y una repercusión importante para el negocio.

Up Next
Requisitos