Desarrollo de software. Cycle time y productividad

Conseguir una mejora del Cycle time cuya repercusión en los resultados sea mayor que la inversión económica realizada y sin pérdida de calidad en el resultado final debe ser un objetivo de todo sistema de estas características (sea Kanban o cualquier otro que utilice estrategias similares).

De hecho la aplicación de Kanban pretende de entrada detectar qué aspectos están afectando al Cycle time y posteriormente detectar de la manera más temprana posible esos cuellos de botella (pretende, por tanto, detectar resistencias y atacarlas con el objetivo de reducir su impacto).

No podemos olvidar que lo más importante siguen siendo las personas, su interacción, sus conocimientos y su capacidad, factores que influyen notablemente en el Cycle time, además de otros aspectos, como los medios disponibles y la tecnología.

Tal y como decía en el primer párrafo, la mejora del Cycle time no debe hacerse a expensas de la calidad del software o al menos debe sopesarse qué supone una cosa y qué supone otra. De nada vale entregar antes pero que el producto resultante sea peor, se llega antes, pero después se tendrá que invertir esfuerzo en dar una solución a los defectos o a reenfocar aspectos funcionales o no que se podían haber hecho mejor si se le hubiera dedicado una mayor atención.

El peligro de utilizar el dinero como motivador

Utilizar el dinero como motivador suele ser eficaz a corto plazo, a medio y largo plazo resulta fatal para tu departamento u organización.

¿Por qué? Pues porque lo excepcional se convierte en costumbre y al cabo del tiempo ya no será suficiente para motivar o no tendrá el mismo efecto. Además, en el momento en que falta ese ingreso se suele obtener el efecto contrario: reducción del rendimiento por falta de motivación.

De esta forma se crea en la cultura de que lo que realmente mueve a los profesionales de la organización es el dinero y no el interés por el trabajo que se realiza en la misma, el propio afán del desarrollador por mejorar o la pasión que puede sentir por su profesión.

Otro problema lo tenemos en que la persona tenderá a ir a por los objetivos que le permiten obtener la recompensa, dejando de lado otros que pueden ser igualmente importantes para la organización. La persona se convierte en cumplidor pero en cumplidor de lo que le interesa, de lo que le hace ganar más dinero.

Estoy hablando de recompensas sistemáticas y no de retribuciones justas. Soy de la opinión de que un profesional debe estar pagado acorde a sus méritos, conocimientos y experiencia (aunque raras veces se pague a los profesionales siguiendo esos criterios). Tampoco estoy en contra de las retribuciones variables siempre y cuando las mismas se realicen siguiendo criterios objetivos y estén al alcance del conjunto de empleados de la organización.

Austin Freeman. Simplicidad y eficiencia

Para Austin Freeman: «la simplicidad es el alma de la eficiencia».

Cuando como desarrolladores asumimos que el producto se construye mediante aproximaciones sucesivas desde soluciones más simples y que no hay nada más productivo que evitar el desperdicio de esfuerzo en la implementación de funcionalidades no necesarias o que todavía no se han madurado lo suficiente, hemos dado un paso muy importante para tratar de maximizar la relación valor/inversión, lo cual supone una ayuda significativa en los diferentes proyectos en los que trabajemos.

Pero los desarrolladores nos debemos limitar a hacer nuestro trabajo y a asesorar a los responsables funcionales, por lo que independientemente de que tratemos de aplicar principios de simplicidad a nuestros trabajos no será suficiente si los encargados de definir la línea de desarrollo del producto no lo aplican también.

Una vez superado nuestro impulso de querer terminar demasiado pronto (y no es fácil conseguirlo), toca tratar que los usuarios piensen también en simple y eso es complicado porque suelen pensar en soluciones de máximos o en asegurar un buen número de funcionalidades desarrolladas, en lugar, tal vez, de ser menos ambicioso y tal vez llegar a menos pero mejor y con mayor valor.

La eficiencia es invertir adecuadamente el esfuerzo y no desperdiciarlo en lo que no merece la pena. Teniendo en cuenta que es muy difícil no desperdiciar porque si no fuera así siempre acertaríamos a la primera y eso no va a ser así. La economía del desperdicio se basa en partir de lo simple para a través del conocimiento generado y validado seguir creciendo.

