Gestión de Proyectos

El mercado actual evoluciona de una manera tan acelerada que las empresas están constantemente en un proceso de creación y adaptación de las soluciones tecnológicas con las que dirigen sus negocios.

Inicialmente, las empresas se preocupaban por llevar registros contables para pagar sus impuestos y no caer en multas elevadas, posteriormente adecuaron sus soluciones a realizar actividades de forma automáticas o semi automatizadas. Hoy en día, la toma de decisiones debe ser lo más visual posible para poder ejecutar todos los puntos administrativos de manera eficiente.

Para poder cumplir con todo lo antes mencionado, los managers de IT deben de poseer habilidades de planificación y gestión de proyectos, adicionales a los conocimientos ya adquiridos de lenguajes de programación e infraestructura de sistemas.

Los socios o dueños de las empresas para los cuales laboran los managers de IT, siempre estarán buscando el modo de optimizar los procesos de su empresa y poder reducir los costos y aumentar las ventas y ganancias al máximo. Los socios siempre buscarán productos tecnológicos para poder cumplir sus objetivos y en este punto, es que las necesidades se convierten en proyectos.

Actores de un proyecto IT

Un proyecto es la planificación de actividades y recursos para cumplir un fin. Existen tres actores principales en un proyecto:

• Stakeholders: Son los inversionistas que requieren de la realización del proyecto y contratan a un equipo de especialistas para llevar a cabo el trabajo.

• Project Manager: Es el encargado de realizar los cronogramas de actividades, que contiene tiempos de ejecución y recursos. Estas actividades están enlazadas y se ejecutan con orden de prioridad y forman una ruta desde la primera actividad hasta la última, lo que se conoce como ruta crítica.

• El equipo de trabajo: Está compuesto por personas especialistas en diferentes campos y estos definen las actividades y tiempos que se utilizarán en el cronograma de actividades. El experto es quien indica la actividad y el tiempo, el Project Manager emplea estos datos para generar el cronograma de actividades. Para poder cumplir con un proyecto, es crítico poder definir el alcance del mismo.

Alcance de un proyecto de IT

Al igual que un proyecto normal, un proyecto de IT posee un alcance y la definición de este se componen en base al trabajo de un DevOps.

El DevOps es el encargado de poder transformar la visión de los Stakeholders en un producto. El DevOps puede ser el mismo manager de IT, sin embargo, lo ideal es que sean personas diferentes. El Project manager se encargará del cronograma y seguimiento y el DevOps de acercar el alcance a un prototipo.

El DevOps posee conocimientos de Front End (diseños de pantallas, funcionalidad de pantallas, mapa de la solución) y Back End (validaciones, API, bases de datos), adicionalmente está capacitado en liderar las pruebas QAS que definan el correcto funcionamiento del producto.

Una vez definido el Alcance con un prototipo, se procede a reunir el equipo de programadores Front End y Back end.

Gestión de proyectos IT simultáneos

El manager de IT enfrentará retos diarios de diferentes soluciones, donde cada una tendrá su propio alcance y personas que representan a los Stakeholders. Para poder tener una gestión correcta de los proyectos es necesario de manejar varios puntos antes de empezar.

El primer punto consiste en la holgura de tiempos. Los Stakeholders invierten su dinero en recursos que desarrollarán el alcance. El dinero sirve para comprar el tiempo de dichos recursos. Previamente a la definición del cronograma, se le aclara al experto que las actividades las midan con un tiempo extendido. Al presentar el cronograma, los Stakeholders aceptará la propuesta dependiendo de la urgencia y presupuesto para el proyecto. La holgura servirá en caso de que los Stakeholders necesiten la entrega de proyecto en un plazo más cercano, poder sacrificar holgura y aceptar la fecha de entrega sugerida. En caso de que acepten los tiempos holgados, se cuenta con un colchón de tiempo para resolver imprevistos. Este colchón es adicional al porcentaje de imprevistos que se calcula.

El segundo punto consiste en tener una programación de todos los proyectos en un solo cronograma. Esto permitirá al manager de IT poder visualizar la disposición de sus recursos a través del tiempo y poder anticiparse al reclutamiento de personal para no entrar en desabastecimiento.

El tercer punto es la comunicación dentro del equipo. Aunque la tecnología permite poder tener reuniones desde cualquier punto, realizar reuniones donde no definan soluciones, prototipos o planes de trabajo, se consideran como reuniones improductivas que solo consumen el tiempo de trabajo de los recursos. Saber cuándo se debe de realizar una reunión es muy importante.

