archivo

Archivo de la etiqueta: esfuerzo

Cuando se falla en las estimaciones estamos golpeando en la línea de flotación del proyecto y también contra nosotros mismos. Se falla muy a menudo y después toca sufrir las consecuencias porque se adquieren compromisos que costarán muchísimo esfuerzo ser respetados.

¿Por qué nos equivocamos en las estimaciones? Son muchos los factores que pueden influir:

– La incertidumbre inherente que tienen los proyectos de desarrollo de software. Si aplicamos un enfoque iterativo incremental con sprints cortos tiene una menor o nula influencia dentro de ese segmento de trabajo, pero si consideramos el proyecto en su totalidad sí que la tiene cuando hay cambios significativos ya sea sobre las condiciones iniciales o sobre el producto que se lleva desarrollado.

– Se tiende a estimar considerando situaciones ideales y después sabemos que hay problemas.

– Se estima en muchos casos sin conocer suficiente detalle sobre el trabajo a realizar.

– Se estima en muchos casos sin conocer suficientemente las restricciones de la tecnología o del entorno de trabajo.

– No estima quien va a realizar el trabajo.

– La presión del cliente por tener plazos más cortos (y a menor coste).

Estoy seguro de que se os ocurren otro montón de causas que provocan que no se acierte con las estimaciones. Ahora bien, una cosa es que sea difícil estimar y otra que no se intente acertar en lo posible con las mismas porque no queda otra, por ese motivo es importante tomar el control de todos aquellos factores que estén en nuestra mano y que puedan afectar a la calidad de la estimación, esto dependerá como no podría ser de otra forma del proyecto en sí y de su contexto.

Como sabemos los problemas que hay con las estimaciones y que es necesario dar la importancia que se merece al feedback sería recomendable que el cliente pensase más en términos de valor que de agenda, si bien, no resulta sencillo conseguir esas condiciones ya que se mostrarán, por términos generales, reacios a considerar que el presupuesto inicial puede variar después …

Anuncios

El tamaño y la incertidumbre importan. Para un proyecto donde se prevé el desarrollo de un nuevo sistema de información de medio o gran tamaño o un mantenimiento evolutivo importante del mismo resulta muy complicado acertar, es más, soy de la opinión de que si se acierta es por casualidad.

Un gran desarrollo tiene incertidumbre inherente porque es sabido que en la mayoría (aplastante) de los casos, los usuarios no saben realmente lo que quieren hasta que se va avanzando en la construcción del producto y esto sucede independientemente del enfoque de desarrollo que se le quiera dar. Si a eso le sumas otros factores como la inestabilidad de los procesos de la organización cliente, de la propia organización, el mercado, etc…, todo se hace mucho más complicado.

Por ese motivo es importante que todas las partes sean conscientes de lo complicado que resulta acertar en un contexto como ese. Desgraciadamente en muchos casos, los usuarios y los clientes no atienden a razones y dan lugar a una gestión orientada a la agenda (a intentar mantener un equilibrio en el triángulo de hierro) en la que se sufrirá mucho si la desviación entre lo estimado y la realidad es sensible y que fracasará seguro si se superan los umbrales del Death March Project.

¿Por qué es importante tener en cuenta que estimar en esas condiciones es una batalla perdida? Pues precisamente para considerar la estimación como una referencia pero no como una losa que llevar a la espalda durante todo el proyecto, es decir, no se debe malgastar el presupuesto pero se debería ser flexible en su gestión y tener la mente abierta a la necesidad de contar con más presupuesto en el caso de que sea necesario.

Las estimaciones irán mejorando conforme se vaya avanzando en el conocimiento del producto y el equipo de trabajo se vaya familiarizando con el entorno tecnológico y el negocio. También se reducirá el margen de error si las historias de usuario o funcionalidades a desarrollar no son de gran tamaño.

Aún así se seguirá fallando y será necesario gestionar esas desviaciones, sobre todo en lo que al cumplimiento de los compromisos de la iteración se refiere, ya que en este caso, al estar más acotada la estimación y ser mayor el conocimiento que existe, las desviaciones a nivel de esfuerzo serán poco significativas (lo suficiente para fastidiarte o ponerte muy difícil cumplir con los objetivos del sprint) pero con escaso impacto a nivel presupuestario,.

Un enfoque iterativo incremental de ciclos cortos y el feedback que se obtiene a partir de ellos permite probar la efectividad de los enfoques de los usuarios (que inicialmente no son más que hipótesis sobre lo que quieren) y realizar ajustes que nos van acercando progresivamente a una solución que realmente satisface las expectativas del usuario.

En los enfoques clásicos las hipótesis no se compruebas hasta etapas finales del desarrollo en donde los presupuestos están casi agotados y en donde el tamaño del producto dificulta la realización de modificaciones. Menos dinero, más envergadura del producto, más deuda técnica, menos margen de maniobra.

