Desarrollo por módulos: por qué no construir todo de una vez

En resumen: El desarrollo por módulos consiste en partir un sistema en piezas con alcance y precio propios, y construir primero la que resuelve el dolor más urgente. Baja el riesgo de presupuesto, facilita que el equipo adopte la herramienta y permite ajustar los requisitos con uso real. La condición es diseñar desde el inicio el modelo de datos y los roles.

Cuando una empresa decide construir su propio sistema, la tentación es pedirlo completo: pedidos, inventario, despachos, cartera, compras y tableros, todo junto. Suena eficiente. En la práctica, es la forma más cara de equivocarse, porque todo el presupuesto se compromete antes de saber si el equipo va a usar lo que se construye.

¿Qué es un MVP cuando no eres una startup?

En una empresa establecida, el MVP (producto mínimo viable) es la versión más pequeña del sistema que reemplaza una parte real del proceso y que alguien usa todos los días. No es una maqueta ni una demo: es una herramienta de trabajo.

En una startup el MVP sirve para averiguar si existe un mercado. En tu empresa el mercado ya existe: el proceso se hace hoy, con Excel, WhatsApp y buena voluntad. Lo que el MVP valida es que el sistema encaja en la forma en que tu equipo trabaja. Si el término te suena ajeno, lo definimos junto con otros en el glosario de tecnología para gerentes.

La palabra clave es "viable". Un módulo a medias que obliga a seguir usando la hoja de cálculo en paralelo no es viable. Debe cubrir un proceso completo, aunque sea uno solo.

¿Qué riesgos tiene construir todo el sistema de una vez?

El riesgo principal es que todo el presupuesto queda comprometido antes de tener una sola pantalla en uso. De ahí se derivan los demás:

• Presupuesto. Si a mitad de camino la plata se acaba o las prioridades cambian, queda un sistema a medio hacer que no sirve para nada.
• Adopción. El equipo recibe un sistema grande de golpe, con diez pantallas nuevas y otra forma de trabajar. La resistencia crece cuanto más cambia todo al mismo tiempo.
• Requisitos que cambian. Lo que se definió en el mes uno puede no ser cierto en el mes seis: el negocio se movió.
• Errores que se descubren tarde. Un malentendido sobre cómo se aprueba un pedido aparece cuando el sistema entra en uso. Si eso ocurre al final, corregirlo toca muchas piezas.
• Retorno tardío. Nada ahorra tiempo hasta que todo está listo.

Criterio	Todo de una vez	Por módulos
Plata comprometida al inicio	El proyecto completo	Solo la fase 1
Primera pantalla en uso	Al final del proyecto	En las primeras semanas
Ajustes por uso real	Difíciles y caros	Parte natural de cada fase
Riesgo si algo falla	Todo el proyecto	Un módulo
Adopción del equipo	Cambio grande de golpe	Cambios graduales

¿Cómo se parte un sistema en módulos?

Un sistema se parte en módulos siguiendo los procesos del negocio, no las pantallas. Cada módulo cubre un proceso completo, se puede usar solo y tiene alcance y precio propios. Es lo que en el oficio se llama desarrollo incremental.

Los criterios que usamos para trazar los límites:

1. Cada módulo entrega valor por sí solo. Si el módulo de pedidos no sirve hasta que exista el de despachos, el límite está mal puesto.
2. Límites claros. Debe quedar escrito qué hace el módulo y qué no, para que el alcance no se estire en silencio.
3. Dependencias explícitas. Si un módulo necesita datos de otro, se dice desde el principio y se decide el orden según eso.
4. Alcance y precio propios. Así puedes decidir módulo por módulo, sin comprometerte con todo el paquete.

Así trabajamos en CodeLess Co: primero diseñamos la solución completa, después la partimos en módulos con alcance y precio propios, y tú eliges cuáles entran en la fase 1. Las entregas son cortas y funcionales, y el sistema crece cuando el negocio lo pide. Diseñar todo y construir por partes permite ver el mapa completo sin pagarlo completo, y es una de las decisiones que más influyen en el costo de desarrollar software a medida.

¿Cómo elegir qué va en la fase 1?

La fase 1 debe ser el módulo que más duele, que más se usa y del que más dependen los demás. Una forma práctica de ordenarlo es calificar cada módulo de 1 a 3 en tres criterios y multiplicar:

Prioridad = dolor x frecuencia x dependencia

• Dolor: cuánto cuesta hoy el problema en tiempo, errores o plata.
• Frecuencia: cada cuánto ocurre. Lo que pasa diez veces al día pesa más que lo que pasa una vez al mes.
• Dependencia: cuántos otros módulos necesitan sus datos. Un módulo del que todo depende conviene hacerlo temprano.

La fórmula no reemplaza el criterio del gerente, pero ordena la conversación y obliga a justificar por qué algo va primero.

Una regla adicional: si antes de la fase 1 el proceso no está claro, el primer paso no es construir. Es revisar el proceso antes de construir software.

¿Qué debe quedar diseñado desde el inicio para no rehacer?

Hay decisiones que no se pueden tomar por módulos, porque cambiarlas después obliga a rehacer lo construido. Estas quedan definidas desde el primer día, aunque la construcción vaya por partes:

