Negociacion y contratos

1. Rakos, J. (1990). La negociación y los contratos: los aspectos legales. En Software project management:for small
to medium sized projects (pp.50 - 55)(302p.) (Trad. Universidad ESAN) . Englewood Cliffs : Prentice Hall. (C20697)
5
La Negociación y los Contratos
Los Aspectos Legales
5.1 LA NEGOCIACION
Por qué será que cuando la gente va al mercado en México negocian horas sobre un
precio de unos pocos dólares, pero cuando están tratando con un producto avaluado en
cientos de miles de dólares se muestran renuentes a regatear? Nunca se avergüence
de negociar. Aprenda a hacerlo correctamente y será capaz de utilizar esta habilidad en
situaciones que van desde un mundo de proyectos hasta una venta de garaje de su
barrio.
La Ciencia y el Arte de la Negociación
La clave para una negociación exitosa es conocer los hechos. En primer lugar y princi­
palmente, conozca el producto que está intentando vender o comprar. Por ejemplo, si su
administración (o el usuario) está tratando de bajar el estimado de su precio para un
proyecto de software, tenga a mano los detalles de los métodos y las fórmulas que utilizó
para calcular dicho precio. En el Capítulo 13 discutiremos los métodos de estimación y
determinación de precios, pero el punto principal es que aprenderemos es que se debe
partir el proyecto en pequeñas piezas y estimar cada pieza. Armado con estos detalles,
Ud. puede voltear la tortilla a aquellos que tratan de reducir su estimado diciendo, •¿Qué
parte cree Ud. que podría reducirse ?" De hecho, debería haber muy poco o ningún
regateo en un proyecto interno. Si Ud. establece una reputación de realizar estimados
exactos (y honestos), puede sostener firmemente su primera propuesta.
Antes de embarcarse en una sesión de negociación, decida dos cosas: lo que
necesita que quede absolutamente fuera del trato y lo que está dispuesto a ceder. Si Ud.
es el vendedor de software y el ítem a negociarse es el precio, tenga una idea buena del
precio mínimo que Ud. está dispuesto a aceptar. Si Ud. es el comprador, conozca el
TOMADO DE: SOFTWARE PROJECT MANAGEMENT. FOR SMALL TO MEDIUM SIZED
PROJECTS. Por: John J. RAKOS. Ed. Prentice Hall, lnc. USA., 1990
Moterial didOctico reproducido en ESAN, para uso exclusivo en clase.

2. 51
precio máximo que está dispuesto a pagar. También ayuda conocer las necesidades de
su oponente tanto como su flexibilidad.
Ud. también debe anticipar cuánta negociación habrá. Sí siente que la oposi­
ción creerá que Ud. no tiene argumentos, prepare un estimado detallado y declárelo
como un hecho no negociable. Esta es la mejor manera de enfocar una licitación cerra­
da donde la postura es ya sea aceptada o rechazada como viene. En una situación
competitiva o cuando la administración no tiene experiencia, generalmente tendrá lugar
una negociación. Infle su estimado de manera que permita una ligera reducción. De­
pendiendo de su oponente, incluso puede haber un beneficio sicológico al permitirle
bajarle el precio un poquito.
Los Tres Negociables de un Proyecto
El ítem que más a menudo se negocia es el precio, pero la duración del proyecto y las
funciones que provee también pueden ser puestos sobre la mesa de negociaciones.
Como dice el dicho, "Ud. puede tenerlo barato, rápido o bueno: escoja dos." A veces se
puede ahorrar dinero tomándose un poco más de tiempo. O si el precio es absolutamen­
te inaceptable, considere el proponer menos aspectos. Incluso se puede hacer entrega
del producto por versiones. La Versión 1 contiene las funciones básicas por un preCio
básico, y las versiones subsiguientes añaden más y más funciones. Esta implementa­
ción por partes tiene ventajas para ambas partes. El usuario no tiene que exceder su
presupuesto actual, y también tiene un margen de seguridad al no tener que comprome­
terse con todo el proyecto de una vez. El equipo del proyecto obtiene el primer trabajo y,
a menos que lo estropeen por completo, generalmente también harán las siguientes
etapas. (Vea en el Capítulo 10 la programación e integración de un sistema que será
construido por etapas).
Usted Obtiene Aquello por lo que Paga
Si Ud. es el comprador del producto, cuídese de regatear demasiado al equipo del pro­
yecto, o de aceptar una oferta inusualmente baja. Imagínese la siguiente situación:
La compañía ABC hace conocer su requerimiento de software al mercado. Re­
cibe dos ofertas: La Primera es de la Compañía de Software Los Inteligentes (INTEL).
Esta empresa ha hecho un estimado preciso y ofrece un precio de $200,000, para ser
realizado en doce meses. La segunda oferta es de la Compañía de Software Los
lnescrupulosos (INESC). Ellos ofrecen $100,000, con una duración de seis meses. Puede
que ellos hayan sido deshonestos, estimando que el trabajo se desarrollaría por $200,000
y doce meses, pero haciendo una propuesta baja para •poner un pie en el proyecto". O
puede que hayan sido tontos y hayan estimado incorrectamente. Tratando de ahorrar
dinero, ABC porsupuesto acepta la propuesta de los segundos.
Seis meses después, y después de realizar pagos a Los lnescrupulosos por $100,000,
tiene lugar la siguiente escena:
ABC:
INESC:
ABC:
INESC:
ABC:
El sistema será entregado hoy, correcto?
Bueno, tenemos malas noticias.
Cuáles son las malas noticias ?
Lamentablemente, hemos gastado los $100,000, pero tenemos desa­
rrollado sólo la mitad del sistema. Tienen dos alternativas: o nos dan
otros $100,000 (quizás más), o toman la mitad de su sistema.
Pero tenemos un contrato!

