Realizar el descubrimiento

El descubrimiento proporciona al Product Engineer la comprensión suficiente para definir un producto útil y evitar pedir a los agentes de programación que resuelvan el problema equivocado. Debe identificar el resultado buscado, las personas y los procesos implicados, las restricciones importantes y las decisiones pendientes relevantes. El objetivo es un punto de partida claro, no un documento exhaustivo antes de que alguien pueda explorar software en funcionamiento.

Rol responsable: Product Engineer.
Participantes: Partes interesadas del negocio, usuarios previstos, expertos del dominio; arquitecto y diseñador de UX cuando sea necesario.
Entradas: Solicitud inicial, material disponible sobre procesos, contexto del producto existente, restricciones empresariales conocidas.
Resultados: Declaración del problema y del resultado, usuarios y partes interesadas identificados, alcance inicial, flujos de trabajo principales, preguntas pendientes y objetivos preliminares.

El Product Engineer puede usar un asistente de IA conversacional para explorar un problema empresarial mientras recopila información de las partes interesadas. En lugar de comenzar con un cuestionario largo o tratar una solicitud inicial como completa, puede explicar el flujo actual y pedir al asistente que identifique supuestos, explore alternativas y examine si la solución propuesta aborda el problema real.

El asistente puede organizar notas dispersas en flujos provisionales, señalar actores olvidados, sugerir excepciones realistas e identificar decisiones pendientes. Sus aportaciones son propuestas para investigar, no requisitos autorizados. El Product Engineer valida las afirmaciones fácticas y devuelve las decisiones de política empresarial al responsable autorizado.

La conversación puede ser oral o escrita y continuar durante varias sesiones. Los resultados importantes deben conservarse en los objetivos, las decisiones y las especificaciones del proyecto, sin depender de la memoria conversacional de un agente.

Un documento de descubrimiento terminado no requiere aprobación formal antes de prototipos habituales. Comience con intención y límites técnicos suficientes para un incremento útil; los agentes mantienen el registro mientras el PE inspecciona resultados. Aclare incógnitas importantes con sus responsables antes de decisiones arriesgadas dependientes. El descubrimiento continúa mediante comentarios sobre el producto real.

La implementación incremental es la opción predeterminada: acordar una capacidad acotada, inspeccionar el resultado funcional y ajustar antes de ampliar. Definir explícitamente el margen creativo/UX, estructural, funcional y de contenido, incluidas las exclusiones. Los experimentos amplios y prototipos reversibles pueden justificar mayor margen cuando se acuerda deliberadamente. Consulta Definir el margen del agente.

1. Comprender la solicitud y el problema real. Aclarar qué motivó la solicitud, quién resulta afectado, qué falla hoy y por qué se cree que la funcionalidad propuesta ayudará.
2. Explorar el flujo mediante conversación. Usar conversaciones con las partes interesadas y, cuando sea útil, un asistente de IA conversacional para trazar el camino normal, las decisiones, los traspasos y las excepciones pertinentes. Pedir al asistente que cuestione supuestos omitidos y compare enfoques plausibles.
3. Definir resultados previstos. Describir qué cambiaría para quienes realizan el trabajo y cómo podría observarse el éxito sin inventar métricas sin fundamento.
4. Identificar actores, datos y restricciones. Determinar permisos, dependencias externas, información sensible, estándares empresariales existentes y límites no funcionales importantes.
5. Separar reglas acordadas de preguntas abiertas. Usar IA para detectar ambigüedades, pero asignar las decisiones de política importantes a quienes realmente pueden tomarlas. Registrar los supuestos explícitamente.
6. Resumir y validar. Convertir la conversación en una descripción concisa del problema, alcance inicial, resultados, flujos, exclusiones y registro de decisiones. Confirmar los puntos importantes con las partes pertinentes.
7. Trasladar la intención validada a las especificaciones. Mantener el conocimiento aclarado en artefactos duraderos; no tratar la transcripción de la conversación como la especificación.

Una parte interesada solicita un panel de aprobaciones. El Product Engineer pide a un asistente de IA conversacional que le ayude a razonar sobre el proceso subyacente. El asistente sugiere que el problema real podría ser la falta de seguimiento de decisiones de aprobación, no la ausencia de gráficos. También pregunta quién puede aprobar, si puede aprobar sus propias solicitudes, si se requieren motivos de rechazo y cómo conoce el resultado quien solicita.

El Product Engineer confirma estas preguntas con las partes interesadas. El resultado acordado puede ser un pequeño flujo de solicitudes y decisiones sin un panel analítico. El agente de implementación no debe decidir por su cuenta los permisos de aprobación ni la política de rechazo.

• ¿Qué trabajo se realiza actualmente y por qué debe cambiar?
• ¿Quién inicia el proceso? ¿Quién puede aprobarlo, rechazarlo o corregirlo?
• ¿Qué constituye un resultado satisfactorio para la persona que realiza el trabajo?
• ¿Qué ocurre cuando falta información obligatoria o es inválida?
• ¿Qué sistemas externos o registros existentes deben intervenir?
• ¿Qué queda explícitamente excluido de la versión inicial?
• ¿Qué decisiones deben tomar los responsables de políticas en lugar del equipo de desarrollo?
• ¿Qué debería poder demostrar una parte interesada durante las UAT?

El descubrimiento es suficiente para comenzar a elaborar especificaciones cuando el problema empresarial y los resultados previstos están claros, se comprenden los actores y flujos principales y el alcance inicial, y las decisiones importantes pendientes quedan registradas junto con sus responsables. La IA conversacional puede ayudar a identificar supuestos y aclarar opciones, pero no sustituye el acuerdo de las partes interesadas ni la documentación duradera del proyecto. El descubrimiento puede continuar a medida que el software funcional revela información nueva.

Tratar una interfaz solicitada como el objetivo empresarial; aceptar reglas contradictorias de las partes interesadas sin aclaración; especificar grandes cantidades de detalles incidentales que los comentarios sobre software funcional resolverían con mayor eficacia; y suponer que un valor predeterminado técnicamente plausible es una decisión de política autorizada.