Ideas
¿Qué pasa cuando podemos construir más rápido de lo que podemos adoptar?
Hace unos meses escuché a un equipo de producto explicar por qué las reuniones trimestrales de su consejo asesor de clientes (customer advisory board) empezaban a sentirse demasiado distantes. Un cliente podía sugerir algo en una reunión y el equipo podía tener un prototipo listo en dos semanas. Necesitaban escuchar a los clientes con más frecuencia para decidir qué construir después.
Ese fue el reto que exploré en La IA y la bala de plata: cuando construir software se vuelve más fácil, decidir qué construir importa todavía más.
Una conversación reciente con un ejecutivo de producto llevó la idea un paso más allá. Su empresa está incorporando IA en sus productos para clientes y usándola internamente para construir más rápido. Su equipo es mejor decidiendo qué construir y está haciendo entregas rapidísimo. Ahora le preocupa qué pasa cuando esas funcionalidades llegan a los clientes.
Supongamos que entregamos la funcionalidad correcta en tiempo récord. ¿Qué tan rápido puede la organización cambiar su forma de trabajar para obtener valor de ella?
La funcionalidad correcta puede seguir siendo difícil de adoptar
Pensemos en una funcionalidad que les da a los planificadores de inventario una mejor recomendación de reabastecimiento. Puede que la entiendan y quieran usarla. Pero ¿tienen los datos y la autoridad para actuar con base en ella? ¿Qué pasa si choca con una política existente?
Imaginemos el raro escenario en que este es el único cambio sobre la mesa. Aun así, la empresa podría necesitar nuevas capacidades técnicas, criterios de decisión más claros o una distribución distinta de responsabilidades.
Conocí formalmente el enfoque de Prosci para la gestión del cambio y trabajé con él en roles anteriores. Hay una distinción de ADKAR que caló en mí: saber cómo hacer algo y poder hacerlo en la práctica son cosas diferentes. Capacitar a un planificador para leer una recomendación no le da la autoridad para actuar con base en ella.
¿Qué podemos hacer antes de que llegue la funcionalidad?
Yo empezaría por reunir a las personas que entienden la tecnología con las que dirigen la operación.
- Hagan visibles las implicaciones. Pongan la forma actual de trabajar y la propuesta lado a lado. ¿Qué haría la gente distinto el lunes por la mañana? Sean claros sobre lo que saben, lo que están suponiendo y lo que todavía requiere una decisión.
- Desarrollen el conocimiento en ambas direcciones. Los equipos técnicos necesitan entender cómo funciona el negocio, incluidas sus excepciones. Los equipos de negocio necesitan entender qué supone la tecnología y dónde las personas todavía deben aplicar su criterio. Usen un lenguaje que ambos lados entiendan y den espacio a las preguntas básicas.
- Trabajen juntos un caso real. Sigan una recomendación hasta la acción que alguien tomaría. Si una política estorba, involucren a su responsable. Acuerden qué resultado debería mejorar y luego comprueben si la nueva forma de trabajar lo logra.
A los ejecutivos de TI a menudo se nos pide ser la punta de lanza de la innovación. Parte de esa responsabilidad es reunir a las personas adecuadas mientras la funcionalidad todavía se está planificando. Podemos ayudar a los líderes de negocio a resolver qué tendrá que cambiar, decidir quién será responsable de esos cambios y seguir involucrados mientras los llevan a la práctica.
Planificar qué construir y planificar cómo el negocio lo va a poner a trabajar pertenecen a la misma conversación.
Publicado originalmente en inglés en LinkedIn.