Consultoras de software: del problema operativo al primer piloto

Una consultora de software ayuda a convertir una necesidad operativa en una solución digital: entiende el proceso, delimita qué debería cambiar y organiza un entregable que se pueda revisar. Según el caso, el trabajo puede involucrar una web o ecommerce, una app, un SaaS o MVP, sistemas e integraciones, o IA y automatización. Para conversar con criterio, no hace falta llegar con una arquitectura elegida: alcanza con describir un problema concreto, quién lo conoce, qué datos intervienen y cómo se comprobaría que el primer alcance está listo.

La forma más útil de empezar es preparar un brief de problema a primer piloto. Ese documento no intenta adivinar todo el producto final. Ordena el proceso actual, deja visibles las decisiones pendientes y evita que una conversación inicial se transforme, sin querer, en un proyecto de alcance indefinido.

El marco PILOTO: seis decisiones antes de pedir una propuesta

PILOTO es una guía de trabajo, no una receta técnica. Cada letra obliga a completar una parte que suele quedar implícita cuando el pedido empieza con una tecnología o una lista de funcionalidades.

El marco cambia el orden habitual de la conversación. Primero se define qué parte de la operación merece atención; después se decide si hace falta una interfaz, una integración, una automatización o una combinación. Esa secuencia también ayuda a distinguir una consulta todavía exploratoria de un alcance que ya puede evaluarse por escrito.

P: describir el problema sin nombrar la solución

Escribí: “Cada pedido se copia desde un canal a otro y la persona de operaciones revisa los campos faltantes”. No escribas primero: “Necesitamos una plataforma con inteligencia artificial”. La primera frase permite investigar el flujo; la segunda ya presupone una respuesta y puede ocultar que el inconveniente está en los datos, los permisos o una regla de negocio.

Un buen problema tiene un verbo y una consecuencia que se pueda observar. “Se pierde trazabilidad entre la solicitud y la confirmación” es más útil que “la gestión es poco digital”. Si no podés describirlo en una o dos oraciones, todavía falta conversar con quien ejecuta la tarea.

I: ubicar a las personas que hacen posible el alcance

Nombrá al dueño operativo, no sólo al área. También indicá quién usa la herramienta, quién aporta información, quién aprueba excepciones y quién recibe la entrega. Una persona puede cumplir varios roles, pero conviene escribirlos por separado. Así aparece temprano una pregunta clave: ¿quién va a decidir que una prueba representa el trabajo real?

L: hacer pequeño el primer recorte

El límite no es sólo una lista de funciones excluidas. Es una frontera operativa: un canal, un tipo de registro, un rol, un flujo y una excepción que se puedan observar juntos. Si el problema abarca ventas, inventario, facturación y soporte, elegí dónde empieza y dónde termina el primer recorrido. Lo que no entre debe quedar escrito, incluso si parece obvio.

O: mapear datos, accesos y dependencias

Anotá de dónde sale cada dato, quién es responsable de él, qué formato tiene y qué sistema lo recibe. Señalá si hay planillas, bandejas de correo, formularios, APIs, credenciales, archivos históricos o reglas que sólo conoce una persona. No supongas que “integrar” significa que dos sistemas pueden intercambiar información sin más: primero hay que conocer permisos, dirección del flujo, errores posibles y dueño de cada cuenta.

T: definir una revisión que no dependa de opiniones

El test mínimo no es una demostración preparada para lucir. Es un recorrido acotado que una persona del negocio puede repetir y revisar. Incluí un caso normal y una excepción: un campo faltante, un dato duplicado, un permiso insuficiente o una aprobación pendiente. Después escribí qué debería verse, qué puede corregirse y qué nunca debería darse por aceptado automáticamente.

O: acordar continuidad y salida desde el principio

Preguntá qué queda documentado, quién tendrá los accesos, cómo se exportan los datos y qué soporte existe después de la entrega. La salida no es una amenaza ni una señal de desconfianza: es una condición para que el trabajo no dependa de una sola persona. También conviene anotar qué ocurre si el piloto se detiene: qué archivos, código, configuraciones, decisiones y pendientes deben quedar disponibles.

La matriz reutilizable: brief de problema a primer piloto

Copiá esta matriz en un documento y completala con frases verificables. En la última columna aparecen únicamente los cinco encuadres de servicio del brief: web/ecommerce, app, SaaS/MVP, sistemas/integraciones e IA/automatización. La columna no decide la solución; sólo ayuda a formular la conversación inicial.

Hay dos reglas para que la matriz no se convierta en un formulario decorativo. Primera: cada fila debe tener un responsable de completar o validar la información. Segunda: si una respuesta es “a definir”, anotá quién la define y en qué momento; no la escondas dentro de una frase amplia como “integración completa”. La incertidumbre visible se puede gestionar. La incertidumbre disfrazada de alcance suele reaparecer más tarde.

Ejemplo trabajado: consolidar pedidos mayoristas

