Antes de construir software, revisa el proceso
La mitad de los proyectos que llegan no necesitan un desarrollo nuevo. Necesitan que alguien mire con calma cómo se trabaja hoy.
Un cliente nos pidió una aplicación para gestionar las órdenes de despacho. Tenía el alcance escrito, las pantallas dibujadas y presupuesto aprobado. Antes de cotizar pedimos dos cosas: sentarnos medio día con la persona que hace el trabajo, y ver el archivo que usa realmente.
El archivo tenía tres pestañas. La aplicación que pedían tenía once módulos.
El proceso del manual y el proceso real
Casi siempre existen dos versiones de un proceso: la que está documentada y la que la gente ejecuta. La segunda es la que importa, porque es la que el software tiene que soportar. Y suele tener atajos, excepciones y acuerdos informales que nadie escribió.
Si construyes sobre el proceso del manual, entregas un sistema correcto que nadie usa. La gente vuelve al Excel a la semana.
Qué miramos en un diagnóstico
- Dónde se detiene la información. Los cuellos de botella rara vez están donde uno cree. Casi siempre hay un punto donde algo espera a que una persona específica lo revise.
- Cuántas veces se digita el mismo dato. Si un número se escribe tres veces en el día, hay tres oportunidades de error y dos de automatización.
- Qué decisiones se toman con esa información. Si nadie mira un reporte, no hay que construirlo. Suena obvio; se construye igual todo el tiempo.
- Qué pasa cuando algo sale mal. Las excepciones son el 20% de los casos y el 80% del esfuerzo de desarrollo. Vale la pena conocerlas antes de cotizar.
Tres finales posibles
Un diagnóstico honesto puede terminar de tres formas, y las tres son buenas:
- No necesitas software. El problema se resuelve cambiando quién hace qué, o eliminando un paso. Pasa más seguido de lo que parece.
- Necesitas menos software del que pensabas. El caso de las once pantallas terminó siendo tres, y funcionando en cinco semanas.
- Necesitas exactamente lo que pediste. Perfecto: ahora lo construimos sabiendo por qué cada parte existe.
Por qué esto nos conviene también a nosotros
Podríamos cotizar los once módulos y facturarlos. Pero un sistema que el equipo no adopta se vuelve un problema de soporte eterno y un cliente que no vuelve. Preferimos entregar menos, que funcione, y que la siguiente conversación sea sobre el próximo problema.