Cómo legar un proyecto de desarrollo a otro programador de forma prolija

En este artículo te voy a contar cómo legar un proyecto de desarrollo a otro programador de la forma más prolija y ordenada posible.

Los proyectos no duran para siempre y llega un punto en que por diferentes motivos simplemente ya no los podemos llevar adelante. Puede ser porque económicamente no nos cierra o porque estamos virando en materia tecnológica o incluso vocacional.

O también puede ocurrir que simplemente estamos tan desmotivados que es necesario aire fresco, tanto para nosotros como para el proyecto.

En este artículo te voy a contar sobre el legado de un proyecto para un cliente que comencé hace 4 años y al que finalmente le estoy diciendo adiós.

Los motivos de mi desvinculación

Como comenté al principio, puede haber diferentes motivos para uno querer desvincularse de un proyecto. En mi caso se dieron varios al mismo tiempo, pero uno predominó más: un cambio de dirección no sólo en materia profesional sino también a nivel personal.

Hay caminos en la vida que son incompatibles con determinados trabajos. Por más que uno se esfuerce en acomodar las condiciones, a veces simplemente se hace inmanejable.

Comunicación abierta con el cliente

Me parece que lo primero y más valioso que el cliente puede apreciar de uno es una comunicación sincera de la situación. Explicar con fundamentos claros la irreversibilidad de la situación y la inminente desvinculación que esto trae consigo.

Por supuesto, no hay que olvidar que del otro lado hay personas que tienen que planificar su negocio y que, por ello, necesitan tener información precisa sobre plazos y mecanismos de transición.

En otras palabras, hay que avisar con tiempo y estar abierto a todas las situaciones que pueden darse en una transición.

¿Es necesario realizar una transición ordenada?

Cuando uno se abre de un proyecto está tentado a desvincularse abruptamente. Pedir las disculpas del caso y desaparecer. ¿Qué responsabilidad se puede achacar si no hay un contrato de por medio? ¿Qué reclamo podría ser válido si vivimos en un mundo libre? Nadie puede obligarnos a trabajar en un proyecto que no queremos.

Sin embargo, vivimos en un mundo demasiado cambiante. Un mundo hiperconectado en el que los planes de tu vida pueden alterarse por eventos que pueden darse al otro lado del mundo. En ese contexto es necesario estar preparado para cualquier circunstancia.

Dar un portazo y abandonar a un cliente de un día para el otro puede ser perjudicial en el futuro. Nadie tiene asegurado nada en esta vida.

Cuando cerramos un proyecto es importante concluir una etapa, pero no cerrar una puerta. Nadie tiene garantizado nada en este mundo y no sabemos dónde podemos estar en un tiempo.

Por lo tanto, abandonar un proyecto dando un portazo y quebrando relaciones comerciales no es para nada acertado. La alternativa profesional es una salida coordinada que satisfaga al cliente y le deje un buen recuerdo de nuestro paso por allí.

Y ahora… ¿quién podrá sucedernos?

La primera incógnita que el cliente querrá despejar es la de quién o quiénes se harán cargo del proyecto que queda vacante. Este primer paso es primordial y también urgente porque de no seleccionarse un reemplazo, todo el proceso de transición se demorará.

Es probable que el mismo cliente nos pregunte si conocemos a alguien que pueda tomar el proyecto. Cualquier tipo de sugerencia que esté a nuestro alcance es válida, pero hay que pensar si los contactos que podemos acercar están a la altura de las circunstancias.

Podemos sugerir quién puede reemplazarnos, pero la decisión final sobre esto la tendrá siempre el cliente.

Cualquier persona que conozcamos y que maneje algo de la tecnología en que está hecho el proyecto no es suficiente para poder legárselo. Hay otras características que son importantes como la confianza, la disponibilidad horaria, la responsabilidad y, por supuesto, el nivel necesario.

Lo ideal es que el propio cliente encuentre a un nuevo programador o a una empresa que pueda hacerse cargo del proyecto. Como programadores salientes podemos validar las aptitudes de los sucesores pero me parecería excesivo entrometernos en la decisión propiamente.

En otras palabras, la última palabra la tendrá el cliente. En el peor de los casos, si vemos que la decisión es desacertada, podemos advertirlo, pero no más que eso.

Con los sucesores ya elegidos comienza la etapa de transición.

El proceso de transición

El proceso de transición comprende todas las acciones de transferencia de información que se tienen que llevar adelante para que el sucesor o los sucesores puedan tomar las riendas del proyecto.

Una buena idea es fijar una fecha límite para todo el proceso, aunque esto puede llegar a ser complicado porque depende de varios factores. Entre ellos, nuestra capacidad para generar documentación y la capacidad de los sucesores de asimilarla.

En mi caso, no lo hice porque entiendo que la cantidad de información que tengo que legar es inmensa y sé que se necesitan meses hasta que quien me reemplaza pueda tomar por completo el control del proyecto.

