Por Nicho Agencia Digital · Publicado el

1. Conserva una versión del alcance acordado

Antes de discutir una nueva función, identifica qué versión sirve como referencia: usuarios, procesos, integraciones, datos y criterios de aceptación. Una lista de pantallas no siempre explica qué comportamientos debe soportar el sistema. Guarda también exclusiones y supuestos, porque allí suelen aparecer los malentendidos.

No reescribas silenciosamente esa referencia cada vez que llegue una petición. Conserva la versión anterior y añade un registro de decisiones. Si todavía estás definiendo el producto, revisa primero cómo delimitar un MVP. Cuando el alcance inicial es ambiguo, etiquetar todo como «extra» tampoco resuelve el desacuerdo.

2. Describe el problema antes de pedir una solución

Recoge quién necesita el cambio, qué intenta hacer, qué ocurre hoy y qué resultado espera. «Agregar un botón» describe una solución; «el supervisor necesita aprobar una devolución sin pedir ayuda técnica» describe una necesidad que puede tener distintas respuestas.

El Service Manual de GOV.UK propone expresar usuario, necesidad y objetivo, y acompañarlos con criterios de aceptación. Puedes usar ese enfoque para aclarar solicitudes empresariales sin copiar un proceso completo. Adjunta un ejemplo ficticio o anonimizado y explica qué debe suceder cuando falte un dato o el usuario no tenga permisos. Eso permite estimar algo más concreto que una idea en un chat.

3. Clasifica antes de estimar

Una solicitud puede corregir un incumplimiento de lo acordado, aclarar una regla ambigua o ampliar el producto. La clasificación debe apoyarse en la versión de referencia y la evidencia de la prueba, no solamente en quién la solicita. Un defecto y una mejora no tienen necesariamente el mismo tratamiento.

Si hay desacuerdo, registra el punto pendiente y separa la discusión del resto del trabajo. No borres reportes para que el tablero parezca limpio. Tampoco presentes una estimación preliminar como compromiso de fecha o precio: indica supuestos, dependencias y qué información falta para confirmarla.

4. Usa una ficha de impacto pequeña pero completa

Para cada cambio prepara una ficha que permita decidir:

  • Resultado: necesidad y criterio observable de aceptación.
  • Alcance: usuarios, pantallas, reglas y datos afectados.
  • Dependencias: integraciones, accesos y decisiones de otras personas.
  • Impacto: trabajo, pruebas, soporte y posible efecto en el calendario.
  • Alternativas: incluir ahora, sustituir otra función, reducir o aplazar.
  • Decisión: responsable autorizado, versión y fecha de aprobación.

Incluye migración de datos y mantenimiento cuando correspondan. El costo total del software no termina al programar una pantalla. No inventes importes para completar la ficha: los campos pendientes deben permanecer identificados.

5. Ejemplo ficticio: añadir una segunda sede

Ejemplo hipotético, no proyecto real de NICHO: un portal pensado para una sede recibe la petición de operar dos. Duplicar el selector visual parece sencillo, pero pueden cambiar permisos, inventario, responsables y reportes. El equipo identifica primero si cada sede tiene datos propios o comparte existencias.

Se proponen dos alternativas: incluir ambas sedes en la siguiente entrega con las pruebas adicionales necesarias, o mantener una sede inicialmente y preparar la separación para una etapa posterior. El decisor elige después de revisar el impacto. Una conversación exploratoria no se registra como aprobación y una aprobación del cambio no significa que ya esté entregado.

6. Cierra el cambio con evidencia y una nueva referencia

Después de implementar, prueba el comportamiento nuevo y las funciones afectadas. Verifica permisos, errores, datos existentes y recorridos anteriores; mostrar únicamente la pantalla nueva puede ocultar regresiones. Conserva el resultado de las pruebas y las excepciones que siguen abiertas.

Actualiza documentación, instrucciones y versión del alcance cuando se acepte la entrega. Distingue solicitado, evaluado, aprobado, desarrollado y aceptado. Si algo vuelve a cambiar, abre una nueva decisión vinculada a la anterior. Un proyecto de software a medida necesita ese historial para evolucionar sin perder de vista qué se prometió y qué se comprobó.

El siguiente paso

Comparte el alcance actual y una solicitud de cambio anonimizada. Podemos revisar dependencias, alternativas y pruebas necesarias para decidir una siguiente entrega de software con límites claros.

Software a medida para empresas · Conversar sobre tu proyecto ↗

Fuentes y alcance

Fuentes consultadas el 1 de noviembre de 2026. Las recomendaciones de proceso son propuestas editoriales de Nicho; los ejemplos identificados como hipotéticos no representan resultados de clientes.

Contenido preparado con asistencia de IA y comprobaciones automáticas. No sustituye una evaluación de tu implementación ni garantiza resultados. Escríbenos si encuentras algo que debamos corregir.