Vì sao solutioning quan trọng

Giai đoạn 3 (Solutioning) biến xây gì (từ giai đoạn Planning) thành xây như thế nào (thiết kế kỹ thuật). Giai đoạn này ngăn xung đột giữa các agent trong dự án nhiều epic bằng cách ghi lại các quyết định kiến trúc trước khi bắt đầu triển khai.

Vấn đề nếu bỏ qua solutioning

Agent 1 triển khai Epic 1 bằng REST API
Agent 2 triển khai Epic 2 bằng GraphQL
Kết quả: Thiết kế API không nhất quán, tích hợp trở thành ác mộng

Khi nhiều agent triển khai các phần khác nhau của hệ thống mà không có hướng dẫn kiến trúc chung, chúng sẽ tự đưa ra quyết định kỹ thuật độc lập và dễ xung đột với nhau.

Lợi ích khi có solutioning

workflow kiến trúc quyết định: "Dùng GraphQL cho mọi API"
Tất cả agent đều theo quyết định kiến trúc
Kết quả: Triển khai nhất quán, không xung đột

Bằng cách tài liệu hóa rõ ràng các quyết định kỹ thuật, tất cả agent triển khai đồng bộ và việc tích hợp trở nên đơn giản hơn nhiều.

Solutioning và Planning khác nhau ở đâu

Khía cạnh	Planning (Giai đoạn 2)	Solutioning (Giai đoạn 3)
Câu hỏi	Xây gì và vì sao?	Xây như thế nào? Rồi chia thành đơn vị công việc gì?
Đầu ra	FR/NFR (Yêu cầu)	Kiến trúc + Epics/Stories
Agent	PM	Architect → PM
Đối tượng đọc	Stakeholder	Developer
Tài liệu	PRD (FRs/NFRs)	Kiến trúc + Tệp Epic
Mức độ	Logic nghiệp vụ	Thiết kế kỹ thuật + Phân rã công việc

Nguyên lý cốt lõi

Biến các quyết định kỹ thuật thành tường minh và được tài liệu hóa để tất cả agent triển khai nhất quán.

Điều này ngăn chặn:

Xung đột phong cách API (REST vs GraphQL)
Không nhất quán trong thiết kế cơ sở dữ liệu
Bất đồng về quản lý state
Lệch quy ước đặt tên
Biến thể trong cách tiếp cận bảo mật

Chọn độ sâu solutioning

Đặc điểm công việc	Khuyến nghị solutioning
Thay đổi cục bộ rõ ràng với pattern đã ổn định	Thường không cần
Nhiều component liên quan với ràng buộc đã biết	Tùy chọn theo rủi ro phối hợp
Nhiều epic hoặc quyết định liên hệ thống	Cần thiết để đồng bộ implementation
Sáng kiến tuân thủ, rủi ro cao hoặc enterprise	Tuân theo governance bắt buộc; solutioning thường là yêu cầu

Solutioning thay đổi ngữ cảnh cung cấp cho bmad-build, không thay đổi workflow triển khai.

Cái giá của việc bỏ qua

Bỏ qua solutioning trong dự án phức tạp sẽ dẫn đến:

Vấn đề tích hợp chỉ được phát hiện giữa sprint
Làm lại vì các phần triển khai xung đột nhau
Tổng thời gian phát triển dài hơn
Nợ kỹ thuật do pattern không đồng nhất