Peritajes & Peritos

Este mes de Septiembre de 2017 hemos finalizado y presentado para próximo juicio una pericial de un proyecto de App para Android e iPhone orientado a localización de restaurantes de un cierto perfil. En este caso el cliente que encarga a un partner su desarrollo nos contrata por el proyecto fallido. Estamos ante un proyecto que debería haberse desarrollado en su completitud en apenas 10 meses y que pasados 24 el proyecto adolece de muchas carencias. Estamos ante un Peritaje informático de App

Peritaje informático de App

En esta pericial de parte he estudiado y centrado la pericial en los siguientes aspectos:

  1. Contrato y oferta firmada entre partner y cliente.
  2. Documento funcional y visual que describía el proyecto a realizar.
  3. App para Android e IOs para comprobar todos los problemas de mal funcionamiento y de ausencia de funcionalidades contratadas.
  4. Emails y actas de trabajo compartidas entre ambas partes.

Cuando una empresa tiene una idea a desarrollar en un formato App, debe tener en cuenta que la mera idea no es suficiente para que el proyecto acabe en éxito. Se debe disponer de competencias para dirigir un proyecto, de un seguimiento firme con el proveedor de fechas e hitos que se vayan alcanzando. Por otro lado la selección de la tecnología por parte del partner puede ser uno de los factores que lleven a éxito el fracaso o éxito del proyecto contratado. La selección de una tecnología hibrida frente a otra nativa puede limitar el algún aspecto el correcto desarrollo del proyecto. Es obvio que el cliente, generalmente no sabe cuál es la tecnología idónea para un proyecto que debe desarrollar un partner pero si éste debería informar al partner que esa tecnología no supondrá, en ningún momento, frenos para disponer de un interfaz rico, de conectividad con funcionalidades del Smartphone, etc

En mi opinión en esta pericial de parte del cliente hemos demostrado diferentes evidencias que demuestran que el cliente no tiene la responsabilidad del proyecto fallido y si la tiene el partner, en concreto y por citar algunas de las evidencias:

  1. El partner selecciono una tecnología poco adecuada para una interfaz necesaria tan rica en calidad, transiciones y funcionalidad. Esta selección incorrecta influyó notablemente en el fracaso del proyecto. Hecho o evidencia que es imputable únicamente al partner.
  2. La selección de la incorrecta tecnología viene derivada, desde mi punto de vista, de una infravaloración de la complejidad del proyecto. Esta infravaloración lo pude demostrar en diferentes evidencias de problemas que se generaban en el proyecto y que el propio partner terminaba por reconocer que era más complejo que lo que preveía inicialmente.
  3. Funcionalidad sin cobertura a Internet. Esta funcionalidad clave en muchas app que utilizamos día a día, fue planteada y solicitada por el cliente desde el inicio del proyecto. Un perfil técnico o tecnólogo sabe que el diseño de la arquitectura de una app donde es necesario funcionalidad offline, debe ser tenido en cuenta desde el principio del proyecto. Abordar esta funcionalidad cuando el proyecto casi está terminado provocó que las app dejaran de funcionar en puntos que ya estaban resueltos.
  4. Problemas de seguridad y ciberseguridad que provocan poner en riesgo la comercialización del producto.

Conclusiones

He querido citar solo 3 de las evidencias que demuestro en mi pericial y que defenderé ante el juez. Muchos proyectos fracasan por estas cuestiones, llevando a proyectos fallidos que no acaban con el resultado esperado, muchos de ellos en juicio. Como perito informático colaborador con la justicia recomiendo siempre contar con un partner experimentado y si es posible con un director de proyecto interno con capacidades técnicas que pueda supervisar no solo los hitos que el partner marque sino la tecnología utilizada por el partner.

Luis Vilanova Blanco, Perito informático colaborador con la justicia.

Fuente: Perito Judicial informático - Luis Volanova

Source