• El modelo de datos. Las entidades principales (clientes, productos, pedidos, pagos) y cómo se relacionan. Si el primer módulo guarda al cliente de una forma y el tercero necesita otra, toca migrar datos a mitad de camino.
• Los roles y permisos. Quién es vendedor, bodeguero, jefe de cartera o gerente, y qué puede ver cada uno. Agregar módulos es fácil; cambiar la lógica de permisos no.
• Los catálogos maestros. Productos, clientes y bodegas con sus códigos únicos. Todos los módulos los van a usar.
• Las integraciones previstas. Aunque la conexión con la facturación electrónica llegue en la fase 3, el modelo de datos debe tenerla en cuenta desde la fase 1.
• La arquitectura y la infraestructura. Dónde corre el sistema y cómo crece, para que el costo mensual siga siendo bajo y predecible cuando lleguen más módulos.

Lo que sí puede esperar: las pantallas de los módulos futuros, los reportes detallados y las reglas de excepción que todavía nadie ha pedido.

Ejemplo: una distribuidora con seis módulos

Ejemplo hipotético: supón una distribuidora de productos de aseo con 8 vendedores en la calle, una bodega y unos 300 clientes. Hoy los pedidos llegan por WhatsApp, el inventario vive en un Excel y la cartera se revisa a mano cada viernes. El sistema completo tendría seis módulos:

Módulo	Dolor	Frecuencia	Dependencia	Prioridad	Fase
Pedidos desde el celular	3	3	3	27	1
Inventario y bodega	2	3	3	18	1
Despachos y rutas	2	3	1	6	2
Cartera y cobro	3	2	1	6	2
Compras a proveedores	2	1	1	2	3
Tablero gerencial	2	2	1	4	3

Fase 1: pedidos e inventario. Los vendedores dejan de mandar fotos por WhatsApp y registran el pedido desde el celular, viendo las existencias reales. La bodega sabe qué hay y qué está comprometido. Todo lo demás se alimenta de estos dos módulos, así que hacerlos primero es construir la base. Si te interesa esa parte, la desarrollamos en sistema de inventario a medida.

Fase 2: despachos y cartera. Empatan en puntaje, así que decide el negocio: si el problema más caro son los clientes que no pagan, cartera va antes.

Fase 3: compras y tablero. El tablero gerencial va al final a propósito: necesita datos que generan los otros módulos. Mientras tanto, un listado básico dentro del módulo de pedidos cubre lo esencial.

Con este orden, la distribuidora usa el sistema en semanas, no en trimestres, y cada fase se decide con lo aprendido en la anterior.

¿Cuándo no conviene desarrollar por módulos?

No conviene cuando el sistema es tan pequeño que partirlo solo agrega coordinación. Estos son los casos en que recomendamos otra cosa:

• Un solo proceso y pocas pantallas. Si todo cabe en una entrega corta, se construye completo y listo.
• Hay una fecha que obliga a tenerlo todo. Por ejemplo, un sistema anterior que deja de funcionar en una fecha fija. Aun así, internamente se construye y se prueba por partes.
• Los módulos no funcionan solos. Si ninguna pieza sirve sin las demás, hay que revisar cómo se partió, o aceptar que el núcleo va completo.
• Nadie va a usar la fase 1. El método necesita que el equipo adopte cada módulo al entregarlo. Si la empresa prefiere esperar a tenerlo todo, se pierde la ventaja principal.

La idea de fondo

Construir por módulos no es hacer menos: es hacer primero lo que más importa y decidir lo demás con información real. El sistema completo se diseña desde el inicio; lo que se reparte en el tiempo es la construcción y el pago. Si quieres pedir propuestas con esta lógica, te sirve la guía para cotizar un desarrollo de software y comparar propuestas, y puedes ver cómo lo aplicamos en nuestro servicio de desarrollo de software a medida.

Si quieres, te ayudamos a partir tu sistema en módulos y a elegir la fase 1. La primera conversación es gratis: cuéntanos qué te está costando tiempo.

Preguntas frecuentes

¿Cuál es la diferencia entre un MVP y un prototipo?

Un prototipo sirve para ver cómo se vería el sistema: pantallas de ejemplo, a veces sin datos reales, que ayudan a discutir el diseño. Un MVP es una versión pequeña pero funcional que el equipo usa en su trabajo diario con datos reales. El prototipo se muestra; el MVP se usa. En un proyecto a medida, el prototipo puede ser un paso previo al primer módulo.

¿Desarrollar por fases sale más caro al final?

No necesariamente. Hay algo de trabajo adicional en coordinar cada fase, pero se compensa con lo que no se construye: funciones que parecían necesarias y que el uso real mostró que sobraban. Además, cada módulo empieza a ahorrar tiempo antes. Lo que sí encarece es no diseñar desde el inicio el modelo de datos y los roles.

¿Cuánto debe durar la fase 1 de un proyecto de software?

Lo ideal es que la fase 1 se mida en semanas, no en meses. Debe ser lo bastante grande para cubrir un proceso completo y lo bastante pequeña para que el equipo la use pronto. Si la primera fase se acerca a varios meses, probablemente incluye más de un módulo y vale la pena partirla otra vez.

¿Puedo cambiar de proveedor entre una fase y otra?

Sí, siempre que el código y los datos sean tuyos y el sistema esté documentado. Por eso conviene dejar por escrito, desde la primera fase, la propiedad del código, el acceso a los repositorios y a la infraestructura, y la documentación que se entrega. Así cada fase es una decisión libre y no quedas amarrado a quien construyó la anterior.