Software a medida: describir el trabajo antes que las funciones

Observar un caso real

Una petición como “necesitamos un programa de gestión” deja abiertas demasiadas decisiones. Empieza por una actividad concreta: recibir una solicitud, preparar un presupuesto, asignar una intervención o cerrar un expediente. Sigue un caso de principio a fin y anota las personas implicadas, la información necesaria, las herramientas utilizadas y los traspasos de responsabilidad. Busca especialmente dónde se vuelve a escribir un dato, una decisión queda sin responsable o el trabajo se detiene esperando una confirmación.

Separar reglas y excepciones

No todas las costumbres deben convertirse en una función. Pregúntate qué pasos protegen realmente el servicio y cuáles existen solo porque las herramientas actuales no se comunican. Describe después las excepciones: solicitud incompleta, modificación tras la aprobación, cancelación o ausencia de la persona responsable. Un flujo que funciona únicamente en el caso ideal puede trasladar el problema de la hoja de cálculo al nuevo sistema. Involucra a quienes realizan el trabajo diario, no solo a quienes autorizan el proyecto.

Lista para definir el alcance

• Indica el evento inicial y el resultado que cierra el proceso.
• Enumera roles, permisos y responsabilidades de aprobación.
• Define los datos necesarios, su origen y quién puede corregirlos.
• Señala integraciones, exportaciones y herramientas que deben mantenerse.
• Escribe qué queda fuera del primer lanzamiento y cómo se gestionará mientras tanto.

Hacer verificable cada prioridad

Para cada función importante prepara un ejemplo concreto con datos de prueba no sensibles. Un criterio útil podría ser: la persona responsable asigna una solicitud, el operador ve únicamente las tareas autorizadas y una modificación queda registrada. Evita expresiones vagas como “fácil y rápido” sin describir el comportamiento esperado. Un prototipo de las pantallas puede ayudar a debatir términos, pasos y autorizaciones antes de comprometerse con el desarrollo completo. Acuerda también quién decide cuándo se acepta una función y cómo se documentan las incidencias pendientes.

Preparar el cambio de herramienta

El proyecto incluye importación de datos, formación y asistencia, no solamente código. Antes de migrar comprueba duplicados, campos vacíos y opciones de exportación del sistema anterior. Establece un plan de pruebas, un procedimiento de recuperación y una persona de referencia para las incidencias. Empieza por un flujo delimitado, observa dónde necesitan ayuda las personas y recoge las peticiones posteriores en una lista separada. Para conversar con CBF E-Social trae un ejemplo de expediente, los pasos actuales y el resultado deseado: son bases más útiles que una larga lista de funciones genéricas.