A la hora de gestionar proyectos podemos ver dos flujos claros y bien separados. Por un lado, están los proyectos de precios fijos. Los proyectos de precio fijo tienen ventajas comerciales, como la posibilidad de fijar un precio para un ámbito de trabajo definido antes de escribir la primera línea de código. Por este motivo, los clientes suelen preferir los proyectos de precio fijo, ya que les permiten presupuestar con precisión y mantener el riesgo bajo control. Sin embargo, también plantean desafíos en lo que respecta a la ejecución, teniendo en cuenta el estado y la rentabilidad de los proyectos, ya que la estimación del trabajo no suele ser tan precisa o tal vez se basa en una fijación de precios en un ámbito que experimentará varios cambios. Estos riesgos deben gestionarse de alguna manera y acaban consumiendo una cantidad significativa de tiempo. Por otro lado, tenemos proyectos relacionados con el tiempo y el material, que adoptan un enfoque de trabajo abierto en el que los cambios siempre son bienvenidos y se llevan a cabo completamente utilizando marcos ágiles. Los marcos ágiles evitan los problemas comunes a los que nos enfrentamos con los marcos tradicionales y existen numerosos beneficios que confirman que lo hacen con éxito. Promovemos la innovación y mejoramos el trabajo diario de todos los equipos al combinar ambos mundos (ágil y tradicional).
Esto se aplica no solo a proyectos de software y similares, sino también a cualquier tipo de proyecto, independientemente de su industria. Por lo tanto, apoyarse en los marcos ágiles y buscar mejoras en los procesos de gestión puede ser una práctica beneficiosa incluso cuando se trabaja bajo el modelo de precio fijo. El objetivo de este artículo no es hacer una comparación ni detallar metodologías o marcos, sino comunicar cómo, según nuestra experiencia, podemos mejorar la gestión de los proyectos de precio fijo utilizando diferentes herramientas.
Cuando un proyecto se ejecuta con un alcance fijo, es muy común que se soliciten nuevas funciones como resultado de cambios en los requisitos empresariales o simplemente porque la función no se identificó a tiempo. Esto desencadena un proceso de gestión de cambios que puede llevar mucho tiempo e implicar altos costes administrativos para ambas partes a la hora de modificar el contrato original y acordar los cambios en la descripción del trabajo. La parte comercial tiene que volver a involucrarse y el programa de trabajo que se planificó debe modificarse por completo. A diferencia de esto, los cambios en el proyecto que se comunican a mitad del proyecto son mucho más fáciles de adaptar con los marcos ágiles. Estos marcos proponen que, a través de esos artefactos, se puede crear una lista de tareas pendientes con las funciones que hay que implementar a lo largo del proyecto y, al mismo tiempo, centrarse en períodos de implementación cortos (sprints) y ver los avances semana a semana (o el momento en que se planificó el Sprint). Puedes ver el progreso del proyecto y las correcciones a través de los eventos de Scrum: reuniones diarias, de revisión y retrospectivas. En ese sentido, los proyectos tradicionales no ofrecen un nivel comparable de visibilidad a lo largo del proyecto.
Las reuniones diarias, utilizadas con criterios, proporcionan una excelente visión de cómo está trabajando el equipo de desarrollo y ayudan a llevar a cabo los ajustes necesarios a la hora de planificar el proyecto. Por ejemplo: se pueden obtener resultados rápidos y la satisfacción del cliente en cada Sprint si se entrega una versión incremental del producto final o se deja de lado la burocracia excesiva. Organizar reuniones de revisión, en las que se puedan hacer demostraciones a las partes interesadas, es una excelente oportunidad para detectar incoherencias en las definiciones iniciales (lo que se pensaba que tenía un alcance fijo) y, con ello, la gestión del cambio fluye de forma más natural y la negociación con el cliente es mucho más transparente. Además, las demostraciones permiten a las partes interesadas comprobar que lo que solicitaron al principio del proyecto está incompleto en comparación con la necesidad real que pretenden satisfacer. En muchos casos, cuando las partes interesadas están comprometidas con la causa, es posible que visualicen lo que sigue en el proyecto y corrijan ciertos aspectos a tiempo.
En resumen, los proyectos de precio fijo seguirán existiendo. Tienen algunas ventajas que simplemente los convierten en una mejor opción en algunos escenarios. En estos casos, trate de cuestionar la creencia común de que los proyectos de precio fijo requieren un enfoque metódico en cascada. Considera la posibilidad de jugar con otras herramientas disponibles en otras metodologías o marcos. En el caso de Scrum, estos artefactos pueden mejorar la administración diaria y evitar los problemas habituales que tienen los proyectos de precio fijo. A través de los artefactos ágiles, ofrecemos flexibilidad y transparencia, a la vez que mantenemos precios fijos y buscamos el éxito en sus proyectos. De esta forma, puedes participar en tu proyecto formando parte de las reuniones diarias, las revisiones, etc., y nosotros lo llevamos a cabo de forma colaborativa.
Caso probado
En un proyecto para un importante cliente mundial del área financiera, utilizamos Sprints para obtener un plan preciso para las próximas dos semanas. Durante estos Sprint, tuvimos varias reuniones de perfeccionamiento con los patrocinadores y partes interesadas del proyecto, así como con el equipo de análisis empresarial y los desarrolladores, en las que nos centramos en analizar los desafíos del Sprint en curso y en cómo superarlos. Al final de cada Sprint, celebrábamos reuniones de revisión con el cliente en las que, con el uso de demostraciones, podíamos anticiparnos a los problemas y mitigarlos. Además, incorporamos reuniones retrospectivas que nos ayudaron a detectar problemas de rendimiento y a aplicar mejoras rápidas. Por ejemplo: las reuniones retrospectivas ayudaron a detectar una avería en el ordenador de un desarrollador que provocaba varios retrasos y problemas a la hora de programar, así como una sobrecarga en las pruebas de código automatizadas; con acciones rápidas y sencillas, logramos una mejora de alrededor del 45% en el rendimiento general.
.svg)