archivo

Archivo de la etiqueta: negociación

Un buen negociador es aquel que consigue igualar o superar el umbral de expectativa que haya fijado su organización en una negociación. Por lo menos eso es lo que se piensa.

Yo no estoy de acuerdo totalmente con esa definición, ya que para que la negociación sea buena, la otra parte también debe haber salido con la misma sensación, es decir, que el resultado ha sido justo (hablo de sensaciones, no de realidades, ya que lo mismo sientes que te ha ido bien y sin embargo, en términos reales no ha sido así).

A veces el ganar-ganar, el ganar-sensación de ganar, el sensación de ganar-sensación de ganar no son posibles, porque para llegar a ello las partes implicadas tienen que querer llegar a eso y eso requerirá, en ocasiones, asumir errores y pérdidas económicas. Si no es posible alcanzar una solución de ese tipo, por lo menos el resultado de la negociación debe basarse en criterios los más objetivos posibles en base a las premisas de la misma. Tal vez a corto o medio plazo la otra parte no lo entienda o no quiera verlo, pero en el fondo sabrán que el resultado ha sido justo (y si siguen sin entenderlo, ese será parte de su problema).

Es cierto que hay ocasiones donde negocia una organización que es peso pesado contra otra que es peso pluma y en donde el hecho de que el grande pisotee al pequeño puede tener poca trascendencia para el poderoso, sin embargo si una organización repite de manera sistemática este comportamiento, los pesos plumas terminarán conociendo como se las gasta y tomarán sus preocupaciones (entre otras pensarse dos veces, si quieren tener negocios con quien se comporta de esa manera) y otras organizaciones más fuertes, desconfiarán.

Todo lo anterior es aplicable a los negociadores individuales de las organizaciones, los cuales siguiendo instrucciones o no de las mismas pueden tratar de conseguir el acuerdo que a corto plazo puede parecer más beneficioso, caiga quien caiga y cueste lo que cueste. Ese el negociador de jaula de acero y es el tipo de gestores al que va dirigido este antipatrón.

Y hablo de a corto plazo, porque desde mi punto de vista, las negociaciones deben mirar más allá de lo que se está tratando en ese momento, teniendo en cuenta de que tal vez dentro del mismo proyecto haya que realizar nuevas negociaciones y que tal vez en el futuro las organizaciones sigan trabajando juntas (y que también quien es el fuerte en la negociación hoy puede ser el débil mañana).

He insistido en diferentes artículos que gran parte de la suerte del proyecto se juega antes de que comience. Una mala negociación, una mala venta condiciona todo lo demás (pudiéndose partir de una situación de Death March Project) y solo produciéndose determinadas circunstancias ideales: un equipo de proyecto motivado y de calidad y un cliente y unos usuarios que facilitan las tareas, pueden paliar las pérdidas del proyecto, tangibles (en dinero), como intangibles (de pérdida de imagen con el cliente ante un proyecto de ejecución deficiente).

Sin embargo, la venta inicial del producto es solo una de las variables que condicionan el posterior desarrollo del proyecto, la elección de una mala metodología ya sea por parte del proveedor o impuesta por el cliente puede hacer estragos en el trabajo realizado, en el coste y en los resultados.

Lo mismo si no se delimita de manera adecuada el alcance (ya sea antes de la venta o antes incluso de empezar a recoger requisitos).

Y después toca el análisis. Si la metodología condiciona un desarrollo en cascada la realización de un análisis excelente es esencial, si bien, todo se puede ir al traste en el momento en que cambia algunas de las variables del proyecto (interlocutores, procesos, etc…) y es que los modelos predictivos tienen ese problema.

Si la metodología es ágil o al menos iterativa incremental (como RUP), las tareas de análisis también son de gran importancia, aunque desarrollos iterativos y evolutivos dan un mayor margen para la corrección de deficiencias en la captura e interpretación de los requisitos y en el modelado de la solución.

Por tanto, independientemente de que en función de la metodología aplicada la realización de un buen análisis tenga una mayor importancia, en todas condiciona el resto del proyecto y muchísimo.

Un mal análisis, si se detecta en etapas tardías (en muchos casos, cuando el producto ha llegado a producción), provocará un más que probable fracaso de la puesta en marcha del sistema y un más que probable esfuerzo económico importante para resolver esta circunstancia, mediante mantenimientos correctivos y evolutivos, que podrían ser incluso no asumibles si la deuda técnica del desarrollo es elevada.

Pero es que un mal diseño también tiene consecuencias y muy importantes en el resultado final del software.

Por eso destaco siempre que, además de contar con buenos programadores, disponer de buenos analistas funcionales y orgánicos permite que el trabajo de los que codifican brille más y sobre todo, sea útil.

De ahí la importancia de realizar testing desde el principio, fundamento este que dió lugar, por ejemplo a las metodologías de testing en V o en W.

En resumen, aunque muchos piensen que el partido se juega en la construcción del software, si no se han realizado de manera adecuada las etapas anteriores, el partido se habrá perdido antes de que el árbitro de el pitido inicial.

En un proyecto de desarrollo de software, sobre todo aquellos que son de larga duración, se producen situaciones donde cliente y proveedor negocian y llegan a acuerdos.

Romper esos acuerdos es aniquilar la confianza. Un acuerdo, un pacto, puede ser bueno, malo o regular, para una parte o para los dos, pero es el resultado de un proceso de negociación, es algo que se ha construido juntos, como el software que se está desarrollando.

