archivo

Archivo de la etiqueta: stakeholders

Los presupuestos fijos en los proyectos sobre una base de funcionalidades que hay que desarrollar (y que son o pueden ser innegociables) dan lugar a fuertes desviaciones en las previsiones iniciales que se pueden ver reducidas o acentuadas en función del conocimiento del negocio, tecnología y de las personas (componentes de los stakeholders) que van a participar en el proyecto y de la materialización o no de los riesgos previstos e imprevistos.

Cuanto mayor sea la incertidumbre más probabilidad hay de que las estimaciones sean erróneas. Por tanto, cuanto más cerca estemos del inicio del proyecto, más probabilidad de error habrá.

Mike Cohn lo cuantifica de la siguiente manera (traducción libre): “Durante la fase de estimación de la viabilidad de un proyecto la estimación realizada se sitúa entre el 60% y el 160%”.

Sobre esa afirmación se podría pensar que todos los proyectos están abocados al desastre. Tal vez quien piense eso no anda muy mal descaminado, sobre todo si el proyecto se realiza en un contexto de inflexibilidad en el que las distintas partes no se centran en el problema: que es desarrollar un producto software de la mayor calidad posible teniendo en cuenta los recursos disponibles.

¿Qué es ese contexto de inflexibilidad? Este es el presupuesto y esto es lo que hay que hacer, no hay posibilidad de negociación ni voluntad de analizar las causas que han dado lugar a esa situación.

Es importante que tengamos en cuenta lo que nos dice el Manifiesto Ágil al respecto: “Se valora la colaboración con el cliente, por encima de la negociación contractual”, a lo que habría que añadir también que “Se valora la colaboración con el proveedor, por encima de la negociación contractual”.

Y es que las causas hay que analizarlas con el objeto de determinar cuál o cuáles han sido los orígenes de esta situación porque en base a eso hay que dialogar y negociar. Generalmente los problemas de ese diálogo o de esa negociación lo tenemos también como consecuencia de una situación de inflexibilidad y la negativa a reconocer errores por parte del cliente y del proveedor.

Dado que el desarrollo de software es evolutivo soy de la opinión de que el presupuesto en un proyecto debe evolucionar de la misma manera que lo hace el software teniendo siempre presente el cliente y el proveedor el coste de cada actuación. Sobre esta materia recomiendo leer la serie de artículos sobre Contratación ágil que escribí hace un tiempo.

Dentro del ámbito de un equipo de proyecto los rumores relacionados con aspectos profesionales, en las relaciones entre las personas del equipo, en las relaciones con el resto de stakeholders, en las relaciones con el resto de la organización, etc… debe ser el menor posible porque es un elemento de distracción evitable, genera malos entendidos e incluso según la naturaleza del rumor puede afectar a la motivación o a la estabilidad de miembros del equipo.

Dentro del ámbito del proyecto también debe cuidarse este aspecto entre todas las partes que intervienen, por los mismos motivos que los que acabo de exponer pero haciendo especial énfasis en los malos entendidos.

En el ámbito de un departamento o de una organización también debería minimizarse la existencia de rumores, si bien resulta mucho más complicado conforme el tamaño y complejidad de la misma y el número de empleados crece.

Ken Schwaber considera que “Donde hay rumores, no hay una buena comunicación” y yo creo que efectivamente así es ya que en este tipo de contextos la información solo fluye entre una serie de personas que después queriendo o sin querer la filtran completa o sesgada a otras personas dentro o fuera de la organización y a partir de ahí el mensaje queda distorsionado.

El desarrollo de software es algo muy complicado como para añadirle elementos de resistencia adicionales que pueden ser perfectamente evitados a través de una política o estrategia de comunicación adecuada dentro del equipo de proyecto y con los stakeholders.

Desarrollar software es muy complicado, no solo por su componente técnico y por el hecho de que errores muy pequeños en el código puedan provocar incidentes graves, sino porque el proyecto se realiza en un contexto en el que interactúan personas, equipos e incluso organizaciones diferentes, cada una con sus objetivos e intereses.

Los proyectos entran en conflicto cuando alguna de las partes decide abandonar el objetivo general del proyecto (satisfacer las expectativas del usuario) para poner por delante sus objetivos individuales (como por ejemplo ganar o no perder dinero en el proyecto, dedicar más atención a otras tareas que entiende más prioritarias, etc…).

Es cierto que a veces se llega a estas situaciones por no respetar las condiciones de partida del proyecto y que eso provoque que una de las partes quiera imponer en un momento dado sus propias reglas. También es posible que desde fuera del ámbito del proyecto, personas o departamentos con un nivel superior en la jerarquía organizativa den instrucciones para que determinados trabajos tengan una mayor prioridad que el que se está realizando en el proyecto.

Pero también lo es que muchas veces se llega a esto por no haber gestionado de manera adecuada tu rol en el proyecto y los recursos que tienes a tu disposición y se llegue a una situación donde para salvar unos resultados pongas en riesgo el propio proyecto.

Es frecuente que este tipo de situaciones de lugar a un enfrentamiento de desgaste, del tipo de la guerra de guerrillas, donde el objetivo no es tanto ganar, como no perder. Para ello, se tiene que llegar a un punto donde al resto de stakeholders no le compense seguir con la situación y tengan que buscar una vía para continuar con el trabajo. A ese extremo se llega tras mucho desgaste.

Y efectivamente, no se ha ganado aunque el resultado parezca indicar que sí, ya que la actuación que ha tenido en el proyecto ha fracasado (independientemente de que se pueda reconducir posteriormente y terminar con un cierto éxito) y el resto de implicados ha perdido su confianza.

