Desarrollo de software a medida: fases del proceso y cómo encargarlo

¿Cómo funciona el desarrollo de software a medida? Fases desde el análisis de necesidades hasta la puesta en marcha, qué se espera de usted, roles y decisiones.

FUFerhat UğurluEquipo de YazSisPublicado: 10 de noviembre de 20268 min de lectura
En resumen

El proceso de desarrollo de software a medida empieza por definir la necesidad y continúa con el diseño, el desarrollo, las pruebas y la aceptación, la puesta en marcha y el soporte. En cada fase se espera del cliente una aportación y una decisión. El proceso empieza aclarando usuarios, datos y reglas de negocio antes que las pantallas; el error más caro es saltarse este primer paso.

El equipo de ventas recoge los pedidos por WhatsApp, el almacén los introduce en un Excel y contabilidad escribe la misma información por tercera vez. Ha revisado los programas estándar del mercado; ninguno encaja del todo con su orden de aprobaciones, su regla de descuentos o la forma de trabajar del personal de campo. Está pensando en encargar a una empresa un software a medida, pero no tiene claras las respuestas a “por dónde se empieza, qué tengo que hacer yo, cuándo se pone en marcha”. Esta guía explica el proceso desde su lado, es decir, desde la mirada de quien tomará las decisiones.

El desarrollo de software a medida es el proceso de crear software según las reglas de negocio, los roles de usuario y las necesidades de integración de una organización, allí donde un paquete estándar no basta. En general tiene seis fases: análisis de necesidades, diseño, desarrollo, pruebas y aceptación, puesta en marcha y soporte. A continuación verá qué ocurre en cada fase y qué se espera de usted.

¿Qué es el desarrollo de software a medida y cuándo hace falta?

El software a medida no es la respuesta adecuada para todas las empresas. Si se dan a la vez varias de las señales siguientes, ha llegado al límite de una solución estándar:

  • Su proceso se aparta del estándar del sector; el orden de aprobaciones, la regla de precios o el formato de registro son propios.
  • Cada mes añade una hoja de Excel nueva o hace correcciones a mano para adaptar el programa estándar a su proceso.
  • Varios sistemas (pedidos, stock, contabilidad, campo) necesitan intercambiar datos entre sí.
  • Distintos roles deben ver y poder hacer cosas distintas en el mismo registro; las reglas de permisos salen del proceso.
  • El personal de campo necesita un flujo de pasos cortos que pueda usar desde el teléfono.

Fases del desarrollo de software: la tabla de un vistazo

FaseLo que se espera de ustedPunto de decisiónLo que tiene al final de la fase
1. Análisis de necesidadesReservar tiempo de la persona que conoce el proceso; ejemplos de los Excel, formularios y documentos actualesAlcance de la primera versiónLista de objetivos, usuarios, datos y reglas de negocio
2. DiseñoComentarios sobre el flujo de pantallas y el reparto de rolesAprobación del flujo y los permisosFlujo de uso y arquitectura técnica
3. DesarrolloProbar las versiones intermedias y responder rápidoCambios de prioridadMódulos que funcionan
4. Pruebas y aceptaciónProbar con sus propios escenarios realesCumplimiento de los criterios de aceptaciónVersión aprobada
5. Puesta en marchaPreparar a los usuarios y el día del cambioFecha de cierre del sistema anteriorSistema funcionando en producción
6. Soporte y mejoraRecoger comentarios del usoPróximas mejorasUn sistema que se mide y se mejora

¿Cómo se encarga un software a medida? El proceso paso a paso

  1. Análisis de necesidades: el proceso antes que las pantallas. En el primer paso no se dibujan pantallas; se definen objetivos, usuarios, datos y reglas de negocio. Se ponen por escrito las respuestas a “¿quién abre el pedido, quién lo aprueba, cuándo se devuelve, cuáles son las excepciones?”. Lo que se espera de usted es incluir en estas reuniones a la persona que realmente lleva el proceso; el proceso que cuenta solo el directivo a menudo no es el mismo que el de planta. La decisión de esta fase es qué entra en la primera versión y qué queda para después.
  2. Diseño: flujo de uso y arquitectura. ¿Qué pasos hará el usuario y en qué orden, qué verá cada rol, dónde se guardarán los datos, con qué sistemas se comunicará? En esta fase se tratan juntos los bocetos de pantalla y la estructura técnica. Su tarea es revisar el boceto recorriendo sobre él su propio trabajo diario: “¿cuántos pasos lleva en esta pantalla la tarea que hago con más frecuencia?”.
  3. Desarrollo: avance modular. Si el software se construye por partes, cada parte puede probarse pronto. Con un paquete grande entregado de una sola vez, los malentendidos se descubren lo más tarde posible. En esta fase se espera que dé comentarios rápidos sobre las versiones intermedias y que canalice las decisiones a través de una sola persona; las peticiones distintas de tres directivos amplían el alcance sin que nadie lo note.
  4. Pruebas y aceptación: pruebe con sus propios datos. Las pruebas no son solo cosa del desarrollador. Los criterios de aceptación deben estar por escrito desde el principio: “se acepta cuando este escenario da este resultado”. Pruebe el sistema no con datos de ejemplo, sino con una semana real de pedidos, cancelaciones y excepciones. El punto de decisión es si se cumplen los criterios.
  5. Puesta en marcha: del sistema anterior al nuevo. Poner en marcha es tanto un cambio de hábitos como un hecho técnico. Cuándo se cerrará el Excel antiguo, cómo se migrarán los registros existentes y cómo se informará a los usuarios debe planificarse con antelación. De lo contrario, todos trabajan en dos sitios a la vez y empieza la discusión sobre cuál está al día.
  6. Soporte y mejora: poner en marcha y medir. El trabajo no termina cuando el sistema entra en producción; el uso real se ve por primera vez con datos reales. Qué pantalla se salta, qué paso se atasca y qué informe falta salen del uso. Recoger los comentarios y priorizar las próximas mejoras es decisión suya.