Ejemplo ilustrativo, no es un caso real ni describe un trabajo ejecutado. Supongamos una distribuidora ficticia que recibe pedidos mayoristas por correo y por un formulario. El stock se consulta en una planilla interna. Una persona de operaciones copia datos, busca campos faltantes y prepara una confirmación. El problema a encuadrar no es “hacer una app”: es reducir la repetición entre canales sin perder la revisión humana.

Así podría completarse el brief:

• Problema operativo: los datos del pedido se transcriben entre canales y la revisión de campos incompletos ocurre tarde.
• Proceso afectado: recibir la solicitud, identificar el origen, ordenar los campos, marcar faltantes y dejarla lista para revisión de operaciones. La confirmación comercial queda fuera del primer recorte.
• Responsable y usuarios: el dueño es el rol de operaciones; participan operaciones y ventas, con permisos distintos. No se presupone que ambos puedan editar todo.
• Sistemas y datos existentes: formulario, correo y planilla de stock. El brief debe registrar quién administra cada cuenta, qué columnas son confiables y qué datos no deben copiarse a una herramienta nueva.
• Integraciones requeridas: relevar si la primera versión necesita leer el formulario, consultar la planilla o sólo ordenar entradas exportadas. No se da por hecha una conexión directa.
• Test mínimo propuesto: usar dos pedidos ficticios de formatos distintos, uno completo y otro con un campo faltante. Verificar si cada dato queda asociado a su fuente, si la excepción se identifica y si una persona puede corregirla sin alterar el registro original.
• Criterios observables de aceptación: la entrada conserva su origen; los campos obligatorios se distinguen de los opcionales; la excepción queda visible; la revisión requiere una acción explícita; y se puede entregar un formato acordado para el siguiente paso.
• Accesos, código y datos: la distribuidora autoriza los accesos necesarios y define qué información puede usarse. La consultora debe dejar asentado qué configura, qué entrega y qué queda bajo administración de la organización.
• Soporte y continuidad: se documentan los campos, los estados y el procedimiento manual alternativo. Si una conexión no está disponible, el proceso no debe quedar sin una forma de recepción.

• Salida: si el flujo cambia, si no hay dueño de los datos o si la revisión no puede realizarse, se detiene la ampliación y se entrega lo acordado junto con pendientes y decisiones abiertas.

La lectura de este ejemplo es deliberadamente sobria. El primer alcance podría encajar en sistemas/integraciones y, si el formulario público forma parte del trabajo, también en web/ecommerce. No hace falta agregar IA/automatización sólo porque el problema tenga tareas repetitivas. Primero hay que comprobar que los campos, las reglas y la revisión sean suficientemente claros para que una intervención tenga sentido.

Matriz de decisión: elegir el primer encuadre

Usá esta tabla después de completar el brief. Si aparecen varias señales, elegí una categoría principal y dejá la segunda como dependencia; no conviertas todas las señales en un alcance único.

Señal que aparece en el brief	Categoría para evaluar	Primer recorte razonable	Dejar afuera por ahora
La relación con la organización ocurre en un canal público y el problema está en informar, recibir o cobrar una solicitud.	web/ecommerce	Un recorrido público y el dato que debe llegar al responsable.	Todo el backoffice, catálogo completo y reglas que todavía no estén definidas.

Las personas trabajan fuera del escritorio y necesitan capturar o consultar información en el momento.

app

Un rol, una acción principal y una condición de sincronización clara.

Todas las variantes de usuario y cada dispositivo posible.

Hay usuarios, registros, estados y permisos que deben convivir en una herramienta propia.

SaaS/MVP

Un tipo de registro y el recorrido de un rol principal.

Configurar módulos para áreas que aún no validaron el proceso.

El mismo dato se copia entre fuentes y destinos, o las operaciones se traban entre sistemas.

sistemas/integraciones

Una fuente, un destino, un flujo de datos y manejo explícito de errores.

Sincronización bidireccional o conexiones no autorizadas.

Existe una tarea repetitiva de clasificación, derivación o redacción que una persona debe revisar.

IA/automatización

Una tarea, una regla de revisión y una forma de volver al trabajo manual.

Decisiones sin revisión, múltiples excepciones y datos sin dueño.

La categoría es una hipótesis de conversación, no una especificación. El mismo problema puede necesitar una interfaz y una integración; la tabla ayuda a decidir qué dependencia debe aclararse primero.

Cómo implementar el brief en seis pasos

1. Escribí la versión cero en una página. Completá problema, proceso, dueño, usuarios, fuentes y límite. Si el documento ya tiene muchas pantallas o funciones, volvé a la frase del problema.

2. Recorré el trabajo real con el responsable. Pedile que describa una operación normal y una excepción. Registrá nombres de campos, decisiones y puntos donde se cambia de sistema. No copies datos sensibles en el brief; usá una descripción o una muestra autorizada y reducida.

