archivo

Archivo de la etiqueta: Death March Project

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,.

En el fútbol se puede jugar muy bonito y no ganar ningún partido. Se puede jugar muy feo y conseguir tus objetivos. Puede que prefieras que tu equipo juegue bien a ganar o bien que tu equipo gane sea como sea.

En el desarrollo de software para ganar has tenido que jugar bien, no hay otra opción. Y jugar bien no implica aplicar tal o cual metodología sino haber sabido interpretar qué le ha venido mejor al proyecto en cada momento, que las personas que participan en él hayan estado implicadas y acertadas, que el talento colectivo haya predominado sobre el individual y que de entrada el partido no estuviera perdido (Death March Project).

En el fútbol juega un equipo contra otro, en un proyecto de desarrollo de software todos deberían jugar en el mismo equipo. Cuanto más evidente sea la diferencia entre las diferentes organizaciones, departamentos o áreas de las personas que intervienen en el proyecto, tendremos más equipos pero menos equipo.

Cuanto tenemos equipos y no equipo sí que empiezan a ponerse sobre la mesa planteamientos de ganar (o de no perder) y anteponer eso a los intereses generales del proyecto, es decir, de tratar de conseguir un resultado como sea, aunque perjudique a un tercero. Cuando eso sucede, cuando se buscan victorias parciales, es el proyecto quien pierde el partido.

Buena parte de la contratación del software está basada en acuerdo llave en mano en la que se pacta un precio cerrado para desarrollar un producto en base a unas especificaciones, por regla general, no muy detalladas de lo que se pretende hacer.

En muchos casos, el proyecto parte de una situación de Death March Project que dará lugar, si es que se consigue llegar, al menos, a ese punto, a un producto que no satisfará las necesidades y expectativas del usuario y en medio de todo eso se habrá producido un desgaste importante entre los diferentes implicados en el proyecto.

Los defensores de esta estrategia de contratación se centran en que el riesgo se traspasa al proveedor que es quien asume unas condiciones y como tal, debe cumplir lo pactado. Sin embargo es algo que termina volviéndose en contra también del cliente, que se debería conformar, con las especificaciones que dé en la fase de captura de requisitos, sin posibilidad de modificarlas posteriormente (la llave en mano y el desarrollo en cascada son compañeros de viaje).

¿Qué pasa? Pues que acertar a la primera es muy complicado y conforme vaya avanzando el desarrollo y los responsables funcionales vayan viendo partes del producto funcionando, surgirá la necesidad de realizar cambios sobre las especificaciones o incluso la necesidad de incrementar el alcance inicialmente previsto.

En ese momento entran en juego las negociaciones y dependerá de la voluntad de las partes que las mismas lleguen a un punto donde sea posible todavía entregar un producto que cumpla unas condiciones mínimas.

Desde mi punto de vista creo que, a pesar de ser legítima, una situación de partida en la que una de las partes trata de echar sobre la otra todo el riesgo no es positiva para un proyecto por sus propias características inherentes: incertidumbre, carácter evolutivo del desarrollo y las diferentes contingencias, casuísticas y problemas que suele haber en los mismos.

El valor del producto proporciona directamente valor a la organización que hace uso de él y también resulta positivo y adecuado que la organización trate de armonizar ciertos tipos de desarrollos con el objeto de que el parque de aplicaciones no crezca de manera desproporcionada (otro de los males que aquejan a las organizaciones), la integración de datos sea efectiva y exista una cierta homogeneidad tecnológica, a la par de trata de conocer cómo se está gestionando el resultado de la inversión que se está realizando.

Y es que casi que más que calidad (aunque se siga utilizando de forma inevitable ese término), cada vez me gusta hablar más del valor del producto. Son dos términos compatibles y complementarios, a la vez de que la calidad de un producto contribuye a su valor.

