5 Errores comunes en gestión de proyectos

niño adulto con computadora

Cuando un proyecto planificado de 3 meses se convierte en un proyecto de 7 meses, conviene analizar los puntos que han determinado una demora. Y si es posible aprender de lo analizado para evitar caer en los mismos errores.

Por fin, parece que el último de los proyectos en los que he estado trabajando en los últimos 7 meses llega a su fin, al menos en la fase 1 tal y como la Dirección se marcó el objetivo.

El proyecto forma parte de un paquete de varias iniciativas que lanzaron simultáneamente en una importante firma ubicada en Palma de Mallorca para el sector Turismo. Mallorca, y Baleares en general, es un gran destino turístico y tiene una larga experiencia en sector. De ahí que residan aquí grandes firmas internacionales que se dediquen a la venta de alojamiento hotelero.

Hoy en día las empresas del sector se ven obligadas al cambio. Empresas tradicionales que han pasado de ser organizaciones familiares a competir en un mercado global basado en la consulta y comparación de precios con un par de clicks ante una infinidad de proveedores. En la lucha por el cambio tecnológico que sucede hoy en día se tiende a quitar el exceso de eslabones que forman la cadena de venta, entrando en una competición, casi exclusivamente, por precio. Es fácil ver como un mismo producto puede y de hecho tiene diferentes precios según el canal de venta.

Afrontar el cambio

Desde esta importante firma se decide que ha de ampliar los canales de venta, adaptándose a las nuevas opciones que tienen los clientes finales en la reserva de productos turísticos. De ahí que aparecen varias iniciativas. Entre ellas en la que se nos ha destinado a nuestro equipo, que ha sido la creación de un Motor de Reglas de Negocio a medida, para la gestión del pricing en la reserva hotelera. Refiriéndose a pricing como la técnica que permite variar el precio del producto en tiempo real bajo determinados criterios definibles por el usuario.

7 meses que han pasado rápido. A pesar que inicialmente el alcance del proyecto se estableció en tan solo 3 meses. Sí, se ha tardado más del doble estimado en fase inicial. En las siguientes líneas se intentará resumir las presuntas causas que han dado lugar a esa demora, con el fin de dejar plasmados los errores cometidos, aprendiendo de ellos.

Al menos, podemos decir que el sistema ya está en producción desde hace una semanas y se empieza a ver la luz al final del túnel. Las primeras pruebas arrojan resultados positivos para la firma y nos dejan una cierta sensación de deber cumplido. Otro tema será, el cómo se repercute sobre el esfuerzo dedicado por varias decenas de personas durante meses para llevar a cabo todas esas iniciativas…

Tu calidad de vida profesional es inversamente proporcional al número de líneas de código fuente que tendrás que mantener.

Por la parte que me implica, y el objeto de este post, es tratar de plasmar los puntos que han afectado en la duración (y por lo tanto coste) del proyecto, y qué consideraciones y notas se deberían tener presente para los siguientes proyectos que estén por llegar.

El objetivo inicial

El objetivo inicial: «queremos un sistema donde se desea poder cambiar el markup (comisión aplicada al precio del proveedor que se repercute al cliente) en función de ciertas condiciones como fechas, destinos, tipo de hotel, personas y/o edades, etc… Y que el usuario pueda cambiar dichas reglas fácilmente».

Entrando en acción

La verdad es que, el objetivo plasmado así no parece algo difícil. Uno lo primero que piensa es un intérprete de reglas y un mantenimiento de las mismas. Por lo tanto una estimación inicial de 3 meses parece más que suficiente para crear un par de pantallas de edición de reglas, y unas cuantas clases (Java en este caso) que cambien un simple número decimal, el markup.

Planificación

Primer error. Establecer una planificación del proyecto de forma independiente sin tener en cuenta el software donde estará ubicado y la relación que tendrá éste con otros proyectos. Una planificación de 3 meses es absolutamente válida en un entorno en donde el sistema es independiente y aislado.

En la realidad pocas veces ocurre ya que se requieren hacer cambios en otros sistemas para incorporar las nuevas funcionalidades. Sobre todo cuando el sistema a desarrollar se debe introducir como un eslabón más de una cadena existente.

Por ejemplo, si el nuevo sistema va a calcular un nuevo precio, este precio sobre-escribirá el precio o será un dato nuevo para conservar el precio original. Si se desea conservar el precio original se debe tener en cuenta que todos los sistemas posteriores deberán ser capaces de entender el nuevo campo de precio y propagarlo en la cadena. Por tanto se tendrán que modificar los sistemas posteriores, como mínimo para propagar el dato. Decisiones como conservar el precio original o no pueden determinar mucho lo rápido que se podrá desplegar las nuevas funcionalidades.

En mi opinión, la solución para este primer error, es mantener implicados a todos los miembros clave de las diferentes iniciativas mediante reuniones de control y seguimiento.

Implicación de los usuarios

En cualquier caso comenzamos el proyecto utilizando la planificación anunciada como primera aproximación. Prácticamente desde la primera semana comenzamos a escribir código, una vez que tuvimos las estaciones de trabajo configuradas con el entorno de desarrollo. Y aquí es cuando aparece el segundo gran problema: la comunicación con los/el usuario clave.

El grueso de las funcionalidades que el sistema ha de soportar han de ser definidas por los usuarios implicados. Y en este caso, los requisitos recaen sobre un único usuario en su gran mayoría. Por tanto la accesibilidad e implicación del usuario condicionarán en gran medida la puntería de los constructores del sistema ante el acierto en los objetivos. Hay que evitar de todas las maneras posibles que elaborar el documento funcional se convierte en una tarea de imaginación e improvisación contínua, asumiendo por parte de la consultoría demasiado riesgo en un posible desvío del objetivo que espera el cliente.

