Los años de experiencia acumulada en el desarrollo de productos nos muestran que, especialmente para un rol senior, las buenas prácticas incluyen:
- Entender el problema
- Buscar resolver el problema correcto/de fondo, en vez de solo corregir síntomas
- Elegir la apuesta según el contexto actual
- Tener muy claros los objetivos y prioridades del negocio
- Buscar mover la aguja en los objetivos de negocio
- Construir pensando en cómo generar evidencia del impacto de los avances del producto
La lista es más larga, pero creo que ya entiendes a qué me refiero. Se trata de tomar/recibir un problema completo e ir desde ahí hasta implementar la solución.
El caso es que para moverte de esa manera necesitas ser parte de un entorno en el que puedes tener estos alcances dentro de tu área de dominio.
Pero la realidad es más tricky. Especialmente si el espacio queda en disputa y surge una lucha de poder.
Si diferentes áreas buscan tener el poder sobre el mismo espacio, no va a resultar.
Expectativa versus realidad
Sabiendo estas cosas igualmente no me pude librar. Por varias semanas, y debido a que surgió una nueva área dentro de un proyecto no muy grande, he sido parte de todo esto. Y, como también me dedico regularmente a hablar de cultura, todo ha sido mucho más frustrante.
(Esto pasa en un grupo de solo hombres. Vaya, vaya, qué sorpresa)
Pero después de algunas batallas decidí que, como dice una amiga, prefiero estar bien más que tener la razón.
Pedí ayuda y la salida fue armar una nueva forma de interactuar. Creamos un Kanban o tablero con varias columnas, donde cada una es una etapa del viaje de usuario.
El equipo que ahora toma las decisiones define dónde quiere intervenir y cómo quiere intervenir. Nosotros tomamos los requerimientos y los implementamos. Con claridad pero sin juicio.
Es la primera versión y probablemente tenga algún ajuste, ya que nunca he trabajado de esta manera.
Ahora, y para que la dinámica de interacción y trabajo tenga mínimos de claridad y visibilidad, y para que luego se pueda ir evaluando el impacto, en cada requerimiento de desarrollo, pedimos:
- Diagnóstico o hipótesis del problema/oportunidad
- Intención (qué queremos que pase con esta nueva implementación)
- Posibles impactos positivos y negativos
- El detalle de la implementación en sí, lo que incluye documentar cambios si corresponder
Con esto movemos el ownership y bajamos la fricción. De nuestro lado podríamos agregaremos nuestro punto de vista, especialmente sobre posibles impactos.
Duele un poco y va en contra de lo que recomiendo, pero sí oficialmente –en este proyecto– soy un tomador de pedidos.🤘