Cómo escribir un pliego de software que sirva

En corto: un pliego de software (o pedido de presupuesto) que sirva tiene siete partes: el problema, cómo funciona hoy, las excepciones, quiénes lo usan, con qué tiene que hablar, los volúmenes y lo que no entra. Con eso, todos los proveedores cotizan el mismo proyecto y los números se pueden comparar. Si escribirlo te parece demasiado, una etapa corta de relevamiento produce el documento por el 5 a 10 % del proyecto.

Pedir tres presupuestos de software y recibir números que van de USD 6.000 a USD 25.000 no significa que dos te estén robando. Casi siempre significa que cada uno entendió un proyecto distinto, porque lo que les mandaste permitía entender tres proyectos distintos.

Un documento de pedido bien armado no es burocracia. Es lo que hace que los presupuestos se puedan comparar, y de paso lo que hace que el proyecto se pueda cumplir.

Esta guía sirve tanto para pedir presupuesto a una software factory como para ordenar un pedido interno o una compra en una empresa grande. Lo que cambia es el nivel de detalle, no la lógica. Si querés ver el número que suele salir de un pliego bien armado, mirá cuánto cuesta un software a medida en Argentina.

Lo que no sirve

Una lista de funcionalidades sueltas. "Login, ABM de clientes, reportes, app móvil." Cada ítem admite diez interpretaciones de tamaño.

Un documento de cuarenta páginas escrito por alguien que no hace el trabajo. Largo no es preciso.

Copiar un pliego de otra empresa o de una plantilla genérica. Una plantilla sirve de índice, no de contenido: si las secciones están llenas de frases generales, el proveedor no aprende nada de tu operación.

Una descripción del sistema que querés. Suena raro, pero describir la solución antes que el problema es lo que hace que termines pagando por algo que no era necesario. Vos conocés tu operación; el proveedor conoce las formas de resolverla.

Lo que sí sirve, en siete partes

1. El problema, en un párrafo

Qué duele hoy, en términos de negocio. No "necesitamos un sistema de gestión", sino "tres personas dedican la mañana del lunes a consolidar planillas y los números igual no cierran".

Esto orienta todo lo demás y a veces produce la mejor sorpresa: un proveedor honesto puede decirte que tu problema se resuelve con algo mucho más barato.

2. Cómo funciona hoy

El circuito real, paso a paso, desde que entra un pedido hasta que se cobra. Quién hace cada paso, qué documento se genera, dónde se traba.

Escribilo con la gente que hace el trabajo, no con quien lo supervisa. Salen distinto y el bueno es el primero.

3. Las excepciones

Esta es la parte que más plata define y la que casi nunca se escribe.

El cliente que factura distinto. El descuento que autoriza sólo el dueño. El producto que se vende por peso pero se stockea por unidad. La sucursal que trabaja con otro circuito.

Las excepciones son el 40% del trabajo de un desarrollo. Un presupuesto que no las contempla es un presupuesto que va a crecer, y la discusión de si estaban o no incluidas va a ser desagradable para todos.

4. Quiénes lo usan y qué ve cada uno

La lista de roles y, por cada uno, qué puede ver y qué puede hacer. Los permisos son de las cosas que más crecen sin que se note.

5. Con qué tiene que hablar

Los sistemas con los que tiene que integrarse, y qué ofrece cada uno: API documentada, base accesible, o nada. Es el dato que más mueve el número y el que el proveedor no puede averiguar solo.

6. Los volúmenes

Cuántos usuarios simultáneos, cuántos registros hoy, cuánto crece por año, cuántas transacciones por día. Y los picos: si en fin de mes se multiplica por diez, decilo.

7. Lo que NO entra

Una lista explícita de lo que queda afuera de esta etapa. Es contraintuitivo y es la sección más útil del documento: evita que cada proveedor cotice un alcance distinto por las dudas.

Un ejemplo de pliego, resumido

Para ver cómo baja esto a la práctica, este es un ejemplo hipotético, no un cliente real: una distribuidora mayorista que hoy toma pedidos por WhatsApp y los carga en planillas.

1. Problema: dos personas pasan la mañana pasando pedidos de mensajes a una planilla; se pierden pedidos y el stock no coincide con el depósito.
2. Cómo funciona hoy: el vendedor manda el pedido por WhatsApp; administración lo carga; el depósito lo prepara con una lista impresa; se factura al final del día; la cobranza se anota en otra planilla.
3. Excepciones: hay clientes con lista de precios propia; algunos productos se venden por caja pero se stockean por unidad; los descuentos mayores al 10 % los autoriza el dueño; una sucursal factura desde otro punto de venta.
4. Usuarios: vendedores (cargan y ven sus pedidos), administración (todo), depósito (solo preparación), dueño (reportes y autorizaciones).
5. Integraciones: facturación electrónica con ARCA; envío de comprobantes por WhatsApp; exportación de cobranzas al estudio contable.
6. Volúmenes: 15 usuarios, 3.000 productos, 400 pedidos por día, con picos del triple a fin de mes.
7. Queda afuera de esta etapa: compras a proveedores, app de reparto y tienda en línea.

