Cómo preparar el encargo de un proyecto de software

Escriba dos o tres frases sobre lo que falla hoy y a quién afecta. Por ejemplo, un equipo comercial copia datos entre dos sistemas y, tras corregir un pedido, no sabe qué registro es válido. Esto sirve mejor que pedir un panel nuevo: permite identificar datos, responsabilidades y una primera prueba útil. Añada con qué frecuencia ocurre y qué coste tiene en tiempo, errores u oportunidades perdidas. Si no dispone de mediciones, presente la cifra como estimación.

Explique qué debería cambiar para una persona concreta cuando termine el proyecto. ¿Quién introduce la información, quién la aprueba y quién resuelve la excepción? Describa un recorrido habitual y otro en el que algo falle. Separe el resultado obligatorio de su propuesta de solución. Así podrá comparar una mejora del sistema, una integración y un producto nuevo frente al mismo objetivo. No tiene que elegir la tecnología de antemano; si existe una restricción contractual, indique su motivo.

Enumere los sistemas implicados y quién es responsable de cada dato importante. Para cada intercambio, indique quién puede leer, quién puede modificar y qué sucede cuando la otra parte no responde. En pagos, distinga una solicitud recibida de un resultado confirmado. En un CRM, defina quién corrige los registros contradictorios. En IA, aclare si puede recomendar o también ejecutar acciones. Incluya ejemplos sin datos personales reales y señale lo que nunca debe enviarse a herramientas públicas.

Anote como hechos las restricciones que condicionan el diseño: software existente, licencias, interfaces contractuales, roles de usuario, idiomas, trabajo de campo, disponibilidad y políticas internas. No esconda las incógnitas; asigne a cada una un responsable y una fecha de comprobación. Si el producto está regulado, identifique a quien evaluará las obligaciones legales y de seguridad. Registre también dependencias de otros equipos y cualquier plazo que tenga una razón comercial real.

Elija un recorrido importante que pueda completarse de principio a fin. Indique qué constituye éxito, cómo se mostrará un error y quién aceptará el resultado. La primera versión puede dejar fuera informes o automatizaciones, pero no puede ignorar identidad, datos sensibles, recuperación básica o comportamiento ante interrupciones si son esenciales para ese recorrido. Un piloto pequeño o una prueba técnica puede ser la primera etapa adecuada cuando una incógnita pone en duda el plan completo.

Defina tres señales de mejora: menos copias manuales, menor tiempo de resolución, menos registros desajustados o más tareas completadas. Para cada señal, anote el punto de partida actual o cómo se medirá. Evite prometer porcentajes sin datos. Pregunte qué podría mostrar el equipo después del primer mes y cómo ese resultado cambiaría la siguiente decisión. Así, una ambición general se convierte en una propuesta comprobable.

El primer mensaje necesita seis elementos: problema e impacto, usuarios principales, proceso y sistemas actuales, restricciones importantes, un recorrido esperado para la primera versión y una persona autorizada para decidir. Mencione los materiales que pueden compartirse de forma segura. No envíe contraseñas, datos confidenciales de clientes ni exportaciones de producción. Indique abiertamente lo que todavía desconoce. Un buen encargo inicial permite conversar con sentido, sin fingir que todas las decisiones técnicas están tomadas.

Pida al equipo una primera etapa de verificación, los datos que necesita de usted, su método para estimar y la forma de entregar el trabajo. Hable de cambios de alcance, situaciones de error y responsabilidad operativa. Precio y plazo solo tienen sentido para un alcance acordado y unas dependencias conocidas; una guía general no puede proporcionar una cifra fija honesta. Termine la reunión con responsables de las preguntas abiertas, un siguiente entregable concreto y el criterio para continuar.