Las claves para rescatar un proyecto fallido

A lo largo de mi trayectoria profesional, he visto muchos casos de proyectos de software fallidos. He estado metido en tantos que conozco mejor casos de fracaso que de casos de éxito. Puede parecer contraproducente para la consultoría informática pero en realidad no lo és. Haber aprendido del fracaso de tantos emprendedores (y de los mios, por supuesto) me ha permitido tener un punto de vista bastante único en lo relacionado al desarrollo software.

En el post de hoy voy a compartir mi experiencia en este campo de mi vida laboral... y ojo!!.. aunque estés inclinad@ a pensar que si he estado metido en tantos proyectos que no han sido fructíferos, es porque el problema quizás sea yo... hay tanta gente involucrada en la toma de decisiones de un proyecto de software que la probabilidad sería sencillamente demasiado pequeña :-P.

La cantidad de cosas que pueden salir mal durante el desarrollo de un proyecto software (como en cualquier otro proyecto) es bastante grande, por lo que es importante ser capaz de mantener la agilidad, y poder mantenerte firme ante cualquier imprevisto. Cuanto mejor mantengas el control de tu proyecto, menos te afectarán los imprevistos.

En este artículo os daré unas pequeñas claves para rescatar un proyecto digital. Pero primero, un poquito de teoría.

Una de las cosas que siempre destaco es la necesidad de ver el desarrollo softwaer como inversión en I+D+i . Y como tal inversión, requiere de un estudio previo. De un modo análogo a cuando compramos una casa, se tasa, se mira que no haya ningún desperfecto y si se ha de construir, se contrata a un arquitecto, existe en informática la figura del arquitecto de software quien es el encargado de orquestrar  o crear la estructura interna que conformará a un proyecto de software.

Programar es una tarea moderadamente complicada (o más para según que cosas). Seguramente alguna vez te habrás quejado de lo lento que va tu ordenador o teléfono móvil, pero es posible que no seas capaz de imaginar que más de tres mil personas, de diferentes nacionalidades , han trabajado en desarrollar alguna parte de tu terminal. Coordinar lo que programan tanto en software como en hardware tantas personas en equipos de trabajo tan diferentes es una tarea colosalmente dificil, y siempre surgen imperfecciones. 

La ingeniería del software es la ciencia de saber dónde tiene que ir cada cosa en un programa, para que su uso sea optimo, y tenga una alta mantenibilidad.  Esto quiere decir que si otro programador entra a trabajar sobre un código que tu has programado, será capaz de entenderlo con el menor esfuerzo. 

Comprender si un software está siendo bien programado por dentro no es una tarea trivial. Es algo que requiere de estudio y experiencia, y por eso uno de los aspectos fundamentales en el desarrollo de un proyecto tecnológico es el de contar con la figura de un CTO (Chief Technical Officer) que entienda del desarrollo software. Si bien no tiene por qué ser ni socio ni inversor, si debe de existir la figura de alguien dentro de la empresa (o de confianza y asociada a ella) que entienda lo que se está programando.

Empiezo el artículo con esto porque una de las mayores razones por los que veo a proyectos fracasar es porque no cuentan con un CTO.

Dicho esto, expongo una lista sobre los puntos más fundamentales para que todo proyecto sea lo más agil y rescatable posible.

Uno de los aspectos más fundamentales es que el proyecto esté bien documentado. Esto implica crear documentos para cada fase del desarrollo del proyecto y tenerlos localizados. Piénsalo así, por cada cosa que tu o tu equipo no sepáis, la persona encargada de rescatarlo tendrá que averiguarlo por su cuenta y tiempo, lo cual hará que el coste de cualquier futuro rescate aumente. De manera análoga a la construcción de una casa, se necesita conocer los planos de construcción. Ayuda saber dónde están las regatas, las tuberías, los cables .. antes de ponerse a picar.

Entre los documentos que puedes necesitar tener:

Para el diseño, es necesario tener una guía de estilos que especifique cosas como los colores, la tipografía fuente a utilizar, el tamaño de los encabezados y espaciados etc.

Si vas a desarrollar algún servidor, te servirá un documento técnico que explique cómo ha sido programado y con qué finalidad, un listado de los servicios que ofrece tu servidor y rutas o formas de acceder a ellos, y poder autenticarse en ellos.

En el desarrollo de front-end y apps mobile, es importante que se hayan seguido estándares o frameworks durante el desarrollo. También es importante tener un wireframe o un prototipo rápido clickable.

Si tu web es un e-commerce o un CMS, un listado de los plugins que se han empleado e instalado, así como copias de sus licencias (si las requisiesen).