El valor se asocia al sistema que se está desarrollando y las acciones que se realizan sobre el mismo pueden incrementarlo, mantenerlo o reducirlo y pueden impactar o no en los costes asociados para conseguirlo, por tanto, el valor es importante, mucho más que el coste si después se puede recuperar la inversión en un tiempo razonable, pero no debemos olvidarnos que tratar de buscar la eficiencia en el desarrollo implica también tratar de maximizar el margen entre el valor y el coste.

Esto implica que debemos desarrollar con intención con el objeto de incrementar en lo posible el valor del producto en cada evolución del mismo y también con la misión de que sea a un coste razonable, ya que lo que consigamos ahorrar se podrá volver a invertir en seguir incrementando su valor o en incrementar el valor de otras aplicaciones.

¿Conviene arriesgar coste a cambio de valor? Esta no es una respuesta que daba dar el desarrollador sino el responsable funcional o del producto, él es quien decide sobre su línea de desarrollo y de evolución y es el que debe evaluar si la inversión realizada puede poner en riesgo la continuidad de los desarrollos o del mantenimiento básico de la aplicación (debería dejarse asesorar también por los desarrolladores).

Si bien es responsabilidad del propietario del producto mi opinión es que si tenemos la oportunidad de rematar adecuadamente una versión del producto lo hagamos, aunque eso implique un coste adicional al que se tenía pensado inicialmente.

Tratar de conseguir un mayor valor es independiente del contexto, hasta en proyectos condenados desde el principio (Death March Project), podemos tratar de conseguir el mayor posible, independientemente de que se consiga llegar hasta el final o que los resultados no sean satisfactorios. Conseguir el mayor valor posible no quiere decir que se consiga superar el umbral para que la aplicación vaya a tener una acogida satisfactoria y tenga éxito.

Siempre es posible desarrollar un software aplicando las mismas técnicas de gestión que para construir un puente, sin embargo estaríamos prescindiendo de una de sus principales características, su maleabilidad, lo que le permite adaptarse al cambio y modificar criterios con un coste asumible (siempre y cuando se tenga la deuda técnica bajo control).

Cuando tienes un puente a medio construir, tomar la decisión de poner un carril más en cada dirección puede ser prácticamente imposible o requerir una inversión muy superior a la que hubiera sido necesaria si se hubiera tenido en cuenta desde el principio.

En el desarrollo de software no es así. Es cierto que el cambio tiene un coste pero no es equiparable al de las construcciones físicas.

Renunciamos a la maleabilidad del software cuando lo importante es el cumplimiento de una agenda, es decir, se prioriza mantener previsiones de costes y plazos sobre la posibilidad de entregar un producto con mayor valor. Hay que analizar cada circunstancia y es posible que no haya otra alternativa que cumplir con la agenda: no es posible dedicar mayor presupuesto al proyecto y/o modificar los plazos, siempre y cuando se entienda que no es posible la cuadratura del círculo: cumplir agendas y tener al producto sometido a continuos cambios de criterio.

Mi apuesta es incrementar el valor del producto que se pone en producción y eso requiere un enfoque iterativo incremental para aprovechar el feedback del usuario. Esto tiene implicaciones presupuestarias que se solucionarían bien teniendo abierto el presupuesto del proyecto o si está cerrado centrarse en que las funcionalidades prioritarias vayan bien (esto último siempre y cuando no nos encontremos en una situación de Death March Project en la cual todo será mucho más complicado).

El concepto de espíritu de Dunkerque surge como consecuencia del esfuerzo realizado en mayo de 1940 por ciudadanos británicos en conjunción con sus fuerzas armadas para la evacuación del grueso de las tropas aliadas en la 2ª Guerra Mundial, como consecuencia del empuje de las fuerzas alemanas y el riesgo de quedar arrasadas ante la imposibilidad de defensa u otras vías de escape.

Se considera que el esfuerzo y el riesgo de unos pocos, implicados directamente o no en la guerra, permitió salvar a muchos.

Por tanto, ese concepto se utiliza para representar un espíritu de unión ante una situación adversa o complicada.