¿Qué te queda entonces? Solo el balance económico del proyecto (visión cortoplacista), pero si levantas la vista, en ese campo solo te queda desierto.

Otro antipatrón muy típico en el desarrollo de software.

Se produce cuando ante una contingencia (generalmente, de una cierta importancia) que ocurre en el proyecto y que lo deja bloqueado o ralentiza de manera considerable su ejecución (y que terminará finalmente bloqueado), que requiere de la participación o del consenso entre los directores stakeholders, no se le termina de dar una solución satisfactoria, de manera que todo queda prácticamente igual.

Ante esta situación, el equipo de proyecto y el personal del resto de stakeholders que no ocupan posición directiva, se quedan ante un panorama difícil de resolver, ya que probablemente se habrá llegado a esta situación, por un conflicto entre equipos de trabajo, por desacuerdos contractuales y/o por alguna circunstancia en el proceso de desarrollo que de no repararse, podría poner en peligro el éxito del proyecto.

El problema se produce en el día del proyecto (o es consecuencia de él), se escala (o llega desde arriba), los de arriba no le dan solución al problema, vuelve hacia abajo, pero la situación es peor, se ha perdido más tiempo, se ha sufrido desgaste y nada.

Cuando se llega a esta situación es complicado que se resuelva por sí misma, por lo que la estrategia a aplicar dependerá del estado en el que se encuentre el proyecto.

Si estamos en etapas iniciales, lo mejor es resolver el contrato. Si estamos en etapas intermedias, es necesario escalar el problema tantas veces como sea necesario porque sin acuerdo, por bueno o malo que sea, no se tendrá producto software y todos saldrán perdiendo. Si estamos en etapas finales, es necesario darle cierre al proyecto cuanto antes (resolver el contrato, pero con una serie de hitos a conseguir), aunque requiera de la apertura de un nuevo proyecto para terminar de desarrollar por completo el producto.

El crédito de una persona, de un equipo de proyecto o de un proveedor es un gran facilitador. Esto en el desarrollo de software es un instrumento importante tanto a la hora de sentar las bases para su realización, como en la propia ejecución.

De esta manera una oferta económica, una propuesta metodológica o estrategia para realizar el proyecto, la selección de una alternativa de solución, la propuesta de necesidades para que el trabajo se realice en un contexto adecuado, etc… serán más fácilmente aceptadas.

Además, el manejo de las crisis, de las relaciones con otros stakeholders será más llevadera, ya que tendrás el tiempo y la autoridad necesaria para reconducir la situación, algo que sin tener el crédito suficiente se hace mucho más cuesta arriba.

El crédito es algo que vas sembrando con tu trabajo, con tus resultados y con tu comportamiento en el éxito y en el fracaso, cuando aciertas y cuando te equivocas (porque equivocar te vas a equivocar eso es seguro, la diferencia se encuentra en cómo afrontas esa situación). Requiere tiempo, no se consigue en dos días.

Las personas que son capaces de reunir este nivel de credibilidad permiten fidelizar clientes y éstos verán en muchos casos a esa persona como la referencia, no a su empresa.

Si una empresa tiene credibilidad es fruto del crédito de las personas que tiene a su cargo y no necesariamente debe existir una figura clave en la relación con el cliente que proporcione ese crédito (aunque como he comentado antes ayuda mucho), sino que los propios equipos de proyecto con sus resultados son los que consiguen ese hito.

Una de las causas que puede dar lugar al fracaso en un proyecto de desarrollo de software consiste en no dedicar tiempo a hacer una evaluación o gestión inicial del riesgo. Afrontar un trabajo sin tener en cuenta ese factor te puede meter en un campo minado, cuando lo mismo se podía haber elegido otro camino o, por lo menos, si se adivinan los problemas que puede haber, tienes recursos para intentar salir con éxito del mismo.

Otra de las causas y sobre la que he escrito bastantes artículos, consiste en evitar no solo Death March Projects, que digamos que son la situación extrema, sino en establecer unas condiciones de partida que proporcionen un contexto a partir del cual un proyecto tenga posibilidades de ser ejecutado con éxito (presupuesto y plazos adecuados, stakeholders implicados de verdad, conocimiento y reconocimiento de la estrategia y/o metodología que se va a seguir para realizar el proyecto, etc…).

Una cita de Sun Tzu que complementa a otra de este mismo y sobre la que ya he tratado en el artículo: “Sun Tzu. El proyecto y las condiciones necesarias para la victoria“, es la siguiente: “Si las estimaciones realizadas antes de la batalla indican victoria, es porque los cálculos cuidadosamente realizados muestran que tus condiciones son más favorables que las condiciones del enemigo; si indican derrota, es porque muestran que las condiciones favorables para la batalla son menores. Con una evaluación cuidadosa, uno puede vencer; sin ella, no puede. Muchas menos oportunidades de victoria tendrá aquel que no realiza cálculos en absoluto”.

Hay una cita que dice que la programación es una pelea continua. El desarrollo de software en general es una pelea continua.

¿Hay algo malo en ello? Lo único malo es que no se gane la pelea y no se gana si no cumplimos con las expectativas que se tienen depositadas en el software.

Por lo demás, la pelea continua (si se quiere llamar así) es inherente al proceso de desarrollo porque su incertidumbre hace que se necesite que el equipo de proyecto y el resto de stakeholders tengan su enfoque en el proyecto.

También puede interpretarse como pelea continua el desgaste que supone este trabajo. Y sí, desgasta, porque desgraciadamente es difícil que los proyectos sigan un guión establecido, por su incertidumbre y por la naturaleza humana que sirve de base a los mismos.