Con una página así, tres proveedores cotizan prácticamente el mismo proyecto. Más detalle de los módulos que incluye este tipo de sistema en sistema de gestión para distribuidoras y mayoristas.

Cómo adaptar el pliego según el rubro

Cada operación tiene preguntas propias que el pliego tiene que contestar. Algunos ejemplos de lo que suele faltar:

Para cada una hay una guía de módulos y alcance típico: software para clínicas, software para constructoras, software para inmobiliarias, software para empresas de logística y software para estudios contables.

Qué cambia si lo que pedís es un agente de IA

Si el pedido es un agente de inteligencia artificial y no un sistema tradicional, el pliego suma otras preguntas, porque el comportamiento no se define con pantallas sino con casos:

• Qué tareas tiene que resolver solo y cuáles debe derivar a una persona.
• De dónde saca la información: documentos, base de datos, preguntas frecuentes, y quién la mantiene actualizada.
• Ejemplos reales de consultas, incluidas las difíciles y las que no debería contestar.
• Por qué canal atiende: WhatsApp, web, correo.
• Cómo se mide que anda bien: porcentaje resuelto sin intervención, tiempos de respuesta, errores que se detectan.

Más sobre esto en la página de agentes de IA y en agentes de IA para empresas que automatizan de verdad.

Lo que hay que pedir que te devuelvan

Para poder comparar, pedí que todos respondan con la misma estructura:

• Alcance entendido, escrito con sus palabras. Si no coincide con lo que quisiste decir, lo descubrís antes y no en el mes dos.
• Precio desglosado: desarrollo, migración, capacitación, infraestructura, mantenimiento del primer año.
• Plazo con entregas intermedias, no una sola fecha final.
• Qué necesitan de vos y cuándo: decisiones, datos, accesos, gente para probar.
• Qué queda explícitamente afuera.
• Modelo de contratación y qué pasa con los cambios de alcance.
• Propiedad del código y de las cuentas.

Ese último punto ponelo por escrito desde el pedido. Es mucho más fácil acordarlo antes de que exista una relación comercial que después.

Cómo comparar las propuestas que te llegan

Con un pliego igual para todos, se puede armar una tabla de comparación. Una forma simple es asignar un peso a cada criterio según lo que más te importa:

Los pesos son una sugerencia: ajustalos a tu caso. Lo importante es decidirlos antes de abrir las propuestas, para no reacomodarlos según quién te cayó mejor. Para la parte de elegir a quién pedirle presupuesto, la guía de cómo elegir una software factory: 12 preguntas tiene el listado de preguntas, y para decidir entre las opciones de contratación está precio cerrado o por hora.

Cuántos proveedores consultar y cómo

Entre dos y cuatro es un número razonable. Menos de dos no te permite comparar y más de cuatro te lleva más tiempo del que ahorra. Algunos criterios prácticos:

1. Enviá el mismo documento a todos, con la misma fecha de respuesta.
2. Ofrecé una reunión de preguntas abierta a todos o igual para cada uno, para que ninguno tenga información que los otros no.
3. Pedí referencias que puedas llamar, no solo capturas de pantalla.
4. Considerá la demo. Ver algo funcionando sobre tu caso dice más que una presentación. En Atomix ofrecemos una demo gratis en 24 a 48 horas, antes de cotizar.
5. Firmá un acuerdo de confidencialidad si el pliego incluye información sensible de la operación.

Errores comunes al escribir el pedido

• Escribirlo en términos técnicos. Si decís "necesito una API REST con microservicios", estás eligiendo la solución antes de que alguien entienda el problema.
• No incluir al usuario final. Quien va a usar el sistema todos los días suele ver excepciones que el gerente no ve.
• Dar un presupuesto máximo y ocultarlo, o al revés, revelarlo antes de cotizar. Lo más útil suele ser dar un orden de magnitud: permite que cada proveedor proponga un alcance realista para ese rango.
• Pedir todo para la primera versión. Separá lo imprescindible de lo deseable; lo segundo va a la etapa dos.
• No decir quién decide. Un pliego sin un interlocutor con autoridad genera propuestas que después se frenan en las decisiones, como se explica en cuánto tarda un desarrollo de software.
• Ignorar los datos existentes. Cuántos hay, en qué formato y quién los limpia. Es parte del alcance; ver cómo migrar datos a un sistema nuevo.

Lista de control antes de enviar el pliego