Este punto me ha recordado a las anotaciones de las clases de ingeniería de software, y al hecho de tropezar varias veces con la misma piedra. De vuelta a la toma de requisitos, de aquí se deriva que mejor un equipo, aunque con un responsable que pueda coordinar a estos, que un único usuario para la toma de requisitos de aplicación. Conviene que los acuerdos de los requisitos sean vinculantes en forma de actas de reunión firmadas, y que el responsable final de las iniciativas sea consciente las acciones decididas.

Liderazgo multi departamental

El siguiente gran problema ya ha sido anunciado entre las lineas anteriores de manera implícita, y es la falta de liderazgo común a todas las iniciativas. Se necesita un mecanismo de control, por no decir presión, que empuje a todas las iniciativas para que trabajen a la misma velocidad. En un sistema de producción donde se están realizando cambios en las diferentes tareas del mismo proceso, no puede pasar que haya eslabones que no estén sincronizados todos ellos con la misma versión. Por lo tanto la velocidad más lenta de las iniciativas condicionará al resto de las acciones. Debe ser el líder quien tome las acciones necesarias para sincronizar la velocidad de todas ellas.

Aun así, aunque el líder cumpla eficientemente su objetivo, lógicamente en un plan de acción con tantas iniciativas es inevitable que aparezcan situaciones no esperadas en el entorno de producción.

Velocidad de adaptación

Los más experimentados en integraciones sabrán lo difícil que es preveer todos los posibles escenarios de datos y su calidad que provienen de las integraciones. Al mismo tiempo también es complejo generar código que responda correctamente a cualquier entrada.

Sin embargo el escenario encontrado es uno en el que los ciclos en los que reproducir el error, realizar la corrección y el despliegue del arreglo es tremendamente pesado. Las acciones en global han de tener un buen plan de despliegue que permita añadir correcciones para evitar situaciones no deseadas con un mínimo tiempo de respuesta. Es más que recomendable configurar desde el primer momento alguna herramienta de integración continua con test unitarios que automatice el proceso de despliegue en todo lo posible. 

Gestión del conocimiento

Otro punto muy importante, para mí el que más. Es la correcta gestión del conocimiento que tienen los recursos en los equipos implicados en las acciones. Es muy importante que los recursos tengan una visión global y no puramente técnica de la información sobre el funcionamiento del negocio. Entender el porqué de las acciones, además claro está, del conocimiento técnico necesario para el desarrollo. Y no me limito a únicamente conocimiento de Java, si no a los procesos de negocio, procesos de producción, entornos de sistemas, configuraciones, planes de despliegue, planes de pruebas, etc.

Los equipos han de están implicados en todas las fases, y no convertirse en islas independientes entre ellas. Hay que buscar las sinergias, compartir el conocimiento, hacer equipo. A cambio tendrás motivación e innovación que vendrán de la mano. Recomendación, hacer reuniones periódicas con el equipo técnico, aunque sólo sea para cambiar impresiones.

Conclusión

Como se anunció en la primera parte del post, el proyecto se ha demorado debido principalmente a la demora del resto de iniciativas. Que un proyecto se demore, quiere decir que el tiempo asignado para ciertas tareas desaparece, por lo que hay que reasignar el tiempo restante entre las tareas que queden. A algunas se les asignará más o menos tiempo y otras tareas directamente desaparecerán. Una mala práctica, que puede ser fatal, es asignar todo el tiempo restante (incluyendo horas adicionales a la jornada habitual) en la consecución de las funcionalidades nuevas bajo cualquier coste, totalmente orientado a la producción, sacrificando tiempo para la validación. Hecho que entra totalmente en contradicción en un sistema que ha de estar 7×24 funcionando correctamente donde prima que siga funcionando sobre, que siga funcionando a veces pero con opciones nuevas. 

Hay funcionalidades nuevas que a veces son inevitables y que producen errores. También hay que vivir con ello, pero que dan un mal sabor de boca en altas esferas por mucho que se trate de explicar. Por ejemplo la incorporación de técnicas no antes probadas en la casa que permitan abordar un problema sólo detectable en producción y que antes no existía.

Implementar soluciones tecnológicas en los proyectos que antes no han sido verificadas para solucionar un problema nuevo es un riesgo. Sobre todo si el problema no es reproducible en un entorno controlado, ya sea por falta de configuración, presupuesto o el motivo que sea. Hay que hacer todo lo posible para que los errores siempre puedan ser reproducibles en entornos controlados, asegurar un mecanismo de trazas que permita recopilar y aislar los datos que han producido la situación no deseada. Cuanto antes se pueda reproducir, antes se podrá arreglar con garantías.

Cada nueva funcionalidad en un entorno complejo requiere la comprobación en multitud de situaciones diferentes, se puede tardar horas e incluso días en probar todos los caminos posibles. De este punto se derivan dos cosas, primero mantén el sistema lo más sencillo posible, cuantas más cosas se hagan más probabilidad de error y más checks tendrá tu plan de pruebas. Segundo, se un obseso de la reutilización y minimización de elementos (código fuente por ejemplo) que forman parte de tu sistema. Elimina todo lo superfluo, optimiza al máximo.

Si te dedicas al mundo del software es probable que algunos de estos problemas te hayan surgido con anterioridad. Así que:
¿Quieres compartirnos tu experiencia en la gestión de algún proyecto?

Autor: Ramón Arnau

Director de Arteco Consulting sl. Ingeniero Informático. Máster en Administración y Dirección de Empresas. Máster en Tecnologías de la Información. Auditor ISO 27001. ITIL.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *