sumarEste artículo es una traducción autorizada del post "Why You Shouldn't Hire More Developers" de Ash Moran publicado el 3 de Febrero de 2012 en PatchSpace Blog, y al que desde aquí agradezco el permiso y la disposición para publicarlo en Navegápolis.

La situación latente

Eres el responsable de un equipo de cinco programadores, y estás completamente quemado. Pasáis los días en la oficina desde primera hora de la mañana hasta el final de la tarde, intentando hacer frente a una acumulación continua de trabajo.
De hecho empiezan a ser mejor las noches para trabajar, porque durante el día estáis inundados con interrupciones, emergencias y errores que reclaman atención, por lo que cada vez tenéis menos tiempo para desarrollar funcionalidades nuevas.
Casi no puedes atender a los clientes actuales, y los de comercial acaban de cerrar el acuerdo con un nuevo cliente, que tiene un montón de peticiones. Cada vez pierdes más tiempo en reuniones tratando de mantener la situación bajo control. Probablemente ya te estás tirándo de los pelos, pensando que no tienes tiempo para todo y que tienes que tomar una determinación.

Así que esbozas la situación en una hoja: Cada programador dedica al menos 60 horas a la semana, así que tienes unas 300 horas/programador por semana, de las que estimas que unas 50 se les van en corregir errores, otras 30 en atender la operativa del sistema y 20 en reuniones. En total 100 horas: ¡una tercera parte del tiempo! antes de poder atender las funcionalidades nuevas que están en un backlog que no para de crecer. ¡Y ahora para colmo un nuevo cliente!.

La conclusión es obvia: hay demasiado trabajo, y tienes desbordado todo el tiempo disponible, así que necesitas más gente. Si tuvieras dos programadores nuevos se podrían dedicar a la corrección de errores, a las cuestiones operativas e incluso podrían pellizcar algunas de las funcionalidades nuevas. Sólo tendrías que pagar por 40 horas semanales de cada uno, y como siempre, en cuanto asuman la cultura de la empresa acabarán dedicando más. Así que la solución es obvia, y vas a tu jefe para que autorice una selección de personal.

Mal. Lo último que deberías hacer en una situación como esta es contratar nuevos programadores.

Nuevos programadores avivan el incendio.

La nueva programadora, Alicia, empieza el lunes, día que hipoteca por completo a otro programado para ir instalando su equipo. El martes por la mañana Alicia continúa por su cuenta, porque estáis todos reunidos, pero al final tiene que estar también toda la tarde para rehacer lo que había hecho porque no sabía que usábais un sistema propio de integración continua, que Bob no pudo documentar en su momento porque asistió a una reunión imprevista. El miércoles dejásteis a Alicia revisando unos errores sencillos. Dedicó todo el día, porque al mismo tiempo se iba desenvolviendo con el código. El jueves y el viernes intentó programar una de las tareas fáciles del backlog, de la lista de nuevas funcionalidades, pero estuvo más de la mitad del tiempo con otro programador porque se tropezó con un viejo bug. (Seguramente debía estar registrado en el "bug-tracker", pero desde que alcanzásteis los 200 bugs abiertos, ya no le hace caso nadie.) Al final terminó la semana y desplegásteis una nueva versión el viernes por la tarde.

Empieza el fin de semana, y todos desconectáis los fines de semana, porque aún no los han invadido el exceso de trabajo.

El lunes es un caos. Al arreglar su primer bug, Alicia cambió lo que creía que era un error, y que en realidad era una regla de negocio extremadamente rara. Nadie lo revisó porque todos le habían dedicado ya bastante ayuda, y sabían que era una tarea fácil. Así que tenéis que echar atrás el deploy del viernes. Os dáis cuenta rápidamente de que Alicia programó la nueva funcionalidad sin comprender las reglas de negocio del sistema, así que alguien del equipo tendrá que revisar el código. Y lo de menos es el tiempo que le pueda costar este arreglo, porque está claro que Alicia se encuentra a mucha distancia del equipo, por todo el volumen de código que ya hay desplegado, así que esta situación va a ir para largo.

¿Es culpa de Alicia? ¿Debería haberse esforzado más? ¿Es culpa del sistema?

El cuello de botella

