Tu app ya tiene usuarios, datos guardados y un comportamiento del que la gente depende. Cuando traes a un desarrollador para corregir un error o añadir una funcionalidad, esos compromisos existentes forman parte del trabajo.
Empiezo por entender el sistema actual y el cambio que necesitas. Puedes ayudarme con un ejemplo claro, un mapa de los servicios implicados y una lista de lo que tiene que seguir funcionando. Esta guía explica qué preparar y qué esperar de la revisión.
Describe el cambio según lo que hacen los usuarios
“La app va lenta” es un punto de partida útil. “En el móvil, abrir la página de pedidos tarda varios segundos cuando un cliente tiene un historial largo” nos da algo que investigar. Para una funcionalidad nueva, describe qué debería poder hacer el usuario y qué puede hacer hoy.
Para un error, envía los pasos que llevan a él, lo que esperabas y lo que pasó en su lugar. Indica el dispositivo o el navegador si parece relevante. Una grabación de pantalla corta ayuda; quita los datos de clientes y los mensajes privados antes de compartirla.
Cuéntame con qué frecuencia ocurre el problema, a quién afecta y si hay una forma de sortearlo. Un fallo en el pago que afecta a clientes activos necesita una respuesta distinta a un problema visual en una página interna.
Este es un informe de error inventado, con suficiente detalle para empezar a investigar:
En la página de pedidos, elige “Últimos 30 días” y abre la segunda página de resultados. El filtro de fecha se reinicia y aparecen pedidos más antiguos.
Esperado: el filtro de fecha sigue seleccionado al pasar de página.
Ocurre siempre en Chrome en mi portátil. El equipo puede sortearlo buscando por número de pedido, pero revisar los pedidos recientes lleva más tiempo.
Dame un mapa del sistema actual
No necesitas conocer cada detalle técnico. Empieza por lo que sabes y dime quién puede responder preguntas sobre el resto.
Dónde está el código, quién es el titular del repositorio y qué versión está publicada.
Dónde se ejecuta la aplicación y cómo se despliegan hoy los cambios.
La base de datos, el almacenamiento de archivos y los servicios externos que usa.
Instrucciones de instalación, comprobaciones automáticas o documentación existente.
Problemas conocidos, trabajo a medias e intentos anteriores de resolver este problema.
Si el desarrollador anterior u otro equipo está disponible para preguntas.
Si tienes un entorno de staging (una copia separada donde se prueban los cambios antes de que lleguen a los clientes), dime cómo acceder. Si no lo tienes, lo planificaremos cuando el trabajo lo requiera.
Menciona lo que el sistema actual debe conservar: enlaces existentes, datos guardados, permisos de usuario, integraciones o versiones de la app que siguen en los móviles de tus clientes. Es fácil pasarlos por alto cuando se habla de una sola pantalla nueva.
Da acceso mediante invitaciones
Conserva la titularidad de tu repositorio, hosting, dominio y cuentas de pago. Invita al desarrollador con el control de acceso de cada servicio y con los permisos que necesite el trabajo. Si el proveedor lo permite, una revisión puede empezar con acceso de solo lectura y un entorno de pruebas.
No pegues contraseñas, claves de API de producción, exportaciones de clientes ni un archivo de entorno completo en el brief. Acordaremos cómo entregar por separado los secretos necesarios. Las cuentas de prueba y los datos de ejemplo suelen ser más útiles para reproducir un problema que el acceso sin restricciones a datos reales de clientes.
Entiende la revisión antes del presupuesto
En un código existente tengo que comprobar cómo funciona, seguir el comportamiento relevante y entender qué partes podría afectar un cambio. Una funcionalidad que parece aislada puede tocar permisos, facturación o una migración de base de datos.
Acordamos el alcance y las condiciones de la revisión antes de empezarla. Su resultado por escrito debería explicar:
Qué se revisó, qué se pudo reproducir y qué accesos o información faltan todavía.
El cambio recomendado, con las alternativas que valga la pena considerar.
Qué funcionalidades o datos existentes podrían verse afectados.
Cómo se comprobará el trabajo, cómo se publicará y cómo se revertirá si hay un problema.
Qué se puede estimar ya y qué necesita más investigación.
Pide una razón antes de reescribir
El código antiguo puede seguir haciendo bien su trabajo. Un framework distinto o las preferencias de un nuevo desarrollador son malas razones para sustituir un sistema que funciona. Muchas veces el cambio correcto es una corrección concreta, un test que faltaba o una actualización por etapas.
A veces una sustitución está justificada. Pregunta qué requisitos no puede cumplir razonablemente el sistema actual, qué partes se podrían conservar y cómo sería la transición. La comparación tiene que incluir la migración de datos y la conservación del comportamiento existente, además de escribir el sistema nuevo.
Acuerda cómo llegan los cambios a los usuarios
Antes de desplegar, deberíamos saber cómo se probará el cambio, quién lo revisará y qué pasa si algo sale mal. En un producto en producción quiero un plan de publicación acordado y una forma de volver atrás. Revertir el código no siempre deshace un cambio en los datos, así que las migraciones de base de datos necesitan su propio plan.
En el ejemplo del filtro de fecha, comprobaríamos que la selección se mantiene al paginar y que los demás filtros siguen funcionando bien. Deberías poder revisar ese comportamiento en una vista previa antes de que la corrección llegue a la web en producción.
En la entrega deberías poder ver qué cambió, cómo se comprobó y qué trabajo queda pendiente. Los nuevos pasos de instalación, los cambios de configuración y las limitaciones conocidas van en la documentación.
Qué enviarme primero
Este es el producto y quién lo usa: …
Esta es la funcionalidad o el problema, con un ejemplo: …
Esto es lo que tiene que seguir funcionando: …
Esto es lo que sé del código, el hosting y el desarrollador actual: …
Este es el impacto, la prioridad y el plazo, si lo hay: …
Empieza enviando ese contexto por elformulario de contacto. No hace falta que ordenes todo el proyecto ni que escribas documentación técnica antes de pedir ayuda.