Llegar a una reunión con un proveedor de software sin la información adecuada alarga los plazos, infla los presupuestos y multiplica los malentendidos. Esto es lo que conviene tener listo antes de la primera llamada.
La primera conversación con una empresa de software suele ser un momento de optimismo. Hay una necesidad, hay una idea de lo que se quiere construir, y hay un proveedor que escucha y toma notas. Pero esa misma conversación, cuando se repite con tres o cuatro proveedores distintos, produce cotizaciones que pueden variar en un factor de tres o cuatro veces. Y la diferencia no siempre está en la calidad del proveedor: muchas veces está en la información que el cliente llevó —o no llevó— a la mesa.
Preparar ciertos elementos antes de la primera llamada no solo acorta el ciclo de cotización. Reduce los malentendidos, limita los supuestos que cada proveedor va a tener que hacer por su cuenta y aumenta la probabilidad de que el presupuesto que recibas refleje lo que realmente necesitás, no lo que el proveedor supuso que necesitabas.
La información más importante que podés llevar a una reunión con un proveedor de software no es una lista de funcionalidades. Es una descripción clara y concreta del problema que querés resolver.
Hay una diferencia enorme entre decir "necesito una app con login, dashboard, notificaciones push e integración con Mercado Pago" y decir "tengo un negocio de servicios a domicilio y necesito que mis clientes puedan agendar, pagar y recibir confirmación sin que nadie de mi equipo tenga que estar coordinando por teléfono". La primera frase limita al proveedor a ejecutar una solución que vos ya diseñaste, sin saber si es la más adecuada. La segunda le permite proponer alternativas que quizás no habías considerado.
Describí el problema en un párrafo. Después, en otro párrafo, describí qué pasaría si ese problema no se resuelve. Si no podés escribir esos dos párrafos sin mencionar tecnología, el problema todavía no está lo suficientemente claro.
Definir el perfil de los usuarios es tan importante como definir el problema. No es lo mismo construir para un equipo interno de cinco personas que usan la herramienta ocho horas por día en una oficina, que para clientes externos que entran una vez por mes desde el celular mientras hacen otra cosa.
La información útil incluye: cuántas personas van a usar el producto, con qué frecuencia, desde qué dispositivos, en qué contexto (oficina, calle, casa), con qué nivel de familiaridad tecnológica, y si necesitan usar el producto de manera colaborativa o individual. También conviene aclarar si hay distintos tipos de usuarios con distintos permisos o necesidades.
Esta información le permite al proveedor tomar decisiones de arquitectura, diseño de interfaz y tecnología que impactan directamente en el costo. Un sistema para diez usuarios internos no se construye igual que uno para diez mil clientes. Si el proveedor no tiene esta información, va a asumir lo más simple —y después los cambios van a costar caros.
Si el producto que estás encargando va a reemplazar o mejorar un proceso que ya existe —aunque sea manual—, documentar ese proceso actual es una de las piezas de información más valiosas que podés llevar.
No hace falta un diagrama de flujo profesional. Alcanza con describir los pasos que sigue el proceso hoy, quién ejecuta cada paso, qué herramientas usa (planilla, WhatsApp, papel, sistema antiguo), y —esto es lo más revelador— dónde están los puntos de fricción: dónde se demora, dónde se pierde información, dónde se cometen errores, dónde los clientes se quejan.
Esta información ayuda al proveedor a entender no solo qué hay que construir, sino qué hay que mejorar. Y le da contexto para proponer simplificaciones que quizás no se te habían ocurrido. Como se explica en cómo detectar procesos digitalizables en tu empresa, muchas veces el mayor valor no está en digitalizar el proceso completo sino en automatizar los puntos específicos donde se concentran los errores y las demoras.
Pocas empresas arrancan de cero. La mayoría ya tiene algo: un Excel, un sistema de facturación, una base de clientes en algún lado, un sitio web, una herramienta de email marketing. Saber qué existe, dónde están los datos y en qué formato es información crítica para el proveedor.
Si el producto nuevo necesita consumir datos que ya existen, el proveedor va a necesitar saber cómo acceder a esos datos (API, archivo plano, base de datos compartida) y en qué estado están (estructurados, normalizados, actualizados). Si los datos existentes están desordenados o incompletos, el proyecto va a incluir una etapa de limpieza y ordenamiento que tiene costo y plazo. Es mejor saberlo antes de recibir la cotización que descubrirlo cuando el desarrollo ya empezó.
También conviene aclarar si hay restricciones técnicas. Por ejemplo, si la empresa ya tiene contratado un servidor o un servicio cloud que quiere seguir usando, o si hay políticas internas que obligan a usar ciertas tecnologías o a evitar otras.
Un proveedor de software necesita entender qué significa "éxito" para vos. No en términos técnicos, sino en términos de negocio: ¿cuánto tiempo debería ahorrar el equipo? ¿Cuántos errores deberían reducirse? ¿Cuántos clientes más deberían poder atenderse? ¿A partir de qué momento considerarías que la inversión se pagó?
Esta información no solo ayuda al proveedor a dimensionar el proyecto. También te obliga a vos a definir expectativas concretas. Un proyecto que no tiene métricas de éxito definidas desde el principio es muy difícil de evaluar después. Todo el mundo va a tener una opinión sobre si "funciona" o no, pero sin una medición objetiva, esas opiniones van a estar basadas en percepciones, no en datos.
Elegí tres métricas que te gustaría ver mejorar como resultado de este desarrollo. Pueden ser tiempo de respuesta a clientes, cantidad de errores en pedidos, horas del equipo dedicadas a tareas repetitivas. Cualquier proveedor serio va a agradecer tener ese punto de partida.
Hablar de plata en la primera reunión incomoda, pero evitarlo es peor. Si el proveedor no tiene una referencia de presupuesto, va a diseñar una solución sin restricciones y la cotización puede venir muy por encima o muy por debajo de lo que podés pagar. En cualquier caso, vas a tener que pedir ajustes, y cada ajuste consume tiempo y desgasta la relación antes de que empiece.
No hace falta dar una cifra exacta. Alcanza con un rango: "estamos evaluando invertir entre X e Y en esta etapa". Con ese dato, el proveedor puede decirte si el alcance que tenés en mente entra en ese rango o si hay que recortar. Y si no entra, es mejor saberlo en la primera llamada que después de dos semanas de idas y vueltas.
También conviene mencionar restricciones no presupuestarias: plazos que no se pueden mover, dependencias con otros proyectos, períodos del año en los que el equipo no va a estar disponible para dar feedback. Todo lo que limite la ejecución debería estar sobre la mesa desde el día uno.
Preparar información para el proveedor no significa pretender que tenés todas las respuestas. Al contrario: ser honesto sobre lo que no sabés es una de las señales más útiles que le podés dar a un proveedor. Le permite identificar las áreas donde va a necesitar ayudarte a definir, y evita que haga supuestos que después resultan incorrectos.
Una buena práctica es llevar una lista corta de preguntas abiertas: cosas que el equipo no ha podido resolver internamente y sobre las que esperás que el proveedor aporte criterio. Pueden ser preguntas técnicas, de experiencia de usuario o de alcance. El proveedor que se toma el tiempo de responder esas preguntas con honestidad —incluso cuando la respuesta es "esto es más complejo de lo que parece"— es el que probablemente querés tener del otro lado de la mesa.
Preparar esta información antes de la primera conversación con una empresa de software no garantiza una cotización perfecta, pero reduce drásticamente la distancia entre lo que pedís y lo que recibís. Y si después de leer esto te quedan dudas sobre cómo elegir al proveedor adecuado, el artículo sobre cómo elegir una empresa de desarrollo de software profundiza en los criterios que conviene aplicar para tomar esa decisión.
¿Quieres evaluar cómo aplicar esto a tu proyecto?
Cuéntanos tu caso →