Pusimos a trabajar a nuestros clientes en el Comité Directivo Internacional de FreeBalance 2018, celebrado en Miami el mes pasado. El los talleres de gobernanza aprovecharon las técnicas de desarrollo ágil adaptados al contexto gubernamental. FreeBalance utiliza un enfoque único centrado en el cliente para nuestra hoja de ruta de productos y servicios. (Sí, ofrecemos asesoramiento, aplicacióny sostenibilidad servicios).
Las prácticas de hoja de ruta de los proveedores de software empresarial son similares entre ellos. Los jefes de producto elaboran las hojas de ruta basándose en los comentarios de los socios de integración de sistemas y en las peticiones de funciones de los clientes. La principal conexión de los clientes con los fabricantes de software es a través de los socios de integración de sistemas. Estas empresas de integración de sistemas generan ingresos a través de la personalización del código. Los incentivos no están necesariamente alineados con los clientes. Los fabricantes rara vez participan directamente en las implantaciones.
Las solicitudes de mejora de los productos llegan a los fabricantes de software a través del canal de atención al cliente. Los fabricantes suelen estar desconectados de los clientes. Se espera que los jefes de producto compensen esta falta de información. Las prácticas aceptadas de gestión de productos incluyen la gestión y triangulación de las solicitudes de características. Las hojas de ruta de los productos se convierten en "loterías de características". Los resultados suelen decepcionar por igual a todos los mercados verticales.
![Gestión de hojas de ruta de proyectos: Enfoque de planificación de recursos empresariales]()
Contexto y hojas de ruta de los productos
Entender el contexto es el reto más difícil para los jefes de producto. A menudo tienen que adivinar por qué los clientes piden funciones específicas. ¿Qué problema resolverá esta función? ¿Es un problema compartido y debería formar parte del producto? La gestión de la hoja de ruta depende a menudo de la experiencia y la opinión de los jefes de producto. Los jefes de producto a menudo tienen que hacer abstracción de múltiples peticiones para identificar patrones.
Esto ocurre a raíz de las ideas "brillantes" de los ejecutivos o de las reticencias de los equipos de desarrollo que tienen preferencias de ingeniería. (Hay un dicho que dice que los jefes de producto son como mini-jefes ejecutivos, lo cual es muy engañoso porque los jefes de producto no tienen privilegios de "contratar y despedir").
Los jefes de producto a menudo tienen que equilibrar las necesidades de prestaciones con las ideas tecnológicas. La tecnología emergente es más interesante, pero los jefes de producto se enfrentan a menudo a la creación de soluciones punteras en busca de problemas.
Se hace un gran esfuerzo para trazar el futuro de los productos. Proliferan los diagramas de Visio y las presentaciones de PowerPoint. Los fabricantes de software elaboran complejas hojas de ruta a lo largo de muchos años. Esto parece extraño dado el ritmo del cambio tecnológico. Hemos visto numerosos casos en los que los fabricantes han sido incapaces de predecir las necesidades futuras. Muchos productos nuevos, y nuevas versiones de productos de software empresarial ya existentes, han recibido una respuesta decepcionante por parte de los clientes.
¿Qué ocurre cuando las grandes empresas de software empresarial entran en nuevos mercados con hojas de ruta optimistas? La mayoría de las veces, estas empresas tienen que adquirir empresas ágiles.
El enfoque tradicional de la hoja de ruta del software empresarial está roto.
Una hoja de ruta ininterrumpida centrada en el cliente
FreeBalance ha estado utilizando un enfoque de votación de hoja de ruta en las conferencias de la FISC desde 2007. Este enfoque se ve facilitado por nuestro enfoque exclusivamente gubernamental. No vendemos a ningún otro "mercado vertical". También se ve facilitado por nuestra participación en todas las implantaciones. Recibimos información directa de nuestro personal de servicios de implantación. Además, recibimos aportaciones indirectas de los socios de integración de sistemas y a través de solicitudes directas de funciones.
El FISC proporciona el contexto que subyace a los puntos de la hoja de ruta. Nuestra hoja de ruta se ajusta cada año en el FISC mediante un proceso de votación. Como escribí en 2014:
En 2007 quisimos cambiar la dinámica de los eventos centrados en el producto a los centrados en el cliente. Esto significaba que gran parte de la ceremonia asociada a las conferencias de proveedores tenía que cambiar:
- Empresa a las necesidades del cliente: cambiar el enfoque de lo que la empresa necesita a lo que preocupa a los clientes, independientemente de cuál pueda ser la contribución de FreeBalance a las soluciones.
- Vender para comprometerse: Cambiar el énfasis empresarial de la venta dotando a la conferencia de ejecutivos y directivos en lugar de vendedores. Involucrar a los clientes para poder mejorar los productos y servicios.
- Dictar para colaborar: cambiar la dinámica de dictar qué productos se ofrecerán y cuándo, a que los clientes cambien las prioridades de los productos, adapten la hoja de ruta y trabajen juntos por objetivos comunes.
- Controlando al foro: cambiar el paradigma de las comunicaciones, pasando de presentaciones ingeniosas y controladas a un foro en el que los clientes se relacionen con otros clientes, ponentes externos y personal de FreeBalance para aprender lo que funciona en la reforma de la Gestión de las Finanzas Públicas (GFP).
Esto nos deja en una situación interesante porque los vendedores de software empresarial han condicionado a los compradores a esperar hojas de ruta centradas en el vendedor, en lugar de centradas en el cliente.
circuitos de retroalimentación. Los clientes potenciales quieren ver nuestra hoja de ruta a 5 o 10 años. Podríamos elaborar un documento que cumpliera este objetivo, pero es un ejercicio inútil. Nuestra hoja de ruta de productos y servicios cambia cada año. Los ciclos tecnológicos se han comprimido. Como se ha indicado anteriormente, nos centramos en la administración pública y el Mapa del componente de gestión de las finanzas públicas. Esta es la visión central que subyace a la FreeBalance Accountability Suite. Nuestra hoja de ruta está delimitada por este mapa de componentes. Efectivamente, nuestra hoja de ruta incluye todo lo que figura en el mapa de componentes de la GFP.
Nuestra hoja de ruta consta de elementos previstos para 1 año, 2 años y 2+años. Estos cambian cada año. Por eso aprovechamos los procesos ágiles e integramos el desarrollo de productos con los servicios de implantación en nuestra plataforma A-i3+qM TM metodología.
Tendencias de FreeBalance
Este ha sido mi duodécimo año recopilando información sobre nuestra hoja de ruta de productos. Ha sido un viaje fascinante para descubrir las aspiraciones de ganancia y los puntos débiles de la gobernanza. Algunas de las tendencias que he observado son:
- Adición de una hoja de ruta de servicios debido a las lagunas de los proveedores de servicios tradicionales y los socios donantes.
- Mayor atención a los requisitos no funcionales, sobre todo para mejorar la capacidad de mantenimiento, reducir los costes de funcionamiento y mejorar la integración con subsistemas que no sean FreeBalance.
- Aumento de los conocimientos y la capacidad tecnológicos
- Soluciones de usabilidad que reducen la huella de formación
La hoja de ruta de 2018 tenía productos y servicios con tecnologías emergentes como "blockchain", aprendizaje automático, desarrollo de bajo código y gobierno inteligente.
Este año hemos dedicado más tiempo que en años anteriores a explicar las ventajas de los productos o servicios. Estas declaraciones de beneficios estaban en consonancia con las finanzas públicas, la función pública y los requisitos de transparencia que comparten muchos gobiernos. Me complace decir que el primer elemento de la hoja de ruta surgió de la lluvia de ideas de los clientes del FISC. (Una de mis ideas quedó en segundo lugar con 98% de votos del elemento principal).
Agile amplía orgánicamente las hojas de ruta de los productos
Reescribimos nuestro software con una arquitectura orientada a servicios (SOA) a nivel de componentes. Esto nos permitió componer nuevas aplicaciones basadas en componentes empresariales reutilizables, que denominamos "entidades gubernamentales" en un diseño unificado. Esta reutilización facilita nuestra hoja de ruta de productos.
Este enfoque también permite el desarrollo a medida, incluido el desarrollo de aplicaciones gubernamentales únicas. Estos provienen de leyes de reforma únicas. Pero casi todas las implantaciones de FreeBalance están sujetas a alguna legislación singular. Nuestro enfoque de esta situación difiere de las normas del mercado.
Las empresas de integración de sistemas adaptan el código a necesidades específicas. Es la práctica aceptada. En descrito en un post la semana pasadaEsto deja a los clientes "en la estacada", con código huérfano y deuda técnica.
FreeBalance siempre forma parte de los contratos de implantación gubernamentales. La personalización a las necesidades únicas son requisitos contractuales.
FreeBalance personaliza el código para los clientes en la mayoría de las situaciones. FreeBalance dispone de un Entorno de Desarrollo Integrado (IDE) basado en Eclipse. Se puede formar a socios y clientes. Pocos clientes lo han hecho debido a la elegancia de la A-i3+qM TM metodología para el desarrollo a medida.
- El personal de los servicios in situ de FreeBalance elabora guiones gráficos y casos de uso de forma interactiva con los clientes
- El personal de gestión de productos de FreeBalance valida esta información utilizando conocimientos tecnológicos e identifica cómo pueden ampliarse las entidades gubernamentales para otros requisitos del mapa de componentes de PFM.
- Los storyboards y casos de uso validados son aprobados por los clientes
- El personal de gestión de productos de FreeBalance elabora las especificaciones
- El desarrollo de productos FreeBalance valida las especificaciones antes de desarrollar el código
- El personal de servicios in situ de FreeBalance se suma a la garantía de calidad para asegurar que el resultado satisface las necesidades del país
- Las pruebas de aceptación del usuario por parte del cliente validan el uso del código en producción (o demuestran la necesidad de adaptar las especificaciones).
El diagrama anterior sugiere que el proceso llega a su fin con la aprobación de la UAT del cliente. Eso es un poco engañoso porque sólo termina el proceso de poner el software en producción.....