Los retos de la gest
...
23
/
01
/
2023
Ejerzo mi actividad en el sector del transporte público y más concretamente en el del Transporte a la Demanda (TAD), un servicio de transporte flexible, alternativo al coche y al taxi, que se adapta a diferentes públicos y usos, al tiempo que reduce el impacto ecológico del transporte en el medio ambiente.
Trabajo para la empresa Padam Mobility, que ofrece un algoritmo de optimización del transporte, así como un conjunto de todas las interfaces necesarias para la explotación de un servicio de TAD: interfaces para facilitar los desplazamientos de los usuarios, una interfaz de conductor adaptada a todos los tipos de explotación, y una interfaz de gestión destinada a los operadores y a las autoridades organizadoras del transporte.
En este sector, he observado que la gestión de proyectos de digitalización del transporte, en un contexto de evolución constante del software, induce una fuerte complejidad.
En primer lugar, examinaremos la gestión de los proyectos de transporte y, a continuación, nos centraremos en los proyectos técnicos. Por último, examinaremos sus modos de funcionamiento en paralelo.
Mi actividad principal es la gestión de proyectos para la implantación de servicios de Transporte a la Demanda en zonas rurales y periurbanas.
En este sector, los proyectos pueden ser complejos en muchos sentidos:
La gestión del proyecto, tanto en lo que se refiere al contenido como a la gestión de los cambios, o al seguimiento y cumplimiento de los plazos, es por tanto un reto diario. Además, los contratos de adquisición pueden tardar mucho en validarse y obtener fechas definitivas de lanzamiento del proyecto puede resultar complicado. Una vez iniciado el proyecto, los equipos suelen tener que ser capaces de presentar la oferta de Transporte a la Demanda en un plazo de 2 a 3 meses, dependiendo de la complejidad del proyecto.
A menudo, los retos mencionados se multiplican por diez debido a la naturaleza evolutiva del mercado y a la creciente importancia del impacto medioambiental en el sector del transporte. Este último punto tiene un fuerte impacto en la evolución del software que hay que desarrollar para satisfacer las necesidades del cliente.
Para responder a la constante evolución del mercado del Transporte a la Demanda, el software debe permanecer en constante evolución.
La estrategia de desarrollo de software de una empresa SaaS debe responder, por su propia naturaleza, a una necesidad común a todos o a la mayoría de los usuarios, y no a una necesidad única o específica. Según este principio, no hay un equipo técnico dedicado a un cliente concreto.
La mayoría de las veces, los proyectos se gestionan en paralelo, dentro del equipo de producto (centrado en investigar las necesidades) y del equipo de desarrollo (centrado en ofrecer la solución como tal). Estos equipos se organizan según el método «ágil», con ciclos cortos de desarrollo de unos dos meses, separados en sprints de dos semanas. Si bien la gestión ágil de proyectos es más avanzada y permite cierta velocidad de evolución, la complejidad del software añade dificultades al desarrollo, haciendo que ciertas evoluciones sean inciertas tanto en términos de plazos como de viabilidad técnica.
Pero, ¿qué interacciones podemos observar entre un modelo SaaS basado en la gestión ágil de las evoluciones técnicas y la gestión de los proyectos de despliegue de TAD?
Los dos métodos de gestión paralela presentan apuestas y plazos diferentes, y podemos caer rápidamente en incoherencias y dificultades para completar los proyectos.
Un ejemplo concreto es la integración de los sistemas de Transporte a la Demanda en un proyecto más global de MaaS (Mobility as a Service) o soluciones de Movilidad con Servicios. En este contexto, la digitalización del TAD debe encontrar su lugar en las normas de transporte estándar y poder integrarse en programas informáticos de planificación de viajes más globales. Por tanto, es necesario normalizar y estandarizar un modo de transporte que, por definición, era extremadamente flexible.
A continuación, los avances técnicos deben basarse en estas normas creadas y probadas. Las interdependencias de las tareas son a menudo demasiado fuertes para poder seguir un calendario preciso. En la misma línea, el software puede quedar obsoleto o incluso inutilizable inmediatamente después de su lanzamiento cuando se produce un cambio en el mercado del MaaS o del TAD. En este caso, se pone en peligro el proyecto técnico.
En Canadá, los proyectos de TAD suelen integrar las herramientas de pago en línea para la compra de los billetes de autobús. En Padam Mobility ya se había puesto en marcha un proyecto técnico para implantar la emisión integrada de billetes con herramientas de TAD para satisfacer las necesidades de otro mercado, el británico. Sin embargo, las expectativas y necesidades del mercado canadiense no coincidían necesariamente con todos los avances previstos. Por tanto, esta realidad tendía a poner en peligro el proyecto de despliegue de TAD.
En estos dos ejemplos, los temas de los proyectos de TAD o de desarrollo técnico no son necesariamente convergentes o son muy interdependientes. Esto exige encontrar soluciones adecuadas para no poner en peligro el conjunto de los proyectos.
Existen varias herramientas para responder a las dificultades mencionadas. Sin embargo, deben utilizarse de forma que se garantice la plena integración entre el proyecto técnico ágil y el proyecto para proporcionar una solución digital al TAD.
Para que el proyecto de TAD tenga éxito, como en el caso del billetaje, es esencial realizar un estudio preciso de la nueva necesidad y orientarse hacia el proyecto técnico en curso. La reunión de sprint o de mitad de sprint será el mejor lugar para exponer los nuevos requisitos y encontrar un enfoque para integrarlos en el desarrollo en curso. La agilidad del proyecto es sumamente interesante en el sentido que permite que el desarrollo evolucione en función de las necesidades.
Las iteraciones y los intercambios tienen lugar en un calendario preciso que combina las limitaciones de tiempo de ambos proyectos. El carácter iterativo de la solución permite responder a plazos restrictivos. Una primera versión del desarrollo permite tener en cuenta el MVP (Minimum Viable Product) de la necesidad del cliente recién llegado, sin perder de vista la versión final, que permanece en la hoja de ruta del desarrollo para futuros ciclos.
Tengamos en cuenta que los proyectos de TAD presentan restricciones impredecibles y evolutivas que inducen grandes riesgos temporales en los proyectos.
En conclusión, en el sector del Transporte a la Demanda, la agilidad de los proyectos técnicos y la capacidad de escuchar las necesidades de los clientes son los dos elementos clave para lograr el éxito simultáneo de los dos tipos de proyectos realizados en paralelo.
Camille Bouin, CSM, Padam Mobility, enero de 2023.
30
/
06
/
2023
13
/
04
/
2023
30
/
08
/
2023