archivo

Archivo de la etiqueta: negociación

Si yo fuera proveedor de servicios de software intentaría tener invertido una buena parte de mis proyectos en plazo fijo, es decir, en proyectos donde facture por horas. En este tipo de trabajos, salvo que se gestionen muy mal o la calidad del servicio sea deficiente, se ganará dinero, tal vez no tanto como en otros, pero la seguridad de tener cubierto una buena parte de tu presupuesto, también tiene su valor.

Tanto se ha trabajado así entre clientes y proveedores que incluso en los proyectos orientados a cumplir un servicio, los proveedores siempre ponen sobre la mesa las horas cuando ven que existe una desviación en el presupuesto.

Si se contrata un servicio, debe estar por encima del esfuerzo ejecutado, ya que eso es lo que se ha contratado, un presupuesto cerrado.

El adjudicatario del servicio medirá internamente los costes del proyecto basado en las horas y el avance del mismo y también puede expresar al cliente su preocupación por las desviaciones en el presupuesto y ese es el límite al que se puede llegar.

Si las desviaciones son consecuencia de que el proyecto no va sobre las líneas especificadas en el contrato, sí que resulta razonable negociar y tal vez intercambiar unas tareas por otras o cambiar presupuesto de los trabajos.

Sin embargo poner sobre la mesa las horas y ser esa la base para una nueva negociación es un error. Si están justificadas plantea las causas y no tengas problemas en intentar que se te escuche. Si no hay una justificación en el proyecto, mi recomendación es que se asuman los errores y no se intenten compartir con el cliente, ya que al desgaste que se produce en el desarrollo normal del proyecto, se le añadirá otro que puede hacer muy complicadas las relaciones en el mismo y hará más difícil alcanzar los objetivos y si estos no se consiguen nadie terminará contento, nadie gana, aunque se consigan beneficios económicos.

Existe proyectos de desarrollo de software que no terminan de funcionar adecuadamente para clientes (no tiene todas las funcionalidades principales implementadas o algunas de ellas no tienen un comportamiento adecuado) y para proveedores (desviación del esfuerzo estimado y disminución de la expectativa de beneficio o incluso, entrada en pérdidas) por el hecho de que no se han priorizado adecuadamente en el proceso de desarrollo las funcionalidades a implementar, lo que ha podido provocar que se haya distraido la atención y el esfuerzo en tareas que no son importantes o decisivas en el proyecto, perdiendo el enfoque de lo que resulta importante o no.

Esta circunstancia en un desarrollo utilizando el ciclo de vida clásico o en cascada resulta fatal y dará lugar a multitud de situaciones de conflicto entre cliente y proveedor, ya que en fases tardías del desarrollo se intentará enderezar la nave y salvo que todos los requisitos se hayan catalogado, la única solución será entrar en un proceso de negociación entre las partes, intercambiando unos requisitos por otros, solución que por otra lado no dejará satisfecho a nadie. Incluso catalogándose los requisitos, existen tantas posibles contingencias que pueden provocar desviaciones en proyecto, que pueden hacer que no se terminen implementando todos los requisitos, lo que hará que al final se tenga un producto donde buena parte de las funcionalidades no estén disponibles. Es lo mismo que tener un coche que a simple vista resulta estupendo, pero al que le faltan piezas fundamentales para que funcione o para que su conducción sea cómodo.

En desarrollos iterativos e incrementales con ciclos de corta duración, este tipo de problemas se detectarán antes por regla general (siempre y cuando el equipo de usuarios no persista en su error hasta iteraciones muy posteriores), sobre todo en aquellas soluciones que pretenden que en pocas iteraciones se tenga ya una aplicación o esqueleto andante que ya pueda ser utilizado por los usuarios.

Un proyecto que no termina de cerrarse es un sumidero por donde no deja de escaparse dinero. Esto a veces es un problemilla y en otras ocasiones puede suponer un riesgo importante para el proveedor.

Lo anterior no debe justificar que se salga corriendo del proyecto, nunca lo debe ser. Salir de un cliente de mala manera puede tener más perjuicio que la pérdida económica, lo intangible muchas veces pesa más que lo que tiene cuerpo.

Los proyectos de desarrollo de software no son fáciles de cerrar porque pese a que trabajamos con unos y ceros, las situaciones no son de un color u otro sino que pueden tener cualquier tonalidad. Difícilmente nos encontraremos con circunstancias donde queda claro quién tiene la razón (independientemente de que alguien lo piense que la tiene).

Cliente y proveedor deben pactar las condiciones del cierre del proyecto, será necesario negociar, a veces serán muy duras, con desgaste, porque cada parte defenderá lo suyo. Incluso puede pasar que las dos partes no terminen satisfechas, pero aunque así sea, si hay negociación no se perderá la confianza o por lo menos el daño no será irreparable, salvo que en la misma se haya perdido el respeto o una de las partes haya abusado de su posición.

Las condiciones pactadas hay que respetarlas, si no es así, es casi peor que si no hubiera habido negociación. Si hay que cambiar algún aspecto, hay que volver a sentarse y cerrar unas nuevas condiciones.