1. ¿Una persona que hace el trabajo leyó el circuito actual y lo corrigió?
2. ¿Están escritas al menos cinco excepciones reales?
3. ¿Cada rol tiene qué ve y qué puede hacer?
4. ¿Figuran los sistemas externos y qué ofrece cada uno?
5. ¿Hay volúmenes y picos?
6. ¿Hay una lista explícita de lo que no entra?
7. ¿Está definido quién decide de tu lado y con cuántas horas por semana?
8. ¿Pediste que todos respondan con la misma estructura?

Un atajo que funciona muy bien

Si escribir todo esto te parece mucho —y para muchas empresas lo es—, hay un camino mejor que mandar algo incompleto: pagá una etapa corta de relevamiento.

Un proveedor dedica una o dos semanas a entender tu operación y produce el documento de alcance con pantallas, reglas y criterios de aceptación. Suele costar entre el 5% y el 10% del proyecto.

Lo importante es esto: ese documento es tuyo, y sirve para pedirle presupuesto a otros tres proveedores sobre exactamente la misma base. Acordalo así desde el principio.

Las señales de que el presupuesto que recibiste no sirve

• Un número redondo sin desglose.
• No menciona nada de tus excepciones, lo que significa que no las leyó o no las contempló.
• No dice qué necesita de vos. Todo proyecto necesita cosas del cliente; el que no las lista va a reclamarlas tarde.
• Coincide sospechosamente con tu presupuesto en vez de con tu alcance.
• Es mucho más barato que los otros dos sin una explicación de por qué. A veces es eficiencia real; a veces es que entendió menos y lo vas a descubrir después.

Preguntas frecuentes

¿Por qué los presupuestos de software son tan distintos entre sí?

Casi siempre porque cada proveedor entendió un proyecto distinto, no porque dos te estén robando. Lo que les mandaste permitía entender tres proyectos distintos, y por eso los números pueden ir de USD 6.000 a USD 25.000. Un documento de pedido bien armado es lo que hace que los presupuestos se puedan comparar.

¿Qué tiene que incluir un pliego de software?

Siete partes: el problema en un párrafo, cómo funciona hoy, las excepciones, quiénes lo usan, con qué tiene que hablar, los volúmenes y lo que no entra. Las excepciones son la parte que más plata define y la que casi nunca se escribe. Evitá la lista de funcionalidades sueltas y describí el problema antes que la solución.

¿Qué le tengo que pedir al proveedor que me devuelva?

Pedí que todos respondan con la misma estructura: el alcance entendido con sus palabras, un precio desglosado y un plazo con entregas intermedias. También qué necesitan de vos y cuándo, qué queda afuera, el modelo de contratación y la propiedad del código y de las cuentas. Así podés comparar respuestas que de otro modo no se parecerían.

¿Qué hago si escribir un pliego me parece demasiado?

Pagá una etapa corta de relevamiento. Un proveedor dedica una o dos semanas a entender tu operación y produce el documento de alcance con pantallas, reglas y criterios de aceptación, y suele costar entre el 5% y el 10% del proyecto. Ese documento es tuyo y sirve para pedirle presupuesto a otros tres proveedores sobre la misma base.

¿Cómo sé que un presupuesto no sirve?

Es una mala señal un número redondo sin desglose, que no mencione tus excepciones y que no diga qué necesita de vos. También que coincida sospechosamente con tu presupuesto en vez de con tu alcance, o que sea mucho más barato que los otros dos sin explicar por qué.

¿Cuánto tiene que medir un pliego de software?

No hay un largo ideal. Para un sistema de gestión de pyme, entre tres y diez páginas bien escritas suelen alcanzar. Lo que importa es que contenga el circuito real, las excepciones, los roles, las integraciones y los volúmenes, no que sea largo.

¿Es lo mismo un pliego que un documento de requerimientos?

Se parecen, pero no son iguales. El pliego es el pedido que envías a los proveedores para que coticen. El documento de requerimientos o de alcance es más detallado, con pantallas, reglas y criterios de aceptación, y suele resultar de una etapa de relevamiento.

¿Conviene decirle al proveedor cuánto presupuesto tengo?

Conviene dar un orden de magnitud. Así cada proveedor propone un alcance realista para ese rango y evitás recibir propuestas que no son comparables. Ocultarlo suele producir cotizaciones muy dispares.

¿Cuántos presupuestos hay que pedir?

Entre dos y cuatro. Con menos no hay comparación y con más, el tiempo que lleva evaluarlos supera lo que ahorrás. Importa más que todos respondan al mismo documento que cuántos sean.

Si preferís no escribirlo solo, en desarrollo de software a medida armamos el alcance con vos antes de cotizar; pedí una demo gratis en 24 horas o agendá una llamada.