El detalle de la transición

Algo que me resultó muy útil fue hacer un listado de aspectos que hay que tener en cuenta a la hora de realizar una transición. Una lista de todas las cuestiones que hay que considerar, tengan que ver directamente con el proceso de trabajo, el código fuente, los servidores involucrados o con recomendaciones extra.

El detalle de todo lo que hay que tener en cuenta varía mucho de proyecto en proyecto. En mi caso, incluye el código fuente del programa, la base de datos, documentación en texto preexistente, documentación a generar, credenciales de acceso a servidores y servicios externos.

Además de estas cuestiones básicas y fáciles de pensar, agregué algunos consejos extra sobre temas puntuales. Recomendaciones sobre cómo proceder en determinadas situaciones y problemas conocidos del sistema.

El proceso de capacitación

Nadie puede tomar el control de un proyecto y dominar cada uno de sus aspectos de forma inmediata. El acercamiento a la tecnología y a los pormenores del proceso deben ser paulatinos. Por eso es necesario iniciar desde el comienzo de la transición, una etapa de capacitación para que el sucesor pueda ir ganando conocimientos lo más rápido posible.

En mi caso, he probado tanto con proporcionar fuentes de documentación oficial, como generando mi propia documentación. Es decir, además de enviar un enlace a una web con documentación rígida, generar manuales y guías más fáciles de seguir, incluyendo capturas de ser necesario.

En la actualidad, puede ser más beneficioso documentar en video que escribiendo extensos manuales o guías.

De todas las formas de documentación que exploré, la que sin dudas ha dado mejores resultados es la de grabar videos. Los primeros que grabé explicaban a grandes rasgos la estructura del proyecto. Luego pasé a hacer un videotutorial de varias partes explicando un ABM básico. Lo mínimo que un desarrollador debe dominar para comenzar a hacer propio el sistema.

A los videos y documentación se le pueden sumar consultas por mensajería instantánea, llamadas y videollamadas.

El camino a la independencia

Desde nuestro punto de vista estaremos esperando que el proceso de transición sea lo más corto posible para independizarnos del proyecto. Para lograr eso creo que hay que pasar por algunos hitos.

En mi caso, lo explicaré a través de un proyecto web, ya que es lo que me toca legar.

• Levantar un ambiente local. Esto es que quien nos suceda pueda tener el ambiente local para hacer pruebas, explorar el código y hacer pequeñas modificaciones para ver qué ocurre. Este ambiente en el futuro le permitirá trabajar y realizar grandes cambios, pero por el momento alcanza con que le sirva para familiarizarse.
• Modificación. En todo este camino, la capacitación no se interrumpe. Llegará un momento en el cual el sucesor estará en condiciones de realizar una modificación o un agregado al sistema. Aquí tendrá que valerse de todo lo que ya sabía y de lo aprendido en las capacitaciones. El éxito en este punto es clave para poder pasar al punto final.
• Despliegue. El despliegue en producción es el desenlace de toda la transición. Pero hay un detalle no menor. Tiene que ser exitoso y lo menos asistido posible.

De esta forma, una vez que el sucesor complete la etapa de despliegue por su cuenta, estará en condiciones de manejar el proyecto de forma independiente. Por supuesto que todavía tendrá algunas dudas, realizará consultas y necesitará de nuestra ayuda, pero ya no será como antes. Ese sistema ya no es nuestro. Lo hemos legado.

El precio de la transición

Realizar una transición lleva tiempo y, como decía Benjamin Franklin: «El tiempo es dinero». Acordar el precio de una transición es algo que puede hacerse al comienzo. Se pueden estimar horas o ponerle un precio fijo. Eso ya depende de las partes interesadas. Es muy probable que esto lo pague el cliente, pero no sería descabellado que el propio sucesor opte por invertir en capacitación.

En mi caso opté por no cobrar esta etapa porque nuevamente entra en juego lo que comentaba al principio. La forma de abandonar el proyecto en este caso me parecía más importante que el dinero. Pero esto es una decisión completamente personal.

Concluyendo

Los proyectos van y vienen. En el caso de que nos queramos alejar de uno de ellos, lo mejor es hablar con claridad sobre el asunto con el cliente. Una vez hecho esto, es preferible pautar una transición ordenada, puesto que es bueno mantener una conducta profesional y no cerrar puertas a futuro.

Elegir al sucesor es tarea del cliente. Podemos dar sugerencias, pero no nos corresponde entrometernos en esa decisión.

El proceso de transición consiste en legar información y documentación a quien nos suceda, hasta que finalmente esta persona o grupo de personas puedan tomar el control del sistema.

Concluida esta etapa, nos habremos despedido para siempre del proyecto y ya tendremos el tiempo libre para dedicarlo a otras actividades.