El problema, no las pantallas

Para solicitar una propuesta no es necesario llegar con la solución diseñada. Lo que más me ayuda es saber quién utilizará el sistema, cómo se realiza hoy ese trabajo y qué resultado se espera. «Necesitamos asignar automáticamente cada incidencia al técnico disponible más adecuado» aporta mucha más información que «queremos un panel moderno».

También necesito saber con qué sistemas trabajáis y dónde está hoy la información. Si existe un documento o una herramienta interna con la que el equipo gestiona el proceso, conviene verlo, con datos anonimizados si es necesario. Ahí suelen estar las reglas de negocio que nadie ha documentado.

La idea, en práctica

Prepara una conversación concreta

Marca lo que ya sabes. El resumen distingue lo definido de lo pendiente.

  1. 01Trabajo actual
  2. 02Alcance inicial
  3. 03Criterio de entrega

¿Qué tienes ya definido?

Separar lo imprescindible de lo que puede esperar

Recomiendo empezar por una lista breve de lo que la primera versión debe resolver y dejar el resto para fases posteriores: quién accede y qué ve cada perfil, qué operaciones se realizan a diario, con qué sistemas debe integrarse y si hay datos que migrar. Si existe una fecha determinante, conviene explicar el motivo, porque puede cambiar el orden en que se construyen las cosas.

Con esa lista, todos los proveedores a los que pidas propuesta valoran el mismo proyecto. Sin ella, cada uno imagina un sistema distinto y las propuestas no son comparables.

Qué revisaría en una propuesta

El precio, por sí solo, dice poco. Revisaría si la propuesta explica qué hará el sistema y cómo se comprobará que funciona antes de darlo por aceptado. También qué documentación se entrega, cómo se pone en producción y cuánto tiempo necesitará tu equipo para pruebas y validación.

Conviene dejar claro desde el principio quién es propietario del código, qué licencias intervienen y cómo se realizará el mantenimiento. Hay que sumar los costes mensuales de infraestructura, uso de modelos de IA y servicios externos, y preguntar cómo se presupuestarán los cambios posteriores, que siempre llegan.

Cuando antes conviene una fase de análisis

En algunos proyectos no es posible dar una cifra fiable de entrada: por ejemplo, cuando hay que integrarse con un sistema heredado poco documentado o migrar datos que nadie ha analizado a fondo. En esos casos propongo una fase de análisis acotada, con un alcance y un entregable definidos, en lugar de una estimación sin fundamento. La mayoría de proyectos no la necesitan.

En cualquier caso, la primera reunión debe terminar con un siguiente paso claro: preparar la propuesta o reunir la información que falta.

Si estás valorando un proyecto de IA o una aplicación a medida, aquí explico cómo trabajo o agendamos una reunión y lo analizamos con tu caso.