3. Marcá dependencias y permisos. Para cada fuente, anotá quién puede dar acceso, quién puede revocarlo y qué información se puede exportar. Separá lo que se sabe de lo que necesita una revisión técnica.

4. Convertí el límite en una prueba. Escribí qué entrada se usará, quién la revisará, qué debe verse, qué puede editarse y qué condición hace que el alcance no esté listo. Incluí una excepción para evitar que el recorrido dependa de un único caso cómodo.

5. Pedí una respuesta con la misma estructura. Una consultora debería poder devolver alcance, exclusiones, supuestos, responsables, accesos, forma de aceptación, continuidad y salida. Si una parte no puede definirse todavía, que figure como pregunta abierta y no como una función implícita.

6. Tomá una decisión por evidencia del proceso. Luego de la revisión, podés ampliar, achicar, cambiar el encuadre o detenerte. El documento tiene que conservar qué se comprobó, qué quedó pendiente y quién decide la siguiente etapa.

La oferta publicada en la página de servicios de software y automatización de Develop Argentina presenta como puntos de entrada web, apps, SaaS y MVP, sistemas e integraciones, e IA y automatización. En esa misma página se aclara que Develop Argentina coordina el proyecto, CodeAustral ejecuta software y que el asesoramiento legal, contable, notarial o de traducción se presta mediante profesionales habilitados con contratación separada. Si tu brief cae en una de esas categorías, podés usarlo para pedir una conversación de alcance más precisa, sin mezclar funciones profesionales distintas.

Limitaciones

Este marco ordena una primera conversación; no reemplaza un relevamiento técnico, una revisión de seguridad, un análisis de datos ni el asesoramiento profesional que corresponda. Tampoco decide por sí solo la arquitectura, el proveedor de infraestructura o la forma contractual. Esas definiciones dependen del proceso, los sistemas existentes, los permisos y el alcance que se acuerde.

La matriz pierde utilidad cuando nadie puede validar cómo se trabaja o cuando el dueño de una cuenta, un dato o una regla no está identificado. En ese escenario, el primer paso puede ser descubrir y documentar, no construir. Del mismo modo, una prueba acotada no permite extrapolar cómo se comportarán todos los casos del negocio: las excepciones, los cambios de proceso y las dependencias externas pueden modificar la etapa siguiente.

El ejemplo es deliberadamente ficticio. No aporta cifras, clientes, credenciales, evaluaciones ni evidencia de una implementación. Las categorías de servicio mencionadas se limitan a las señales públicas suministradas; cualquier capacidad, condición o especialidad que no aparezca allí queda fuera de este artículo.

Preguntas frecuentes

¿Qué hace una consultora de software en la primera conversación?

Ayuda a traducir una necesidad de negocio en un alcance que se pueda analizar: proceso, usuarios, datos, integraciones, prueba, responsabilidades y límites. La conversación no debería obligarte a conocer de antemano la solución técnica. Sí debería dejar claro qué problema se está tratando, quién lo valida y qué información falta.

¿Tengo que llevar requisitos técnicos completos?

No. Es más valioso llevar una descripción fiel del trabajo actual, ejemplos de entradas y salidas, roles, permisos y una excepción. La definición técnica puede surgir durante la evaluación. Lo que conviene evitar es confundir “todavía no sé cómo construirlo” con “no sé qué tarea necesito cambiar”.

¿Cuándo tiene sentido empezar por un primer piloto?

Cuando existe un recorrido acotado, una persona responsable, datos o entradas accesibles y una revisión observable. No es un buen punto de partida si el problema cambia según cada área, nadie puede aprobar el alcance o no está permitido acceder a las fuentes necesarias. En esos casos, primero hay que resolver esas condiciones.

¿Cómo elijo entre web/ecommerce, app, SaaS/MVP, sistemas/integraciones e IA/automatización?

Elegí según el lugar donde ocurre la fricción. Si es público y orientado a una solicitud, mirá web/ecommerce; si exige uso móvil, app; si organiza usuarios, registros y permisos, SaaS/MVP; si mueve datos entre herramientas, sistemas/integraciones; y si repite una tarea revisable, IA/automatización. La elección puede combinar categorías, pero el primer recorte debería tener una dependencia principal.

¿Qué debería quedar acordado antes de empezar?

El problema y el flujo incluidos, las exclusiones, los criterios observables de aceptación, los datos y accesos necesarios, la titularidad y entrega de código y datos, el soporte, la continuidad y las condiciones de salida. Si alguno de esos puntos está abierto, anotá la pregunta, la persona responsable y el momento en que se resolverá.

¿Qué hago si mi idea todavía es demasiado amplia?

Volvé al proceso y elegí una sola transición: recibir, validar, registrar, derivar, cobrar, consultar o entregar. Definí quién la ejecuta, qué información usa y qué excepción querés revisar. Con ese recorte podés completar la matriz sin prometer una solución total y detectar qué conversación técnica hace falta después.