¿Qué es lo que estrangula el funcionamiento de esta empresa.? Está claro que no es el departamento comercial, que trae clientes a más velocidad de la que producís el software. Tampoco es el análisis. Los requisitos también se van construyendo a más velocidad de la que pueden codificar los programadores. (Supondremos por ahora que los requisitos son realmente adecuados). Tampoco es la operativa de trabajo, porque las tareas previstas para la semana estuvieron desplegadas el viernes por la tarde, aunque el deploy rompiera las reglas de negocio. Así que si el cuello de botella es el área de desarrollo, ¿por qué está mal contratar más gente para aumentar la capacidad del área sobrecargada?.

Presunciones de la contratación

Para explicar esta situación vamos a analizar las suposiciones tácitas por las que se contrata personal para un equipo con exceso de trabajo. Este análisis es crucial para descubrir y poner de manifiesto lugares comunes en la forma de actuar muchas empresas de software. Es comparable a la diferencia entre el trabajo invisible y el visualizado y puesto de manifiesto sobre un tablero kanban. (Ten en cuenta que incluso las organizaciones que emplean tarjetas kanban suelen quedar ocultas muchas tareas.)
La siguiente no es una lista exhaustiva, pero sirve de referencia.
Muchos equipos actuan como si esto fuera cierto:

 

  • Los programadores son recursos.
  • La productividad es proporcional a las horas de desarrollo.
  • La corrección de errores es una actividad que aporta valor al producto.
  • Todos los requisitos son necesarios.

 


Los programadores son recursos

Tom DeMarco lo denomina "The Myth of the Fungible Resource" en su libro Slack: En la producción industrial, para muchos puestos de trabajo hay una relación directa entre horas/recurso y productividad. Sin embargo esta es una hipótesis errónea para desarrollar software, en donde un nuevo empleado, aun en el caso de que conozca el lenguaje de programación y el marco técnico de trabajo, tarda mucho tiempo en aprehender el conocimiento tácito del proyecto.

No creo que los programadores se consideren recursos (al menos no se considera así ninguno de los que yo conozco) pero sin embargo he visto trabajar con la hipótesis del "programador=recurso" a muchos departamentos de personal.
Cada vez que contratas a un nuevo programador para incrementar de forma inmediata la productividad del equipo, estás considerando táticamente al trabajo de programación al revés de como lo hacen la mayoría de los programadores, y en toda contradicción sólo es cierto uno de los extremos.

La productividad es proporcional a las horas de desarrollo

Esta hipótesis se puede materializar de dos formas: La primera suponiendo que un programador que trabaja 10 horas es un 25% más productivo que el que trabaja 8, y la segunda suponiendo que un equipo de 10 programadores es un 25% más productivo que uno de 8.

Se puede entender el error en la primera suposición, comprendiendo que el desarrollo de software es en esencia el desarrollo de nuevo conocimiento, como expongo en el post "Why can't developers estimate time".

El desarrollo de software es una actividad creativa cuyas tareas exigen un ejercicio continuo de toma de decisiones lógicas. (Por ejemplo: ¿Convendría dividir ya este largo bloque de código? ¿Uso XML o JSON? ¿No sería mejor reemplazar el marco de la aplicación?)

Como se explica en el artículo "Do you suffer from decision fatigue?" (The New York Times Magazine) el cerebro humano tiene una capacidad limitada para hacer este tipo de elecciones, y cuando se encuentra cansado opta por tomar atajos.

Seguir trabajando después de alcanzar la sensación de "por favor, me quiero ir a casa" puede ser la causa de errores. El mito del programador heroico no es cierto: emplear horas extras como consecuencia de la baja capacidad del equipo es un error demostrado numerosos estudios científicos.

La segunda suposición: creer que la productividad y el tamaño del equipo mantienen una relación proporcional directa, tampoco es cierta, por la sencilla razón de que aunque la complejidad en la gestión de las personas no se incrementa sustancialmente por el número de éstas, sí lo hace la complejidad de la comunicación. Compara por ejemplo lo fácil que resulta que 50 personas alineadas se pasen una pelota, con lo difícil que resulta a 5 llegar a un acuerdo sobre el menú que van a comer en un restaurante chino.

La corrección de errores es una actividad que aporta valor al producto.

