Peritajes & Peritos

Es interesante ver a proveedores o consultoras de desarrollo informático que no solo han tenido que lidiar con la crisis, bajada en las ventas, bajada en los márgenes, ERE’s etc sino que además han tenido clientes impagados o deuda ‘colgada’ por diferentes razones por parte de terceros que nunca pagaron servicios que si se le prestaron.

Cuando estas razones son derivadas del entorno, crisis, caída de consumo,… es entendible que la empresa debe de esforzarse en innovar, reducir gastos, adecuar presupuestos…pero el problema viene cuando se trata de un proyecto correctamente realizado y, por razones que no nos son del entorno, el cliente decide dejar de pagar parte del proyecto. Aún más grave si el cliente sigue utilizando lo que el partner ha desarrollado con normalidad y el partner, por ética, no deja de darle servicio, pagando el hosting donde esta albergada su aplicación web etc…

Esta situación, que es el caso que quiero contar, deriva en un peritaje, es la clásica situación donde un cliente decide, por terceras razones e intereses, que ya ha pagado bastante y que no debe pagar más. Entonces el partner, en mi caso una pyme que derivado de este impago debe realizar un ERE (el proyecto era muy importante), llega al límite de tener que tomar una decisión complicada, un camino difícil de entrar, pero necesario, poner en manos de su abogado el problema.

Poner en manos de un abogado el problema de que un portal web, en funcionamiento, no se pague por parte del cliente, alegando básicamente que aún faltan ciertos desarrollos, es un tema complicado. Más cuando el partner ha desarrollado más de lo pactado y, por otro lado, el cliente ha incumplido ciertas cuestiones contractuales. El lector, si es ajeno a este mundo, puede pensar que si el cliente le debe dinero al partner y no lo abona pues que el partner lo denuncie. Varias cuestiones a tener en cuenta:

El desarrollo de un portal web se establece, como todo proyecto informático serio, bajo el marco de un contrato donde se trata de indicar las obligaciones de ambas partes…Todos los informáticos sabemos la complejidad para definir un proyecto informático, alcance completo, aspecto, navegabilidad, interfaces, funcionalidad, requisitos, integraciones,….Además si en un proyecto, como es el caso, necesita de una integración con una plataforma tercera y la dependencia de un tercer proveedor es ‘critica’ entonces tenemos todos los ingredientes para un coctel explosivo.

En este caso mi labor como perito judicial informático es fundamental. Demostrar con todas las herramientas a mi alcance que el proyecto está realizado, que está funcionando, que los posibles retrasos han sido aceptados por el cliente durante la vida del proyecto, que los desarrollos son lógicos y el precio-proyecto es adecuado…. Etc es clave para poder ayudar al cliente y al abogado.

Proyecto a medida abierto vs proyecto cerrado

Uno de los conceptos más complicados de entender en un proyecto informático es definir que diferencia a un proyecto donde el alcance se delimita desde un inicio, a un proyecto donde los requisitos no están cerrados o se dan otras circunstancias para que se pueda derivar en un proyecto a medida abierto.

Es fundamental comprender (hacer entender al magistrado y al juez) que si un proyecto se enmarca dentro de un contrato con unos plazos y compromisos, tanto funcionales, hitos y aceptaciones por parte del cliente, pagos etc si estos se incumplen estamos ante una ruptura de las normas establecidas para hablar de un proyecto cerrado y para mí, como Ingeniero en Informática y perito judicial, el proyecto, claramente, se traduce en un proyecto abierto.

Es decir, si en un proyecto un cliente se compromete a dar el ok a unas fases que el partner le entrega y no solo NO lo hace sino que sigue con las siguientes fases o solicitando nuevos requisitos, hay un incumplimiento tácito del proyecto cerrado y por tanto pasamos a hablar de un proyecto abierto o proyecto a medida abierto.

Un proyecto cerrado es un proyecto enmarcado en unos requisitos, plazos, hitos y obligaciones por ambas partes que deben ser cumplidas. Si no lo son, a mi modo de ver, el concepto de cerrado o pactado deja de tener sentido ya que en ese momento, respecto de lo que le afecta al partner, las horas de desarrollo se disparan ¿a cuenta de qué? ¿A qué fase son imputables? ¿Debe parar el proveedor de trabajar y de dar servicio al cliente? En mi modo de ver no lo recomiendo, pero debe hacer entender al cliente que se ha roto el concepto de proyecto cerrado.

Este enfoque es el que ha dado el éxito del litigio a mi cliente y por ello creo más aun en él.

Recomendación para las consultoras de desarrollo software

Desde el punto de vista del partner o consultora de desarrollo, recomiendo que los contratos de proyectos donde se busca un acuerdo de colaboración de proyecto cerrado se enmarque este dentro de unos compromisos claros por parte del cliente, hitos de aceptación y continuación con siguientes fases. Recomiendo incluir una cláusula donde especifique claramente que el no cumplimiento de los compromisos de aceptación de hitos ‘rompe’ el acuerdo acordado en el contrato y que se pasa a un proyecto abierto tarificable por horas si el partner así lo ve conveniente.

Luis Vilanova – 606954593

Perito Judicial Informático

Luis.vilanova@leyesytecnologia.com