Si vas a contratar un hosting o un cloud para tu web o app, asegúrate de que el servidor o hosting final está a tu nombre o al de tu empresa. No utilices servidores ajenos. Es mejor contratarlos por tu cuenta y dar acceso a las empresas y / o programadores afiliados al desarrollo del proyecto. Otra cosa importante (que la he visto ocurrir muy a menudo) es que debes de ser tu mism@ o tu empresa quien compre el dominio. Si no, a efectos legales y corporativos, le pertecenerá a otra persona y recuperar un nombre de dominio así es un proceso largo, tedioso, complicado, aburrido , caro y no siempre garantizable su recuperación.

La verdad es que con el tiempo me he dado cuenta de que son la parte menos problemática de todas. A menudo se firman contratos de confidencialidad para evitar que el equipo de desarrollo pueda robarnos nuestra idea... como si tuviesen tiempo... ellos ya tuvieron su idea y ya están trabajando en ella...

La auténtica utilidad de un acuerdo de confidencialidad es la de preservar trabajo ya realizado , prevenir que pueda ser reutilizado en un futuro y... en caso de que pudiera haber algún problema, permite legalmente poder señalar con el dedo a alguien y decir "¡es tu culpa!".

No implica desconfiar de tu equipo,  Es un formalismo muy estándar en la industria y cubrirse las espaldas.

Otra gran cosa de importancia es tener siempre acceso al código fuente, para poder controlar el trabajo que se está realizando y la manera (o el modo) en el que se está ralizando.

Tener acceso al código fuente es todo ventajas , y suele ser el 99% del trabajo a tener para poder recuperar un proyecto.  A menos que se trate de un prototipo que al probarlo está tan mal hecho y en una fase tan temprana, reutilizar el código será casi siempre más barato y óptimo que empezar de nuevo. Y digo casi siempre porque si, hay casos en los que es mejor tirar y reempezar, pero no suelen ser lo más común.

Con el código fuente, puedes permitir que otra empresa imparcial entre y juzgue el proyecto, hacer auditorías externas durante el desarrollo y obtener feedback sobre el mismo. Las ventajas son infinitas.

Si un equipo de desarrollo tiene la política de no compartir el código fuente durante el desarrollo, desconfía.

"Eso es que lo lleva fulanito, le preguntaré y te diré" es lo que más bloquea en tiempo el rescate de un proyecto. La imposibilidad de acceder a ver, a visualizar, a palpar la funcionalidad y cómo está programada paraliza cualquier rescate.

Un archivo, o un documento confidencial - aunque sea una hoja de papel - con todas las claves y contraseñas de todos los servicios, programas... o tu o tu equipo debeis tenerla siempre a mano.

Si tienes dudas, no lo ves claro o no tienes CTO, apoyate en una consultora externa. Según la dificultad técnica del proyecto, siempre existirá la necesidad de gente que lea la documentación para añadir nuevas funcionalidades, o seguir trabajando en el proyecto. Una consultora es una fuente excelente de este tipo de recursos. 

En mi caso, a menudo veo que se requieren de perfiles muy especializados para cubrir partes de proyectos más complejos.  Que un equipo de desarrollo cuente con un perfil que entienda PHP o Javascript es relativamente sencillo. Que tengan a alguien experto en blockchain o Inteligencia artificial o conexiónes remotas ya es màs complicado. Es común que retomar un proyecto requiera de contratar un nuevo perfil que se encargue de hacer las partes más específicas (bien).

Además, un estudio es una excelente manera de conocer a tu equipo, su forma de trabajar y su metodología sin mojarse demasiado.

Las cosas que he enumerado son a priori bastante básicas. A menudo las cosas que fallan de un proyecto son solo una parte específica de la aplicación. Muchos piensan que "bueno, solamente falla esto, así que debería de ser poquito, fácil o barato".

Pero error, no siempre es así. Cuando te pones a excarbar y a investigar es cuando salen las cosas. Una vez estuve involucrado arreglando un proyecto de un cliente que requería alterar un bug que no permitía acceder a ver unas imágenes de un usuario. Al desenterrar me dí cuenta de que ninguna parte del servidor estaba protegida y que el módulo de autenticación no estaba funcionando. 

Algo así de obvio suele ser un error que no pasa desapercibido, pero en este caso era una parte tan específica que si lo hizo.  A veces el error puede ser una única linea de código, pero las horas para saber exáctamente que linea de código era son casi casi innumerables.

Siempre animo a mis clientes a que no piensen en pequeño, porque también es cierto que si tienes problemas serios con tu equipo de desarrollo, hasta tal punto que debes desconfiar de ellos y pasarlo a otro , es bueno dejar que tu nuevo equipo fisgonee , investigue y te asesore.  No siempre es pensar "hay una cosa que falla y que tengo que arreglar" sino "necesito que otra persona me gestione este proyecto". 

​Y bueno, si ese es tu caso, preguntanos sin compromiso. ¡Pincha en contacta y escribenos!