En la industria del desarrollo de software, la analogía de un proyecto navegando sin brújula probablemente te resuene con particular fuerza cuando la comprensión de la necesidad del negocio es deficiente y/o ambigüa, ¿no es cierto? ¿o acaso nunca lo has experimentado? ¡Vamos!.
He podido observar con frecuencia un inconveniente recurrente: la tentación de iniciar la fase de construcción/desarrollo antes de haber asimilado/entendido el problema u oportunidad que el software busca resolver. Muchos pueden ser los motivos del porqué sucede esto: atender urgencias que tiene el negocio, atender urgencias operativas, atender urgencias tecnológicas, y otros.
Cuando la necesidad operativa o de negocio no se entiende con absoluta claridad, el equipo se direcciona en un camino incierto, construyendo/desarrollando «a ciegas» y con un riesgo elevado de entregar una solución que no satisface las expectativas o, peor aún, que no resuelve el problema subyacente. ¿Cuántas veces te habrá ocurrido, verdad? ¿y qué hiciste? ¿y qué pudiste haber hecho para evitarlo? ¿se trata y discute durante la RETRO o durante la sesión de REFI?
La consecuencia directa de esta «ceguera inicial» es la generación de una significativa deuda técnica y funcional (a veces también no funcional). Un producto desarrollado bajo premisas equivocadas requerirá costosos ajustes, retrabajos o, en el peor de los casos, será descartado. Esto no solo impacta negativamente los presupuestos y cronogramas, sino que también erosiona la moral del equipo y la confianza de los stakeholders, e incluso hasta puede afectar la imagen de la marca institucional. La inversión en tiempo y recursos se desvanece si el punto de partida y la comprensión de la necesidad, es defectuoso y hasta desgastante para los miembros del equipo. Es aquí donde la integración del aseguramiento de la calidad desde las fases más tempranas emerge como una estrategia indispensable. En síntesis, pensemos en aplicar calidad temprana.
Involucrando a todo el equipo (Testers y Desarrolladores) y Stakeholders: El poder de las sesiones de descubrimiento
Para contrarrestar la construcción «a ciegas», la solución reside en un enfoque colaborativo y proactivo de la calidad. La práctica de involucrar a los testers, desarrolladores y a stakeholders clave desde el inicio en sesiones de descubrimiento es fundamental. No se debería dejar de lado esta instancia de sesiones y hasta se debería plantear este punto cuando se inicia el proyecto para que todos estén al tanto del tema ya que les afectará las agendas diarias de los que estén participando en el proyecto.
- ¿Qué implica esto? Se trata de facilitar encuentros estructurados y dinámicos donde el Product Owner, los miembros del equipo de desarrollo (concepto de agilidad: desarrolladores y testers) y los representantes del área de negocio se unen para explorar, debatir y documentar conjuntamente la necesidad operativa o de negocio. No es una mera toma de requisitos pasiva, sino un ejercicio de co-creación y validación activa. Aquí hay que considerar que se deben poner de acuerdo más de una gerencia seguramente en la que intervienen costos internos y afectaciones de tiempos de colaboradores con otros de otros áreas. Por lo tanto aquí es el primer desafío que el Gerente de Proyectos junto con su equipo deben enfrentar para «vender» correctamente la idea y lograr de esta forma los correspondientes acuerdos.
- ¿Por qué funciona esta aproximación? La eficacia de esta metodología radica en su capacidad para alinear la visión desde múltiples perspectivas. Al reunir a quienes entienden el problema (negocio), quienes lo transformarán en software (desarrolladores) y quienes lo verificarán (testers), se fomenta un entendimiento holístico. Esto permite identificar necesidades reales que quizás no fueron explícitamente articuladas, descubrir puntos débiles operativos ocultos y desvelar posibles malentendidos antes de que se invierta tiempo y esfuerzo en el diseño o desarrollo. Los testers, con su mentalidad orientada a la validación y a los casos límite, son cruciales para desafiar supuestos y asegurar que la comprensión sea completa y libre de ambigüedades.
- Un ejemplo práctico: Consideremos la realización de un workshop inicial donde el equipo técnico, el Product Owner y los representantes del negocio se reunen para mapear el flujo de valor actual y los problemas específicos a resolver. En esta sesión, pueden utilizar técnicas como el event storming, el user story mapping o la creación de ejemplos concretos (Behavior-Driven Development – BDD) para ilustrar cómo se espera que el sistema se comporte. Por ejemplo, al discutir la necesidad de «optimizar la gestión de pedidos» (ejemplo), se podría simular un pedido desde su inicio hasta su finalización, identificando cada paso, actor involucrado y posibles desviaciones. Esto no solo clarifica la necesidad, sino que también sienta las bases para criterios de aceptación claros y testeables.
En última instancia, la inversión en estas sesiones de descubrimiento tempranas, con la participación activa de los perfiles de calidad, no es un costo, sino una salvaguarda esencial. Es la brújula que guía al proyecto, asegurando que cada línea de código contribuya a una solución que realmente genere valor de negocio.
Uno de los puntos críticos aquí a debatir como gran desafío es el tiempo que les insumirá a cada una de las personas que participen en este tipo de sesiones considerando los roles que deben estar involucrados. Una de las preguntas que pueden surgir es la siguiente: ¿Beneficia al proyecto este tipo de acciones? ¿Entiende el negocio la importancia de realizar este tipo de sesiones? ¿Entienden todos que ocupándose de manera temprana sobre la situación a resolver o a generar, se evitan demoras posteriores?
Prompt para el PO
Prompt para el Product Owner:
- Objetivo del prompt: Asegurar la dirección del proyecto desde el primer día.
- Idea principal: «Programa un workshop de descubrimiento colaborativo con tu equipo de desarrollo y los stakeholders clave. Utiliza ejemplos concretos y escenarios de uso para validar la necesidad de negocio. Asegúrate de que todos los miembros clave del equipo, desarrolladores y testers estén presentes para desafiar suposiciones y ayudar a definir criterios de aceptación claros desde el inicio. ¿Qué tres preguntas clave sobre la necesidad crees que surgirán en esa sesión?»
Template
Te comparto un modelo de template que el Product Owner podría utilizar para guiar a la IA Generativa (ChatGPT, Gemini, Claude, DeepSeek, Copilot) y obtener ayuda en la planificación de una sesión de descubrimiento para entender y validar la necesidad de negocio:
Solicitud de asistencia para IA: Planificación de sesión de descubrimiento de necesidades
Este template está diseñado para que, como Product Owner, puedas proporcionar a una Inteligencia Artificial los parámetros necesarios para ayudarte a estructurar y preparar una sesión de descubrimiento y validación temprana de la necesidad de negocio de tu proyecto. El objetivo es asegurar una comprensión clara y compartida, minimizando riesgos desde el inicio.
Instrucciones: Completa los siguientes campos con la información relevante de tu proyecto. Cuanto más detallado seas, mejor podrá la IA generar sugerencias a tu medida. Recuerda la frase que uso en varias oportunidades: Ingresa basura, Sale basura; y otra: Hay que explicar y describir muy bien el contexto, objetivo, y de ser posible, incluye ejemplos.
[Inicio del Template para IA]
1. Título del Proyecto (o de la iniciativa/funcionalidad a definir):
- [Ej: Plataforma de Gestión de Pedidos; Módulo de Facturación Automática; Optimización de Flujo de Onboarding de Clientes]
2. Descripción breve del proyecto/objetivo general (máximo 2-3 líneas):
- [Ej: Desarrollar una solución web para automatizar el proceso de gestión de pedidos de principio a fin, reduciendo errores manuales.]
3. Necesidad operativa/de negocio principal a entender (El «Por Qué» fundamental):
- [Ej: Reducir los costos operativos en un 20% al eliminar el procesamiento manual de pedidos; Mejorar la satisfacción del cliente disminuyendo el tiempo de respuesta en un 30%; Habilitar la expansión a nuevos mercados agilizando los procesos de registro.]
4. Stakeholders clave involucrados en la necesidad (roles y áreas):
- [Ej: Gerente de Ventas, Responsable de Logística, Equipo de Atención al Cliente, Director Financiero. Para el equipo técnico: Lead Developer, Lead QA/Tester.]
5. Desafíos actuales o ambigüedades conocidas sobre la necesidad:
- [Ej: No está claro cómo se manejan las excepciones de pedidos especiales; Hay discrepancias entre el equipo de ventas y el de logística sobre el punto de «cierre» del pedido; Los usuarios finales no pueden expresar sus necesidades técnicas.]
6. Tipo de ayuda esperada de la IA para la sesión de descubrimiento:
- (Puedes seleccionar una o más opciones, o describir una nueva)
- Generar una agenda de workshop de 2 horas.
- Proponer preguntas clave para el PO durante la sesión.
- Sugerir ejercicios prácticos para la colaboración (Ej: mapeo de flujo, BDD).
- Ayudar a formular posibles criterios de aceptación iniciales.
- Identificar posibles casos de borde o escenarios complejos.
- [Otra: describir tu necesidad específica]
7. Formato preferido para la sesión (si aplica):
- [Ej: Presencial, Virtual (Zoom/Teams), Híbrido. Con o sin herramientas colaborativas (Miro, Mural).]
8. Conocimiento previo del equipo sobre BDD o metodologías de descubrimiento (si aplica):
- [Ej: Nulo; Básico; Experto en Gherkin; Familiarizados con user stories.]
[Fin del Template para IA]
Con este template, el Product Owner puede proporcionar a la IA la información estructurada necesaria para recibir una guía precisa y relevante para sus sesiones de descubrimiento de necesidades, alineándose con el objetivo de aplicar control de calidad temprana.
Espero que haya sido de utilidad todo este contenido y me ayudarías mucho a mi también si dejas un like y un comentario en el contenido asociado y que publiqué en LinkedIn, además de compartirlo entre tus amigos, conocidos y colegas. Muchas gracias por seguirme.
