El proceso de desarrollo de software es el conjunto de etapas por las que pasa un proyecto, desde la primera plática hasta el sistema que tu equipo usa todos los días. En un software a la medida para un negocio, las etapas del desarrollo de software suelen ser: descubrimiento y requerimientos, alcance y cotización, diseño UX/UI, arquitectura, desarrollo en ciclos cortos, pruebas, lanzamiento, capacitación y mantenimiento. Cada etapa te entrega algo que puedes revisar, y cada una te pide algo a cambio: tiempo, decisiones, datos o comentarios. Si sabes qué viene, lo puedes planear, y eso es casi todo lo que mantiene un proyecto a tiempo y dentro del presupuesto.
¿Cuáles son las etapas del desarrollo de software?
Los ingenieros le llaman ciclo de vida del desarrollo de software, o SDLC por sus siglas en inglés. Cada equipo le pone nombres distintos a los pasos, pero el trabajo es el mismo. La tabla muestra cada etapa desde tu lado como cliente: qué pasa, qué aportas tú y qué recibes. Los porcentajes de tiempo son una guía aproximada para un sistema de negocio típico, no una regla. Los proyectos con muchas integraciones o con una migración de datos grande mueven el equilibrio.
| Etapa | Qué pasa | Qué aportas tú | Qué recibes | Parte típica del tiempo (guía aproximada) |
|---|---|---|---|---|
| 1. Descubrimiento y requerimientos | Entrevistas con quienes van a usar el sistema, revisión de los Excel, formatos y herramientas que usas hoy, y una lista de los problemas a resolver | Acceso a las personas correctas, ejemplos de tus documentos y reportes actuales, tus objetivos y tus límites | Un resumen de requerimientos: usuarios, roles, flujos principales, integraciones y prioridades | Alrededor de 5 a 10% |
| 2. Alcance y cotización | Los requerimientos se convierten en una lista de pantallas, roles, integraciones y reportes, dividida en fases, con tiempos y costo | Decidir qué entra en la primera versión y qué puede esperar | Un alcance por escrito, un calendario y una cotización | Alrededor de 5% |
| 3. Diseño UX/UI y prototipo | El diseño de las pantallas y un prototipo navegable de los flujos principales | Comentarios de usuarios reales y tu visto bueno en las pantallas clave | Wireframes o maquetas y un prototipo en el que puedes dar clic | Alrededor de 10 a 15% |
| 4. Arquitectura y tecnología | Diseño de la base de datos, hospedaje, seguridad y cómo se va a conectar cada integración | Accesos o contactos de los sistemas a conectar, como tu PAC, tu sistema contable o WhatsApp, y cualquier regla de TI o de cumplimiento | Un plan técnico corto y en lenguaje claro: tecnología, hospedaje, dónde viven los datos y a nombre de quién quedan las cuentas | Alrededor de 5% |
| 5. Desarrollo por ciclos | Las funciones se construyen en ciclos cortos, normalmente de una a dos semanas, con una demostración al final de cada uno | Asistir a las demostraciones, responder dudas rápido y probar las primeras versiones | Software funcionando que puedes ver y usar, entrega por entrega | Alrededor de 40 a 50% |
| 6. Pruebas y control de calidad | Pruebas de funciones, roles, casos raros y dispositivos, y luego pruebas de aceptación con tu equipo | Tiempo de tu equipo para probar casos reales y reportar fallas | Fallas corregidas y una versión aprobada para salir | Alrededor de 10 a 15%, buena parte durante el desarrollo |
| 7. Lanzamiento | Configuración del servidor de producción, migración de datos, revisiones finales y salida en vivo | Datos limpios para importar y una fecha de arranque que le acomode a tu operación | El sistema en vivo, con cuentas y accesos a tu nombre | Alrededor de 5% |
| 8. Capacitación y adopción | Sesiones de capacitación, guías cortas y acompañamiento cercano en las primeras semanas | Tiempo de tu personal para aprender y una persona interna que impulse el cambio | Usuarios capacitados y documentación | Alrededor de 5% |
| 9. Mantenimiento y mejora continua | Actualizaciones de seguridad, corrección de errores y nuevas funciones según el uso real | Comentarios y una lista de lo que quieres mejorar después | Un sistema que sigue el paso de tu negocio | Continuo después del lanzamiento |
Fíjate que programar es apenas la mitad del esfuerzo, más o menos. Las etapas de antes deciden si se construye lo correcto, y las de después deciden si la gente de verdad lo usa.
¿Qué etapas suelen subestimar los dueños de negocio?
Casi todos esperan la parte de programación. Estas son las etapas que más los sorprenden:
- Descubrimiento. Puede sentirse como pura plática y nada de avance. Pero una función mal entendida aquí se corrige con una conversación, y la misma función mal entendida después del desarrollo se corrige rehaciendo trabajo. Invita a las personas que hacen el trabajo, no solo a los gerentes que lo describen.
- Diseño y prototipo. Un prototipo navegable es el lugar más barato para cambiar de opinión. Mover un botón o reordenar un flujo toma minutos en un prototipo y días en código terminado. Recórrelo con algunos usuarios reales antes de aprobarlo.
- Pruebas de aceptación. El equipo de desarrollo prueba que el software funcione. Solo tu equipo puede confirmar que funciona para tu negocio: el cliente que siempre pide algo distinto, la excepción a la regla, el reporte que tu contador necesita al cierre de mes o la factura con complemento de pago. Aparta tiempo en las agendas para hacerlo.
- Migración de datos y capacitación. Años de registros en Excel casi nunca se importan limpios. Duplicados, campos vacíos y nombres escritos de mil formas hay que limpiarlos, y alguien de tu lado tiene que decidir qué dato es el correcto. La capacitación importa igual: un sistema en el que la gente no confía termina funcionando junto al Excel de siempre en lugar de reemplazarlo.
Metodología ágil vs cascada: ¿cuál conviene a una pyme?
Son las dos formas clásicas de organizar las etapas. En cascada (waterfall), cada etapa se termina y se aprueba antes de empezar la siguiente: primero todos los requerimientos, luego todo el diseño, luego todo el desarrollo y al final las pruebas. En ágil (agile), el equipo trabaja en ciclos cortos llamados sprints, y cada ciclo entrega una pieza pequeña de software funcionando que tú revisas antes de planear el siguiente.
| Enfoque | Cómo funciona | Funciona bien cuando | Cuidado con |
|---|---|---|---|
| Cascada | Etapas en secuencia, con una aprobación en cada paso | Los requerimientos son estables y se conocen bien, como al reemplazar un sistema conocido o seguir reglas fijas | Ves software funcionando muy tarde, y los cambios después de aprobar salen caros |
| Ágil | Ciclos cortos, con una demostración y nuevas prioridades después de cada uno | Las necesidades se van a aclarar cuando la gente use el software | Sin un alcance y un presupuesto por escrito, el proyecto se puede ir alargando |
| Híbrido | Alcance y cotización por escrito desde el inicio, y después construir y revisar en ciclos cortos | La mayoría de los proyectos de pequeñas y medianas empresas | Necesita un proceso claro de solicitudes de cambio para que los ciclos no vayan creciendo el alcance sin que nadie lo note |
Para la mayoría de las pymes, el esquema híbrido es la respuesta práctica. Necesitas un alcance por escrito y una cifra que puedas presupuestar, que es la fortaleza de la cascada. También necesitas ver el software pronto y ajustarlo con los comentarios de tu equipo, que es la fortaleza de lo ágil. Un esquema ágil abierto, sin presupuesto fijo, le queda mejor a una empresa de producto con su propio equipo de desarrollo que a un negocio que encarga un sistema.
¿Quién participa en un proyecto de software?
En un proyecto pequeño, una misma persona puede cubrir varios de estos roles. Lo importante es que cada responsabilidad tenga dueño.
- Quien toma las decisiones. Tú, o una persona que tú designes. Aprueba el alcance, define prioridades y da el visto bueno en cada etapa. En los equipos ágiles a este rol se le llama product owner.
- Usuarios clave. Las personas que hoy hacen el trabajo. Explican cómo es el proceso de verdad y prueban el resultado.
- Líder de proyecto. Planea los ciclos, dirige las demostraciones, cuida el alcance y el presupuesto, y es tu contacto principal.
- Diseñador UX/UI. Convierte los flujos de trabajo en pantallas y arma el prototipo.
- Desarrolladores. Los de front-end construyen lo que ven los usuarios. Los de back-end construyen la base de datos, las reglas del negocio y las integraciones.
- Tester o QA. Revisa funciones, roles y casos raros antes de que los vea tu equipo.
- Hospedaje y DevOps. Configura servidores, publicaciones, respaldos y monitoreo. En equipos pequeños, normalmente lo resuelven los desarrolladores de back-end.
¿Cómo evitar que un proyecto de software se retrase?
La mayoría de las palancas están de tu lado, y no cuestan nada:
- Nombra a una sola persona que decida. Cuando tres gerentes dan comentarios que se contradicen, el equipo se detiene o adivina. Una persona junta las opiniones dentro de tu empresa y da una sola respuesta.
- Pon el alcance por escrito. Pantallas, roles, integraciones, reportes y lo que de plano queda fuera de la primera versión. Si no está escrito, cada lado lo va a recordar distinto.
- Asiste a las demostraciones. Una revisión corta cada una o dos semanas detecta malentendidos cuando todavía es barato corregirlos. Saltarse demostraciones es como los huecos pequeños se vuelven grandes.
- Usa solicitudes de cambio. Las ideas nuevas son normales y muchas veces buenas. Anota cada una, pide un estimado de tiempo y costo, y decide si entra ahora, después o nunca. Así los cambios quedan a la vista en lugar de estirar el calendario sin que nadie lo note.
- Responde rápido. Una duda que espera una semana puede frenar un ciclo completo. Acuerden tiempos de respuesta de los dos lados.
- Protege la primera versión. Lanza primero el flujo principal. Un sistema más chico que se usa todos los días vale más que uno grande que siempre está casi listo.
El contrato debe respaldar todo esto. Nuestra guía sobre el contrato de desarrollo de software explica el documento de alcance, la aceptación, las solicitudes de cambio y quién es dueño del código.
¿Por qué fracasan los proyectos de software?
Casi nunca por el lenguaje de programación. Las causas de siempre tienen que ver con personas y procesos:
- Requerimientos vagos. "Un CRM como los grandes, pero más sencillo" es una idea, no un alcance.
- Saltarse el descubrimiento para ahorrar. El ahorro regresa en forma de retrabajo.
- Cambios sin proceso. Cada agregado pequeño parece inofensivo. Juntos pueden duplicar el trabajo.
- Nadie que decida, o alguien que decide pero no tiene tiempo para el proyecto.
- Comentarios solo al final. Ver el software por primera vez en el lanzamiento es demasiado tarde para cambiarlo sin que cueste.
- Datos e integraciones subestimados. Los datos desordenados y los sistemas sin documentación son donde los tiempos se escapan. En México, la facturación CFDI y las conexiones con WhatsApp merecen atención desde el alcance.
- Sin plan de adopción. Sin capacitación ni acompañamiento, la gente regresa poco a poco a la forma de antes.
- Sin plan después del lanzamiento. Un software sin mantenimiento se va descomponiendo conforme cambian los navegadores, las librerías y los servicios con los que se conecta.
¿Cuánto tiempo toma el proceso de desarrollo de software?
Depende del alcance, no del proceso en sí. Como guía general de mercado, una herramienta interna o un MVP enfocado suele tomar de 2 a 4 meses, una plataforma de negocio como un portal de clientes o un CRM a la medida de 4 a 8 meses, y un sistema complejo más tiempo, normalmente entregado por fases. Nuestra guía sobre cuánto cuesta un software a la medida explica qué mueve el tiempo y el presupuesto. Si todavía no sabes si necesitas un sistema o solo una mejor página, lee primero la diferencia entre página web y aplicación web. Y si lo que necesitas es un CRM, nuestra guía de CRM a la medida entra más a detalle.
¿Cómo trabaja inSpace un proyecto de software a la medida?
Desarrollamos software desde 2005, en español y en inglés, para negocios en México y Texas. Nuestro proceso tiene cuatro pasos que se acomodan sobre las etapas de arriba:
- Llamada de diagnóstico. Una llamada gratis de 30 minutos para entender cómo trabaja hoy tu equipo y qué lo frena.
- Plan y cotización por escrito. Pantallas, roles de usuario, integraciones y tiempos por escrito, con una cotización fija.
- Desarrollo por etapas cortas. Ves el software funcionando mientras se construye, y la opinión de tu equipo le da forma.
- Lanzamiento y soporte. Capacitamos a tu equipo, alojamos y mantenemos el sistema, y seguimos agregando lo que necesites.
Ese es el proceso detrás de sistemas como la plataforma de operaciones de vuelo SATA, el portal de facturación TAR con CFDI 4.0, el software de administración de yates Navis, el CRM de HAAB y Superior Safety OS, un CRM con portal de clientes. Puedes ver más en nuestros proyectos o conocer nuestro servicio de desarrollo de software a la medida. Cuando estés listo, agenda una llamada gratuita de 30 minutos y cuéntanos qué quieres construir. Te explicamos cómo se vería cada etapa en tu proyecto.