3. 52
INESC: Tengo que pagarles a mis programadores, de otra manera se irán. Si
no me pagan me declararé en quiebra. Por favor envíenme todo el
correo al Brazil.
El cliente neófito no puede hacer nada con la mitad del sistema, por lo que no le queda
otra alternativa que pagar la cantidad extra. Nótese que esta escena también pudo
haber tenido lugar en un proyecto interno. Recuerdan el escenario del "estimado por
mandato"? El diálogo que sostuvieron el Gerente del Proyecto (GP) y el gerente de más
alto nivel (GA) fue como sigue:
GP: Estimamos que el proyecto demandará $200,000, en doce meses.
GA: Deben hacerlo por $100,000 en 6 meses.
GP: Por qué $100,000 ?
GA: Eso es lo que está presupuestado.
GP: Por qué en seis meses ?
GA: Ese es el tiempo que marketing ha prometido al cliente.
GP: Haré lo que pueda.
Los resultados serán los mismos. Un proyecto de doce meses no puede ser realizado en
seis, no importa lo que se haga. Justifique su precio demostrando su bien planificado y
bien controlado método administrativo. Pruebe que Ud. sabe lo que está haciendo. Si el
usuario confía en que obtendrá un producto de calidad, esperará pacientemente y paga­
rá un precio justo.
5.2 LOS CONTRATOS
El contrato del producto de software obliga al equipo del proyecto a proporcionar ciertos
entregables, en ciertas fechas, por alguna clase de remuneración. A menos que el pro­
yecto se realice sobre una base muy formal para una organización externa, no se nece­
sita elaborar un "contrato" especial. En lugar de eso, se colocan los siguientes ítems en
la propuesta. Recuerde que la propuesta es un documento firmado y debe ser conside­
rada como un contrato formal. Estos ítems podrían aparecer dentro del texto de la pro­
puesta, o mejor aún, bajo un tópico llamado nTérminos y Condiciones".
ltems que deben figurar en el Contrato.
En adición al precio, fecha de entrega y entregables, el contrato puede incluir otros térmi­
nos y condiciones tales como no-exposición o reproducción, tenencia de precios, licen­
cias o garantías. Si el mal funcionamiento del software puede originar pérdidas de vidas
u otras situaciones críticas, se debe aclarar las responsabilidades de los autores. Si los
estimados están basados en información verbal del usuario, se debe incluir una "cláusu­
la de escape". Esto permite que el equipo del proyecto pueda retirarse en caso de haber
recibido información falsa. Deben escribirse las responsabilidades del usuario, tales
como el proporcionar información exacta y oportuna, o inclusive efectuar una parte del
trabajo tal como la documentación.

