Cómo es un proyecto de desarrollo de software a medida, de principio a fin

Antes de firmar, todo el mundo pregunta por el precio y el plazo. Después de firmar, la pregunta cambia: ¿y ahora qué pasa, y qué tenemos que hacer nosotros? Este artículo responde a eso. Cuenta un proyecto de desarrollo de software a medida en el orden en que ocurre, qué pone tu empresa en cada fase y qué decisiones no se pueden dejar en manos del proveedor.

Hablamos de proyectos de varios meses que tocan varias áreas de la empresa, que se tienen que integrar con lo que ya existe y en los que alguien de dentro dedica horas cada semana. Lo que conviene preguntar antes de pedir presupuesto está en qué preguntar antes de pedir presupuesto, y lo que conviene preguntar al proveedor, en preguntas antes de contratar una empresa de software. Aquí empezamos una vez firmado.

1. Análisis: los procesos y las hojas reales

Lo primero no son pantallas. Son vuestras hojas de cálculo, los correos que se reenvían, los papeles que pasan de mano en mano y las excepciones que solo conoce quien hace el trabajo. Un buen análisis se hace sentándose con esas personas, no solo con la dirección, porque lo que cuesta dinero suele estar en el detalle: el pedido que se factura en dos veces, el cliente con condiciones especiales, el paso que alguien hace a mano porque el programa actual no lo permite.

Qué pone tu empresa: una persona de referencia que conozca el negocio y pueda decidir, y acceso a quienes hacen cada tarea. También ejemplos reales: facturas, pedidos, hojas de cálculo tal como se usan hoy. Qué sale de aquí: un mapa de los procesos y una lista ordenada de lo que entra en la primera versión y lo que se deja para después.

2. El modelo de datos: las decisiones que más cuesta cambiar

Antes de construir, hay que decidir qué es cada cosa para tu empresa. ¿Un cliente puede tener varias sedes? ¿Una obra o un pedido puede repartirse entre varias sociedades? ¿Un producto tiene variantes, o cada variante es un producto? Parecen preguntas técnicas, pero son de negocio, y cambiarlas cuando el sistema ya tiene datos sale caro. Es la parte de la arquitectura que más condiciona el resto. En nuestros casos contamos cómo se tomaron estas decisiones en dos proyectos.

Qué pone tu empresa: respuestas claras a esas preguntas, pensando en cómo trabajaréis dentro de dos o tres años, no solo hoy.

3. La primera entrega, a las dos semanas

A las dos semanas tiene que haber algo funcionando. No todo, pero sí una primera parte con vuestro vocabulario y vuestros casos reales: por ejemplo, dar de alta un pedido como lo hacéis hoy y verlo en un listado. Sirve para dos cosas. Para comprobar que el análisis se entendió bien, y para que tu equipo empiece a ver el sistema como suyo y no como algo que llegará algún día.

4. Entregas cada dos semanas

A partir de ahí, el proyecto avanza en ciclos de dos semanas. Cada ciclo acaba con una demo de lo que ya funciona, y en esa demo se decide qué viene después. Las prioridades pueden cambiar entre ciclos: es normal que, al ver el sistema, aparezcan cosas que en el análisis no estaban. Lo importante es que el cambio se decida mirando el conjunto, no añadiendo piezas sin más.

En esta fase entran también las integraciones con lo que ya tenéis: la contabilidad, la tienda online, el banco, el programa de un proveedor. Cada una se trata como una entrega más, con su prueba.

Qué pone tu empresa: asistir a la demo, probar entre demos con datos reales y decidir las prioridades. Esta es la parte que más se subestima. La persona de referencia necesita horas cada semana; sin ellas, el proyecto se para o, peor, avanza en la dirección equivocada sin que nadie lo note. De qué depende el plazo total lo explicamos en cuánto se tarda en desarrollar un ERP.

5. La migración de datos

Los datos que tenéis hoy tienen que pasar al sistema nuevo: clientes, productos, histórico de pedidos, saldos. Casi siempre aparecen duplicados, campos usados para lo que no eran y registros a medio rellenar. La migración no se hace una vez: se ensaya varias, cada vez con datos más completos, hasta que el resultado cuadra.

Qué pone tu empresa: decidir qué se limpia, qué se descarta y qué histórico hace falta de verdad, y revisar que lo migrado cuadra con lo que tenéis. Los datos son vuestros y esa decisión también.

6. La puesta en marcha, en paralelo con el sistema anterior

El día del cambio no se apaga lo antiguo y se enciende lo nuevo. Lo prudente es que los dos convivan un tiempo: un área o una sede empieza con el sistema nuevo, se comparan los resultados con el anterior y, cuando cuadran, se fija la fecha en que el resto da el salto. Así la empresa no se para y los errores aparecen cuando todavía hay red.

7. La formación

La formación funciona mejor por puestos y con vuestros propios datos: cada persona aprende lo que va a usar, no un recorrido por todas las pantallas. La persona de referencia, que ha visto crecer el sistema demo a demo, se convierte en quien resuelve las dudas del día a día. Por eso conviene que sea alguien que se vaya a quedar.

8. La evolución

El software no se termina el día que arranca. Con el uso aparecen ajustes, y con el tiempo, partes nuevas: la siguiente fase que se dejó fuera de la primera versión, un informe, otra integración. Se sigue trabajando igual, en ciclos de dos semanas, con la dedicación que tenga sentido en cada momento.

Lo que no se puede delegar en el proveedor

Un buen proveedor propone, pregunta y avisa de las consecuencias. Pero hay cuatro cosas que tiene que decidir tu empresa:

• Las reglas de negocio: cómo se hace cada cosa y las excepciones.
• Las prioridades: qué va primero y qué puede esperar.
• La validación: si lo entregado sirve para trabajar o no.
• Los datos: qué se migra, qué se limpia y qué se descarta.

Cuando un proyecto a medida sale mal, casi siempre falla una de estas cuatro, no la tecnología.

Qué recibes al final

Al terminar cada fase, y no solo al final, tu empresa debería tener tres cosas a su nombre: el código, en un repositorio de vuestra cuenta desde el primer día; la documentación, para que otro equipo pueda continuar si un día hace falta; y los datos, en un formato que podáis exportar. También las cuentas de los servicios en la nube y del dominio. Por qué importa tanto lo contamos en de quién es el código de tu software.

Cómo lo hacemos en Vettra

Es el proceso que seguimos en nuestros proyectos de desarrollo de software a medida, y el tipo de proyecto más habitual es un ERP a medida o un software de gestión que conecta varias áreas. Si estás valorando uno, cuéntanos qué tenéis hoy y te diremos cómo plantearíamos las primeras semanas.