Trabajar duro, ¿trabajar bien?, efectividad, productividad y aprendizaje

Respeto mucho a la gente que trabaja duro, a las personas que tienen un nivel de responsabilidad y compromiso para consigo mismo y su equipo (extenderlo a nivel organizativo sería generalizar demasiado porque no son muchas las organizaciones que hace sentir a las personas que trabajan en ellas como parte importante de la mismas). Después las cosas saldrán bien o mal, pero no será por el empeño que se ha puesto.

Ahora bien, si no sale bien, tampoco es cuestión de mala suerte (o por lo menos no se puede recurrir siempre a eso) porque trabajar duro y de manera efectiva no significan lo mismo.

Por ese motivo no se debe ligar productividad a horas trabajadas sino a la efectividad, extendiéndose este último concepto a algo más que completar tareas de manera adecuada, llegando incluso a considerarse como parte del mismo al aprendizaje que vamos obteniendo incluso en aquellos casos donde los resultados no sean todo lo positivos que esperamos.

Si además de no conseguir resultados, no extraemos conocimiento todo será desperdicio.

La productividad entendida de esta manera puede crear controversia porque nos estamos saliendo de la ortodoxia de su concepción clásica, no obstante, si no tenemos en cuenta esos otros activos que se pueden obtener como consecuencia del trabajo que realizamos, estamos dejando fuera del análisis a una parte importante del producto obtenido, intangible, sí, aparentemente (solo aparentemente) inútil, que tal vez no permita recuperar el tiempo perdido pero que más adelante (tal vez mañana mismo) puede producir resultados tangibles y efectivos.

Productividad, sobreesfuerzo y superhéroes

La productividad pasa por ser efectivo y no por echar más horas. Los que nos dedicamos al mundo del desarrollo de software sabemos que en diferentes ocasiones tenemos que echar horas de más para completar determinadas tareas, sin entrar a analizar si es algo que se debe admitir o no, sabemos que en ocasiones es necesario y la mayoría lo tenemos asumido.

También sería de interés que los responsables de las organizaciones lo tuvieran asumido y reconociesen ese esfuerzo de alguna manera y no hablo de palmaditas en la espalda. Ahora bien, si el sobreesfuerzo es consecuencia de haber dejado las cosas para última hora o por no haber hecho un buen trabajo, no se debe esperar, por lógica y por justicia para el resto de tus compañeros que encima te recompensen.

Sin embargo, echar más horas puede ser efectivo a corto plazo pero perjudicial a medio y largo plazo, sobre todo si esas horas de más se convierten en interminables jornadas que abarcan prácticamente todos los días de la semana. No somos robots, no somos máquinas, más pronto que tarde notaremos física e intelectualmente ese agotamiento y el resultado de nuestro trabajo será un reflejo de ello. Por ese motivo es fundamental saber repartir los esfuerzos y dejar las heroicidades para los superhéroes ya que esa no es nuestra misión.

La competitividad no pasa por malvender proyectos a costa de las personas que después tienen que realizarlos y/o a costa de las satisfacción final del usuario, sino pasa por ser efectivo, ahí es donde se marca la diferencia porque lo otro es capaz de hacerlo cualquiera y, además, suele tener, a la larga, efectos negativos.

Intención, productividad y líneas de código

Un día sin escribir una línea de código puede ser más productivo que una semana picando código sin parar. Nunca el número de líneas, métodos o clases debe considerarse como métrica de avance del proyecto, al menos, mirándolo desde una perspectiva general.

El mejor código es aquel que nos ahorramos de escribir porque la funcionalidad no era necesaria, el enfoque no era bueno, existía una estrategia mejor, hemos podido reutilizar tal código o hemos encontrado una librería que hace justo lo que queríamos.

Partamos de la base de que va a ser prácticamente imposible que nuestro código tenga esos kilos de más entre otras cosas porque el desarrollo de software es evolutivo y lo que hoy parece una funcionalidad imprescindible mañana puede ser algo que no se utilice o que se tenga que rehacer por completo.

