Hasta el 60 % de las funciones en aplicaciones recién lanzadas termina sin utilizarse, mientras que los desarrolladores, en lugar de crear soluciones verdaderamente innovadoras, pasan la mayor parte de su tiempo corrigiendo problemas que solo aparecen después del lanzamiento. Esta realidad fue destacada en la conferencia Software Crafters Barcelona por Nastassia Shahun, reconocida experta en análisis de negocio en TI, gestión de productos y modelado de procesos. Sus investigaciones y ponencias atraen de forma constante la atención de la comunidad tecnológica internacional, y las metodologías que ha desarrollado ya están siendo adoptadas por equipos en Europa y Estados Unidos.
La conferencia Software Crafters Barcelona es una de las plataformas más respetadas del mundo para debatir sobre la calidad del software y las prácticas modernas de ingeniería. Su programa se selecciona mediante un riguroso proceso de revisión por parte de expertos, y la inclusión de la ponencia de Nastassia Shahun fue un reconocimiento directo a su trabajo metodológico y a sus contribuciones prácticas al desarrollo del descubrimiento de producto (product discovery). En su duodécima edición, la conferencia reunió a ingenieros, analistas, arquitectos y expertos en producto de España, Alemania, Polonia, los Países Bajos, Estados Unidos y América Latina.
“No se trata de un evento para el gran público, sino de una plataforma profesional donde los especialistas presentan ideas que realmente transforman la manera en que se construyen los productos”, afirma Nastassia Shahun, quien presentó sus hallazgos originales sobre continuous discovery, un enfoque que ha estado desarrollando y aplicando en proyectos internacionales en los ámbitos de FinTech, eCommerce y startups de alta carga.
El concepto de descubrimiento (Discovery) en TI hace referencia al proceso de validar un producto futuro —como una aplicación— mientras aún se encuentra en desarrollo. Según Nastassia Shahun, el Discovery se ha vuelto crítico para el sector porque la mayoría de las empresas sigue tomando decisiones de producto demasiado pronto y sin suficiente validación. Como consecuencia, los equipos invierten recursos en crear funciones excesivas y, cuando el producto llega al mercado, a menudo tiene dificultades para encontrar su lugar debido a interminables revisiones y retrabajos. A través de su trabajo con sistemas de alta carga y startups de rápido crecimiento, Nastassia Shahun descubrió que los enfoques tradicionales de Discovery son demasiado lentos y pesados para los ciclos de producto actuales. Esto la llevó a desarrollar su propia metodología, basada en un conjunto de prácticas pequeñas, simples y repetibles.
«En esencia, es un marco de trabajo para un Discovery continuo, uno que puede integrarse directamente en un sprint sin interrumpir los procesos existentes: desde descubrir suposiciones ocultas hasta probar hipótesis con usuarios reales mucho antes de que el equipo escriba una sola línea de código. En la práctica, he visto que estos hábitos ligeros pero sistemáticos generan el mayor impacto», afirma Nastassia Shahun. Tras adoptar su enfoque único, las empresas reportaron una reducción en el desarrollo de funciones innecesarias, una mayor precisión en las decisiones de producto y una disminución del 30–50 % en el retrabajo.
Su enfoque ya está siendo utilizado por equipos en varios países y ha demostrado resultados consistentes: una disminución de funciones innecesarias, una mayor precisión en las decisiones de producto y una reducción significativa del retrabajo. El método de Nastassia Shahun se basa en la adopción de cuatro hábitos clave.
El primero es el Mapeo de Suposiciones (Assumption Mapping), una disciplina orientada a gestionar la incertidumbre. En el contexto de TI, implica identificar no solo los requisitos, sino también las brechas, los riesgos y las suposiciones que los sustentan. El Assumption Mapping surgió a partir de casos reales en los que suposiciones no documentadas provocaron incidentes técnicos y retrabajos. «Trabajar con arquitectos e ingenieros de distintos países demostró que esta técnica sencilla permite alinear los riesgos de producto y los riesgos técnicos en un único mapa en apenas 15 minutos», señala Nastassia Shahun.
El segundo pilar de la metodología de Nastassia Shahun es la Formulación de Hipótesis (Hypothesis Framing), que desplaza a los equipos de la simple documentación de solicitudes de funciones hacia la formulación de hipótesis medibles y la definición de métricas relevantes que convierten el comportamiento del usuario en datos accionables. En esencia, representa una transición desde la ingeniería clásica de requisitos hacia un enfoque orientado a resultados dentro de la analítica de producto.
Para minimizar la incertidumbre en equipos distribuidos, Nastassia Shahun propone un tercer hábito: sustituir las discusiones abstractas sobre el futuro del producto por breves investigaciones técnicas conocidas como Picos de Descubrimiento (Discovery Spikes). Este enfoque ayuda a los equipos a desarrollar la conciencia técnica necesaria para comprender la arquitectura del sistema, sus limitaciones y las implicaciones de diferentes decisiones técnicas.
El cuarto hábito se centra en la facilitación y el liderazgo en la toma de decisiones: Bucles de Retroalimentación (Feedback Loops) construidos a partir de visualizaciones claras de las soluciones propuestas.
«En estos cuatro hábitos reside mi experiencia de muchos años trabajando en equipos internacionales, donde las decisiones deben tomarse con rapidez y el costo de un error se mide en semanas de desarrollo», subraya Nastassia Shahun.
Según la experta, la estrategia de “construir hasta el final”, incluso cuando las señales iniciales indican que una hipótesis es errónea, es la que con mayor frecuencia utilizan las startups. La razón principal son las expectativas de los stakeholders respecto a los compromisos sobre funcionalidades. En cambio, las empresas internacionales de producto más maduras están dispuestas a hacer una pausa, revisar una hipótesis y cambiar de rumbo incluso a mitad de un sprint. Entre los casos de Nastassia Shahun hay decenas de ejemplos en los que rehacer una solución permitió a las compañías ajustar rápidamente la dirección de su producto y ahorrar recursos. Por ejemplo, al diseñar un sistema de facturación multicurrency, el equipo con el que trabajaba descubrió que el plan arquitectónico inicial provocaría retrasos y altos costos operativos. «En lugar de seguir adelante, iniciamos un breve discovery spike, reconstruimos la solución en tres horas y finalmente evitamos dos semanas de desarrollo incorrecto», explica. Nastassia destaca que la práctica del discovery continuo reduce el coste emocional de cambiar de rumbo y fomenta una cultura en la que revisar decisiones no se percibe como un retroceso, sino como una parte natural del trabajo de ingeniería de alta calidad.
Según señala Nastassia Shahun, implementar su metodología también exige un enfoque de liderazgo distinto. El estilo clásico “orientado al proceso” no funciona; en su lugar, los líderes deben adoptar un liderazgo basado en la evidencia —un modelo en el que el líder no impone una única opinión “correcta”, sino que crea las condiciones para que el equipo esté dispuesto a cuestionar sus propias ideas, poner a prueba sus suposiciones y cambiar de rumbo cuando los hechos indiquen otra dirección. Esto requiere honestidad intelectual, un enfoque en los resultados en lugar del mero output y la creación de un entorno seguro para la experimentación.
En Software Crafters Barcelona, Nastassia Shahun enfatizó una idea clave: la mejor solución es aquella que demuestra su valor incluso antes de que se escriba la primera línea de código. Tras su ponencia, recibió numerosas preguntas de ingenieros, arquitectos, product managers y team leads. Muchos se interesaron por su enfoque práctico —por ejemplo, cómo realizar microvalidaciones dentro de un sprint, cómo alinearse con los stakeholders y cómo medir el éxito antes de que comience el desarrollo.
Varios participantes le pidieron que compartiera sus plantillas de Assumption Mapping y Hypothesis Framing y, posteriormente, comentaron que planeaban adaptarlas a sus propios procesos porque, en sus palabras, “estas herramientas crean estructura allí donde normalmente predomina la incertidumbre”.
