La Gestión de la Calidad en el software cambió mi vida

Un tema que tuvo un alto impacto profesional en mí fue el de Gestión de la Calidad en el desarrollo de software. Literalmente cambió mi vida para bien y para siempre.

Un tema que tuvo un alto impacto profesional en mí fue el de Gestión de la Calidad en el desarrollo de software. Literalmente cambió mi vida para bien y para siempre.

Hoy, es algo que difundo y comparto (a nivel de evangelizador) a donde voy, pues lo considero fundamental para el desarrollo de software.

Te comparto la experiencia con la que lo comprendí.

Cuando comencé a trabajar en tech, yo era un programador competente. Aprendía herramientas y lenguajes con facilidad. Me desenvolvía muy bien con ellos. Y resolvía bugs "rápidamente".

Mis jefes estaban encantados en esto último, pues veían cómo atacaba con voracidad la lista de tickets y disminuía su cantidad día con día. Sin embargo, esa lista tenía una característica: no tenía fin; si dejaba 5 de 50 en la tarde, al día siguiente volvía a tener 50.

Más de la mitad de mi tiempo estaba dedicado a arreglar bugs (varios míos, muchos ajenos). Todos lo veíamos normal: el software siempre tendrá bugs y defectos. Nuestro trabajo, creíamos, era así, haríamos un poco de software y lo arreglaríamos indefinidamente hasta que pudiese ser usado.

Esta creencia tenía un efecto negativo en mi vida, que también había normalizado: había períodos de crisis recurrentes, de jornadas largas, alto estrés y mucha desmotivación.

Un día, en medio de un proyecto caótico, me registraron en el curso de Personal Software Process (PSP). Accedimos a él a través de un programa del Gobierno Local.

Yo no quería ir porque no me iban a enseñar de programación y estaba muy ocupado arreglando bugs y procurando que el sistema no se cayera. Yo creía que, lo que me haría un mejor developer, sería aprender infinidad de herramientas y hacerme experto en ellas. Refunfuñando, asistí, pues estábamos obligados a hacerlo o perderíamos otras oportunidades en el programa Estatal.

El curso duraba diez días, divididos en dos semanas, con un período de tres semanas de receso entre cada parte. Me presenté al lugar donde serían las sesiones y desde el primer día mi teléfono no dejaba de sonar para reportar problemas del proyecto y yo estaba inquieto.

Traté de prestar atención al curso y ver qué había. Nos hablaron de disciplina, de procesos, de mediciones y de aprendizaje. Todos los días debíamos completar programas que resolvían problemas que nos entregaban en documentos. Había libertad de elegir lenguajes y herramientas. Eran problemas complejos, tomaban varias horas; la mayoría terminábamos entrada la noche o tarde. La mayor parte del tiempo la pasábamos arreglando cosas que estaban mal con el programa. Era mi normalidad, así que simplemente la seguí.

Esa primera semana pasé por dos de las tres etapas que caracterizan esta transformación:

1. No estoy entendiendo.

2. Esto es interesante, pero aún no veo su utilidad.

Completé los ejercicios. Hablé con mi instructor y planteamos objetivos para la segunda parte.

Volví a mi proyecto caótico. Durante tres semanas trabajé igual que siempre. No apliqué nada de lo que vi en el curso.

Regresé al curso, tres semanas después. Me recibe una palabra en la pantalla, que era el título de la segunda parte: CALIDAD. Fruncí el ceño y me senté.

Durante la primera semana, nos habían hablado de la importancia de la disciplina, la medición y el análisis del trabajo. En la segunda, de cómo llevar eso para producir resultados que quedaban bien a la primera. No sería necesario arreglar el programa, la primera vez que lo ejecutáramos funcionaría como se esperaba, sin fallas. “Eso no es posible”, pensé. Teníamos otros cinco programas para completar.

Recordé el reto que me propuso mi instructor al final de la primera semana: "Quiero que el programa 6 lo termines antes de las 4 PM del día que lo presentemos".

Yo, que salía en promedio a las 11 PM de esas sesiones, dudé. ¿Cómo iba a trabajar 7 horas menos? Nunca lo había vivido.

Por primera vez, puse en práctica consciente los conceptos del curso y lo intenté, pero no logré el objetivo en el programa 6. Terminé a las 7 PM, 4 horas antes de lo habitual, pero yo seguía incrédulo, aunque algo había cambiado.

Al día siguiente, me reuní con mi instructor y le dije: no es posible lo que me propones. Me señaló el logro del día anterior: 4 horas menos y me dice “estás más cerca del objetivo que de volver a tu vida anterior”. Yo no había reparado en la magnitud del logro, así que le pregunté qué tenía qué hacer. La respuesta fue: confía en el proceso.

Acepté y seguí el proceso. Como resultado, los programas 7, 8 y 9 fueron concluidos antes de las 4 PM los tres días restantes, sin fallas y cumpliendo los requerimientos. Yo podía salir y ser libre para hacer lo que quisiera

Mi cara era de asombro, ¿qué había pasado? No tenía una respuesta clara.

La semana siguiente, llegué a mi trabajo normalmente, pero yo ya había cambiado. Era lunes.

Mi jefe me asignó el trabajo del día: desarrollar un módulo nuevo y preguntó "¿cuándo lo terminarás?". Mecánicamente, respondí "en dos semanas". Hizo una mueca de desaprobación y se fue.

Esa vez no trabajé como siempre. Decidí hacerlo como en el curso. Apliqué los conceptos. Seguí la disciplina. Medí, registré y analicé. El jueves, solo cuatro días después, me presenté con mi jefe.

- Ya terminé.
- ¿Ya terminaste? Me habías dicho que dos semanas
- Sí, pero ya está listo

Incrédulo, mi jefe me acompañó al escritorio y probó. Probó. Probó. Incrédulo. El módulo funcionaba, no fallaba y cumplía los requerimientos. Se instaló ese mismo día.

Antes de levantarme de mi escritorio, ese día, estaba completando la tercera fase de la transformación:

3. Cómo pude vivir sin esto

El curso no me enseñó a programar. No me enseñó ninguna cosa técnica, pero yo ya era capaz de entregar buenos resultados en la mitad del tiempo.

¿Qué fue lo que cambió? Mi actitud ante la calidad:

• Asegurarla desde el segundo 1

• Cuidarla en todo momento

• Evitar que los defectos lleguen a testing

• Aprender de los errores para los siguientes ciclos

Mis ideas previas eran equivocadas:

No es normal que el software siempre tenga defectos

Lo normal debe ser que tengamos la actitud de prevenirlos y evitarlos. Calidad total a lo largo del trabajo.

Desde entonces, sé que la Excelencia Técnica es muy necesaria para desarrollar software, pero la actitud de trabajo tiene una importancia mayor.

Esa experiencia transformó mi vida y quiero transformar también la tuya del mismo modo.

En los siguientes artículos hablaré de la cultura de la calidad en el desarrollo de software y cómo puede cambiar tu vida como hizo con la mía. ¡Nos estaremos leyendo!