Desarrollo de software. Adaptar el trabajo a la capacidad del equipo y de las personas II

¿Y qué se hace con esas horas que no se facturan? La respuesta a esta pregunta no es simple, de hecho no la voy a responder, solo dejo unas cuantas reflexiones:

- Llegado a un punto, en un proyecto llave en mano las horas que superen lo contratado no serán facturables (salvo pacto contrario) ya que el compromiso es desarrollar un producto con el precio y las condiciones fijadas. En este tipo de proyectos lo que interesa, por tanto, es cumplir la agenda con el objeto de no incurrir en pérdidas y para ello la medida más óptima es que el equipo y las personas que lo componen sean productivas por encima de que el 100% de sus horas sean facturables o no porque al final si no cumples, si no trabajas bien, todas las horas te costarán dinero.

- En general un trabajo que no esté bien hecho y que haya que volver a hacer y/o que erosione tu credibilidad con respecto al cliente es dinero perdido y/o que se dejará de ganar.

- Si una persona o un equipo tiene trabajo que potencialmente supera el 100% de su capacidad corre el riesgo de que en determinados momentos se sature y que la misma afecte a la productividad y a la calidad.

- Lo ideal es que la dedicación de personas a proyectos sea del 100%. El problema de la saturación es provocado generalmente al compartirse entre diferentes proyectos, incluso en aquellos casos donde se quiera tener cuidado de que la dedicación total no supere el 100% porque, ¿quién es capaz de delimitar con tanta precisión las fronteras?, ¿alguien ha tenido en cuenta el esfuerzo real que supone cada cambio de contexto?, ¿quién tiene la suficiente capacidad para olvidarse de los problemas que tiene en otros proyectos en los que esté trabajando?, ¿qué pasa cuando los diferentes proyectos en los que se trabaja están en “crisis”?.

- No todos los perfiles funcionan igual al compartirse entre proyectos distintos. Cuanto mayor sea el nivel de detalle con el que trabaje en el proyecto menos productiva será esa división.

- La productividad de una persona o de un equipo no se debe medir por el número de horas que facturen sino por la efectividad de las horas facturadas, si se es efectivo seguro que será rentable.

Desarrollo de software. Adaptar el trabajo a la capacidad del equipo y de las personas I

Uno de los aspectos en los que he cambiado de opinión está relacionado con la carga de trabajo que debe tener asignada ya sea un equipo o una persona. Justificaba y en mi blog hay artículos hablando de ello que cada persona tuviera tareas que en potencia superasen el 100% de su capacidad de manera que siempre (o casi siempre) hubiera la posibilidad de estar trabajando en tareas aunque uno de los proyectos o líneas de trabajo sufriera un parón.

Desde el punto de vista empresarial la situación ideal es aquella en la que la mayor parte de las horas laborables sean facturables o a través de ellas se generen oportunidades de negocio.

Sin embargo esta situación ideal llevada al mundo real presenta inconvenientes que, por supuesto, los ven solo quienes tienen una visión a ese nivel de detalle o se preocupan por analizar qué mecanismos permiten obtener la máxima productividad de las personas o de los equipos.

Es curioso, en propia persona sufría y sufro esa capacidad potencial de trabajo superior al 100%, veía y notaba sus consecuencias y, sin embargo, lo justificaba. ¿El motivo? Lo terminé considerando como algo normal y a partir de ahí trataba de dar una explicación a ese hecho.

También me pasaba con el enfoque de desarrollo clásico y les pasa a muchos que no terminan de considerar los enfoques ágiles como una alternativa.

Siempre suelo poner los mismos ejemplo. ¿Trabaja mejor tu ordenador cuándo lo tienes saturado de procesos abiertos?, ¿funciona mejor tu conexión a Internet cuando tienes prácticamente ocupado de manera continua tu ancho de banda?, ¿verdad que no?, ¿lo mismo nos pasa a nosotros?. Llega a un punto donde la saturación de trabajo bloquea a todo lo demás y el avance en esas tareas será más lento y probablemente con unos resultados de menor calidad y con una finalización de las mismas mucho más tarde de lo que sería deseable.

La saturación no es positiva, tampoco lo es la situación contraria, de ahí que el objetivo deba ser limitar la cantidad de trabajo y adaptarla a la capacidad que esa persona o equipo pueda asimilar en ese momento. El “ese momento” es importante porque la capacidad no tiene por qué ser siempre la misma y eso es inherente a las personas.

Esto no es fácil, habrá veces que nos quedemos cortos o que nos pasemos, sin embargo lo realmente importante es intentar poco a poco que la desviación con respecto a la situación ideal sea la menor posible.

