Desarrollo de software: qué incluir y cómo priorizarlo

Cuando un equipo trabaja con hojas de cálculo, mensajes y herramientas desconectadas, la petición suele llegar formulada así: «necesitamos un programa». El problema es que esa frase no aclara qué debe resolver, quién lo usará ni qué tendría que ocurrir para considerar útil la inversión.

El desarrollo de software merece la pena cuando traduces una necesidad concreta en un sistema que permite realizar acciones, aplicar reglas y gestionar información de forma más ordenada. Al terminar esta guía podrás decidir qué incluir en una primera versión, qué aplazar y qué información preparar antes de valorar el proyecto.

Si todavía estás comparando una herramienta estándar, una solución configurable o un desarrollo propio, empieza por los criterios para elegir software empresarial. Esta guía parte del paso posterior: cómo definir y priorizar un proyecto que sí requiere desarrollo.

Respuesta directa: empieza por el problema, no por la aplicación

Antes de elegir entre una aplicación web, una app móvil o una herramienta interna, define el cambio que buscas. Por ejemplo: reducir duplicidades al registrar pedidos, dar visibilidad del estado de un servicio o permitir que los clientes consulten documentación sin depender de correos.

La tecnología es la solución; el objetivo es la referencia para decidir. Si no puedes describir el problema, los usuarios y la acción que debe mejorar, aún no tienes un alcance suficientemente claro.

7 elementos que debe concretar un proyecto de desarrollo de software

1. El objetivo operativo o comercial
   Describe qué debe cambiar con una frase observable. «Ordenar la gestión» es demasiado amplio. «Permitir que el equipo consulte el estado de cada pedido en un único lugar» delimita mejor la necesidad y ayuda a comprobar si la solución cumple su función.

2. Las personas que usarán el sistema
   No basta con indicar que lo utilizará «la empresa». Distingue, por ejemplo, entre administración, equipo comercial, responsables de operaciones y clientes. Cada perfil puede necesitar pantallas, permisos y acciones diferentes.

3. El recorrido principal de trabajo
   Explica qué ocurre desde que entra una solicitud hasta que se completa. Un recorrido puede incluir registrar datos, asignar una tarea, cambiar un estado, adjuntar un documento y avisar a una persona. Este orden revela reglas y excepciones que suelen quedar ocultas en una idea inicial.

4. Los datos que se deben consultar o modificar
   Identifica qué información necesita el software: clientes, pedidos, citas, documentos, incidencias, inventario u otros registros propios de tu actividad. También conviene definir quién puede ver, editar o eliminar cada dato.

5. Las funciones necesarias en la primera versión
   Una función debe responder a un objetivo y a un usuario. Por ejemplo, un panel para asignar solicitudes puede ser necesario si evita que varias personas trabajen sobre el mismo asunto; un sistema avanzado de informes puede esperar si al inicio basta con consultar los estados principales.

6. Las conexiones con otras herramientas
   Si el software debe intercambiar información con correo, facturación, pagos, calendarios u otros servicios, concreta qué dato viaja, en qué momento y qué debería pasar si la conexión falla. Nombrar una integración sin describir ese flujo deja una parte relevante del alcance sin definir.

7. El mantenimiento y la evolución
   El proyecto no termina al poner el sistema en uso. Decide quién actualizará contenidos o datos, quién tendrá los accesos y qué cambios son previsibles. Pensar en ello desde el inicio ayuda a evitar una solución difícil de modificar cuando cambien procesos o necesidades.

Cómo priorizar sin intentar construirlo todo a la vez

Clasifica cada necesidad en una de estas cuatro categorías. La clasificación obliga a asumir una consecuencia: incluir algo ahora, posponerlo o descartarlo de forma consciente.

• Imprescindible: sin esta función no se cumple el objetivo mínimo. Si el objetivo es centralizar solicitudes, crear, asignar y consultar una solicitud puede entrar aquí.
• Deseable: aporta utilidad, pero el sistema sigue cumpliendo su función inicial sin ella. Por ejemplo, avisos configurables para distintos eventos.
• Futuro: puede tener sentido más adelante, aunque no forma parte de la primera entrega. Por ejemplo, un área para proveedores si al inicio solo trabajará el equipo interno.
• Fuera de alcance: no responde al objetivo acordado o pertenece a otro proyecto. Dejarlo escrito evita que aparezca como una expectativa implícita.

Para decidir la categoría, responde a estas preguntas para cada función:

• ¿Qué objetivo apoya?
• ¿Quién la utilizará?
• ¿Qué ocurre si no existe al principio?
• ¿De qué datos, decisiones o servicios externos depende?
• ¿Cómo comprobarás que funciona como esperas?

Una función que no tiene usuario, propósito o forma de validarse todavía es una hipótesis, no un requisito listo para desarrollar.

Ejemplo aplicado: una empresa que gestiona solicitudes por varios canales

Este es un ejemplo hipotético. Una empresa recibe solicitudes por teléfono, correo y formularios. La información se copia a una hoja de cálculo y el equipo no siempre sabe quién está atendiendo cada caso.

Su objetivo podría formularse así: registrar cada solicitud y hacer visible su responsable y estado para el equipo.

Una primera versión podría incluir:

• acceso para las personas del equipo;
• registro de solicitudes con campos acordados;
• asignación de responsable;
• estados definidos, como pendiente, en curso y cerrada;
• búsqueda básica y consulta del historial;
• una vista de gestión para revisar los casos abiertos.

En cambio, podrían quedar para una fase posterior la creación de informes a medida, una aplicación móvil específica o conexiones con herramientas que todavía no se han descrito con suficiente detalle.

La decisión no consiste en determinar si esas mejoras son buenas o malas. Consiste en comprobar si son necesarias para resolver el problema inicial y si sus dependencias están claras.

Qué conviene dejar fuera de la primera conversación

No necesitas llegar con una especificación técnica cerrada. De hecho, decidir la tecnología antes de entender el trabajo que debe soportar puede limitar alternativas útiles. Es preferible dejar abiertas estas cuestiones hasta concretar el alcance:

• el nombre exacto de la tecnología o del tipo de app;
• funciones definidas solo como «completas», «sencillas» o «intuitivas»;
• integraciones sin un flujo de datos y un responsable claro;
• plazos ligados a una fecha sin revisar contenidos, accesos y dependencias;
• resultados formulados como garantías;
• extras que no contribuyen al objetivo de la primera versión.

Tampoco conviene tratar una aplicación como una solución aislada. Si un proceso depende de decisiones internas, información incompleta o reglas que cambian con frecuencia, esas condiciones deben revisarse antes de convertirlas en funcionalidad.

Siguiente paso: convertir la necesidad en un alcance revisable

Reúne un ejemplo real del proceso actual, las personas implicadas y las tareas que más problemas generan. Con esa base será más fácil distinguir si necesitas una herramienta interna, un portal para clientes, una aplicación móvil u otra solución.

Si quieres contrastar el alcance de una idea y sus prioridades, puedes explicar tu proyecto de aplicación o software a medida. El punto de partida útil es compartir el problema, los usuarios y las acciones que el sistema debería permitir; la solución técnica debe validarse después.