Hace unas semanas me encontraba en medio de un brote de optimismo. Muy contento con los resultados, había invitado a nuestro equipo y a los empleados del cliente a una barra libre de tapas. Entre plato y plato, el jefe de producto me dijo: “Vosotros los consultores externos siempre veis el vaso medio lleno. Porque estais acostumbrados a que os lancen en paracaídas sólo en proyectos que van mal o necesitan desesperadamente recursos. Entonces pensais: ‘Bueno, en peores plazas he toreado’. Pero a los que llevamos quince años aquí nos gustaría que todo fuese perfecto y ese deseo hace que la percepción sea la de vivir permanentemente dentro de un túnel sin salida”.
En esta ocasión, lo que nos traíamos entre manos salió bien, pero el software es una artesanía muy compleja cuyos proyectos nunca están exentos de incidentes descorazonadores. Para comentar cómo enfrentarse a lo que típicamente resulta frustrante en un projecto de desarrollo de software, voy a basarme en un artículo de 2004 escrito por Michael «Rands» Lopp titulado Qué hacer cuando estás jodido. Del cual daré, naturalmente, mi propia interpretación.
Causa #1: falta documentación importante
Al inicio de un proyecto todo el mundo anda preocupado por definir bien qué es lo que hay que hacer. Esto es importante porque las especificaciones se usan para hacer las estimaciones de tiempo y las estimaciones de tiempo se usan para hacer los presupuestos. Además de que a los programadores no les gusta tener que rehacer en el último minuto cosas que ya habían hecho presuntamente de acuerdo con los requisitos.
Lo que sucede es que al principio del proyecto hay muchas incógnitas que no se pueden despejar. La solución para este problema propuesta por Agile fue, básicamente, negar que existe y aceptar una dinámica de cambios contínuos en el proyecto. Ya he sido bastante crítico con Agile en el pasado debido en parte a esta premisa de negar la mayor porque opino que ninguna metodología ágil puede salvar a un proyecto de unas malas especificaciones puesto que si empiezas sin saber lo que hay que hacer es seguro que tendrás que repetirlo y tener que hacer las cosas dos (o más veces) es malo.
Estoy de acuerdo en que no es necesario que todo esté escrito en piedra antes de empezar. Pero sí es necesario que esté escrito al terminar. Es decir, lo importante sobre la documentación no es tanto su calidad cuando empieza el proyecto sino su calidad cuando termina. Mas lo que suele suceder es que durante el proceso de desarrollo se introducen tantos cambios que la especificación de requisitos original deja de ser en absoluto una imagen fiel de lo que realmente se ha producido.
El problema tiene a menudo bastante que ver con las herramientas, o mejor dicho la falta de ellas, para elaborar especificaciones. Frecuentemente vienen escritas en Word y PowerPoint. Con suerte, almacenadas en un repositorio SharePoint. Pero no pocas veces simplemente en un directorio compartido.
La pega de Word y PowerPoint es que lo aguantan todo, incluída la indisciplina más absoluta para mantener actualizados los documentos. Durante los proyectos ágiles es frecuente que los usuarios pidan cambios mediante un ticket de soporte o simplemente mandando «un correito». Esto es fácil para el usuario porque le ahorra el esfuerzo mental de buscar y actualizar la especificación. Pero a la postre el comportamiento del software acaba especificado en mensajes almacenados en Outlook.
La dispersión de las especificaciones en emails es terriblemente mala, porque a la hora de facturar un proyecto hay tres tipos de entregables: 1) los entregables que estaban en la especificación y se entregaron tal cual figura en los documentos, 2) los entregables que estaban en la especificación original y no se entregaron porque a posteriori se descubrió que no tenía sentido fabricarlos y 3) los entregables que no estaban en la especificación original y se entregaron porque hubo peticiones de cambio. Si, como propone Agile, sólo se factura al cliente por horas/hombre (time & materials) entonces da igual lo que se produzca porque el cliente sólo paga por horas de programador y no por entregables. Pero los clientes se queman de pagar horas sin fin. Y a la postre lo que estaba en la especifición y se entregó, se paga; lo que estaba en la especifición y no se entregó, no se paga; y todo lo que hubo que hacer porque se descubrió por el camino el cliente discute si tiene que pagarlo o no.
Causa #2: falta (o sobra) alguna herramienta
Hemos progresado muchísimo en los últimos 20 años con respecto a la automatización del desarrollo de software. Los programadores son muy buenos automatizando y optimizando procesos. La pega es que los programadores sólo pueden optimizar aquello que forma parte de sus competencias, es decir, el proceso de desarrollo en sí mismo, pero en un proyecto el tiempo de desarrollo casi nunca supera el 30% del tiempo total requerido. Por ejemplo, existen fantásticas herramientas para el diseño de pruebas unitarias, estilo JUnit para las librerías o Selenium para el front-end. Pero la validación de los escenarios de uso sigue siendo mayormente un proceso manual. Entonces sucede que se necesita más tiempo para probar el software que para desarrollarlo.
En ocasiones el problema es el contrario. Alguien compró un cacharro que teóricamente es buenísimo para incrementar la productividad pero que en la práctica sólo es buenísimo para quitarle las ganas de vivir a quienes tienen que usarlo a diario.
Causa #3: mala gestión o ausencia de gestión
Tras lustros en contacto con centenares de organizaciones, intento hacer memoria de aquellas en las que los técnicos estuviesen satisfechos con la forma en la que se estaba gestionando el proyecto, y no se me ocurre ninguna. He conocido empresas donde los programadores junior admiraban los conocimientos de sus compañeros senior, los senior las capacidades naturales de los junior y ambos seguían fanáticamente a algún líder visionario. Pero jamás ninguno de ellos estaba contento con la forma de gestionar el proyecto. La razón es un conflicto de intereses entre los objetivos de los programadores, normalmente orientados a divertirse y alcanzar logros técnicos, y los objetivos de los responsables de negocio cuya misión encomendada es generar la máxima cantidad de dinero con el mínimo de esfuerzo e inversión. No existe ninguna solución a este conflicto. Es por eso que gurus como Richard Stallman recomiendan buscar un trabajo digno y programar sólo durante los ratos libres.
Este desencuentro inevitable entre programadores y accionstas/propietarios puede verse agravado por la incompetencia, ambición, miedo o cualquier neurosis de los gerentes hasta dar lugar al auténtico Jefe Minglanillas.
Tal y cómo está el mercado laboral de informática ahora mismo, yo creo que es innecesario aguantar a un mal jefe, ya que suele ser fácil encontrar otro trabajo. No obstante, también es injusto tener que renunciar a un trabajo cuando quien debería dimitir es el de arriba.
Como ya he apuntado, las dos causas más comunes de trastornos gerenciales son la ambición y el miedo. La ambición de trepar en la carrera profesional y el miedo a fracasar en ella, perder las stock-options enfrentarse a una demanda de divorcio y toda la serie de terrores nocturnos imaginarios que sufren algunos gerentes cuando se empiezan a incumplir los objetivos.
Por detrás de la ambición y el miedo, lo más común son los trastornos histéricos u obsesivos. La histeria la manifiestan las personas que están todo el tiempo acosando a los programadores. Los obsesivos son aquellos que enloquecen en el mismo momento en que alguien se salta algún procedimiento por absurdo que sea. Los histéricos y los obsesivos cumplen funciones en el proyecto generando tensión creativa y vigilando que se cumplan las normas, por ejemplo, en materia de la necesaria seguridad y confidencialidad. Lo que pasa es que los programadores son generalmente gente tranquila que no se adapta bien a trabajar bajo presión. Sí, ya sé que con esta última frase probablemente he indignado instantáneamente algún programador cuya mente ahora mismo está gritando «¿Que no tenemos presión en el proyecto!». Pues si existe presión, pero la presión que sufre diariamente un informático típico es muy inferior a la media de presión en otros trabajos excepto quizá ser poeta o catador de vinos.
En algunos casos el jefe directamente no existe. Esto no es necesariamente mortal, ya que históricamente soldados sin general ganaron muchas batallas (generales sin soldados ninguna) y a fin de cuentas se supone que los equipos ágiles son auto-organizados. Cuando no hay jefe, los problemas aparecen si se necesitan recursos ajenos al equipo o si se producen disputas entre los miembros. En estos casos, lo mejor suele ser que el propio equipo elija un líder que actúe como interlocutor y árbitro.
Causa #4: el clima laboral apesta
Esto puede ser consecuencia de una mala gestión, pero no siempre. Una empresa, cualquier empresa, por bien gestionada que esté, puede entrar en crisis por razones externas.
La crisis afecta al estado de ánimo de los trabajadores y ello causa que el día a día de la dinámica social se vuelva muy desagradable.
He de decir que en no pocas ocasiones he visto a los departamentos de recursos humanos desayudar con el clima. No es raro que los programadores se burlen de las evaluaciones de rendimiento. Y el propio mobiliario y disposición de los puestos de trabajo en las modernas oficinas abiertas es totalmente deshumanizante. Dicen que en algunas start ups y en algunas empresas de Área de la Bahía el entorno no es tan gris. Ciertamente yo he conocido varias start up ubicadas en lofts muy bien decorados. No tengo suficiente vivencia como para opinar en general sobre Silicon Valley, pero mi visita al Campus de Google en 2009 fue decepcionante.
Observando lugares de trabajo, he conseguido reducir a cuatro los factores predictivos de la preocupación de la empresa por sus empleados:
- El estado de conservación de la sillas
- El tamaño y calidad de la cocina/comedor
- El tamaño y calidad de los lavabos
- La disponibilidad de agua y café
Si encuentro en una planta sillas destartaladas que los empleados van robándose unos a otros ya sé que nadie se preocupa demasiado por los factores higiénicos del trabajo. También he visitado empresas boyantes en rascacielos londinenses cuyos lavabos eran peores que las letrinas del ejército.
Creo que lo mejor en estos casos es una correcta acción sindical. No se trata de pedir que pongan mesas de billar ni máquinas de pin-ball, sino de pedir un entorno idóneo y agradable para las largas horas que hay que pasar en la oficina.
Otra causa de mal clima laboral, es la precariedad en la contratación. Sueldos bajos, temporalidad innecesaria, abuso de consultores mercenarios (o todo lo contrario, ausencia absoluta de ellos).
Causa #5: los plazos previstos no se están cumpliendo
Esto puede no ser tan malo como suele parecer a primera vista. Para empezar, en un proyecto informático la cantidad de trabajo terminado aumenta exponencialmente conforme se acerca la fecha de entrega. Es decir, es posible estar en la mitad del plazo y haber completado sólo el 20% del proyecto y, aún así, lograrlo.
Los proyectos suelen retrasarse por cambios e imprevistos, los gestores experimentados lo saben y por eso idean todo tipo de trucos para que las fechas de entrega se puedan deslizar sin que parezca que hubo un retraso. Por ejemplo, contra las avalanchas de cambios al final del proyecto es posible crear dos fechas de entrega: la fecha oficial de puesta en producción y otra misteriosa fecha “post-go-live” que es cuando realmente estará operativo el sistema. Si el proyecto va retrasado lo que se hace es un triaje de cambios solicitados y funcionalidades pendientes. Pongamos por caso que se dividen en prioridades P1, P2, P3 y P4. Entonces los P1 y P2 entran en la fecha de puesta en producción y los P3 y P4 son post-go-live. Es decir, puede que no sea posible mover la fecha de entrega pero casi siempre es posible reducir el número de funcionalidades o la calidad del software entregado.
Lo importante es que no haya sorpresas. En las start ups y en las empresas o proyectos que dependen de rondas de inversión los plazos pueden ser cruciales y muy ajustados. Pero normalmente en las empresas medianas y grandes importa muchísimo más la predictibilidad que la eficiencia.
Posts relacionados:
Cómo sobrevivir a las estimaciones de software.
Lo que sucede cuando un software se convierte en un agujero negro.
1-2-3 de por qué fallan los proyectos informáticos (Versión Cerø).
Pingback: 5 cosas que pueden arruinarte el día en un proyecto (y cómo evitarlas) – Elbinario