Cómo escribir un pliego de software que sirva

Recibir presupuestos de USD 6.000 y de USD 40.000 no significa que alguien te esté robando: significa que cada uno entendió un proyecto distinto. Las siete partes de un pedido que se puede comparar.

Guías de compraBruno Ergang
GUÍAS DE COMPRA
En esta nota (12 secciones)

Pedir tres presupuestos de software y recibir números que van de USD 6.000 a USD 40.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.

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.

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.

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.

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.