Ciclo 1: Desarrollo inicial

El Ciclo 1 lleva un producto desde la recepción de requisitos hasta la aceptación empresarial y establece el conocimiento técnico y de producto que podrán reutilizar los cambios posteriores. La orientación de UX, la preparación de fundamentos técnicos y la generación de especificaciones avanzan en paralelo antes de la implementación inicial y durante ella, según sea necesario. El Product Engineer coordina la iteración, y dos revisiones de la implementación por el arquitecto ayudan a mantener la calidad técnica antes y después de comentarios sustanciales de las partes interesadas.

Responsable: Product Engineer. Participantes: Partes interesadas del negocio, expertos del dominio; arquitecto o diseñador de UX cuando sea necesario.

Comience por el problema real. Identifique a las partes interesadas, los usuarios previstos, los flujos de trabajo, los problemas actuales, los resultados deseados, las restricciones organizativas y lo que queda fuera del alcance inicial. Evite confundir una funcionalidad sugerida con el objetivo empresarial que la motiva. Registre los objetivos y las preguntas sin resolver e identifique las decisiones que requieren un responsable del negocio.

Resultado: Una comprensión compartida del problema y una descripción inicial de los objetivos, los límites y los flujos de trabajo principales del producto. El descubrimiento puede continuar cuando surjan preguntas nuevas.

Responsables: Product Engineer, Arquitecto / Ingeniero sénior y Diseñador de UX, con responsabilidad asignada según la materia.

Orientación de UX. Establecer los recorridos principales, los principios de interacción, las restricciones pertinentes de experiencia y los patrones adecuados del sistema de diseño existente. Proporcionar suficiente orientación inicial para implementar de forma productiva sin exigir el diseño exhaustivo de cada pantalla.

Fundamentos técnicos. El arquitecto identifica las tecnologías y capacidades reutilizables aprobadas adecuadas, establece límites arquitectónicos iniciales y colabora con los responsables pertinentes para garantizar un entorno de ejecución apropiado con restricciones técnicas para el agente. Documentar las decisiones del proyecto y asegurar que las instrucciones permanentes sean coherentes y fáciles de encontrar. La preparación arquitectónica inicial debe ser proporcional a la complejidad, el riesgo y la novedad del trabajo.

Generación de especificaciones. El Product Engineer utiliza conversaciones con las partes interesadas y, cuando resulta útil, IA conversacional para formular especificaciones de funcionalidades versionadas. Describir comportamiento observable, reglas importantes, permisos, excepciones y condiciones de aceptación. Resolver incertidumbres empresariales importantes con las partes autorizadas, sin permitir que un agente de programación invente políticas.

Las tres actividades se informan mutuamente: una restricción técnica puede modificar un flujo propuesto, mientras que una exploración de UX o una conversación sobre especificaciones puede revelar una regla olvidada. La preparación es suficiente cuando el equipo puede iniciar una implementación significativa con capacidades y límites de acceso aprobados, y las decisiones importantes pendientes están identificadas y son tratadas por su responsable.

Resultado: Orientación de UX útil, un conjunto inicial de especificaciones mantenidas y un entorno de proyecto suficientemente preparado para implementar de forma autorizada. SHAPE no exige una revisión de preparación arquitectónica con nombre propio ni una aprobación formal de preparación en esta etapa.

Responsable: Product Engineer. Implementador: Agente de programación con IA.

Utilizar las especificaciones establecidas, los fundamentos técnicos aprobados y las instrucciones de proyecto accesibles para dirigir al agente de programación. Implementar incrementos coherentes de comportamiento funcional. El Product Engineer ejercita los flujos pertinentes, inspecciona resultados, aclara requisitos e indica correcciones. Los cambios del comportamiento previsto deben registrarse en las especificaciones; la reestructuración habitual de código que conserva el comportamiento no requiere una nueva especificación de funcionalidad.