¿Quién debe estar de su lado durante el proceso?

Los proyectos de software se atascan con más frecuencia no por cuestiones técnicas, sino por un vacío de responsabilidad del lado del cliente. Cuatro roles deben tener nombre; una persona puede asumir más de uno, pero ninguno debe quedar vacío:

  • Responsable de las decisiones: la persona que tiene la última palabra sobre alcance, prioridades y aceptación. Debe estar disponible en cada versión intermedia, no una vez cada varias semanas.
  • Responsable del proceso: la persona que lleva el trabajo día a día y conoce las excepciones. Es la fuente de información más valiosa del análisis.
  • Representante de los usuarios finales: el empleado que usará realmente el software en campo, en el almacén o en la oficina. Es quien dice si el flujo de pantallas funciona de verdad.
  • Responsable de datos y sistemas: la persona que sabe dónde están los archivos, bases de datos y demás sistemas actuales; es el interlocutor para las preguntas de integración y migración de datos.

Definir estos cuatro roles en la primera reunión acelera la mayoría de las fases posteriores, porque el “punto de decisión” de cada fase depende en realidad de que una de estas personas responda a tiempo.

El proceso antes que las pantallas; usuarios, datos y reglas de negocio antes que la lista de funciones.

¿Hasta dónde se llega con Excel, WhatsApp y software estándar?

En equipos pequeños, con pocos registros y reglas que cambian poco, Excel y WhatsApp funcionan bastante bien y además no requieren ningún desarrollo. El problema empieza cuando se multiplican las versiones, cuando varias personas actualizan el mismo archivo y cuando llega la pregunta “¿quién aprobó qué y cuándo?”. No se pueden separar permisos, no se puede seguir el historial y la información se queda en el teléfono de las personas. El software estándar suele ser el camino más rápido cuando su proceso es estándar; el software a medida tiene sentido cuando su diferencia real está en el proceso y adaptarlo a una herramienta hecha le da trabajo cada mes.

A veces la solución no es un software nuevo, sino simplificar el proceso. Mapear primero el flujo actual, ver el cuello de botella y decidir solo después suele dar resultados más baratos y rápidos. Una hoja de ruta de transformación digital es un paso que puede dar antes de la decisión sobre el software.

Seis errores frecuentes que frenan el proceso

  • Saltarse el análisis y pedir pantallas directamente.
  • No incluir en las reuniones a la persona que conoce el proceso.
  • No poner por escrito los criterios de aceptación.
  • Intentar meterlo todo en la primera versión; no llevar una lista para la segunda.
  • Que varias personas con poder de decisión pidan cambios sin saber unas de otras.
  • Dejar la puesta en marcha y la información a los usuarios para el último día.

¿Cómo lleva YazSis el proceso de software a medida?

YazSis organiza el trabajo de software a medida en cuatro bloques: primero se definen objetivos, usuarios, datos y reglas de negocio; después se diseñan el flujo de uso y una estructura técnica sostenible; a continuación vienen el desarrollo modular y la validación con escenarios reales; por último, el sistema se pone en marcha, se mide y se mejora con los comentarios. El alcance puede incluir aplicaciones web, paneles de administración por roles, flujos de solicitud, aprobación y asignación, aplicaciones móviles, servicios API para intercambiar datos con otros sistemas e interfaces de back office para equipos de operaciones con mucha carga. En este artículo no damos plazos ni precios; ambos se hablan junto con el alcance después del análisis.

Si no está seguro de en qué fase debería empezar su proceso, puede conocer nuestro enfoque en la página de Software a medida e iniciar una primera conversación describiendo brevemente su necesidad.

Preguntas frecuentes

¿Cuánto tarda el desarrollo de software a medida?

La duración depende del alcance, los roles de usuario, el número de integraciones y la rapidez con que usted dé sus comentarios. Por eso dar un plazo general sería engañoso; un plan realista se elabora junto con el alcance una vez terminado el análisis de necesidades.

¿Cuáles son las fases del desarrollo de software?

En general: análisis de necesidades, diseño, desarrollo, pruebas y aceptación, puesta en marcha y soporte. En cada fase se espera del cliente una aportación (por ejemplo, conocimiento del proceso o comentarios) y una decisión (alcance, aprobación del flujo, aceptación).

¿Debo elegir software estándar o software a medida?

Si su proceso se acerca al estándar del sector y sus reglas cambian poco, el software estándar suele ser el camino más rápido. Si el orden de aprobaciones, la separación de permisos o las integraciones son propios y adaptarse a una herramienta hecha le da trabajo cada mes, conviene considerar el software a medida. Mapear el proceso actual antes de decidir ayuda.

¿Qué debo llevar a la primera reunión con una empresa de software a medida?

Bastan los Excel actuales, formularios, documentos de ejemplo, una breve descripción del proceso y la respuesta a la pregunta “si este software tiene éxito, ¿qué habrá cambiado?”. No hace falta dibujar pantallas; la información sobre usuarios, datos y reglas es más valiosa.

¿Qué se hace en la fase de pruebas y aceptación?

El software se prueba con escenarios reales según criterios de aceptación escritos desde el principio. El cliente recorre el proceso de principio a fin con ejemplos cercanos a sus propios datos, incluidas excepciones y cancelaciones; cuando se cumplen los criterios, la versión se acepta.

FU
Ferhat Uğurlu · Equipo de YazSis

Desarrolla software empresarial, IA y productos de transformación digital junto con el equipo de YazSis.