Por definición, un error es un funcionamiento inadecuado del sistema. Hay situaciones en las que no se sabe si una idea funcionará (es el campo del emprendimiento ágil). Sin embargo este no es el caso de la mayoría de los defectos, que se introducen en el código a pesar de que el programador podría determinar que lo que está haciendo es un error y producirá un malfuncionamiento del sistema, y sin embargo por alguna razón no se da cuenta.
Imagínate que estás estrenando los flamantes frenos que acabas de instalar en tu aumóvil, y al accionarlos descubres que se desvía hacia un lado. ¿Cuál es el valor adicional que le aporta a tu coche el ir a repararlos? aunque la reparación sea gratis.
Corregir este tipo de errores no es un trabajo, sino un re-trabajo. El programador tiene que volver a "sumergirse" intelectualmente en ese trozo de código, incluyendo los requisitos, su funcionamiento y las dependencias con el resto del sistema, y cambiarlo. Aunque al final no tenga que cambiar el código existente, sino simplemente añadir código nuevo, tiene que aprender desde el principio toda un área de código, junto con las presunciones y conocimiento tácito que implique, y luego cruzar los dedos para no romper nada (en el caso de que la batería de pruebas pueda capturar un posible error, por tratarse éste de un conocimiento que está explicitado en los tests) porque si la corrección de errores es un gasto, la corrección de los producidos al arreglar un error previo es un gasto doble. Es lo que llamo "programación wack-a-mole" un término que lamentableme aún no ha cuajado.
Si tu equipo dedica mucho tiempo a corregir errores, tiene bastante más capacidad de la que crees. Lo cual no quiere decir que sea fácil aprovechar esa capacidad de la que no eres consciente, pero que está ahí. La creencia de que los errores son inevitables es perjudicial, porque tiene como consecuencia considerar que corregirlos es una tarea que genera producto.

Todos los requisitos son necesarios

He dejado ésta suposición errónea para el final, porque es de naturaleza diferente al resto de las hipótesis, en cuanto que implica decisiones ajenas al equipo de programación. A menos que el equipo esté construyendo su propio software, habrá otra persona involucrada para especificar el trabajo que se debe realizar. Si al final el 30% de las funcionalidades del software no se usan nunca, o son innecesarias, habremos perdido al menos el 30% del esfuerzo de trabajo. (Que puede ser más al tener que gestionar una base de código mayor, y depurar los errores del código innecesario).
Pero esta suele ser una causa de ineficiencia dificil de solucionar, porque normalmente los equipos están contractualmente obligados a entregar especificaciones de requisitos que no incluyen valoraciones individualizadas o prioridades de cada funcionalidad.

La realidad del equipo ocupado

Recuerda que hemos llegado hasta aquí por analizar la contratación de Alicia para aumentar la capacidad de un equipo con "exceso de trabajo". Pero hemos visto que las razones que supuestamente hacían necesaria su contratación son faltas:

 

  • El equipo no está funcionando a plena capacidad. Consume al menos un 25% del tiempo en un retrabajo y mantenimieno evitable, incluso considerando las horas de exceso de trabajo.
  • Los errores introducidos por el estrés están reduciendo el nivel de calidad que el equipo puede proporcionar.
  • La incorporación de Alicia no puede aportar un alivio inmediato, porque en el corto plazo incrementa el tiempo de información y comunicación con todo el equipo, reduciendo su productividad.

 

Una nota sobre el tamaño de los equipos

Es posible que tengas tengas alguna objeción a mi consejo de no contratar más programadores, porque mejorar la capacidad del equipo no es la única razon para contratar. Una razón muy válida es para tener redundancia, porque los equipos pequeños son muy sensibles a la ley de Murphy: Si un autobús atropeya a tu único programador, el proyecto entra en peligro inminente (en realidad ya estaba en peligro, pero ha hecho falta un autobús para demostrarlo).

Este interesante artículo de Christopher Allen explica algunas consecuencias de los distintos tamaños de equipos en su articulo "The Dunbar Number as a Limit to Group Sizes".

De todas formas el riesgo que supone contar con equipos pequeños es menor de lo que pudiera parecer. Yo no conozco casos de programadores atropellados por autobuses, y son raros los casos de los que dejan el trabajo por el sueldo, comparados por el que es el principal riesgo de pérdida de programadores: condiciones de trabajo insatisfactorias.

También hay otra razón por la que quizá quieras aumentar el tamaño del equipo: Para incorporar a una persona con experiencia y conocimiento útiles para transmitir a los demás. Pero en este caso su responsabilidad irá más alla del puro desarrollo.

Qué hacer

Antes de nada da un paso atrás y comprueba que no estás tratando de solucionar perdidas sistemáticas de esfuerzo, aportando más esfuerzo. Sería similar a poner más marineros para achicar agua, en lugar de trabajar en cerrar la vía. Fred Brooks enunció la Ley de Brooks hace más de 30 años: "Incorporar más mano de obra a un proyecto de software retrasado, lo retrasa más". Ignorando la experienca sólo coseguirás repetirla en tu empresa. Personalmente hay quien me ha confirmado "Tenemos un gráfico que muestra perfectamente cómo baja la velocidad a medida que añadimos personas al proyecto".

