archivo

Archivo de la etiqueta: expectativa

La gestión de expectativas es más efectiva cuanto más cerca se encuentre de la realidad del proyecto, la cual está condicionada por el estado actual de los trabajos, de las actuaciones y decisiones pasadas y del contexto en que nos encontremos.

Trabajar con ilusiones, deseos y fantasías dando lugar a una realidad paralela solo nos lleva a un sitio que no es otro que el fracaso en el proyecto y es que no se puede esperar otra cosa si las expectativas son falsas y si no se han tomado las medidas adecuadas ante las desviaciones y contingencias que se hayan producido.

Se trabaja más cómodo obviando los problemas pero es mejor trabajar teniéndolos en cuenta porque al menos así tendremos alguna posibilidad de que el final de la historia sea feliz.

La siguiente cita de Jim Highsmith es posible que provoque disparidad de opiniones entre quiénes la lean. “La fórmula para el éxito es sencilla: entrega hoy y adapta mañana”.

Muchos de estos autores cuando hacen estas afirmaciones buscan la reflexión del lector por encima de dar un mensaje o afirmación rotunda sobre un determinado concepto. En muchos casos es más interesante provocar una confrontación de esas ideas con las tuyas porque es probable que de esta forma el conocimiento adquirido se adapte más a tu contexto profesional”.

¿Fórmulas para el éxito? En el caso del desarrollo de software no las hay o si hubiera alguna no sería válida en todos los contextos o incluso siendo válida para el contexto inicial de un proyecto podría dejar de serlo ante cambios en el mismo (que lo más probable es que ocurran).

Es cierto que no hay fórmulas pero sí prácticas que pueden producir buenos resultados si se aplican adecuadamente en el momento y en las situaciones adecuadas.

Estoy de acuerdo en que cuanto antes se vayan entregando versiones del producto antes será posible evaluar las expectativas de los usuarios. Por este motivo soy partidario de enfoques iterativos e incrementales, ahora bien, sí que considero necesario que cada iteración se haga con una intención, no a probar por probar, no a especular a ver qué pasa. También resulta necesario evaluar el nivel de criticidad del sistema y de los controles que debería tener antes de pasar a un entorno real.

En cualquier caso sí que deberíamos buscar que dentro de las características del sistema a desarrollar y de su contexto el tiempo necesario para pasar una versión a producción evaluable por los usuarios (y a ser posible utilizarse en un entorno de producción real) sea el menor posible.

En esta filosofía de entregas rápidas (con los matices que he indicado) está implícito el concepto de adaptación como consecuencia del feedback obtenido tras la puesta en marcha de cada iteración.

Decía Milt Bryce que: “Si viviéramos en un mundo perfecto, no sería necesario la existencia de gestores; los proyectos se ejecutarían en tiempo y coste. Sin embargo, la realidad es que vivimos en un mundo imperfecto”.

Para mi el objetivo principal de un gestor es que el equipo tenga claro que el objetivo es que como consecuencia del proyecto el cliente y/o el usuario estén satisfechos con él de manera que se hayan satisfecho sus expectativas, respetando que nos encontramos dentro del ámbito de una organización cuyo objetivo es obtener beneficios a través de los servicios que ofrece.

Ahora bien, este objetivo resulta utópico de conseguir cuando las condiciones de partida de un proyecto no se adaptan a las exigencias del mismo (proyecto infravalorado en esfuerzo y/o en tiempo y/o no compatible con las expectativas de calidad). Si se parte de un Death March Project o de una situación próxima a él, el gestor tendrá muy complicado mantener un discurso coherente porque cuando la manta es demasiado pequeña solo da para taparse la cabeza o los pies.

De la misma forma, si aún comenzando el proyecto con unas condiciones favorables, a lo largo de su desarrollo se producen contingencias que afectan sensiblemente a su ritmo, de manera que se requiere invertir un mayor esfuerzo en tareas que no lo requerían (cambios en procesos, sucesivas vueltas a atrás de funcionalidades por problemas en la especificación por parte del área usuaria, etc…), nos podemos encontrar en una situación parecida a la de si las condiciones de partida hubieran sido desfavorables.

¿Cómo mantener entonces ese discurso en el equipo? Soy de la opinión de que ese discurso debe mantenerse inmutable pero sin obviar la realidad en la que nos encontramos. El objetivo del equipo debe ser el mismo pero modulado a través de los discursos disponibles.

