Un nuevo desarrollador quizá pueda terminar tu software si puede comprobar qué funciona, obtiene acceso autorizado a lo que necesita y muestra una forma viable de completar una tarea importante. Pide primero una evaluación breve. Una pantalla puede parecer terminada y aun así detenerse antes de guardar el resultado. A una copia del código pueden faltarle las instrucciones o los servicios necesarios para ejecutarla.
Si ya hay personas que dependen de una versión en producción, acuerda quién la mantendrá en funcionamiento durante la evaluación. Puedes resolver cómo darle soporte ahora y decidir más adelante si la sustituyes.
¿Qué puedes entregar a un nuevo desarrollador?
Pide la última versión del código fuente que se utilizó o se probó, junto con las instrucciones y dependencias necesarias para compilarla. Averigua quién controla las cuentas con las que se despliega el software y se conecta a otros servicios. Identifica dónde se guardan los registros de la empresa y las copias de seguridad, y qué te permiten compartir o modificar tus acuerdos. Tener acceso al repositorio no acredita por sí solo esos permisos.
Comprueba estos puntos por separado. Un equipo puede ejecutar una copia y seguir sin tener acceso para actualizar la versión en producción. También puede tener acceso al alojamiento sin poder reconstruir el software a partir de lo que le han entregado. Si hay que trasladar registros, prueba por separado una exportación que el nuevo sistema pueda utilizar.
¿Qué debería demostrar el equipo que se incorpora?
Elige una tarea importante para la empresa. Imagina una herramienta inacabada que usa el personal de coordinación del servicio: un trabajador puede enviar una solicitud, pero todavía nadie ha demostrado que un responsable pueda aprobarla y consultar la decisión más adelante. Pide al equipo que compile una versión conocida y pruebe esa tarea en un entorno separado y autorizado. Usa registros inventados y desactiva las notificaciones reales, los pagos y otras acciones que afecten a la operación. Deja fuera de la prueba el sistema en producción.
Sigue la solicitud hasta donde llegue y apunta dónde se detiene. Si el responsable puede aprobarla, pero la decisión desaparece al abrirla de nuevo, el equipo tiene un problema concreto que investigar. Si una dependencia ausente impide arrancar el software, anota que todavía no se ha podido demostrar el proceso e identifica qué falta. El siguiente paso será distinto al de un fallo confirmado en la aprobación.
Una compilación demuestra que el equipo pudo preparar esa versión en esas condiciones. No acredita la seguridad o facilidad de mantenimiento del sistema completo, el permiso para desplegarlo ni que esté listo para producción. La explicación de Google sobre el traspaso de la responsabilidad operativa ilustra esa decisión aparte: su revisión contempla dependencias y preparación para la operación, con formación y mejoras cuando hacen falta.
¿Conviene continuar, reparar una parte o sustituir el software?
Compara las opciones a partir de la misma tarea y del trabajo que exigirá mantener el resultado. La guía de compra del Gobierno británico ofrece un ejemplo de cómo comparar la adaptación y el desarrollo desde cero según las necesidades, los costes y la capacidad de operar la solución elegida.
Continuar el desarrollo
El equipo puede compilar una versión conocida, el proceso actual funciona en el entorno de pruebas y se puede añadir el paso pendiente sin cambiar el funcionamiento del resto del sistema.
Reparar una parte
El proceso principal funciona, pero un área concreta, como el despliegue o una integración, necesita una reparación. Pregunta cómo la probaría el equipo antes de volver a usar esa parte.
Sustituir el software
Las opciones que conservan el software no cumplen un requisito esencial con un coste o riesgo aceptable. Antes del cambio, planifica cómo trasladar los registros y el trabajo en curso.
Si la sustitución parece la mejor opción, decide por separado cómo dar continuidad al trabajo en curso. Mantener ambos sistemas en paralelo durante un tiempo es una transición posible, con sus propios costes y la necesidad de definir quién se hace cargo de los registros.
¿Qué debe quedar por escrito tras la evaluación?
Pide un resumen breve que puedas leer con quienes usan el software. Debe indicar qué demostró el equipo, qué falló o no se pudo probar, qué accesos o permisos faltan y qué podría interrumpir el trabajo actual. Para cada opción viable, identifica la siguiente fase, quién debe actuar y qué comprobarás antes de aprobar más trabajo.
En la herramienta del ejemplo, el siguiente paso podría ser averiguar por qué desaparece una aprobación guardada y luego mostrar que el responsable puede volver a encontrar la decisión en el sistema de pruebas. Si estás valorando equipos para hacerlo, consulta qué preguntar a un desarrollador de software a medida antes de elegirlo.
Preguntas sobre cómo retomar un software inacabado
¿Basta con tener el código fuente?
El código le da al nuevo equipo algo que examinar. Comprueba a qué versión corresponde, si puedes dar acceso autorizado a lo que necesita y si el equipo puede compilarla y probar una tarea importante fuera del sistema en producción.
¿Cuándo basta con una reparación puntual?
Plantéatela si el proceso principal funciona y el equipo puede acotar y probar la reparación en un área. Pregunta qué problemas seguirían pendientes y quién podría mantener el software después.
¿Qué debería entregarme la evaluación?
Un resumen de lo que funcionó en la prueba, lo que queda por comprobar, lo que falta y lo que exigiría cada opción. Deja claro quién mantendrá en marcha la versión que ya esté en uso, si la hay, y qué paso aprobarías después.