Lo que hay que evitar es que la práctica general sea saturar a personas o equipos, ¿que de esta forma no se llega al límite de la capacidad potencial? Os pongo el siguiente ejemplo: cuando hacéis palomitas en el microondas siempre hay maíz que no se termina de abrir, ¿qué pasa si dejáis más tiempo el microondas para que esas pepitas terminen por abrirse? pues que se te habrán quemado las palomitas y la mayoría de las pepitas pendientes de abrirse (que no serán muchas) seguirán sin hacerlo. En este caso, la estrategia más productiva no es calentar las palomitas al 120% sino hacerlo dentro de unos márgenes apropiados aunque no se consiga que el 100% del maíz se abra.

Desarrollo de software. Antipatrón. Presión desmedida

La falta de tensión no es buena, tampoco el exceso de presión. La presión en un momento dado puede ayudar a mantener o recuperar el enfoque en el proyecto, incluso a dar ese 110% que puede ser necesario, siempre y cuando sea durante un período de tiempo soportable.

Pero más allá de eso, es nefasta. También lo es en períodos cortos cuando se trata de conseguir un sobreesfuerzo que está por encima de la capacidad de los desarrolladores y/o del problema en cuestión que existe en ese momento.

Yo también he dicho más de un vez que bajo presión funciono mejor, pero no es así realmente. Bajo presión estás más concentrado y tienes tus sentidos dedicados al objetivo, pero eso es así porque es una presión controlada, no te obligas o no te obligan más allá las de lo que puedes admitir, en el momento en que te exiges o te exigen más, empieza el bloqueo, los nervios y las contramedidas para quitarte de encima esa presión que pasa por tratar de terminar cuanto antes y como sea, con la consiguiente merma de calidad del producto final.

Resulta complicado no trasladar presión a tu equipo si a su vez estás sometido a una gran presión. Es importante que ellos vean y sientan lo que está en juego pero no ir más allá. Tener la capacidad de absorber esa presión y no saturar con ella al equipo es una gran virtud y en contraprestación conseguirás mejores resultados gracias a un trabajo más productivo.

Desarrollo de software. El propósito como motor

Uno de los problemas de que a los desarrolladores se les trate como ganado es que de esta forma es muy complicado que vean un propósito que les sirva como elemento motivador en su día a día. De esta forma solo ven tareas, una tras otra y nada más.

Un desarrollador puede ser productivo de esa manera, pero será menos consistente y más irregular, y tendrá que ser bastante fuerte para no dejarse vencer por la tentación de convertirse en un cumplidor o todavía peor en alguien que aparente cumplir (muchos más frecuentes estos últimos).

El desarrollo de software produce mucho desgaste porque los problemas no se terminan cuando sales de la puerta del trabajo sino que te lo llevas en tu cabeza y tardan en desaparecer (si es que lo hacen). Si detrás de esto no hay algo que te motive, te terminas convirtiendo en un robot.

El propósito no se toma en pastillas, ni se construye con cuatro gestos bien intencionados o de cara a la galería. El propósito es creer en un proyecto (es algo más amplio que un proyecto concreto de desarrollo de software), en una forma de hacer las cosas, en sentir de verdad que tu trabajo hace mejor y te hace mejor. Además debe alimentarse de un trato justo por parte de la organización porque de lo contrario se pierde equilibrio.

El problema de todo esto es que muchos gestores piensan que con el salario ya se ha conseguido todo y no es así.

Desarrollo de software. Antipatrón. Culto a la incompetencia

Es muy frecuente encontrarnos con personas no solo que no sean productivas sino que su productividad neta sea negativa. ¿Por qué negativa? Porque el daño que hacen a la producción es mayor que lo que aportan y esto no es solo provocado por lo que pueden estropear, eso es casi lo de menos, sino por el impacto que tienen en la productividad de los demás.

Este antipatrón surge cuando conociéndose ese problema no se hace nada al respecto, lo que es lo mismo que admitir que tu capacidad de producción tiene una resistencia que no vas a eliminar. Lo peor de todo esto es que esta resistencia generará nuevas resistencias (teoría de las ventanas rotas) porque la cultura del nunca pasa nada es de lo peor que le puede pasar a una organización.

No se trata de generar una cultura de miedo (que es totalmente negativa) sino una cultura de responsabilidad, que es algo totalmente diferente.

El principio de Dilbert como solución a este problema es una huida hacia adelante porque lo que haces es desplazar el problema, ya que aunque lo separes de la línea de producción y lo coloques en un puesto donde sea inocuo, el mensaje sigue estando ahí: “no importa lo mal que lo hagas, que incluso te recompensaremos con ello” y eso termina calando en la organización, hasta tal punto que termina convirtiéndose en parte de la cultura de la misma.

Desarrollo de software. Antipatrón. Falta de ritmo

La falta de ritmo y los parones, que con mayor o menor duración, se pueden producir en un proyecto de desarrollo de software suelen hacer mucho daño.

