Gestión de Proyectos

Las empresas actualmente están en constante evolución debido a la velocidad cambiante de los mercados. Para poder sobrevivir a los constantes cambios, es necesario contar con información actualizada de la operación y esto no es posible si no se cuenta con soluciones tecnológicas como las bases de datos, soluciones web e integración de soluciones.

El equipo de IT siempre será el responsable de coordinar las soluciones tecnológicas antes mencionadas para poder asistir las incidencias de las soluciones, la creación de soluciones y el soporte a la infraestructura física. Sin embargo, encontrar el personal idóneo, contar con capital para invertir en el recurso y obtener retorno sobre los productos y servicios que este personal produce es una receta un tanto difícil de realizar.

La base de realización y gestión dependen de una buena programación de actividades y recursos.

Inicialmente, es necesario que la infraestructura de IT y el soporte de esta esté definido y completo. No existen soluciones web o sistemas de información, si no se cuenta con servidores y personal capacitado para dar soporte de esta infraestructura. El personal de esta área solo responde por ella y no puede ser compartido para otras actividades. Los recursos de infraestructura siempre representan un costo elevado, sin embargo, al contar con un este equipo se garantiza el acceso a la información. Este acceso conlleva a tener servidores en diferentes lugares y continuar la operación, aunque una unidad de almacenamiento se dañe.

Una vez que el equipo de infraestructura este definido, es necesario que la empresa cuente con una plataforma de incidencias. En esta plataforma se pueden reportar incidencias en el funcionamiento diario de soluciones y hacer solicitudes de proyectos. Las solicitudes pueden ser nuevas soluciones tecnológicas y mejoras de soluciones tecnológicas ya existente. Esta plataforma permitirá dar seguimiento e inicio a las actividades de planificación por parte del equipo de proyectos y evitará la barrera de comunicación que puede generarse en un correo.

Proyectos IT

El departamento de proyectos IT es el encargado de gestionar recursos de IT para poder realizar proyectos. Estos proyectos nacen a través de solicitudes realizadas por la empresa. Este departamento está compuesto mínimo por un proyectista, un DevOps, un equipo de desarrolladores Front End, un equipo de desarrolladores Back End y un departamento QAS.

Los actores antes mencionados se encargan de realizar la planificación para la ejecución de proyectos. El proyectista define en conjunto al DevOps el alcance del proyecto.

En función del alcance, se definen las actividades a realizar y el proyectista elabora el cronograma de actividades y la ruta crítica del proyecto en conjuntos a los equipos de expertos y el DevOps. Cada actividad del cronograma de actividades debe de tener un recurso asignado, tiempo y orden de ejecución.

Una vez delimitado el cronograma de actividades, se llega a un acuerdo de tiempo de entrega con el cliente y se define si se requieren más recursos para poder cumplir con lo requerido. Una vez confirmada la fecha de entrega, esta planificación debe ser anexada a la planificación global de proyectos. En esta planificación se unen todos los proyectos y permite evaluar un global de avance de todos los proyectos y permite identificar si la asignación de recursos de un proyecto es viable con respecto a los demás.

Está claro que la planificación es un estimado de tiempo en el cual se espera obtener resultados de acuerdo a lo establecido, sin embargo, cuando no se logra cumplir con lo planificado, llegamos a los retrasos.

Retrasos en proyectos IT

Los retrasos pueden ser de muchos tipos, sin embargo, en proyectos de IT se deben a dos tipos de casos:

• La ejecución del proceso no se puede completar, un error no permite que termine el proceso.
• La ejecución del proceso da un resultado diferente al solicitado.

En este punto, el equipo de Test QAS se encarga de realizar el levantamiento de todas las incidencias reportadas por el cliente. La recolección de estas incidencias debe de contener obligatoriamente el paso a paso que esta ejecutando el cliente para llegar a la misma incidencia. Estos pasos deben de contener imágenes claras de los datos que se utilizan.

Una vez recolectada la base de datos, es necesario categorizar estos incidentes y separarlos entre errores y resultados diferentes. Una vez separadas las incidencias, es necesario categorizarlas y definir una estrategia de resolución. La regla base a seguir para resolver las incidencias es establecer la prioridad de solución en base a lo solicitado por el cliente. En caso de no tener una prioridad definida, es necesario establecerla la prioridad mediante los resultados de incidencias por categoría. La categoría con más incidencias es la primera a resolver.