Cliente y proveedor no tienen por qué estarse aguantando indefinidamente, si uno de ellos (o los dos) entienden que no se ha sido justo y que esa injusticia supera sus umbrales de tolerancia, tal vez la mejor solución es que se busquen otras alternativas, otras experiencias, hacer un paréntesis y más adelante analizar si conviene o no volver a intentarlo.

Lo he comentado en muchas ocasiones. En una negociación el cliente tiene todas las de ganar frente al proveedor, sobre todo si todavía no ha pagado. Por tanto y a las malas, el cliente puede forzar en una negociación y conseguir unas condiciones beneficiosas.

Los proveedores existen más allá del proyecto y las personas que trabajan en ellos mañana pueden estar en otras empresas, por ese motivo soy de la opinión de que no se debe forzar más allá de lo que se considera justo en función de cómo ha evolucionado el proyecto, cómo se ha comportado el proveedor en el mismo y cuál es presupuesto disponible.

Si abres un abismo con un proveedor o con una serie de personas después resulta muy complicado trabajar, por muy profesional que se sea, ya que la desconfianza impide que se cierren las heridas y no es cuestión de rencor. Puedes estar enfadado, muy enfadado, pero eso se supera si la confianza no se ha roto por completo (y no es nada difícil que se haga añicos).

Si el proyecto ha ido conforme a lo pactado y el proveedor ha realizado su trabajo de manera adecuada hay que ser justos en una negociación, lo cual no quiere decir que no intentemos defender la postura de nuestra organización e intentar conseguir un acuerdo favorable. Eso es lícito y entran en juego las habilidades de las personas que intervienen, pero no se debe abusar de la posición de poder (una cosa es utilizarla a tu favor y otra golpear con ella).

A veces se termina mal, muy mal, a veces será culpa del cliente, otras del proveedor y otras de las dos partes y esto sucederá porque no siempre se puede tener todo bajo control, porque existirán presiones externas que harán todo más difícil o porque no se ha querido ver que tras el proyecto vendrán otros más.

Barry Boehm, años después realizó una variante o actualización del ciclo de vida en espiral que definió en 1988.

Con la variante trata de ajustarse más a la realidad de lo que es un proyecto de desarrollo de software, en el cual el resultado final no es exactamente la implementación del catálogo de requisitos, sino que una vez definido se renegocia el alcance del mismo, incluso en diversas partes del proyecto, entre cliente y proveedor con el objetivo de intentar que ambas partes queden satisfechas (aunque en la mayoría de los casos, cada parte solo se mire su ombligo).

La variante se basa en la inclusión de tres etapas o regiones al principio:

1.- Identificar las partes interesadas (stakeholders) para esta nueva iteración del producto: Es necesario definir los interlocutores que serán de áreas que se verán afectadas por el resultado final de la nueva versión. Estos interlocutores serán del área del cliente (puede haber más de uno) y del proveedor.

2.- Identificar las condiciones de victoria de las partes interesadas en el proyecto: Se concreta cuáles son las condiciones que requiere cada parte para que se sienta satisfecha una vez realizada esta versión.

3a.- Reunir las condiciones de victoria: Con las etapas anteriores se han definido unos objetivos generales para la versión y se obtiene conocimiento de los objetivos particulares de cada parte. Ahora toca negociar hasta dónde realmente se va a llegar y cómo, intentando llegar a una solución en la que todos ganen (cliente y proveedor).

Las siguientes etapas tienen una correspondencia con algunas variantes, con la versión inicial del ciclo de vida en espiral:

3b.- Establecer los objetivos, restricciones y alternativas del siguiente nivel: Teniendo en cuenta los objetivos y acuerdos de las fases anteriores, se definirían los requisitos de esta versión, además de especificarse diversas alternativas en el caso de que existan.

4.- Evaluar las alternativas del producto y del proceso y resolución de riesgos: Se realizaría el análisis del riesgo típico de los modelos en espiral.

5.- Definir el siguiente nivel del producto y del proceso, incluyendo particiones: Esta etapa completaría el proceso de análisis y realizaría el diseño y la construcción.

6.- Validar las definiciones del producto y del proceso: Comprendería la implantación y aceptación de la versión, verificándose si el resultado de la iteración satisface el alcance indicado.

7.- Revisión y comentarios: Tocaría hacer inventario, medir el nivel de satisfacción de las partes, el nivel de cumplimiento de objetivos con el objetivo sobre todo de intentar aprender de los errores para mejorar en versiones sucesivas y de detectar correcciones y mejoras a realizar en el producto.

Desde mi punto de vista, lo más interesante del modelo es que se especifique de forma explícita la necesidad de que las partes negocien para llegar a un acuerdo satisfactorio para todos, por eso esta variante recibe el nombre de Win Win. Aunque es complicado alcanzar un equilibrio en el que ambas partes ganen a un 50%, sí que es fundamental que independientemente de si uno es un poco más ganador que el otro, todas las partes estén convencidas en que el acuerdo es bueno.