La mejora de la productividad de un equipo es difícil. Se trata de entender el negocio, el equipo, la trayectoria, los obstáculos que bloquean el progreso. Se trata de un problema complejo y sensible al contexto. Como este post está empezando a tomar un tamaño suficiente para ser aburrido, baste con apuntar la dirección del área de conocimiento adecuada, y sugerir "La Meta" como lectura.

Vemos el mundo a través de metáforas. Eli Goldratt, en La meta, muestra cómo al afrontar los problemas diarios, las suposiciones comunes nos impiden ver las causas reales. Es un libro que ha vendido millones de copias, que se ha utilizado en miles de empresas y se enseña en cientos de colegios y universidades. La meta es el típico libro que muestra cuáles son los fundamentos importantes. Se puede leer en un par de días, y te ayudará a ver la fuente real de los cuellos de botella en tu empresa (este no es un post patrocinado).

Voy a terminar con una regla general: al lidiar con una situación como la descrita, trata de aprovechar lo que ya tienes antes de abordar el problema con más recursos. Te darás cuenta que muchas veces puedes ser más eficaz con las personas y los recursos que ya tienes, si descubres las verdaderas causas del problema.

Gracias por leer este artículo.
Mi nombre es Ash Moran, soy desarrollador de software, y asesor de agilidad, propietario de PatchSpace Ltd (twitter). Si tienes algún comentario, pregunta o si deseas información sobre mis servicios, no dudes en contactar conmigo en Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo..

Bookmark and Share

Comentarios   

0 #2 Juan 26-06-2013 13:21
Hola Carlos.
Sí que tiene "miga" lo que plantea el artículo.
Entre las muchas cosas que te hace pensar, una conclusión con cierta relevancia para mi es la el criterio de "la directiva".
Creo que por lo general cuando los jefes o la directiva de la empresa son gente técnica es más normal que las decisiones de "staffing" tengan más perspectiva, no sea para incorporar "bomberos" para el último incendio sino para ir aumentando el "talento" con previsión y anticipación.

Normalmente son menos frecuentes las culturas y decisioness con criterio de "software-factory" cuando los directivos son de perfil técnico, y más habituales cuando lo son de perfil "empresarial".

Un saludo.
Citar
0 #1 carlos 25-06-2013 18:27
Lo he leido un par de veces. Y tiene mucha miga este post. Es de esos que me me hacen pensar y me acaban dando el dia.

Sera que es un reflejo de muchas fases de mi vida...

Veamos, creo que hay dos moralejas: Que no se sobretrabaje diariamente para asi no producir errores en los que sobretrabajar despues, realimentando el ciclo. Y en segundo lugar, que se revisen los requisitos para evitar atacar los que menos valor aporten. Bien tiene su lógica.

Pero, al final, tenemos un monton de incidencias que responder, un cerro de cosas en la pila que sacar adelante, y probablemente unos directivos que estan acostmbrados a este tipo de gestión.

El post plantea la situacion de contratacion de un mesias que salve el proyecto y creo que ese es el problema, deberia ser un colaborador que este a la chepa de otro, durante un tiempo prudente empapandose de la cultura del proyecto.
En mi humilde opinion, (no voy a enmendar la plana a nadie ;-) ) creo SI que hay que contratar pero NO AHORA, sino antes de que la cosa se desmadrara. Es decir la mejor solución es preveer. Y en todo caso nunca es tarde para hacerlo. Pero hay que cambiar el enfoque.

Finalmente. Lo que en realidad plantea el post es una situacion muy tipica pero donde lo que subyace es la falta de respeto al equipo. No se debe sacar todo a costa de horas extras no remuneradas, una cosa son pìcos puntuales, y otra es quemar al equipo, exigiendo que vaya a la luna en bicicleta.

Pero ¿Como negociar con la directiva, que se contrate a alguien antes de que sea tarde, que se prioricen las cosas antes de prometer unas fechas irreales que nunca se cumplen?. ¿Que metricas (al final una medida se traduce en pasta) usar para tirar por tierra esas ideas preconcebidas? La retorica esta bien, pero a un director solo le interesa la pasta...

Un saludo
Citar

Escribir un comentario


Código de seguridad
Refescar