Todos los que hemos trabajado con ciclos de vida en cascada y/o con contratos llave en mano hemos sufrido esa situación. Da igual lo bien que trates de hacer el análisis que siempre habrá funcionalidades que no se han definido correctamente, que ni siquiera se han definido o que son mejorables y, además, siempre existirán circunstancias a lo largo de la ejecución del proyecto que impliquen cambios de prioridades.

El conocimiento real del producto se va obteniendo conforme se va desarrollando, ¿por qué? pues porque se contrastan las hipótesis y con ello se va mejorando y adquiriendo nuevo conocimiento.

Está bien tener una visión de lo que se quiere pero el detalle se debe trabajar poco a poco, lo demás es correr un riesgo importante de desperdiciar esfuerzo y no nos podemos permitir ese lujo porque en el propio devenir del proyecto y del desarrollo del producto habrá esfuerzo que no proporcione un valor directo, ya que a veces la solución elegida para una determinada funcionalidad deberá cambiar de orientación o ser perfilada en diferentes iteraciones, algo que es normal en cualquier proyecto y que, por tanto, debe contar con suficiente respaldo presupuestario que, como no andará sobrado, es conveniente cuidarlo desde un principio.

Si no has probado a hacer un seguimiento del sprint utilizando un gráfico de burndown te recomiendo que lo hagas porque te permitirá detectar desviaciones de manera temprana y poder tomar decisiones que permitan eliminarlas o paliarlas en el caso de que se considere necesario (y se pueda).

El concepto es igualmente aplicable a ciclos más largos o a otras estrategias de desarrollo, si bien, resulta maś efectiva en contextos donde el nivel de acierto en las estimaciones sea más alto.

El burndown por otra parte no puede ser más simple, en el eje X tenemos la división en días del sprint (puedes poner día 1, día 2, etc… o fechas reales) y en el eje Y el esfuerzo restante para terminarlo, en la unidad de medida que se considere (horas, jornadas, puntos por historia, etc…). Sobre esa gráfica se dibuja una recta que representaría la proporción entre el esfuerzo restante en el proyecto con respecto al día de desarrollo suponiendo que el nivel de avance es lineal.

Lo realmente importante es la segunda línea, la que representa el avance real y que se calcula a partir del tiempo que resta para la finalización de cada tarea o historia de usuario (en función del grado de desagregación que hayas decidido utilizar). Los momentos en que esta segunda línea esta por encima de la recta representa retraso respecto a lo previsto y cuando está por debajo representa un adelanto.

Como podéis ver su mantenimiento es muy simple y los desarrolladores no tienen que realizar ningún esfuerzo significativo para ir actualizando estos datos, si bien deben ser objetivos a la hora de estimar el esfuerzo restante ya que de lo contrario se estarán tomando decisiones a partir de datos incorrectos.

La sobreproducción se entiende como la realización de trabajo de más que no resulta necesario en estos momentos. Tiene las siguientes implicaciones:

– Esfuerzo realizado que tal vez no sirva para nada, ya que una vez que el cliente evalúe lo que realmente necesita puede modificar total o parcialmente todo el conjunto de funcionalidades de más que se han realizado.

– División de la atención entre lo realmente importante y lo que no lo es. Ese esfuerzo que se dedica a lo que no es prioritario puede afectar a la calidad, al grado de terminación y a la tasa de errores de lo que sí lo es.

– El usuario, cuando se le presenta la solución en su conjunto (en su versión actual), también pierde el enfoque pudiéndose perderse en detalles que están lejos del objetivo principal de la versión.

– Incremento de la complejidad del sistema tanto a nivel técnico (deuda técnica) como de la usabilidad.

Trabajo de más es resistencia de más para poder adaptarnos al cambio, ya que nos resta flexibilidad. A lo anterior hay que sumarle el coste que se ha invertido en desarrollar funcionalidades que lo mismo nunca se llegan a utilizar o deben ser sensiblemente reajustadas, por lo que disminuye la proporción entre valor y esfuerzo.

El esfuerzo denota intención, ganas, el deseo por mejorar y querer conseguir unos objetivos y como tal se debe valorar.

Desgraciadamente, cuanto más lejos está la gestión de las trincheras, más borroso se hace el trabajo que hace cada uno y se confunde la gente que se esfuerza y los que se esfuerzan por aparentar que se esfuerzan.

El efecto desmotivador que tiene esto es devastador.

Sin embargo, al final de todo están los resultados. Deming realizó una reflexión demoledora sobre esto: “Estamos siendo arruinados por los mejores esfuerzos”, viniendo a decir que los resultados son los verdaderos jueces de todo esto.

Como decía antes, el esfuerzo se debe valorar pero tarde o temprano tendrás que conseguir resultados. El esfuerzo te dará más cuerda, pero nada más.

Con esfuerzo la recompensa llegará, tal vez no ahora, tal vez no en este proyecto o en esta organización, pero llegará. Para ello, tendrás que asumir la derrota pese a haberte dejado la piel, aprender de los errores (si no es imposible), volverte a levantar y seguir intentándolo con esa actitud.

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.