Hay que tener en cuenta que el equipo de desarrollo está centrado en la realización de este trabajo (independientemente de que alguno de sus integrantes comparta su tiempo con algún otro proyecto) y que si no recibe materia prima para poder trabajar, ocurrirá alguna de las siguientes circunstancias:

- El equipo de proyecto quedará parado o realizando tareas secundarias a la espera de recibir trabajo y ese coste se imputa al cliente.

- Como el cliente no suele asumir ese coste, el proveedor tratará de recolocar a los componentes del equipo en otros proyectos, de tal manera que su colaboración en los mismos sea puntual, para de esta forma poder “rescatarlos” en el caso de que haya una reactivación.

Habrá algún miembro del equipo que no pueda volver por compromisos en el nuevo proyecto en el que está (a veces lo puntual termina por convertirse en una integración efectiva en otro equipo de trabajo) y otros tardarán algo más de lo que inicialmente se esperaba. Esta situación tenderá a ir a peor conforme vaya aumentando el tiempo de parón.

Si la organización no tiene proyectos donde recolocar a algunas de estas personas y el cliente no se hace cargo de este período de inactividad, probablemente la mayoría de ellas deje de trabajar para la organización.

En función del grado de avance del proyecto y de la especialización del personal que participa en él, el impacto de que haya cambios importantes en el equipo puede ser mayor o menos, teniendo en cuenta que incluso en el mejor de los casos hay coste, porque se ha perdido la inercia existente, se requiere un tiempo para la puesta al día y para que la maquinaria vuelva a estar engrasada.

Desarrollo de software. Triángulo de hierro II

En este artículo vamos a analizar el impacto que tiene la reducción de los plazos o la ampliación del alcance en el caso de que se quieran conservar los objetivos de calidad:

- Si se reducen los plazos solo se podrán salvar costes y alcance disminuyendo la calidad.

Aquí también podría entrar en juego la productividad pero con unos efectos similares a los indicados anteriormente.

No obstante, algunos podréis preguntarse, ¿necesariamente tiene que verse afectada la calidad?, ¿no basta solo con meter más personas en el proyecto?.

Meter personas puede funcionar si entran ya rodadas, es decir, conocen perfectamente la tecnología de desarrollo y la dinámica de trabajo del equipo, y aún así, requerirán un tiempo de adaptación hasta poder producir al 100%, además de tiempo de personas del equipo de desarrollo para situarles en el contexto funcional, de arquitectura e incluso técnico de los trabajos. Este tiempo de adaptación tanto por los nuevos como por los que ya formaban parte del equipo tiene que salir de algún lado y se traducirá en overtime y/o en una menor dedicación a determinadas actividades que resultan fundamentales en el desarrollo como es el testing.

Sin embargo no siempre se podrán incorporar al proyecto personas con el perfil indicado o no llegarán a tiempo o simplemente no merecerá la pena, esto dará lugar a que tenga que ser el equipo el que tenga que asumir ese nuevo contexto y aquí inevitablemente tendremos overtime que, además, será sostenido en el tiempo y eso terminará por agotar al equipo e influirá sobre la calidad de los resultados. No debemos olvidar que no somos máquinas, somos personas, y nos cansamos física y psicológicamente, cansancio que será más acusado porque al mayor número de horas habrá que sumar el desgaste que supone la presión.

Y el overtime no será suficiente, al final, con el objeto de ejecutar trabajo se será más descuidado en el proceso de pruebas del software, que además, de base tendrá un mayor número de deficiencias, a lo que habrá que sumar una más que probable deuda técnica adicional porque lo que importará será sacar trabajo por encima de la calidad final del código.

- Si se amplía el alcance solo se podrán salvar costes y alcance disminuyendo la calidad.

El análisis de esta situación es un compendio del indicado en las dos anteriores.

Desarrollo de software. Triángulo de hierro I

Se conoce como triángulo de hierro al espacio que generan tres variables fundamentales a tener en cuenta en el proceso de desarrollo de software: coste (presupuesto), plazos y alcance.

Ese espacio es el que ocupa la calidad del software que se desarrolla.

Esto es teoría, hay equipos que con menos espacio son capaces de desarrollar software de mayor calidad que otros que cuentan con un mayor margen.

Y no solo depende de los equipos, la colaboración o no del resto de implicados en el proyecto también condiciona mucho.

No obstante, pese a ser un aspecto teórico sí que sirve para analizar la implicación directa que tienen esas tres variables sobre el resultado final:

- Si se reduce el presupuesto solo se podrán salvar plazos y alcance disminuyendo la calidad.

Algunos podréis pensar, ¿y si se gana en productividad? Es cierto, puede ser una solución general o, al menos, un instrumento que permita que su impacto en la calidad no sea tan significativo. Pero, ¿se puede mejorar la productividad de manera sensible de la noche a la mañana?.