En términos técnicos, no necesariamente resolver la categoría con más incidencias es la más compleja o la que aportará algo significativo a la solución, sin embargo, la óptica del cliente se enfoca en resultados de proyectos, por ende, ante mayor avance, mejor se posicionará el equipo dentro de la ejecución de proyectos.

En el tiempo en el cual se recolecta la base de datos de incidencias, los programadores siguen con sus actividades planificadas inicialmente. Sin embargo, una vez que la base de datos de incidencias esta lista, los programadores pausarán sus actividades y se dedicarán a resolver las incidencias.

Cuando se cuenta con grupos grandes de trabajo, se pueden generar estrategias en las cuales el 50% de los recursos asistirán las incidencias y el 50% continuará las actividades planificadas. Esto permitirá ver avances a nivel de proyectos, sin embargo, el proyectista tiene que tener en cuenta que las incidencias se deben de resolver si no, estas regresarán en el futuro.

Sin embargo, cuando el grupo es reducido a un programador de front end y un programador de back end, los más indicado es detener las actividades y completar las que están en retraso.

Estrategias para gestionar los atrasos

Los retrasos son finalmente un proyecto dentro del proyecto inicial. Este proyecto de retrasos tiene su propio alcance y consume recursos y tiempo del proyecto inicial. Es necesario completarlo lo antes posible para regresar al proyecto principal.

Una vez creada la base de datos de incidencias, es necesario entender que los errores a mitad de proceso, pueden nuevos errores al momento de continuar el proceso. Adicionalmente, al finalizar el proceso, este puede presentar un resultado completamente diferente al esperado.

Estas nuevas incidencias no deben de frustrar al equipo ya que esto es parte del proceso de pruebas. Lo más importante es evacuar las incidencias que evitan que los procesos concluyan y quedarse con un base de datos de incidencias que únicamente cuente con resultados que no concuerdan con lo esperado por el cliente.

Una vez que se cuente con la base de datos de incidencias que no cumplan con los requisitos del cliente, cada una de estas incidencias se volverán un proyecto dentro del proyecto de retrasos. Estas incidencias inevitablemente consumirán tiempo del DevOps y recursos Front end y Back end. A medida se vayan solucionando las incidencias, el retraso ira mermando y los recursos se irán liberando para retomar las actividades iniciales del proceso. Aunque la resolución de incidencias es el objetivo primordial para salir del estatus de retraso, esta resolución debe de contar con estrategias definidas para optimizar el tiempo de conclusión.

Inicialmente evaluaremos las siguientes estrategias:

Definición de alcance con paso a paso aprobado por el cliente

Al momento de definir estos proyectos dentro del proyecto de retrasos, es importante definir el alcance de cada incidencia y contar con un caso de pruebas de resultados esperados. Este caso de pruebas se debe solicitar al cliente, sin embargo, la mejor estrategia es contactar directamente al cliente y no suspender la reunión hasta conseguir el proceso con el resultado esperado.

De ser posible, grabar la llamada para poder consultar el video sin depender del cliente. Es importante recordar que ya entramos en retraso y nada hará que este estatus desaparezca, únicamente la conclusión de las incidencias. Por ende, hay que tomar el tiempo debido para establecer los alcances de cada incidencia.
Reuniones diarias de avance

La reunión diaria es un elemento desgastante para los involucrados pero necesario para evitar la prolongación del proyecto de retrasos. En estas reuniones, se define la asignación de recursos, el avance de las actividades y si existe algún bloqueo para completar la actividad.

Una vez que se levanten estos puntos, la reunión termina y se continúan las gestiones necesarias en el transcurso del día con los involucrados. El objetivo de esta reunión es poder medir minuciosamente el avance del proyecto de retrasos y las fechas de cumplimiento de las misma. Al inicio, es normal que el número de incidencias sea abrumador, sin embargo, únicamente resolviendo las incidencias se incrementará el indicador de avance del proyecto.

Toma de decisiones efectivas en cuanto a recursos