Es decir, el equipo tiene que ser productivo (acorde a sus posibilidades) e intentar minimizar errores evitables, por otro lado hay que intentar consensuar con el usuario una solución que sea lo más simple posible sin que éste vea perjudicada sus expectativas, además de tener muy cerrados los compromisos del usuario con respecto al proyecto, así como las medidas a tomar en el caso de que los errores o cambios sean debidos como consecuencia de los usuarios (estas dos últimas características deben estar bien resueltas en la fase de negociación, de lo contrario lo que puede ser una venta mala o muy mala se puede convertir en una venta nefasta).

Lo anterior no funciona siempre, es más, no funcionará en muchos casos, porque el cliente se aferrará con fuerza al contrato. Cuando no sea posible llegar a un acuerdo, cuando el cliente no entienda que puede ser más beneficioso tener un producto con las funcionalidades esenciales bien implementadas que un producto final donde casi nada funcione como debería, poco podemos hacer más allá de intentar llegar lo más lejos posible con los recursos disponibles (en el fondo hemos intentado alcanzar las expectativas del usuario aunque nos hayamos quedado a medio camino, respetando también en segundo término las expectativas de nuestra organización respecto al proyecto).

Cuanto más confíe el cliente en nuestro trabajo más entenderá lo que le estamos pidiendo y más dispuesto estará a hacer concesiones. La confianza es también resultado de la coherencia, es decir, no podemos pedirle al usuario que corra con sus errores si nosotros no corremos con los nuestros (y en este caso quien suele mirar por el ancho del embudo suele ser el proveedor).

Por tanto, el objetivo principal del gestor es mantener en el equipo el compromiso de entregar un trabajo de calidad y realizar las actuaciones oportunas para que el contexto del proyecto sea el más favorable posible para conseguir ese objetivo.

El gestor por tanto, es un facilitador, un dinamizador, es alguien que debe estar a disposición del equipo para que éste puede desempeñar su trabajo de la mejor forma posible, para ello debe ser alguien próximo al equipo, alguien dispuesto a sacrificarse y a ayudar, alguien quien dentro de sus posibilidades pueda echar una mano extra al equipo si hiciera falta.

El gestor también debe tomar decisiones y algunas de ellas tendrán un importante desgaste personal. A nadie le resulta cómodo reprender actitudes y a nadie le resulta agradable tener que prescindir de personal, pero si se quiere mantener un equilibrio y solidaridad entre los miembros del equipo de proyecto, será necesario realizar ese tipo de actuaciones.

Entiendo que quien no esté acostumbrado a una gestión de proyectos de este tipo, se cuestione en muchas ocasiones el valor que aporta un jefe de proyectos. También incluso en aquellos casos donde el gestor esté más alejado del proyecto sería conveniente analizar si lo está realmente por una cuestión de actitud del mismo, por una política de su organización o por imposibilidad material al estar participando en demasiados proyectos a la vez.

Uno de las principales ventajas de aplicar un enfoque iterativo incremental, además de permitir una mejor adaptación al cambio y de obtener el feedback del usuario desde etapas muy tempranas del desarrollo del producto, es que si está bien orientado, el desarrollo se basará en una priorización de las funcionalidades del sistema.

No se trata tanto de tener claro desde un principio todo lo que debe hacer el sistema como de tener claro qué es lo que resulta esencial para el mismo, ya que es por ahí por donde se debe empezar, evitando de esta forma distraer esfuerzos en módulos o funcionalidades accesorias.

Ahora bien, con la priorización no resolvemos del todo el problema ya que las actuaciones deben regirse por un principio de simplicidad: “la mejor solución es aquella que satisfaciendo las expectativas del usuario sea la más simple”.

Una ejecución compleja de un módulo o de una funcionalidad además de aportar un valor más que dudoso al usuario implica la realización de un esfuerzo adicional (a la par de una mayor deuda técnica) que perfectamente podría haber sido aplicado en un testing de más calidad del desarrollo, en un desarrollo de más calidad o en remanente para el desarrollo de módulos o funcionalidades menos prioritarias.

Sobre la productividad y simplicidad en el desarrollo, Milt Bryce realizó la siguiente cita: “No hay nada más improductivo que construir algo de manera eficiente que no debería haber sido construido”.