La mejora de la productividad como parte de un proceso de mejora continua siempre debe estar presente a nivel organizativo y a nivel de proyecto, si llevamos esta idea al triángulo de hierro va a permitir mejorar la situación del vértice de los costes, pero una reducción del presupuesto significativa no podrá contrarrestarse con una mejora de la productividad a corto plazo porque estas mejoras llevan su tiempo ya que no solo se trata de cambiar la forma de hacer determinadas cosas sino que también se trata de un asunto de mentalidad de las personas (y eso requiere tiempo de maduración).

En el próximo artículo veremos las implicaciones en el caso de que se reduzcan los plazos o se amplíe el alcance.

Los procesos y su afección a la autonomía

La rigidez en los procesos afectan por regla general a la autonomía de las personas que trabajan con los mismos. Tiene su lógica, más procedimientos y mayor nivel de detalle suele ser equivalente a un menor margen de maniobra.

Puede resultar razonable procesos rígidos en contextos donde el trabajo sea mecánico, de hecho el siguiente paso a eso sería la cadena de montaje donde cada secuencia en el desarrollo de un producto está mecanizada y si hay intervención humano está tremendamente reglada.

Trabajar en un contexto de este tipo donde la autonomía y la creatividad están limitadas o son inexistentes no resulta sencillo, al menos, para mi no lo es. En estos casos el trabajo se convierte en un automatismo en el que hay que tener el aguante suficiente para hacer lo mismo un día sí y otro también.

Sé que hay quienes se sienten cómodos con este tipo de trabajos: se ha adquirido un conocimiento y/o una habilidad y se pone en práctica todos los días, no hay que ir más allá ni tener otro tipo de preocupación que producir en cantidad y en calidad lo que tu organización te haya marcado. Se termina la jornada laboral y mañana será otro día.

Incluso quienes se sienten cómodo con estos trabajos no encuentran más aliciente en el mismo que el propio sueldo, es decir, el trabajo en sí no les supone ningún aliciente más.

El desarrollo de software es diferente siempre y cuando no estés encorsetado en el proceso.

Los procesos son necesarios, proporcionan un background común a los proyectos, ahora bien, deben ser flexibles y no meterse en demasiado nivel de detalle. Armonizar los trabajos resulta interesante pero no debe condicionar los proyectos si hay circunstancias que justifican una desviación de los procesos establecidos (circunstancias objetivas y no caprichos personales).

Procesos rígidos además de afectar a la propia adaptación al cambio afectan a la autonomía que los desarrolladores necesitan para hacer su trabajo con un mayor nivel de motivación y con un mayor enfoque en el problema o problemas con los que se está trabajando: la atención está en el producto y no en el proceso.

La autonomía y la creatividad como elementos de motivación

¿En qué circunstancias sueles entrar con más frecuencia en lo que los estudiosos de la productividad llaman “la zona”?, ¿suele coincidir con la resolución de problemas en los que te han dado un cierto grado de autonomía y que suponen un reto personal superarlos?, ¿suele coincidir con aquellos momentos en los que aplicas tu creatividad para dar solución a un problema o a una tarea?.

Cuando en el artículo anterior hablaba de entornos que te llenasen profesionalmente estaba refiriéndome precisamente a aquellos en los que se fomente la autonomía y la creatividad (dentro de los límites del trabajo que estás desarrollando, ya que como en otros muchos campos el exceso, en este caso, de creatividad puede dar lugar a muchos problemas).

Esa mayor autonomía hay que ganársela (y mantenerla) y eso se consigue a base de conseguir resultados dentro de los márgenes de responsabilidad que te vayan asignando.

Te pedirán unos resultados, existirán unas ciertas reglas del juego (procesos, condiciones contractuales con el cliente, etc…) y unos ciertos puntos de control (que serán más frecuentes y con más detalle en función de la naturaleza de los trabajos y del grado de autonomía que te hayas ganado).

¿No prefieres trabajar en un entorno así?, ¿no te importa eso y sí el sueldo que recibes? Cada cual tiene en la vida unas prioridades y las respeto, este artículo y el anterior los publico con el objetivo de que reflexionemos sobre esto.

Nuestro primer instinto puede ser intentar conseguir el mayor sueldo posible pero pasado un tiempo se empiezan a valorar más otras cosas si estás en un trabajo en el que no progresas (y no me refiero necesariamente a conseguir ascensos), en el que todos los días hay una crisis o en el que estás encorsetado y no tienes prácticamente margen de maniobra no es precisamente el sueldo lo que tiene más importancia. Es posible que el salario que cobres, la situación del mercado laboral o tu situación personal te tengan atado a tu organización pero probablemente si tuvieras la oportunidad aceptarías irte a otro entorno laboral que te llenase más profesionalmente incluso cobrando menos (siempre y cuando se supere el umbral de lo que consideras necesario para vivir).