En un equipo de trabajo es normal pasar por etapas de excesivo estrés: un plazo que se acerca a su fin sin que el producto esté acabado, nuevos proyectos que afloran en el momento más inoportuno, bugs que se acumulan a un ritmo mayor que el que podemos dedicar a despacharlos, reuniones improductivas que nos hacen perder tiempo, dinero y hasta la paciencia, jornadas de trabajo que se alargan más allá de la hora de salida y terminan con una pizza y cantidades ingentes de cafeína…
En esas circunstancias, cuando el equipo de desarrollo parece desbordado y cada miembro está soportando más tensión de la razonable, el jefe de proyecto puede plantearse la opción de incorporar una o dos personas más al equipo. Por supuesto, cada empresa y cada equipo de trabajo es un mundo, pero por lo general conviene reflexionar sobre esta iniciativa, ya que puede ser mucho menos beneficiosa de lo inicialmente esperado.
Más retrasos en el corto plazo
El proceso de incorporación de un nuevo integrante hasta que está plenamente adaptado en el grupo es más largo y laborioso que en otras profesiones debido a la idiosincrasia de la programación.
En primer lugar está la fase de selección. No basta con escoger a alguien que diga conocer el lenguaje de programación y la metodología usados en vuestro proyecto, sino que por lo general una o más personas del equipo deben involucrarse en este proceso de selección para contratar a alguien que demuestre las capacidades necesarias para adaptarse al tipo de trabajo que estáis realizando. Así que, si no estabas suficientemente preocupado por los tiempos, añade las entrevistas y discusiones sobre la idoneidad de los candidatos a tu cúmulo de horas.
Y una vez contratada esa persona, hay que ponerla en funcionamiento cuanto antes, así que lo más probable es que uno o varios de los miembros de tu equipo pierda horas o incluso días configurándole el ordenador con las herramientas a utilizar, habilitándole conexiones, facilitándole contraseñas y accesos a repositorios, etc. Tiempo que ha perdido uno de los miembros activos y durante el cual la nueva incorporación aún no es productiva. Ahora vas más lento.
Cuando hayas dotado a tu nuevo miembro de todos los recursos técnicos necesarios, hay que transferirle el know-how, ese conocimiento sobre operatividad que va más allá del lenguaje y herramientas utilizados. Así que una de dos, o le das una pila de documentación, con lo que lo mantienes improductivo durante varias jornadas, o dedicas tiempo de alguien del equipo en formarlo, con lo cual sigues destinando menos recursos a las labores que tenías que hacer.
Suponiendo que todo lo anterior te haya llevado pocas semanas, falta decidir qué labor asignas al nuevo compañero. Si lo metes en alguno de los proyectos nuevos, corres el riesgo de que los ralentice al no haber adquirido todavía el ritmo de los demás. Pasarlo a un proyecto cercano a la entrega sería una temeridad: puede introducir un error por desconocimiento, o corregir una ñapa difícil de explicar pero que introdujiste porque era totalmente necesaria, y hacer así que llegues a la fecha límite con un suplemento de dolores de cabeza y tirones de los pelos. Y meterlo a corregir bugs de aplicaciones que ya se encuentren en mantenimiento puede ser útil pero, ¿de verdad era para eso para lo que querías a una nueva persona?
Es mejor identificar los cuellos de botella
Por lo general, si se ha llegado a esta circunstancia es por culpa de una mala planificación. Podríamos examinar cada uno de los equipos implicados para buscar dónde se produce el cuello de botella, y por tanto cuál será la mejor solución.
En primer lugar está el departamento comercial o de ventas. Si han traído clientes a un ritmo mayor que el que podemos abastecer, no es necesariamente su problema, ya que la mejor manera de hacer su trabajo consiste en traer cuantos más clientes y más caros, mejor. Otro asunto es si se le están vendiendo proyectos imposibles, o si se están volcando demasiado en ofrecer proyectos a medida en lugar de intentar vender productos completos a falta de una pequeña capa de personalización.
Si el atasco estuviese en la fase de análisis, no nos encontraríamos con unos programadores saturados, sino al contrario, ociosos a la espera de que se le den unas especificaciones que poder seguir, por lo que probablemente podrías desviar al que se encuentra a la espera a otro proyecto donde haga más falta. Otro asunto es que esas especificaciones estén mal expresadas o se rehagan cada poco tiempo, porque eso sí que causa que los programadores tengan mucho trabajo, y además innecesariamente.
Por último, habría que observar el nivel operativo y ver si estamos destinando demasiados esfuerzos a tareas improductivas o con las que se quema fácilmente a los trabajadores. En definitiva, hay que buscar un equilibrio entre las tareas que se pueden terminar rápido y las que producen más beneficio, ya que el ir consiguiéndolas y tachándolas de la lista ayuda a mejorar de forma inconsciente, gracias al optimismo que se genera al cerrar una labor pendiente. Mientras que sumar una persona más a esta ecuación sin fijar bien los objetivos, puede aumentar la frustración ya que con más recursos se consigue prácticamente lo mismo.
El programador como recurso
Aunque no es un término que se use mucho en español, la mejor explicación a este problema es el hecho de que los programadores no somos fungibles. Veamos lo que dice la RAE acerca de esto de los bienes fungibles:
Los muebles de que no puede hacerse el uso adecuado a su naturaleza sin consumirlos y aquellos en reemplazo de los cuales se admite legalmente otro tanto de igual calidad.
Efectivamente, eso es lo que piensan algunos directivos acerca de los programadores: que son recursos intercambiables, que si se va uno puede entrar otro en su lugar y hacer su misma labor sin notar la diferencia, y que se pueden amontonar muchos para conseguir más eficiencia.
Pero nada más lejos de la realidad. Los programadores tenemos una curva de adaptación mayor que la mayoría de empleos, a pesar de conocer a la perfección las herramientas o metodologías usadas, o el ámbito de negocio del cliente. Necesitamos saber cómo trabajan nuestros compañeros, qué ritmos siguen, cómo comparten información, a quién preguntar ante una duda concreta, etc.
Del mismo modo, no somos piezas fácilmente intercambiables. Cada vez que un compañero se marcha del equipo, hace falta realizar un traspaso de conocimiento para que la empresa no pierda esos detalles operativos que la hacen avanzar a cierta velocidad, pero que sólo se conocen a base de trabajo minucioso, y no leyendo documentación.
Por eso no es nada fácil ni rellenar el hueco dejado por un integrante del equipo que se marcha, ni hacer encajar perfectamente a uno nuevo que se incorpora. Somos un puzzle con las piezas demasiado desiguales, y cuando por fin se consigue que encaje perfectamente, es muy complicado añadir una nueva pieza más sin que el resto se desgasten.
No es tan fácil aumentar la productividad
Creo que pocas frases pueden expresar mejor esta situación que aquella de nueve embarazadas no pueden gestar un hijo en un mes. Hay tareas que, por su complejidad, no permiten la división en subtareas básicas que poder repartir a un grupo de personas y acortar plazos, sino que alguien con conocimiento completo del entorno debe desemplearlas de principio a fin.
El problema es que en un equipo hay que desempeñar muchas labores, y cada integrante suele especializarse en una tarea (o conjunto de tareas) concreta, por lo que todo cambio de rol requiere la implicación de otro miembro que le asesore en la nueva tarea por conocerla mejor. Así, una persona nueva que llegue requerirá tiempo de todos los componentes del grupo hasta ser mínimamente capaz de valerse por sí mismo, por lo que su incorporación en etapas de estrés probablemente no sea la mejor opción.
Por último, me gustaría añadir que siendo programador, lo último que pretendo es tirar piedras contra mi propio tejado. Lo que quiero expresar es que una decisión de este calibre no debe tomarse a la ligera, forzado por la situación, sino que es mejor tener cabeza fría y prever estos picos para poder incorporar a esa persona antes de que se produzcan, y así sí, contar con una persona más al 100% a la hora de arrimar el hombro.
Vía | Patchspace (traducción al español en Navegapolis)