Es normal que, al entrar en retraso, el cronograma principal se vea afectado. Sin embargo, es claro que avanzar el cronograma inicial con incidencias, puede conllevar a incidencias posteriores que siempre van a regresar al mismo punto, las incidencias iniciales. Al tener esto en cuenta, es necesario definir que es más importante, enfocar todos los recursos para solventar las incidencias o, trabajar las incidencias sin destinar todos los recursos mientras se avanza lentamente en las actividades originales del cronograma.

En este punto, los más recomendable es no trabajar en paralelo y cerrar los retrasos, sin embargo, si avanzar en las actividades originales permitirá presentar un nuevo producto en corto tiempo, es mejor seguir esa dirección. Esta decisión se debe a que el cliente percibirá avances. Sin embargo, se debe de regresar a destinar todos los recursos a las incidencias, después de entregar el nuevo producto. En caso de que el nuevo producto se entregue en un tiempo posterior a 2 semanas, es mejor cerrar los retrasos y posponer la entrega.

Lecciones aprendidas

En muchos proyectos existe un falso éxito donde el proyecto se entrega a tiempo y con el alcance completado, sin embargo, el equipo no realizó una carga equitativa de trabajo, es decir que muchos actores cubrieron los roles de otros y los gerentes de proyectos asumen que este tipo de proceder es normal. Este mal hábito, normalmente es confundido con una óptica de trabajo diferente, cuando realmente es una clara deficiencia por parte del gestor de proyectos.

Cuando los retrasos surgen, es cuando empieza el verdadero aprendizaje de los actores que integran el proyecto. Los planes de resolución permiten al gestor de proyectos analizar las causas que generaron las incidencias. Resolver una incidencia aporta valor al porcentaje de avance del proyecto, sin embargo, definir la causa que provocó la incidencia tiene un impacto en las demás entregas del proyecto y en futuros proyectos.

Identificar Dobles Agentes

Una de las reglas más importantes al momento de resolver conflictos, es despersonalizar al problema y ver como solventar el incidente. Esta práctica siempre debería de funcionar ya que el experto está técnicamente capacitado para realizar las actividades asignadas y con una lista de objetivos claros, la actividad debería de completarse.

Por ende, la mejor solución siempre es confrontar las incidencias y no a las personas.

Lo antes mencionado es muy importante, sin embargo, el jefe de proyectos debe de estar pendiente de una conducta inaceptable a nivel de equipo. Esta conducta es, la del doble agente, este recurso siempre buscará brillar, aunque deba de apagar a otro. También se especializa en distorsionar la comunicación, ya sea de manera intencional o inconscientemente.

Esta conducta tiene como resultado, el avance de actividades a costa del fracaso de otras. Esta situación de manera prolongada trae como resultado directo entrar en retraso.

El retraso es el menor de los problemas ya que el personal afectado, empieza a sentirse incomodo y a desgastarse. La constante presión del retraso y el acoso del doble agente, terminarán por la deserción o el peor de los casos, la desmotivación y conformismo del personal afectado.

Normalmente, un doble agente no tiene este rol por elección propia, es más un mecanismo de supervivencia. Este mecanismo se activa al ser expuesto ante actividades que no puede realizar o defender. Esto no necesariamente se deba a que el recurso no esté capacitado debidamente en el área que se especializa, muchas veces las funciones del puesto están mal delimitadas.

El gestor de proyectos siempre debe de estar atento a esta situación, ya que es necesario mantener a los recursos del proyecto en condiciones óptimas de operación.

Para identificar a los dobles agentes, siempre es necesario evaluar la satisfacción de los recursos y del cliente. Normalmente, no es difícil identificarlos ya que sus acciones los exponen directamente y estas exposiciones son más notorias cuando la presión por retrasos está vigente.

Un llamado de atención en privado es suficiente para frenar este tipo de comportamiento. El llamado no debe de ser con enfado, basta con exponer la inconformidad de varios miembros del equipo y ver si algo interno o externo aqueja al doble agente.

Finalmente, se debe de tomar en cuenta que existen situaciones que rebasan al llamado de atención y esto se da cuando el doble agente ha llegado hasta su posición gracias a sus habilidades de doble agente. En este caso, el administrador de proyectos debe de usar las verdaderas habilidades del recurso y suplir las que no posee. Esto dejará al equipo en un porcentaje menor al momento de afrontar las actividades, sin embargo, es mejor poder dimensionar con el porcentaje real que con uno ficticio.