Siempre se puede renegociar, pero sobre unas bases que lo justifiquen y si la otra parte está de acuerdo (si hay confianza, por regla general no habrá problemas en sentarse, por lo menos, a escuchar y si lo que se pide es coherente, es probable que se llegue a un nuevo acuerdo).

Romper acuerdos unilateralmente y tomar como base esa situación para forzar una negociación, destruirán o dejarán muy mermadas las relaciones de cara a un futuro.

Tanto si vamos a trabajar con metodologías ágiles, como con otras metodologías como RUP y sobre todo, en ciclos de vida clásicos o en cascada, resulta fundamental delimitar cuanto antes el alcance del proyecto.

Como mínimo hay que llegar a una primera aproximación en la negociación del contrato con el cliente (cuanto mejor sea la misma, más variables se tendrán a favor para hacer una correcta valoración en esfuerzo y plazos del proyecto) y es más que recomendable hacer otra aproximación al inicio del proyecto.

Acotar el alcance no debe ser entendido como poner límites al proyecto, al menos en el sentido estricto, ya que a través de la propia evolución del software, la aplicación tenderá a ir hacia donde van las expectativas del usuario. Pero sí se debe entender como un marco hacia donde enfocar el desarrollo, ya que no todas las funcionalidades que se quieren implementar son iguales de prioritarias o críticas.

El proyecto debe centrarse en lo verdaderamente importante, dejando para más adelante aquello que no lo es. Probablemente no habrá presupuesto (por lo menos en primera instancia) para todo, por lo que lo primordial es cubrir lo que resulta necesario.

Si no delimitamos el alcance, se quedarán demasiadas puertas abiertas por detrás, con el riesgo de que el cliente o usuarios quieran volver a ellas. Es cierto que al final el proyecto va hacia donde quiere el cliente o los usuarios, pero no es lo mismo tener pactado por escrito un alcance que no tenerlo y no es lo mismo hacer pedagogía desde el inicio del proyecto que no hacerla.

En todas las etapas de un proyecto de desarrollo de software se pueden tomar decisiones erróneas, una mala ejecución de los trabajos, baja productividad, falta de compromiso, desencuentros entre el cliente, el proveedor, los usuarios, etc… y en todas se produce un impacto en el proyecto que puede ser más o menos grave en función de su intensidad y del momento en que se producen.

Sin embargo hay dos etapas decisivas y que tienen un gran peso en todo lo que va a venir después: la etapa de negociación del proyecto y las primeras fases del análisis que es donde se acota el objeto final de trabajo.

Si la negociación no es buena, se aceptan proyectos por debajo de su precio de mercado, prometiendo lo imposible o se hace una estimación y planificación errónea, está situando al posterior proceso de desarrollo en un contexto difícilmente salvable o incluso en un Death March Project.

No importan tus procesos, no importa que tengas los mejores, no importa que el cliente se vuelque contigo, si el error de partida es grave, remontarlo costará mucho trabajo (cuando se pueda).

Después se puede volver a negociar, pero dependerá de muchos factores conseguir éxito en la misma, sobre todo si el error es tuyo y si desde el primer momento existe desgaste con el cliente.

También resulta muy importante la fase inicial de enfoque del proyecto, determinar su alcance, por lo menos a corto y medio plazo. Una mala elección en lo que es prioritario y en lo que no lo es, será negativo para el cliente, pero también para el que realiza los servicios de desarrollo de software, sobre todo si se trabaja con presupuestos cerrados en proyectos con objetivos abiertos.

Ed Yourdon destaca dos variables como causantes de que la crisis del software siga hoy tan vigente como cuando Edsger Dijkstra hizo referencia a ella en la década de los 60.

Por un lado vuelve a destacar la falta de habilidades negociadoras que, por regla general, existe en quiénes negocian los contratos y las condiciones de los proyectos, de manera que se aceptan unos parámetros presupuestarios, de plazos y de calidad muy difíciles de cumplir y por otro el hecho de que las nuevas generaciones de desarrolladores no presten la atención que se merece a la experiencia de los más veteranos, lo que provoca que de manera reiterada se vuelva a caer en los mismos errores.

Yo llevo gestionando proyectos software desde hace ocho años y mientras que la tecnología avanza a un ritmo vertiginoso, los problemas de los proyectos de hoy son los mismos que los de ayer.

Comenta Ed Yourdon que independientemente de que existan circunstancias que te empujen irremediablemente a un Death March Project (decisiones de empresa ya sea por la parte cliente o proveedora), en muchas ocasiones se aceptan condiciones que podrían haber sido evitadas o, al menos, paliadas con la existencia de una negociación bien llevada.

El desarrollo de software no solo requiere habilidad técnica, es algo que sabemos todos y que comento con relativa frecuencia en mi blog, sino que son muchas variables las que intervienen para que un proyecto de desarrollo de software, una empresa o una organización tengan éxito.

Una persona no tiene por qué reunir todos esos ingredientes, estamos hablando de que el desarrollo de software es un trabajo en equipo y que va más allá del ámbito del proyecto. Lo importante es que la suma de los ingredientes que proporcionan las personas permitan hacer una buena receta.

La negociación es una habilidad. Hay personas que de manera innata lo hacen muy bien, sin embargo, además de ese instinto, cuanta mucho la técnica y sobre todo la experiencia.

Es cierto que una negociación influye mucho tu posición en la misma, ya que a veces se juega con las cartas marcadas, pero incluso en las circunstancias más adversas se pueden conseguir logros.