Resultado: Una implementación funcional adecuada para una revisión técnica significativa, con limitaciones conocidas documentadas en lugar de ocultas.

Responsable: Arquitecto / Ingeniero sénior. Colaborador: Product Engineer.

Revise la estructura de la implementación, el uso de componentes y servicios aprobados, la postura de seguridad, la separación de responsabilidades, la mantenibilidad, las decisiones de integración y otros riesgos pertinentes para el producto. Identifique los problemas importantes a tiempo para que las iteraciones de retroalimentación no se construyan sobre fundamentos deficientes. El Product Engineer dirige la corrección y el arquitecto confirma la resolución de los hallazgos críticos.

Resultado: Unos fundamentos técnicamente sólidos, listos para comentarios sustanciales de las partes interesadas.

Responsable: Product Engineer. Participantes: Partes interesadas del negocio, diseñador de UX cuando corresponda y agente de programación para la implementación.

Muestre funcionalidad en ejecución y pida a las partes interesadas que completen o evalúen flujos de trabajo significativos. Distinga entre malentendidos, comportamiento ausente, problemas de usabilidad y alcance realmente nuevo. Actualice las especificaciones para reflejar los cambios acordados y después impleméntelos y revíselos. Repita hasta que las partes interesadas consideren que el producto está listo para la verificación formal y la preparación de la aceptación.

Resultado: Un producto coherente cuya implementación y especificaciones reflejan el comportamiento acordado tras los comentarios.

Responsable: Agente o contexto de verificación separado; el Product Engineer evalúa los hallazgos.

Derive pruebas de las especificaciones registradas en el repositorio mediante un contexto independiente, en lugar de confiar por completo en las pruebas sugeridas por el agente implementador. Ejercite la aplicación en ejecución, la API y los flujos de usuario cuando sea viable. Registre la cobertura de requisitos y los resultados, incluidas las comprobaciones satisfactorias, los fallos, los bloqueos y las ambigüedades sin resolver. Corrija defectos, actualice las especificaciones cuando sea necesario y vuelva a ejecutar la verificación afectada.

Resultado: Evidencias documentadas de conformidad y una relación explícita de las limitaciones restantes. Las pruebas basadas en especificaciones no pueden demostrar que una especificación incompleta recoja todas las necesidades del negocio.

Responsable: Arquitecto / Ingeniero sénior.

Revise el estado técnico final a la luz de los hallazgos anteriores, los cambios de las partes interesadas, los resultados de verificación y cualquier consecuencia arquitectónica o de seguridad de la iteración. Confirme que los hallazgos importantes se han resuelto o tratado explícitamente conforme a la política aplicable. La aprobación técnica aborda la preparación de ingeniería; no es la decisión de aceptación empresarial de las partes interesadas.

Resultado: Revisión técnica completada para la entrada en UAT según la política empresarial.

Responsable: Proceso empresarial de UAT y aceptación del negocio. Coordinador: Product Engineer.

Entregue el producto, el contexto de los requisitos, las limitaciones conocidas y las evidencias de verificación pertinentes al proceso de UAT existente en la organización. Las partes interesadas del negocio autorizadas confirman si el producto satisface las necesidades previstas y deciden su aceptación conforme a las prácticas establecidas. Si las UAT producen cambios, concílielos con las especificaciones, implemente las correcciones y repita las comprobaciones necesarias.

Resultado: Una decisión documentada de aceptación empresarial o una lista clara de problemas por resolver. El ciclo de desarrollo definido por SHAPE termina aquí.

Las etapas describen responsabilidades y comprobaciones importantes, no ocho departamentos aislados ni una instrucción para congelar prematuramente la comprensión. Los equipos pueden volver a revisar material anterior. Lo que importa es que los cambios de comportamiento aceptados actualicen las especificaciones, que el trabajo de los agentes se mantenga dentro de los límites aprobados y que las revisiones independientes técnicas y empresariales sigan siendo significativas.