¿Qué haces cuando amas la tecnología? ¿estás listo para el cambio en las actividades diarias que conlleva pasar de Desarrollador a Gerente de Proyecto o Project Manager?
Si bien el camino de todos es diferente, compartiré mi historia de cómo terminé como PM.
Comencé a trabajar como programador independiente en C++ y VisualBasic antes de terminar la universidad. En aquellos días, uno tenía que ser un gato de todos los oficios. Hice desarrollo web, administración de sistemas, administración de bases de datos y más.
Esos fueron los días previos a la crisis de las .com, y a medida que trabajaba más y más, me especialicé en el desarrollo de bases de datos SqlServer para pequeñas y medianas empresas. Durante muchos años de mi carrera me la pasé limpiando bases de datos en Access o creando accesos de datos desde hojas de trabajo de Excel, que se llenaban con más o menos algún criterio. Pero era muy pesado el servicio que venía después de la entrega.
Terminaban ocurriendo cosas raras, como que los empleados de la empresa llenaban de virus sus computadoras o simplemente, en un momento de locura e inconsciencia, borraban toda la base de datos. Todo esto acababa por ser mi culpa de alguna u otra manera.
Fue entonces cuando empecé a dejar de desarrollar, para mas bien, diseñar proyectos, e incluso comencé un negocio de consultoría con un amigo. La emoción de trabajar con empresas y resolver sus problemas era poderosa. Se sentía genial lidiar con desafíos nuevos y emocionantes a diario, y era otro IT el encargado de resolver esos problemas que surgen durante la implementación.
Una vez ejerciendo, mi primera tarea fue ayudar a un equipo a definir el rol que cada quién debería asumir. Trabajamos en la creación de estándares y documentación, etc., el tipo de cosas que todos tienen que hacer, pero a nadie realmente le gusta hacer. Después de días de trabajar en esto, finalmente llegó el momento de poner el proyecto a caminar.
Exactamente: ¿Qué hace un Gerente de Proyecto?
Tal vez se pregunte, como hice inicialmente, ¿qué hace exactamente un Gerente de Proyecto? En pocas palabras, combinamos todas nuestras experiencias de vida con tecnología para ayudar a los clientes a resolver problemas.
Y no cualquier cliente, algunos de los clientes más grandes son nombres conocidos. Pasamos una buena cantidad de tiempo escuchando los desafíos que enfrentan los clientes y analizando preguntas desafiantes para encontrar la raíz de sus problemas.
Buscamos patrones y tendencias sobre múltiples problemas para ver cómo se pueden mejorar los sistemas y procesos. Identificamos los puntos débiles que impiden que las empresas cumplan con sus objetivos o pasen al siguiente nivel.
Pero pronto descubrí que no todo ocurría como se planificaba. Había varias razones, pero, puedo citar como las principales que la gente asumía la tecnología como algo que ayudaba a ser más rápido, que las computadoras son artefactos mágicos o incluso que son inteligentes (se siguen vendiendo pequeñas computadoras de bolsillo como teléfonos inteligentes, una gran mentira) o mas allá de eso, los sistemas iban en contra de una cultura corporativa arraigada y simplemente se negaban a ingresar los datos asegurando que era un proceso engorroso.
Uds. dirán: ¡Y volvió el dolor de cabeza!, en cierto modo, pero me divertía más. Con el paso del tiempo encontré un sistema, un paradigma que me ayudaba a que los clientes asumieran el proyecto de forma diligente, que entendieran la verdadera razón para implementar la tecnología. El Seis Sigma (6 σ)
¿En qué ayuda el Seis Sigma?
Es una estrategia de mejora de procesos, centrada en la reducción de la variabilidad de los resultados del mismo, reforzando y optimizando cada parte del proceso consiguiendo mitigar o eliminar los defectos o fallos en la entrega de un producto o servicio al cliente.
Suena a utopía, pero no lo es, apenas la gente le agarra el ritmo lo agradece, lo entiende, lo abraza, lo termina aplicando a su vida cotidiana.
Tiempo necesario: 180 días
El proceso seis sigma se caracteriza por 5 etapas concretas
- Definir
consiste en poner en palabras cual es el dolor que está sintiendo la organización y validarlo, a la vez que se definen los participantes del proyecto.
- Medir
consiste en entender el funcionamiento actual del proceso que se pretende corregir o mejorar.
- Analizar
pretende averiguar las causas reales del problema o defecto.
- Mejorar
determinar las mejoras y planificar el código a programar procurando minimizar la inversión a realizar.
- Controlar
se basa en tomar datos para analizar con el fin de garantizar la continuidad de la mejora y valorarla en términos económicos y de satisfacción.
Estos pasos se ejecutan en ciclos, que generalmente yo implemento en bucles de seis meses, de manera que se controla por seis meses la versión previa al mismo tiempo en que se desarrolla la versión siguiente. Y todo de manera clara y transparente, tanto para la gerencia como para el programador junior.
¿Y qué cambió más en mi vida diaria?
Lo principal fue dejar de ver los trabajos como algo que tiene un inicio y un fin, un requerimiento de un cliente con un plazo de entrega. Debo admitir que eso era lo más estresante en mi vida de desarrollador independiente. Que inevitablemente el software desarrollado iba a fallar, porque falla, pero el cliente veía esto como que había contratado un mal programador, y no como un proceso normal.
Dejé de hacer contratos por desarrollo de proyecto y empecé a hacer contratos de lo que yo llamo «mantenimiento de proyecto» y trato de establecer al menos un año de contrato, estos es, dos ciclos de Seis Sigma.
Los proyectos consiguen, por un lado, mejorar las características del producto o servicio del cliente, permitiendo conseguir mayores ingresos, y por otro, el ahorro de costos que se deriva de la disminución de fallas.