02 / Compras · Arquitectura de soluciones
Cuando la decisión deja de depender de la próxima reunión.
Un proceso de compras dependía de comités que se reunían dos veces al mes. Ayudé a diseñar un portal en SharePoint para llevar ese flujo al entorno que la operación ya utilizaba.
¿Cómo sacar la decisión de la agenda de reuniones y preservar sus reglas?
01 / El punto de partida
Antes de diseñar la pantalla, entender la decisión.
El diagnóstico reunió documentación, registros del proceso, conversaciones con la operación y la participación de un especialista en compras. Las reuniones en fechas fijas condicionaban el avance de las solicitudes.
Llevar esto a software exigía entender quién decidía, qué información se necesitaba y qué reglas había que preservar.
02 / Mi contribución
La arquitectura y los permisos eran parte del producto.
Mi responsabilidad se concentró en la arquitectura y en los requisitos de seguridad: autenticación, permisos y visibilidad de los votos. Esas elecciones definían lo que cada participante podía hacer y ver.
Usamos SharePoint, que ya formaba parte del entorno del cliente. Un equipo de dos personas construyó la prueba de concepto, con colaboración entre negocio y desarrollo.
03 / Cómo lo construimos
Detallar el flujo para hacer posible la implementación.
El desarrollo contó con el apoyo de la IA en la redacción de requisitos, especificaciones, documentación y pruebas. El trabajo de aclarar reglas y validar el comportamiento siguió a cargo del equipo.
El caso muestra la conexión entre el diseño de procesos y la arquitectura: la experiencia de uso tenía que reflejar las reglas de la decisión, incluso aquello que no debía quedar visible para todos.