Blog

Por qué fracasan los proyectos ¿Cuándo rescatar un proyecto?

Admitamos que a nadie le gusta reconocer que se ha equivocado, y en ocasiones se va retrasando una decisión dolorosa como dar por perdido el dinero invertido en un desarollo web o una aplicación que no funciona. Los motivos que pueden llevar a este punto son muchos, y no exclusivamente son responsabilidad del cliente o del proveedor.

En ocasiones el exigir un plazo muy ajustado de entrega y el miedo del proveedor a perder al cliente llevan a pactar una fecha de entrega imposible con la esperanza de estirar el plazo y aguantar al cliente hasta la entrega. Esto lleva a desarrollar los proyectos con un análisis deficiente, con el uso de herramientas que permiten un desarrollo rápido pero no óptimo, o incumplir las especificaciones del proyecto.

El contratar por un precio más económico tampoco es una buena opción dado que "lo barato siempre sale caro". Un precio superior por hora de un profesional no significa que realizar la misma tarea nos vaya a suponer un mayor desembolso. Al contrario: se paga la garantía de que un profesional cualificado va a emplear toda su experiencia y conocimientos en realizar la tarea de forma confiable y eficiente, de modo que se entregue en el plazo correcto, y luego no se alargue en constantes "revisiones" porque no cumple con lo pactado. O que tenga constantes fallos.

Al final, un precio económico por hora redunda en un mayor número de horas de desarrollo, y por tanto, un mayor coste en tiempo y dinero que contratar a un profesional competente.

Contactar con el equipo no adecuado es quizás el peor error. Hoy en día existe una gran cantidad de "empresas especializadas en web" que generalmente se centran en el marketing y posicionamiento, sin contar más que (probablemente) con uno o ningún desarrollador. Finalmente, muchas de ellas optan por subcontratrar autónomos externos de forma opaca, de manera que realmente tu proyecto lo está realizando un desconocido que tiene como información del proyecto únicamente lo que le aporta un comercial.

La toma de requerimientos y el presupuesto

Es muy frecuente cuando se busca un presupuesto para una web o un desarrollo encontrar "tarifas planas" de páginas web "a partir de 400 euros", por ejemplo. Obviamente estos precios no son más que reclamos de desarrollos de poca calidad, utilizando CMS mal configurados y reaprovechando una y otra vez las mismas plantillas. Estas fórmulas son válidas para clones de páginas que posteriormente no incluyen ningún tipo de mantenimiento, ni optimización en rendimiento, y por supuesto tampoco tienen una imagen propia.

Lo mismo sucede con los programas de gestión, CRMs o ERPs genéricos. Según la naturaleza de la empresa y de sus procesos, es posible que no sea adecuado el uso de una herramienta genérica. Es necesario realizar un análisis minucioso de los procesos que van a tener reflejo en la aplicación para evaluar que esa es la decisión correcta. Eso no quita que en ocasiones sea la decisión correcta, pero a veces los procesos llevan mucho tiempo implantados y no conviene cambiarlos por ser eficaces, o simplemente no "cuadran" dentro del esquema de un programa comercial ya existente.

Un correcto análisis del proyecto siempre ayuda a realizar un presupuesto correcto. No debe de contener "generalidades" o "rincones oscuros", y debe de darse con la confianza por ambas partes de que cubre todos los requerimientos y tareas a realizar. De lo contrario, tarde o temprano surgirán las desconfianzas mutuas y los reproches. El poder comunicarse directamente el cliente con el desarrollador responsable del proyecto, por lo menos antes del inicio del proyecto, va a garantizar que existe una toma de requerimientos adecuada.

El desarrollo y la comunicación con el cliente

Cuando se comienza un desarrollo siempre tiene que existir una relación con el cliente, consulta de dudas, muestra de resultados, etc. Es un error esperar al resultado final. Se deben de ir cubriendo "hitos" que debe de dar por válidos el cliente. Del mismo modo, el cliente no debe de realizar cambios constantes sobre lo ya pactado, o volviendo sobre temas ya cerrados. Si esto ocurre se debe de parar y volver a la fase de toma de requerimientos. 

Para un cliente es frustrante ver que no se avanza en un proyecto. Para un equipo de desarrollo, el invertir horas de trabajo en una programación para volver una y otra vez a revisarla, también.

