No soy un recurso
La creatividad e innovación no se asignan en MS Project
Recuerdo con claridad la primera vez que sentí que faltaron al respeto a mi trabajo. Eran cerca de las 9 de la noche y la oficina estaba casi vacía. ¿No te vas? me dijo un compañero. Yo negué con la cabeza y seguí escribiendo un email al gerente de desarrollo. Mi puesto era de tester y durante las últimas dos semanas estuvimos trabajando jornadas de 12 horas (y hasta más). La fecha límite llegó sin tener el software terminado y funcional. Esa noche, en un tono que intenté conciliador, escribí cuáles pensaba que eran los “puntos a mejorar” y que debemos hacer para evitar desastres como el que acababa de pasar. Palabras como planeación, capacitación, procesos y análisis a detalle salieron en ese email. De eso han pasado 10 años.
Durante todo el desarrollo, los jefes nos recordaban la criticidad de la fecha, por qué era inamovible y las demandas que podríamos tener. Me enojé aún más cuando me enteré que esa fecha “inamovible” lo es desde hace muchísimos años, ya que es cuando el SAT (la agencia que recauda los impuestos en México), le exige a las empresas privadas reportar los impuestos pagados y retenidos a nombre de sus empleados. Por supuesto, mi empresa había conocido esa fecha desde siempre ya que no era nueva en el negocio. Ese dolor de cabeza lo sufría cada año. ¿Por qué no hacen algo? ¿Por qué prefieren arriesgar su negocio? No lo podía entender.
Poco tiempo después me fui de esa empresa con el objetivo de aprender a desarrollar software sin dolor y con clientes satisfechos. Estudié una maestría (Ingeniería de Software, en Madrid) en la que aprendí a estimar con puntos funcionales, a establecer procesos y métricas, técnicas de pruebas, administración de la configuración. El control del desarrollo propuesto con estas técnicas y metodologías me hacía feliz. Incluso, le llamaban niveles de madurez.
Cuando volví a Querétaro, entré a trabajar a una empresa que ya tenía la tan anhelada madurez: CMMI 3. Los procesos institucionales, las métricas, las auditorías, las verificaciones, todo estaba ahí. Mi corazón desarrollador era feliz. Era tester y seguía todos los procesos, procedimientos y guías que mi proceso especificaba. Sin embargo, comencé a notar que algunas cosas no funcionaban: testers y desarrolladores no formaban equipo; incluso tenían jefes y objetivos diferentes. La ejecución de las pruebas aportaban muy poco valor ya que se ejecutaban (manualmente, claro) hasta el final del desarrollo y a las carreras. Si acaso se ejecutaban completamente, algunos bugs no se atendían. El proceso exigía que el cliente estuviera de acuerdo con nuestros casos de prueba. Para mí, eso era transferir la responsabilidad del equipo, al cliente. Para algunos líderes de proyecto, mi trabajo era tratado como un mal necesario que requería el proceso institucional y que debían aguantar.
Sé que no era la única afectada. Recuerdo a un desarrollador que quería innovar con tecnología para hacer un mejor manejo de versiones. Instaló un servidor de integración contínua y mudó el código fuente de CVS a SVN. Tenía métricas de calidad y productividad de código. El equipo estaba motivado. Sin embargo, esto estaba fuera del proceso institucional y se ganaron una desviación de auditoría. Por supuesto, la moral se fue para abajo y el desarrollador terminó renunciando.
Tener una certificación CMMI era importante para mi empresa y supuestamente una garantía de calidad hacia nuestros clientes. Lamentablemente nunca me enteré si alguna de las aplicaciones en las que participé llegaron fueron puestas en producción.
Aún así, aguanté un poco más. Me moví a las áreas de procesos y auditorías para entender la foto completa: Control de la Calidad y Aseguramiento de la Calidad. El resultado, a pesar de haber logrado un CMMI5, fue una crisis profesional.
Me alejé del desarrollo de software para dedicarme a escribir. Fue un año grandioso: viajé, conocí al que ahora es mi esposo y me hice más adicta a la literatura.
Un año después, volví al Desarrollo de Software. Necesitaba trabajar en equipo, crear juntos algo importante. También necesitaba dinero. Así que cuando me ofrecieron integrarme a una empresa como gerente de QA, acepté.
La gerencia de desarrollo estaba tratando de implantar algo llamado Ágil-Scrum. Investigando un poco más me topé con un libro llamado Agile Testing: a Practical Guide for Testers and Agile Teams, escrito por Lisa Crispin y Janet Gregory. Entonces tuve una maravillosa revelación: entendí por qué tantas métricas, procesos, horas extra no habían funcionado: la gente es tratada como si fuera una tuerca que ajustar en la línea de producción.
No soy un recurso que contabilizar en MS Project. Soy una persona inteligente que quiere crear. Sé que el trabajo en equipo funciona. Confío en que la gente de desarrollo es apasionada y noble. Que los retos se superan con tecnología y aprendizaje continuo.
Por fortuna me encontraba en una empresa que me escuchaba y que estuvo dispuesta a intentarlo. Dejé la gerencia de QA para convertirme en Agile Coach / Scrum Master y guiar el cambio. Los testers se integraron al equipo de desarrollo. Quitamos alguna “grasa” del proceso y aprendimos a trabajar en iteraciones. Las cosas se movieron y terminé como gerente de desarrollo. Traté de entender nuestra cultura organizacional al mismo tiempo que hacía malabares con nuestra deuda técnica.
En ese rol gerencial entendí que tratar a las personas como recursos es muy sencillo. Con el “poder” asignado en el organigrama, es muy tentador como gerente caer en una forma de trabajo “yo digo y tú haces”. Es más sencillo obedecer que cuestionar. Es más sencillo mandar que convencer. Sin embargo, en este manera de trabajar no hay un genuino compromiso, se mata la creatividad y día a día, la felicidad y las ganas de venir a trabajar todos los días.
Las personas tienen opiniones, deseos, emociones, dolor, cansancio, etc. Todas son distintas y tienen necesidades diferentes. Tratar de entenderlos, dar feedback efectivo, construir confianza es muchísimo más difícil que seguir un proceso.
Hace poco volví al rol en que me siento más feliz y en el que aporto más valor: el de Agile Coach / Scrum Master. Mi interés principal siempre ha sido desarrollar software con el que el cliente esté satisfecho y el equipo de desarrollo esté feliz, motivado y sientan pasión y orgullo por lo que todos juntos creamos.
Sé que no es sólo una fantasía y que se puede lograr. También se que a veces me puedo sentir perdida y ver el panorama muy obscuro. Esos días en que los problemas abruman y pareciera que no hay solución. Pero entonces, el equipo implementa un nuevo mock, alcanza coberturas de 95% en junit, respondemos rápido al cambio y nos organizamos para comprar cervezas.
Una y otra vez he escuchado y leído que Scrum (ágil en general) no es fácil. Tampoco es para todos. Lo bueno que no estoy sola.