Muchos creen que los correos pueden evitar reuniones, sin embargo, el mal uso de la herramienta hace que los puntos importantes se pierdan.

Dentro de la comunicación existe un punto más crítico que las herramientas como reuniones y correos y es la desinformación. La desinformación creada por recursos que realizan actividades que no le corresponden termina en cumplimento de actividades desde una falsa óptica. Esto causa la reutilización de recursos y consumo de tiempo en reparar alcances mal definidos.

El cuarto punto consiste en el manejo de incidencias. Es normal verse abrumados por una base de datos de Excel con más de 100 incidencias. Lo más importante en este punto es buscar metodologías de hacer lo más amigable el proceso de resolución y encontrar los resultados deseados en cuanto a avances.

El error más común recae en intentar solucionar punto por punto la base de datos de incidencias.

Al encontrarse con una base de datos gigante, lo más importante es agrupar las incidencias. Finalmente transferir esos grupos a una o dos páginas de Word. El tracking es más agradable y puede ser transmitido con mayor facilidad a un grupo y se puede imprimir con facilidad.

Una vez que se cierre un punto, este representará varias líneas de la base de datos y el avance se verá reflejado de mejor forma que ir línea por línea.

La base de datos puede irse pintando de un color y se espera ver el avance a medida que la base de datos empiece a tomar la tonalidad del color con el que se pinta.

Puntos clave previos al inicio del proyecto

El manager de IT debe de involucrar al DevOps desde antes del día 1. Aceptar una fecha sin tener un prototipo, es la estrategia perfecta para llevar al fracaso un proyecto. El fracaso es medido por el incumplimiento del alcance en la fecha de entrega pactada.

Los recursos del proyecto no pueden estar compartidos. Muchas veces se escucha a los encargados decir que un recurso trabaje medio día en un proyecto y medio día en otro. El resultado de esta práctica es alargar el tiempo de ambas actividades con un alto riesgo de incumplimiento.

Los proyectos pueden estar divididos en fases y cada una tiene fechas de finalización y de inicio. Sin embargo, la fecha a cumplir es la del alcance. No se pueden empezar actividades sin haber culminado las pendientes. Se pueden atrasar las fechas de inicio de fases, pero no la entrega final.

El cronograma debe de estar listo previo a la fecha de inicio del proyecto. Muchos estilan a utilizar tiempo del proyecto para realizar el cronograma de actividades y tiempo después recaen en que han consumido el tiempo de actividades y no tienen ningún entregable tangible. Una vez que el alcance y la fecha de entrega han sido definidos, es el momento exacto en el cual el cronograma debe de empezar a crearse. Si ciertas actividades están definidas sin que el cronograma aun este creado, se debe de empezar inmediatamente. Un documento de guía como lo es el cronograma, no debe de impedir el inicio de actividades, todo tiempo ganado al inicio, es crucial previo a la fecha de entrega.

El gerente de proyectos debe de estar constantemente entregando avances tangibles. El alcance no puede ser entregado en una sola entrega. Es necesario definir metas que vayan aportando al resultado final. El peor error es intentar entregar el 100% en un solo paso. Es obligatorio dividir el alcance y definir los entregables por fases. Una vez que la fase esté completada al 100%, el avance del alcance será inamovible y esto trae como ventaja fijar un porcentaje de avance que no disminuirá en el futuro.

Así como se mencionó la holgura de tiempos en las actividades, se debe de hablar con el equipo para intentar salir de las actividades de lo antes posible sin afectar la calidad. Hacer esto garantiza aumentar el colchón de tiempo para resolver imprevistos. En caso de que el equipo termine las actividades en su totalidad y el proyecto tenga agendado tiempo adicional, el equipo tendrá este tiempo para preparase para la presentación final. Este tiempo no debe de utilizarse para cubrir actividades de otro proyecto.

Indicadores y Estrategias de presentación de avances

Todos los proyectos poseen un Alcance, sin embargo, para poder lograrlo, es necesario crear una serie de actividades. Estas actividades a su vez pueden tener otras actividades y esto puede extenderse los niveles que sean necesarios. Este escenario siempre ocurre y es cuando se debe de manejar el proyecto en fases. Cada fase será un proyecto dentro del mismo proyecto.