La comunicación entre el cliente y el desarrollador debe de ser fluida, eficaz y sin ambiguedades. Siempre debe de ser por escrito y a ser posible utilizando una herramienta pensada para un entorno colaborativo como Trello.  Permite descomponer cualquier proyecto en tareas, dentro de las cuales se pueden establecer hilos de comunicación y dejando constancia escrita.

El email es un "mal menor" a evitar también, pues suele derivar en la mezcla de temas y en cadenas infinitas de mensaje.

El teléfono debe de evitarse siempre que sea posible. No es un modo eficaz de comunicación, pues si bien para el emisor es una manera fácil de quitarse un problema de encima, interfiere con la tarea del receptor y da lugar a malentendidos al no quedar constancia escrita. Del mismo modo, ningún programa de mensajería como WhatsApp es un entorno adecuado, salvo para concertar una reunión.

Señales de que algo no va bien

Al principio normalmente es dificil ver si un proyecto va bien o no. Pero siempre existen señales de que algo "no acaba de funcionar", a los que debemos de prestar atención:

  • Continuos retrasos en las entregas. Como hemos dicho anteriormente, cualquier proyecto, por sencillo que sea, debiera de tener una serie de hitos o fechas de entrega de funcionalidades o partes del mismo. Se pueden entender los retrasos, pero si el análisis ha sido correcto y sincero, nunca debieran de ser demasiado acusados. Y mucho menos repetidos.
  • Las entregas no incluyen todo lo pactado o tienen multitud de fallos. Igual que en el punto anterior, cuando se realiza una entrega tiene que ser con la garantía de que cumple las expectativas de lo pactado. Siempre debe de existir una fase de pruebas del software tras la cual se debería de dar por cerrada una entrega.
  • No hay respuesta a las comunicaciones o los tiempos de respuesta muy altos. Se deberán de definir unos plazos en las comunicaciones al principio del proyecto, y en caso de existir algún problema, comunicarlo.
  • Continuos cambios de desarrollador. Normalmente este factor no suele ser apreciable por el cliente cuando establece la comunicación con un comercial o agente. Pero es muy frecuente en proyectos en vías de fracaso cambiar de programador en plena situación, con la esperanza de rescatarlo. Rara vez funciona, dado que generalmente reescribir el código a partir del trabajo de otro implica empezar de cero.
  • La aplicación no respeta las especificaciones del softwara a utilizar. Desde el principio debe de quedar claro cuáles son las funcionalidades y requisitos del software a implementar, y su base tecnológica. Ya sea un CMS genérico o un desarrollo a medida.
  • La aplicación no funciona bien, es muy lenta o está repleta de fallos. Una vez llegado a este punto, está claro que existe un problema. Si además, los problemas han sido continuos a lo largo de todo el desarrollo, la comunicación seguramente ya habrá degenerado.
  • Solventar los errores de programación facturándolos como mejoras. Cualquier producto o desarrollo tiene un tiempo de garantía. Si existen fallos de programación en procesos correctamente definidos, no deben de repercutir en el cliente, sino asumirlos el equipo de desarrollo.

La decisión final y el rescate del proyecto

Cuando la realidad ya es manifiesta y no se ve otra solución, lo mejor es analizar las causas, y, si no hay otra opción, cambiar el equipo de desarrollo.

Nunca es fácil, pero siempre es mejor acabar de la mejor manera posible, aunque con firmeza, una vez tomada la decisión. Conllevará un nuevo comienzo, por lo que deberemos de evaluar al nuevo equipo. Pero esta vez tenemos la experiencia anterior. Naturalmente, existirá una desconfianza lógica, pero la sinceridad siempre será la mejor arma por ambas partes, y un calendario donde demostrar los plazos y la profesionalidad es lo mejor.

En cualquier rescate de proyecto se va a plantear lo mismo: desechar el trabajo anterior y comenzar de nuevo. Ello no conlleva en ningún caso desechar los datos, a no ser que el proyecto no llegara a ponerse en marcha. Un equipo con experiencia siempre podrá migrar los datos a un nuevo esquema aunque cambie la programación. Siempre será mas caro y peligroso tener que revisar una programación fallida que comenzar de nuevo.