4. 53
El Contrato de Precio Fijo (PF)
Este es el tipo más común de contrato. En el contrato PF el equipo del proyecto coloca
el precio total del proyecto directamente. En este contrato, sin embargo, el equipo del
proyecto asume la mayor parte de los riesgos. Qué pasa si ciertos ítems fuera de su
control hacen que el proyecto exceda el precio acordado ? Utilice un contrato de precio
fijo solamente si Ud. puede cuantificar y determinar el precio de los riesgos (Vea la
Sección 2.5 que trata sobre el riesgo). Un contrato PF resulta apropiado si:
1. Ud. está confiado en que no ocurrirán cambios importantes.
2. Ud. está trabajando con productos conocidos de_ software y hardware.
3. Ud. tiene una buena comunicación con su usuario.
De hecho, el usuario generalmente prefiere un contrato PF. Sabe cuanto expone y pue­
de presupuestar mejor directamente. Pero cuidado, el usuario tratará de obtener tanto
como pueda de su precio fijo (lo cual sin duda debe hacer!).
El Contrato de Costo Plus (CP)
Si los riesgos son demasiado altos como para colocar un precio fijo, el equipo del proyec­
to debe optar por un contrato CP. En el contrato CP se le paga al equipo del proyecto
una cantidad fija por hora o día trabajado, más gastos en que incurre. Generalmente no
se hace ninguna promesa firme de cuánto se demorarán. El contrato CP es apropiado
si:
1. Ud. siente que ocurrirán cambios importantes. (El Documento de Re­
querimientos no existe o los requerimientos no son precisos o claros).
2. Ud. está trabajando con un sistema operativo, paquete o máquina
desconocida, o tendrá que elaborar herramientas especiales de de­
sarrollo, tales como simuladores o algo parecido.
3. La comunicación entre el usuario y Ud. es débil.
4. La mayor parte de las actividades son orientadas a las personas, por
ejemplo, las entrevistas. {Trate de estimar la tarea de "Entrevistar a
alguien hasta que se hayan definido todos sus problemas".). Esta es
la razón por la cual grandes compañfas de software tales como DEC
generalmente tratan de realizar sus Etapas de Definición y Análisis en
un contrato CP separado.
Términos y Condiciones
Si Ud. va a hacer un contrato CP, asegúrese de que los términos y condiciones sean
claros. Lo siguiente es citado de un contrato CP de DEC:
CLAUSULA DEL CONTRATO DE COSTO PLUS
(Estimamos que el proyecto tomará X horas. Esto) ..... está basado en la comprensión
actual de los requerimientos por parte del equipo del proyecto. El equipo del proyecto
proveerá dicho servicio hasta un máximo de X horas (a un costo de $Y por hora). Si se
requiriera servicios adicionales, el equipo del proyecto reiniciará el trabajo solamente
después de obtener la autorización escrita del usuario, momento en el cual se determi­
nará mutuamente un nuevo estimado.

5. 54
Note como expresa DEC la extensión y los límites de su servicio en un simple párrafo.
Incluya todos sus términos y condiciones- los aspectos legales de la manera
como desea trabajar con el cliente. Esto proteje tanto al cliente como a Ud., y evita las
dificultades más adelante. Los aspectos legales que pueden necesitarse aclarar desde
el inicio pueden incluir temas de pagos, copias de los fuentes y de la documentación,
garantías y problemas con el hardware o el software proporcionado por un fabricante.
Los Contratos en una Organización
Externa versus una Organización Interna.
Los contratos son ampliamente aceptados si una compañía u organización externa es la
que está proporcionando el servicio. Por qué no es lo mismo para un proyecto interno ?
Aún cuando existen las relaciones más estrechas entre el equipo de trabajo y el usuario,
debería haber alguna suerte de acuerdo escrito y formal que describa los servicios que
brindará el equipo de trabajo. Esta puede ser una carta de intención o una propuesta
formal. Póngala por escrito y evitará discusiones interminables más adelante.
5.3 LAREVISION DE LA PROPUESTA DEVUELTA
Puede ser que el usuario devuelva la propuesta aceptada con cambios "menores". Pro­
grame un tiempo para que los miembros técnicos del equipo de trabajo revisen dichos
cambios- cambios menores en palabras podrían signifícar esfuerzos importantes. Inclu­
sive el precio podría tener que renegociarse. Busque los desacuerdos en los Términos
y Condiciones. Deje que los administradores de alto nivel o quizás el departamento legal
sea el que los maneje. No inicie el trabajo hasta que todos los acuerdos sean definitivos.
Sé de un proyecto que fue cancelado seis meses después de que el equipo de trabajo lo
inició debido a un desacuerdo sobre los derechos de autor sobre el software. Puede
incluso beneficiarlo el dejar que su usuario conozca sus términos y condiciones antes de
escribir la propuesta.
5.4 CONCLUSIONES SOBRE LA ETAPA DE DEFINICION
Esto nos trae al final de la etapa de definición. Revisemos los hitos clave que hemos
alcanzado. Recuerde que estos hitos fueron utilizados para planificar el proyecto y con­
trolar su progreso.
1. El Documento de Requerimientos está completo y acordado por el
equipo del proyecto y el usuario. Busque la manera de hacerlo firmar
formalmente, tal como un memorándum donde se exprese la acepta­
ción.
2. Una propuesta, ya sea para el análisis o para todo el desarrollo, se ha
completado y ha sido aceptada por el usuario. Se requiere un acuer­
do por escrito.
3. Aunque no es considerada un hito, la aprobación del Plan Preliminar
del Proyecto por aquellos que proveen los recursos es necesaria.

6. 55
PREGUNTAS
1. ¿Qué debe Ud. saber antes de que pueda comenzar a negociar ?
2. ¿Cuáles son los tres ítems que pueden ser negociados en un proyecto de soft­
ware ?
3. Enumere los tres ítems principales ( y tantos ítems secundarios como pueda)
que podrían tener que establecerse legal y formalmente en el contrato de un
proyecto de software.
4. ¿Cuáles son las diferencias entre un contrato de precio fijo y un contrato de
costo plus? Describa dos situaciones en las cuales podría utilizar un contrato
de p·recio fijo y dos donde se podría utilizar uno de costo plus.
5. El cliente ha cambiado algo en la propuesta al revisarla. ¿Bajo qué circunstan­
cias debe revisar el equipo del proyecto el impacto de estos cambios?
6. ¿Cuáles son los hitos de la Etapa de Definición?