Las fases permitirán saber el porcentaje de avance del proyecto. Este punto es crítico tanto para el Project Manager como para los Stakeholders ya que permiten el seguimiento de ambas partes. Lo más importante es tener siempre a los Stakeholders satisfechos en cuanto a los entregables y al cumplimiento para poder conservar su confianza.

El incumplimiento del primer entregable garantiza el incumplimiento del segundo y de todos los sucesivos incluyendo la entrega final. Esto genera inconformidad por parte de los Stakeholders y deja marcado al equipo. Es muy común ver como una solución cumple con el alcance, pero la ejecución y entrega son desastrosas. Esto puede evitarse fácilmente con una buena planificación de tiempos y una definición correcta del alcance con su prototipo.

Cuando se manejan varias fases de un proyecto, se debe de tener cuidado en la forma en que se presentan los avances frente a los Stakeholders. Es muy común que se realicen actividades con tal de ver un avance, pero al final, la culminación de actividades aisladas no genera ningún entregable tangible. Si alguno de los Stakeholders identifica esto, no volverán a confiar en ninguno de los indicadores presentados.

En cuanto a los indicadores del proyecto dentro del equipo de trabajo, se debe de manejar siempre la fecha de entrega y la cantidad de actividades. Al calcular los días entre la fecha actual y un día anterior a la fecha de entrega, obtendremos los días restantes antes de la entrega. A los días restantes antes de la entrega, se le restan los días feriados y los que no se trabaja como sábados y domingos, esto nos deja los días totales laborables antes de la fecha de entrega.

Al dividir las actividades totales entre los días totales laborables, encontraremos el indicador de cuantas actividades hay que realizar por día. Aunque el cronograma indique que las actividades tienen una duración de X días, sabremos que, para poder cumplir la fecha, es necesario terminar las actividades antes de lo previsto.

Es en este punto, las holguras planificadas se hacen efectivas. En caso de que las holguras de tiempo no sean suficientes, se deben de tomar decisiones de pago de horas extras o contratación de recursos adicionales.

Un indicador para medir la cantidad de recursos adecuados, se calcula al dividir los días totales laborables antes de la fecha de entrega entre 8 (horas laborables por día). El resultado indica cuantos empleados están disponibles por día, en caso de contar con menos empleados del resultado, el equipo estará sobre cargado y es posible que se requiera de una contratación adicional, en caso de contar con más empleados de los que indica el indicador, se puede analizar si se puede utilizar el recurso disponible para avanzar otra actividad.

Los indicadores siempre van a permitir dar una claridad de los avances y es importante manejar los proyectos con mucha granularidad. Entre más granular sea el proyecto, esto nos dará la ventaja al momento de presentar avances.

Semanalmente se presentan avances sobre el proyecto. El peor de los escenarios es tener una pobre granularidad que no deje que se reflejen los avances. Sin embargo, siempre será mejor presentar indicadores que se muevan semanalmente a indicadores que se muevan quincenal o mensualmente.

Producto Mínimo Viable (MVP)

El seguimiento y desarrollo de las actividades de un proyecto requieren de diferentes herramientas y metodologías que son aplicadas en diferentes momentos y esto depende del equipo de trabajo. Habitualmente se intuye que las metodologías no funcionan, pero muchos no se preguntan si hace falta un jugador en el equipo.

El principio de utilización de una herramienta o metodología es contar con los actores (Project Manager, DevOps y equipo de trabajo).

Después de reunir el equipo indicado, es necesario que el Project manager entienda las necesidades de los Stakeholders, estos necesitan entregables tangibles. Estos entregables no son documentos, presentaciones ni diseños. Estos productos deben de ser prototipos interactivos.

Los más importante recae en que el prototipo cumpla con las funcionalidades esperadas dentro de la fase en la que se encuentra el proyecto. Este prototipo es la base para llegar a la solución final y se irá ajustando a medida transcurran las fases del proyecto. A estos prototipos se les conoce como productos mínimos viables.

La ventaja de utilizar este modelo de trabajo es que permite la flexibilidad de poder rediseñar los prototipos sin afectar drásticamente los tiempos pactados. En caso de que el prototipo no sea lo que los Stakeholders esperan, este modelo de trabajo permite recuperar cierta base y trabajarla para alcanzar los cambios esperados. Los cambios y diseños de lógicas siempre deben de correr por cuenta del DevOps y el equipo de desarrolladores.