Teniendo presente eso, tenemos que tener en mente tanto nosotros como los responsables funcionales o products owners que la prueba y el error no es lá técnica a seguir (salvo en casos muy puntuales) sino que se debe desarrollar con intención con el objetivo de evitar la cómida rápida y que nuestro producto tenga una dieta equilibrada baja en calorías.

Retrabajo

El retrabajo es volver a trabajar sobre un determinado desarrollo o la realización de nuevo de una serie de tareas (que puede ser de mayor o menor entidad) y que ha podido ser perfectamente evitable.

Tiene un impacto importante en los proyectos porque es tiempo perdido, esfuerzo que no ha proporcionado ningún valor al proyecto.

En el desarrollo de software estamos acostumbrados a hacer y a rehacer, la diferencia con el retrabajo es la diferencia entre la intención y la negligencia. Se ha podido desarrollar una funcionalidad con intención, de manera meditada y después el usuario descartarla porque una vez desarrollada no le termina de ver utilidad en el sistema.

Se ha ido con una idea concreta y se ha fallado, la negligencia es cuando sin esa reflexión necesaria u obviando soluciones más claras y probables se decide tirar hacia adelante.

Es cierto que entre intención y negligencia hay toda una escala de grises y que cada caso concreto merece su análisis. No obstante, las situaciones extremas son fácilmente identificables y cuando se mete la pata resulta complicado disfrazarlo.

El retrabajo puede ser motivado por el product owner pero también por los desarrolladores.

¿Se quiere mejorar la productividad en los desarrollos? No solo basta con simplificar o eliminar tareas que aportan un valor escaso o nulo con respecto a la inversión necesaria para realizarlas, también es muy importante evitar, en la medida de lo posible, el retrabajo.

Desarrollo de software. Mejor en lo que sabes

Si estamos tratando de desarrollar un producto y la incorporación de una nueva tecnología no aporta ninguna ventaja competitiva o el acceso a un segmento de mercado nuevo, es mucho más productivo desarrollar en lo que ya sabes, reutilizando todo lo que sea posible (siempre que sea adecuado al proyecto).

No se trata de no evolucionar en tus conocimientos, sino de ser efectivo. Si quieres aprender o probar cosas nuevas, ya tendrás tiempo para hacerlo, pero en proyectos reales con dinero de por medio, todo lo que sea aplicar soluciones con intención termina ahorrando costes: tienes controlados la mayoría de los problemas relacionados con la tecnología, sabes cuál es tu ritmo de desarrollo, tienes más facilidad para encontrar la solución más simple, etc…

Cuando no controlas la tecnología es como si estuvieras caminando en un campo de minas, encontrándote, cada día o cada semana con nuevos problemas que afectan al desarrollo normal del proyecto y al cumplimiento de los compromisos que se vayan fijando. Esas contingencias suponen un esfuerzo desaprovechado que llegado a un punto ya no se puede recuperar por muy efectivo y productivo que se sea, salvo que se resienta el producto, tu propio tiempo (overtime) o la cuenta de resultados.

Desarrollo de software. Enfoques iterativos incrementales y tiempo de espera para nuevas tareas

En el artículo de ayer vimos diversas formas de gestionar las solicitudes de modificaciones sobre la pila de sprint en donde no se aceptaban las mismas (inspiración Scrum) o en donde cabía la posibilidad de aceptarlas (inspiración Kanban siempre y cuando haya un orden). En cada una de esas estrategias el tiempo de espera cambia:

– Si nos inspiramos en Scrum el tiempo de espera medio para empezar a trabajar en nuevas tareas, será la mitad del tiempo de duración de los sprints.

– Si nos inspiramos en Kanban el tiempo de espera medio para empezar a trabajar en nuevas tareas será el tiempo que se tarda en que haya un hueco (Kanban establece límites en ciertas fases del flujo de trabajo), por lo que el tiempo de espera en este caso será mucho menor.

En ambos casos se tiene un control sobre la cantidad de trabajo en progreso (WIP: Work in progress) y eso es importante en cuanto a que estamos tratando de limitar el trabajo a la capacidad del equipo con el objetivo de conseguir predecibilidad y una mayor productividad pero, nada es gratis, es decir, se requiere pagar un precio que es el tiempo de espera.

¿Merece la pena pagarlo? Mi opinión es que sí ya que el caos no es productivo.

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.