Cuando un producto software empieza a evolucionar de verdad hacia una solución que satisfaga las necesidades y expectativas del usuario es cuando éste empieza a verlo y a usarlo.

Por muy buena capacidad de abstracción que tenga el usuario, por muy bien que se le cuente cómo va a funcionar el sistema, por mucho que él crea que lo tenga claro, la realidad es que cuando se encuentra ante un desarrollo va a ser distinto a lo que se había imaginado y descubrirá que no está de acuerdo tanto con decisiones que ha tomado como con algunas lagunas de la definición del producto que ha cubierto el equipo de desarrollo, sin contar con que probablemente la experiencia de uso de la aplicación diferirá de sus expectativas.

Por tanto, no solo la incertidumbre y la capacidad de adaptación al cambio hacen recomendable un enfoque iterativo incremental, también resulta esencial para la adaptación del producto lo antes posible a lo que el usuario espera.

En las relaciones cliente/proveedor, uno de los aspectos que más complicado resulta a la hora de enfocar un proyecto siguiendo un enfoque iterativo incremental lo tenemos en el marco contractual.

Teniendo en cuenta la incertidumbre que existe en el proceso de desarrollo de software y que el objetivo final debería ser cumplir las expectativas de los usuarios a los que va dirigida la aplicación, la situación ideal sería ir facturando por iteración hasta conseguir la versión final del producto.

Es decir, a priori, no tendríamos ni límite presupuestario ni límite de plazos. Muy pocos clientes aceptarían un marco de trabajo como ese, entre otras cosas porque ellos sí que se tienen que ceñir a un presupuesto y en la mayoría de las ocasiones (con mayor o menos flexibilidad) a unos plazos.

Por tanto, va a resultar necesario adaptar los trabajos a un marco limitado en presupuesto y también en plazos, pero resulta absolutamente necesario que el cliente sea consciente de qué es lo que se va ejecutar con ese presupuesto y que el proceso de desarrollo de software es adaptativo, evolutivo y bajo incertidumbre o lo que es lo mismo, que el planteamiento inicial que se haga puede variar (de hecho variará).

Se pueden aplicar diferentes fórmulas para realizar una contrato ágil, en próximos artículos veremos algunas posibilidades.

Es frecuente encontrarnos en proyectos de desarrollo de software con obstáculos que de alguna y otra forma impiden la correcta ejecución del mismo.

Algunos de ellos se pueden sortear o solventar de manera más o menos rápida pero existen otros que persisten en el proyecto y cuya solución requiere en muchos casos de bastante diplomacia, en otros de la intervención de niveles superiores en la organización.

En otros casos una solución no es viable, ya sea por el tiempo o esfuerzo que requeriría, porque otra parte implicada no quiere que haya solución, etc…

Algunos ejemplos de obstáculos que pueden complicar el desarrollo de un proyecto y soluciones que se suelen aplicar:

- El área usuaria no participa, no lo hace en el tiempo que sería necesario o no terminan de implicarse.

Una solución que se suele aplicar es que todos los demás tiren para adelante con lo que hay.

- Se necesita la integración con un tercer sistema y los responsables del mismo no quieren proporcionar la interfaz de comunicación necesaria o no lo consideran prioritario y lo planifican en un plazo no compatible con los plazos en el proyecto.

En este caso salvo que sea una integración imprescindible, en cuyo caso bloquearía el proyecto, se obvia la funcionalidad que puede proporcionar ese componente o se reinventa la rueda.

¿Cuándo tenemos este antipatrón? Pues cuando ante un problema de estas características se decide rodearlo sin intentar encontrar una solución.

Claro que habrá veces que no sea posible (aunque si el inconveniente es grave, habría que pensarse muy seriamente dar por finalizado el proyecto y resolver el contrato, antes de que todos pierdan más dinero) y no tendremos más remedio que buscar una alternativa que permita continuar los trabajos. Procura que todos estos problemas sean conocidos cuanto antes a nivel de dirección y que tengan constancia escrita.

Pero en muchos casos llegar a terminar un proyecto a través de esa alternativa puede requerir mucho esfuerzo (y disgustos), no solo por el necesario para sortear el obstáculo y buscar la solución tal vez por un camino más largo, sino porque el resultado final puede que se aleje de las expectativas del usuario.

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 3.215 seguidores