Sumilla
¿Qué hice?
Diseñé y lideré el desarrollo de un producto digital crítico para una empresa minera, orientado a la vinculación, evaluación de riesgo legal y seguimiento a proveedores mineros de pequela escala, en un contexto regulado, sensible y de baja madurez digital.
¿POR QUÉ LEER ESTE CASO?
Si estás buscando a alguien que:
• Se haga responsable de un producto hasta su consolidación;
• Ordene un sistema complejo;
• Acompañe a la organización en el paso de proyecto digital → producto vivo;
Este caso te dará una buena idea de cómo trabajo y cómo pienso.
La historia completa
Flujos de trabajo fragmentados y manuales.
Cómo empezó todo
El origen del SGV (Sistema de Gestión de Vinculaciones y Verificaciones) fue casual, pero no accidental.
Vi una publicación en LinkedIn del esposo de una amiga de la universidad, buscando un CRM aplicado a minería. No decía mucho más, pero para mí fue suficiente para detectar algo importante: no estaba buscando una herramienta, estaba buscando ordenar un problema.
Guardé la referencia.
Días después le compartí un producto existente que, aunque no era específico del sector minero, podía servir como aproximación. Su respuesta fue clara: no era lo que necesitaba. Aun así, esa interacción abrió una primera conversación real.
Días después le compartí un producto existente que, aunque no era específico del sector minero, podía servir como aproximación. Su respuesta fue clara: no era lo que necesitaba. Aun así, esa interacción abrió una primera conversación real.
La oportunidad llegó poco después, en una reunión de amigos, pudismos conversar lo suficiente como para entender mejor el problema.
Entender el problema antes de proponer una solución
Me explicó que tenía poco tiempo en la empresa, venía de una maestría en tecnología y estaba explorando cómo digitalizar el trabajo de las oficinas de acopio, las unidades descentralizadas que tienen contacto directo con los mineros artesanales proveedores de mineral.
Me hablo en primera instancia de la verificación de labor minero, un proceso clave para asegurar la trazabilidad del origen del mineral y de las condiciones adecuadas de la operación conforme a ley.
Este proceso se realizaba de manera manual y desconectado del flujo de información de la empresa, lo cual generaba desorden y retrazo evitable en la vinculación de nuevos proveedores, en otras palabras, pérdida de oportunidad de negocio para la empresa.
Ahí entendí algo clave:
esto no era un CRM ni un sistema administrativo.
Era un sistema de gobernanza de proveedores, en un sector altamente sensible en el Perú, expuesto a riesgos legales y reputacionales.
esto no era un CRM ni un sistema administrativo.
Era un sistema de gobernanza de proveedores, en un sector altamente sensible en el Perú, expuesto a riesgos legales y reputacionales.
El primer prototipo
Con ese input le propuse realizarle un bosquejo de solución:
“Déjame intentar plasmar esto en un prototipo”.
En pocos días le envié el prototipo centrado solo en el proceso de verificación. No era exhaustivo, pero sí preciso. La reacción fue inmediata: había captado la lógica, el flujo y lo hice ver como algo viable.
Ese prototipo fue el verdadero punto de entrada al proyecto.
Me pidió una propuesta técnica–económica para presentarla internamente. Cuando la propuesta fue evaluada, la empresa decidió ampliar el alcance: ya no solo verificación, sino todo el proceso de vinculación de proveedores.
Ahí el proyecto cambió completamente de escala.
Prefiero presentar los bocetos con diseños de alta fidelidad para que se entienda bien la idea.
Cuando entendí que esto ya no era un proyecto pequeño
La ampliación del alcance transformó el encargo en un proyecto de alta complejidad:
• Más roles• Más decisiones
• Más dependencias
• Más riesgo
En ese momento tomé una decisión que marcó todo el trabajo posterior:
no acelerar sin entender.
no acelerar sin entender.
Organicé el proyecto en tres etapas claras —investigación, diseño y desarrollo— aun sabiendo que podía parecer un enfoque “poco ágil”. Lo hice porque entendí que:
• Los procesos no estaban completamente explicitados
• Los roles tenían visiones parciales del sistema
• El equipo de TI era nuevo
• La organización aún no tenía madurez en producto digital
En retrospectiva, sé que hubiera sido valioso introducir antes más testeo iterativo, pero en ese contexto la prioridad era construir criterio compartido antes de iterar.
Investigación: personas, procesos y contexto legal
Durante la etapa de investigación entrevisté a todos los roles involucrados. Procesé la información de forma sistemática, como en un proceso formal de UX Research, y volví constantemente a esos insights cada vez que surgían dudas.
Algo clave fue la relación humana. Mantener comunicación directa —muchas veces por WhatsApp— con las personas que representaban los roles me permitió:
• Resolver ambigüedades
• Completar historias de usuario
• Construir confianza
• Convertirlos en aliados del producto
En paralelo, recopilé documentación formal e investigué la normativa de formalización minera. El SGV no solo podía limitarse a ser eficiente, también tenía que proteger al negocio.
Flujo optimizado del proceso de vinculación
Diseñar para el negocio, no solo para el sistema
Con una comprensión clara del negocio, diseñé KPIs vinculados a la capacidad productiva aportada por nuevos proveedores, porque el objetivo final del proceso de vinculación era aumentar volumen de negocio sin perder legalidad ni trazabilidad del origen del mineral.
Diseñé el flujo principal respetando la forma actual de trabajo, pero introduciendo reacomodos que reducían fricciones y tiempos innecesarios. Luego pasamos a las historias de usuario, trabajadas con mucho detalle.
Cada historia de usuario representaba una estación del flujo:
• Un rol
• Una acción
• Un objetivo
Incluía requerimientos funcionales, criterios de aprobación, diseño de interfaces y un video explicativo. El objetivo era facilitar la comprensión, acelerar aprobaciones y reducir fricción en desarrollo.
Desarrollo: proteger el producto más allá de nosotros
Para el desarrollo tomamos decisiones deliberadas:
Usar las tecnologías que ya utilizaba la empresa, aun cuando no era obligatorio, para proteger el producto cuando ya no estuviéramos.
Evitar duplicar datos existentes en sistemas internos, aun cuando eso implicara desafíos técnicos y riesgo de cronograma
Diseñamos un modelo de datos que terminó sirviendo también como estándar interno. La gestión del desarrollo se centralizó en Trello y la relación con TI requirió paciencia, claridad y mucha comunicación, especialmente en temas de seguridad y accesos.
Gestión de historias de usuario
Diseño y desarrollo de interfaces
App
El piloto: cuando el producto se encontró con la realidad
Hacia el cierre, el tiempo era limitado. En coordinación con el owner del proyecto tomamos una decisión clave: simplificar alcance y canjear historias secundarias por un piloto real.
El objetivo del piloto fue concreto: validar el flujo princial de vinculación de inicio a fin con expedientes reales. Algo así como lanzar un MVP e iterar en base al feedback entregado por los usuarios.
Recogimos alrededor de 80 observaciones entre bugs, mejoras y dinámicas fuera de proceso.
Se priorizó y atendido las observaciones de mayor impacto y viabilidad, dentro del tiempo disponible del piloto. El sistema terminó representando fielmente la dinámica real de las oficinas de acopio.
El punto de inflexión: proyecto entregado, producto en riesgo
El verdadero punto de inflexión llegó en la presentación final.
Parte de la alta dirección asumía que el sistema ya estaba “terminado” y que no requería mejoras posteriores. Ahí quedó en evidencia algo crítico: la organización aún no pensaba en términos de producto digital.
En ese momento entendí que, si nadie asumía ese rol, el SGV corría el riesgo de convertirse en un software correcto pero estancado.
Desde ahí mi foco cambió:
ya no era solo cerrar un proyecto, sino proteger el producto en el tiempo.
ya no era solo cerrar un proyecto, sino proteger el producto en el tiempo.
Propusimos una etapa de consolidación con iteraciones adicionales, impulso y capacitación. Hoy estamos entrenando al área de TI en gestión de producto digital, instalando la idea de que el SGV necesita un responsable de producto que vele por su evolución.
Lo que deja este proyecto
Entregamos un producto:
• Integrado
• Testeado en un piloto real
• Ajustado según feedback de usuarios
• Listo para entrar en producción
Pero, sobre todo, dejamos un sistema preparado para evolucionar.
Este proyecto confirmó algo central en mi forma de trabajar:
Mi valor no está solo en diseñar o implementar, sino en hacerme cargo de productos complejos cuando todavía no hay una cultura de producto instalada.
Eso es lo que hice con el SGV.
Y es el tipo de desafío donde mejor trabajo.
Y es el tipo de desafío donde mejor trabajo.
Validación desde el negocio
El impacto del SGV no se dio solo en el producto, sino en la forma de trabajar y tomar decisiones durante el proyecto.