En cualquier caso sigue sin ser absolutamente realista con respecto al transcurso normal de un proyecto de desarrollo de software, donde la negociación se extiende en muchos proyectos hasta el mismo proceso de construcción del sistema de información, no obstante, si los incrementos no son muy grandes no tendría por qué extenderse tanto la negociación, no obstante, como en este tipo de modelos de ciclo de vida, en cada iteración (incluida la primera) se intenta tener un producto funcionando, salvo que éste sea trivial, las primera etapa por lo menos tendrá tamaño suficiente para que en muchos casos nos encontremos con casos donde se estén negociando aspectos del proyecto hasta el final.

Sucede en muchas ocasiones que sin ni siquiera haberse iniciado un conflicto, alguna de las partes pone todo el arsenal en escena. Esto es un error incluso con el conflicto en marcha y teniendo razón, así que nos podemos imaginar qué supone eso cuando no se sabe si habrá algún tipo de problema y si además no se tiene razón.

Si la reacción es exagerada se le están dando a la otra parte todos los argumentos, ya que has empezado atacando y encima enseñando las cartas. En la mayoría de los casos si tu estrategia es conocida le estás dando al contrario toda la ventaja para que te gane y si encima lo haces con vehemencia se te termina volviendo en tu contra ya que todos aquellos que no conocen de verdad la historia pensarán que te estás pasando (tengas o no tengas razón) y que estás exagerando, restándote credibilidad.

El mejor conflicto es aquel que no existe por lo que hay que intentar siempre que no se llegue a él, a veces se puede evitar y a veces no, pero por lo menos hay que buscar antes otras alternativas. En el caso de que haya conflicto hay que intentar ser lo más frío posible, algo que es complicado ya que implica tener un fuerte control sobre tus emociones y eso es muy difícil. Cuanto más frío se sea, mejor, ya que se evitará pasar del terreno profesional al personal, momento en el cual cualquier argumento que tengas, por bueno que sea, no servirá de nada, habrás perdido. Además si las emociones no te ciegan, te evitarán decir cosas de las cuales después te tengas que arrepentir aunque realmente no sientas o te creas lo que estás diciendo.

Hay veces también que se entra en conflicto por cuestión de orgullo o por intentar justificar lo injustificable, ni que decir tiene que estas situaciones hay que evitarlas porque no van a traer nada positivo, ya que no tienes absolutamente nada que ganar y mucho que perder. El orgullo visto de esta manera no sirve de nada, solo puede perjudicar, entre otras cosas porque es un orgullo de mentira ya que viene de la frustración o del desengaño, el orgullo de verdad es otra cosa.

Cuando hay conflicto o negociaciones complicadas hay que saber evaluar qué te estás jugando (¿merece la pena?), qué fuerza tienes en la misma (¿existe alguna forma de sacar algo positivo?), si el beneficio que se puede conseguir es pírrico o no es posible sacar algo positivo (o sentar las bases para conseguir algo positivo más tarde), ¿para qué entrar en debates que lo más probable es que no lleven a nada? (hay innumerables ocasiones en las que nos metemos en el fango por nada) y a partir de qué momento se puede dar por buena una solución (a veces es mejor plantarse que intentar conseguir mucho más de lo que se puede).

No todo el mundo sabe manejar correctamente este tipo de situaciones (a mi me queda muchísimo que aprender al respecto y estoy muy lejos de dominarlas todavía), negociar, mantener el tipo en situaciones difíciles entre cliente y proveedor, entre desarrolladores y usuarios, no es nada fácil. Hay personas que tienen más facilidad que otras para afrontar estas circunstancias, pero al final la experiencia marca mucho la diferencia, por ese motivo es importante que cuando en negociaciones complicadas o en situaciones de conflicto tomen las riendas aquellas personas de la organización más preparadas para ello y que en lo posible se vean acompañadas por esas otras que deben ir aprendiendo a desenvolverse en estas circunstancias.

Las palabras se las lleva el viento y en caso de conflicto lo único que vale es lo que está por escrito.

Es muy importante que cuando se participe en un reunión de trabajo siempre se elabore un acta y se haga llegar a los presentes por si tienen algo que objetar, es fundamental que las distintas decisiones que se tomen en el proyecto queden plasmadas por escrito y en particular la aprobación de hitos importantes en el proyecto como por ejemplo el análisis de requisitos o la interfaz de usuario.

Por otro lado, ten perfectamente controlado y localizado el flujo de correos electrónicos del proyecto, en ocasiones será necesario tirar de ellos y cuando más falta haga no se encontrará precisamente aquel que estabas buscando.

Si no lo tienes por escrito estás totalmente vendido y cuando llegue la hora de negociar estarás con las manos vacías, el “te acuerdas que me dijiste” o el “te acuerdas lo que dije” no sirven para nada si la otra parte no quiere que sirva para nada.

Hacer esto no debe salir de un equipo de proyecto concreto sino que debe ser parte de la política de la empresa de manera que además de adoptar una actitud homogénea en todos los trabajos se tenga por escrito la realidad de cada proyecto.

Además de la utilidad que he mencionado, también resulta muy interesante para que los responsables de desarrollo de la organización puedan conocer cómo va el desarrollo del proyecto (además de la utilización de las herramientas propias de gestión de proyectos) y para documentarse en caso de reuniones ordinarias con el cliente.