En los 90’s y 2000’s: Desarrollo de Software
El desarrollo de software lleva muchísimo tiempo antes de los 90’s. Y en mi experiencia, lo conozco desde el 2000’s, desde cuando se enseñaba sobre desarrollo en capas, UML y el ciclo de vida secuencial (predictivo: planificación, análisis, diseño, implementación, pruebas e integración y mantenimiento).
Confieso que cuando aprendí cada una de estas materias me resulto fascinante. Amaba programar, pero, aún más analizar.
Recuerdo muy bien, que el profesor nos exhortaba a que un buen análisis y diseño debía concluir en un documento detallado que empezaba con los diagramas de negocio, diagramas de actividades, luego los casos de usos de cada proceso, para pasar a la especificación detallada de cada uno de ellos con prototipos incluidos, siguiendo con los diagramas de secuencia, y etcétera, que daban pasado al diagrama de clases para resultar en el modelo entidad relación y por último en la base de datos. Claro, sin olvidar hacer tu diagrama de despliegue, sino como se iba a integrar el software con el hardware.
Toda esa documentación que era obligatorio entregar como parte de la metodología y entregables del proyecto, se envía al cliente (interno o externo), quien procedía a aprobar -muchas veces sin ni siquiera leer el gran documento con decenas sino era cientos de páginas, de las que entendía poco o nada- y con esa firma, recién se daba paso a la implementación, es decir, al desarrollo del software.
La regla por la que nos regíamos en ese tiempo era; si haces un buen análisis, el desarrollo debe ser exitoso, porque cuando menos “piensen” los programadores es mejor. Lo que significaba que el programador no debería tener preguntas, debía estar todo claro en el documento y con eso trabajar en modo asilado (él y su PC, en alguna parte de la oficina o en alguna parte del mundo).
Los programadores éramos sacados o liberados de otros proyectos para empezar a uno nuevo, muchas veces sin que se nos explique el negocio y/o los procesos del nuevo proyecto. ¡Ah! pero, si nos entregaban un documento de texto que debíamos seguir al pie de la letra.
De programador a analista
Bajo esa forma de trabajo, trabajé (valga la redundancia) varios años y en diferentes consultoras y empresas (chicas, medianas y grandes), todas ellas con el mismo chip: «El analista es el cerebro y los programadores son la mano de obra mecánica». Y lamentablemente hasta hoy hay varios lugares que siguen trabajando de esta forma.
Esta forma de pensar era reforzada con el pago de los salarios. Un buen analista ganaba como mínimo un sueldo y medio más que un buen programador. Además, el analista era un cargo superior al del programador. Por eso, no resultaba sorprendente que muchos querían desesperadamente pasar de un puesto a otro, a pesar de no tener vocación.
Realmente esto siempre me pareció muy raro y hasta injusto. Tenía compañeros muy habilidosos y capos programando que no querían ser analistas, ni jefes. Ellos querían ser programadores, porque eso les gustaba y lo hacían muy bien, claro que, económicamente no era atractivo. Muchos de ellos, migraban a consultoras de software que desarrollaban para empresas trasnacionales, allí si podían ser económicamente recompensados, aunque como ellos bien decían, no tenían vida.
En mi caso, el cambio fue por vocación. Creo que pase poco tiempo programando (poco más de tres años), menos de lo que me hubiera gustado estar y los suficiente para entender cómo funcionaba la metodología y como yo pensaba que debía funcionar.
En el último año y medio ya no solo era programaba, sino que también así análisis, era “analista – programadora”, es decir, debía hacer los dos roles bien por el mismo precio, pero, eso era un plus para ascender al siguiente nivel: analista de sistemas.
Yo estaba motivada. Solo los analistas podían interactuar con las personas del negocio, conocer los procesos, conocer a fondo lo que se quiere hacer, ir a reuniones y muchas veces cuando no había un jefe de proyecto destacado para ese proyecto, pues el analista cumplía ese rol, tenia un equipo de personas para juntos hacer sistemas, y eso era lo que yo quería, por eso era yo había elegido mi carrera: Ingeniería de Sistemas.
En esos 3 años aprendí muchísimo. Yo estaba por terminar la universidad cuando empezaron a llegar luego nuevos conceptos para el mundo del software.
Gestión de Proyectos
Pasando ahora a la gestión de proyectos. Parte de la gestión implicaba convocar a las reuniones semanales con el equipo y con cliente. Se actualizaba el cronograma y se preparaba una presentación para la reunión, con un informe detallado con indicadores de tiempo, costo y alcance. Explicando los avances y retrasos en caso existiera y que se iba a hacer para recuperarlo.
Un detalle sobre los proyectos era que realmente nunca acababan en tiempo y forma. Generalmente los costos no variaban, o tal vez ligeramente, pero, el tiempo y la forma sí que lo hacían.
Durante las primeras semanas o meses, dependiendo del dimensionamiento del proyecto todo marchaba según lo planificado. Algunas veces con algunas observaciones que se solucionaban de forma sencilla. En esos días todos salíamos a la hora de salida acordada. Sin embargo, al pasar de los días iban saliendo nuevos “detalles” no especificados que empezaban a hacer ruido, mucho ruido.
A veces, era el cliente (interno o externo) quien se daba cuenta a unas semanas de terminar, que el proceso detallado, que los prototipos entregados o que «algo» no era lo que él esperaba y debía de cambiarse. Esto claro, desataba reuniones de emergencia, que había veces se tornaba en una batalla campal de palabras.
El cliente justificaba los cambios, indicaba que los documentos entregados no eran comprensibles o desconocía la existencia del mismo que por cierto tenia su firma.
El jefe de proyectos del área de sistemas de la empresa y/o el equipo de proyectos de la consultora tratába de sustentar lo que se había hecho con papeles y correos. Para que finalmente en su mayoría de casos terminar en un: “Sí, lo vamos a hacer”. Después de todo: “el cliente siempre tiene la razón”.
Me gustaría explicar que los “cambios” o «nuevos detalles», no solo eran porque al cliente se le ocurrían, sino también, porque desde el inicio no se entendió los procesos del negocio o no se entendió lo que realmente quería el cliente. Era hasta entendible que esto pasara. El analista y el cliente se debían imaginar como seria el sistema de inicio a fin en un tiempo limitado y sin opción de cambios posteriores. ¿Complicado, no?
Desarrollo de los cambios: Poco tiempo y mucho trabajo en equipo (agilidad).
Con la aceptación de cambios venia la frase: “no sé cómo, pero, debemos tener todo para XX fecha”. Y en ese momento, ya todos sabíamos que significaba eso: Sí, eso mismo que estas pensando, las famosas amanecidas.
Y aquí es donde más aprendí de agilidad. El ser ágil estaba inmerso dentro del proceso tradicional y resultaba que era la forma como finalmente se llegaba al objetivo.
- Como ya no había tiempo, el analista les explicaba a los programadores los procesos restantes y los cambios -para que ya no tenga que leer el documento- juntos entendían que ha cambiado y que deberían hacer. Se usaban pizarras, hojas y plumones de colores para entender mejor.
- Los programadores tenían más claro que estaban creando así que empezaban a volar con las líneas de código, cosa que emocionaba a muchos a pesar del cansancio que esto implicaba.
- El jefe de proyecto o analista era el encargado de resolver cualquier impedimento (servidores, ancho de banda, comprar la cena, gestionar los pasajes, etc.).
- El equipo o el profesional de QA por otro lado, se olvidaban de la documentación detallada que deberían hacer (plan de pruebas) y se enfocaban en dar feedback rápido y sencillo lo antes posible para las correcciones.
- El ideal era que el equipo trabaje a su máximo potencial .
Y en esos momentos a pesar de la crisis, era cuando todos trabajamos en equipo con un solo ideal: “Terminar el proyecto”. Y aunque tal vez estaba mal enfocado; eso me gustaba. Eso era una pequeña parte de ser «ágil«, sin saber como se llamaba y desconociendo todo lo bueno que nos traería años después. Veamos los valores del manifiesto ágil creado en el 2001.
Ya para finalizar, quiero recalcar que no todo salía mal, ni todo tenía problemas. Muchos de los sistemas en los que participé, hasta hoy siguen funcionando. Algunos han mejorado en apariencia manteniendo las bases y otros siguen haciéndole guerra a ERP world class.
Si tienes preguntas cómo: ¿Qué es agilidad y por qué todos están hablando de eso? ¿Por qué yo (jefe/líder/analista/ejecutivo…) debo saber de agilidad? ¿Quienes hacen agilidad?… y sobre todo, si buscas respuestas a estas y otras preguntas, te esperamos en Agile Fundamentals, dale clic aquí y entérate de todos los detalles. ¡Nos vemos el 26!
Saludos.
Johana Chuquino
Johana Chuquino