¿Cómo puede considerarse algo así un antipatrón y cómo se relaciona con el desarrollo de software?.

Existen proyectos que se consiguen salvar o que llegan a tener éxito gracias al esfuerzo de unas cuantas personas, generalmente las que están en el día a día, pese a que las condiciones de partida se encontraban próximas a un Death March Project y/o el conjunto de toma de decisiones hacían todo mucho más difícil.

Este antipatrón surge cuando tras la realización de ese esfuerzo (con ese espíritu de Dunkerque), esa mala negociación inicial, esa mala venta o esas decisiones tomadas de forma negligente quedan ocultas o minimizadas, con el riesgo de que en el siguiente proyecto pueda volver a pasar lo mismo, si el responsable o los responsables no han aprendido nada de lo sucedido.

Además, cómo no ha pasado nada, el mérito del equipo no será tenido en cuenta de manera adecuada, pudiendo pasar, como sucede muchas veces que el mérito se lo lleve quién o quiénes provocaron la situación de partida o han provocado resistencias en el proyecto.

No es cuestión de quién se lleve las medallas, sino de ser justo. Probablemente si el equipo siente que no ha existido justicia será mucho más complicado que el espíritu de Dunkerque vuelva a aparecer.

Te preguntarás, ¿qué se hace entonces?, ¿se deja fracasar el proyecto para que esos problemas salgan a la luz? No. El equipo de proyecto ha actuado como debe, sacando adelante un proyecto en unas condiciones muy complicadas. Es un problema de carácter organizativo ya que los responsables o jefes de quiénes han provocado esta situación, no han llegado a darse cuenta del problema, ya sea porque no han dedicado la suficiente atención, lo han seguido desde demasiado lejos o han realizado una gestión basada en números. O peor aún, siendo conscientes de la situación, no han hecho nada.

¿Y si vuelve a ocurrir?, ¿qué hacemos? Yo no soy partidario de bajar los brazos, mi opinión es que el equipo debe seguir trabajando de la mejor manera posible, si no lo hace, se convierte en cómplice y creo que eso no sería justo con el equipo. Si bien, entiendo perfectamente que la motivación y como consecuencia, la productividad baje, porque somos humanos y estas cosas nos afectan.

Una organización no se puede sostener si no hay ingresos. La dirección presiona. Los comerciales y/o gerentes necesitan vender para mantener su puesto de trabajo. Ambos ingredientes crean un peligroso caldo de cultivo: la venta lo justifica todo.

Cuando nos encontramos ante un Death March Project muchas veces la culpa es del cliente por querer obtener lo máximo con la mínima inversión posible (cuadratura del círculo que casi siempre da unos resultados terribles), pero otras por el proveedor, que acude con unos precios que de entrada se sabe que van a ser deficitarios o muy deficitarios.

Quien defienda estas prácticas podrá decir: “mejor eso que nada” y yo le contesto que a veces nada es mejor que eso:

– El resultado del proyecto será malo y con un desgaste importante en las relaciones con el cliente, lo que te pondrá muy complicado volver a tener contratos con el mismo y con aquellos que le pidan referencias.

– El coste suele ser muy superior al presupuestado por lo que a medio plazo las pérdidas serán superiores a las ganancias.

Tirar los precios ha hecho mucho daño en el sector, porque los ha abaratado por encima de los costes salariales y de estructura y porque los malos resultados han creado mucha desconfianza en los clientes, que ante los recortes presupuestarios se piensan muy mucho seguir invirtiendo en nuevos sistemas de información o en la mejora de los ya existentes.

Además, se crea una mayor distancia entre quién vende y quién ejecuta, algo que es muy peligroso porque las prácticas de “arrojar al otro lado del muro” agudizarán más el problema: quienes venden tendrán cada vez menos en cuenta a quiénes tienen que realizar el trabajo y los segundos, ignorados en el proceso de venta y de las condiciones finales, se sentirán mucho menos implicados y motivados.