Bạn đã biết cách đánh giá mẫu kiến trúc (pattern), nền tảng triển khai (deployment platform), và thế trận kiểm soát (control posture). Khai phá (Discovery) sẽ tiết lộ liệu bạn có đang giải quyết đúng bài toán hay không.
Một bên liên quan (stakeholder) thường sẽ mô tả bài toán bằng các thuật ngữ kinh doanh. Nhiệm vụ của bạn là lắng nghe những gì doanh nghiệp đang cố gắng đạt được, nhận diện các ràng buộc ẩn đằng sau mô tả đó, và rời khỏi cuộc gọi với một bản ghi mà thiết kế có thể tuân theo.
Khai phá thiết lập các tài sản mà bản thiết kế phụ thuộc vào
Một cuộc trao đổi khai phá hoạt động như một bộ lọc 3 bước: lắng nghe, chuyển dịch, và ghi lại.
Đầu tiên, lắng nghe mục tiêu kinh doanh bằng ngôn ngữ thông thường và chú ý đến ý nghĩa đằng sau từ ngữ. Các bên liên quan thường mô tả kết quả họ muốn chứ không mô tả ràng buộc mà bạn cần thiết kế dựa trên đó.
Thứ hai, chuyển dịch câu nói đó thành các yêu cầu (requirements), giả định (assumptions), và ràng buộc chưa được giải quyết (unresolved constraints). Điều này cho phép bạn nhìn thấy những gì bản thiết kế bắt buộc phải hỗ trợ, những gì vẫn cần xác nhận lại, và những gì có thể chặn giải pháp sau này.
Thứ ba, ghi lại các mục đó trước khi cuộc trò chuyện chuyển sang phần khác. Bản thiết kế cần một bản ghi minh bạch để tuân theo. Nếu không có bộ lọc đó, bản thiết kế sẽ kế thừa các giả định cá nhân của bạn. Sự bất đồng bộ có thể sẽ không lộ diện cho đến rất lâu sau đó — thời điểm mà việc thay đổi quỹ đạo sẽ chậm hơn, khó hơn và đắt đỏ hơn nhiều.
Thao tác cốt lõi là Chuyển dịch: Một sở thích được tuyên bố gần như luôn che giấu một ràng buộc
Kỹ năng quan trọng nhất trong khai phá là Chuyển dịch (Translation). Các bên liên quan thường nói bằng ngôn ngữ sở thích (preferences), nhưng các quyết định thiết kế lại được đưa ra dựa trên các ràng buộc (constraints).
Hãy tưởng tượng một bên liên quan nói: "Chúng tôi muốn hệ thống này mang lại cảm giác liền mạch (seamless)." Nếu bạn ghi lại từ "liền mạch" như một yêu cầu kỹ thuật, bạn vẫn chưa học đủ thông tin để thiết kế bất kỳ điều gì. Bạn mới chỉ có bản tóm tắt của bên liên quan về trải nghiệm họ mong muốn.
Công việc thực sự bắt đầu với câu hỏi tiếp theo: Điều gì sẽ khiến nó cảm thấy KHÔNG liền mạch? Đó là nơi các ràng buộc ẩn bắt đầu xuất hiện:
Có thể người dùng không bao giờ phải chờ quá 1 đến 2 giây cho bước tiếp theo.
Có thể họ không phải nhập lại thông tin vốn đã tồn tại ở thượng nguồn.
Có thể các ngoại lệ (exceptions) nên được chuyển âm thầm sang cho một người rà soát thay vì phơi bày một lỗi kỹ thuật.
Có thể quy trình làm việc phải nằm gọn bên trong một ứng dụng duy nhất để người dùng không bao giờ phải nhảy qua lại giữa các công cụ.
Mỗi câu trả lời sẽ làm sắc nét bản thiết kế. Cuộc trao đổi đó biến từ "liền mạch" thành các yêu cầu mà kiến trúc phải hỗ trợ: một mục tiêu độ trễ (latency target), một yêu cầu tích hợp, một quy tắc bàn giao, và một đường dẫn thất bại an toàn (safe failure path). Bên liên quan gọi tên kết quả bằng ngôn ngữ kinh doanh; bạn biến nó thành một thứ mà hệ thống có thể xây dựng và đo lường được.
Quy tắc dịch chuyển từ Sở thích sang Ràng buộc:
Sở thích nằm ở tầng trên cùng, và ràng buộc nằm ở ngay bên dưới nó. Khi một bên liên quan đưa cho bạn một từ ngữ mô tả trải nghiệm như liền mạch (seamless), dễ dàng (easy), nhanh chóng (fast), đơn giản (simple), hay trực quan (intuitive), hãy coi đó là tín hiệu cho thấy cần phải khai phá thêm.
Hãy hỏi:
Điều gì sẽ làm phá hỏng trải nghiệm đó?
Người dùng không bao giờ được phép nhận ra điều gì?
Điều gì bắt buộc phải xảy ra phía sau hậu trường?
Điều gì vẫn phải đúng khi có sự cố xảy ra?
Những câu trả lời đó mới là thứ thuộc về bản ghi thiết kế (design record).
Một ràng buộc có thể kiểm thử và có ranh giới rõ ràng là thứ mà bản thiết kế có thể được xây dựng dựa trên đó. Sở thích của bên liên quan cho bạn biết nơi cần điều tra, trong khi các câu hỏi đào sâu sẽ tạo ra chính ràng buộc đó.
Bốn câu hỏi biến Khai phá thành Yêu cầu kỹ thuật
Khai phá hoạt động tốt nhất khi bạn ép một phát biểu mơ hồ của bên liên quan vào 4 nhóm (buckets) dưới đây. Một phát biểu như "chúng tôi muốn nó mang lại cảm giác liền mạch" chưa phải là thứ bạn có thể thiết kế dựa vào. Nó thường che giấu một hoặc nhiều câu trả lời cụ thể. Hãy điều tra các khía cạnh sau:
Hệ thống PHẢI làm gì (What the system must do): Đây là các năng lực mà bản triển khai phải bàn giao, được diễn đạt dưới dạng kết quả kinh doanh hơn là tính năng. Đây là nơi bạn tách biệt công việc do Claude sở hữu với công việc thuộc về hệ thống hiện có hoặc con người.
Hệ thống KHÔNG ĐƯỢC phép làm gì (What the system must not do): Đây là các ranh giới, các hành động bị cấm, và các trường hợp bắt buộc phải định tuyến sang cho con người. Các bên liên quan hiếm khi tự nguyện đưa ra những điều này, vì vậy bạn phải chủ động hỏi.
Hệ thống CHI PHÍ bao nhiêu / Ràng buộc tài nguyên (What the system must cost): Đây là ràng buộc ngân sách, được diễn đạt bằng các thuật ngữ mà bên liên quan kiểm soát. Mục tiêu độ trễ, mức trần chi phí cho mỗi lượt tương tác, hoặc dự báo lưu lượng đều cần được tính đến tại đây. Chúng trở thành các ràng buộc thiết kế sống còn.
Hệ thống PHẢI CHỨNG MINH điều gì (What the system must prove): Đây là bằng chứng cho thấy bản triển khai có thể tạo ra một giá trị nào đó. Trong các quy trình bị kiểm soát nghiêm ngặt, các nghĩa vụ chứng minh là một phần của tập yêu cầu. Nhận diện chúng trong khâu khai phá rẻ hơn nhiều so với trong đợt rà soát pháp lý nhiều tuần sau đó.
Sản phẩm đầu ra của Khai phá là một Bảng Chuyển dịch (Translation Table)
Mỗi mục tìm thấy trong khâu khai phá sẽ trở thành một dòng trong bảng chuyển dịch. Dòng này thu thập phát biểu của bên liên quan đúng như cách họ nói, ràng buộc ngầm định, quyết định kiến trúc bắt buộc, và bất kỳ giả định nào bạn đang tài liệu hóa khi ràng buộc chưa được xác nhận hoàn toàn.
Một dòng cho mỗi mục sẽ giữ cho chuỗi lập luận nguyên vẹn khi công việc chuyển từ khai phá sang thiết kế, và giữ cho các giả định luôn được chú ý hàng đầu.
Phát biểu của Bên liên quan (Stakeholder statement) | Ràng buộc Ngầm định (Implied constraint) | Quyết định Kiến trúc Bắt buộc (Required architectural decision) | Giả định Tài liệu hóa (Assumption to document) |
"Chúng tôi muốn hệ thống này mang lại cảm giác liền mạch." | Trải nghiệm phải nằm trong ngân sách độ trễ đã thống nhất. Các sự cố không được làm rò rỉ nội bộ hệ thống hoặc ngắt quãng luồng công việc. | Thiết lập mục tiêu độ trễ p95 làm ràng buộc thiết kế, sau đó thiết kế trạng thái thất bại êm đẹp, an toàn nội bộ (graceful, internal-safe failure state). | Giả định "liền mạch" đề cập đến phản hồi cảm nhận được và tính liên tục của luồng. Cần xác nhận lại. |
"Nó chỉ cần đọc biểu mẫu và định tuyến nó." | Định tuyến có thể là một quy tắc kinh doanh định tân (deterministic business rule). | Giữ quyết định định tuyến bên trong Rule Engine. Claude thực hiện trích xuất dữ liệu, và hệ thống thực hiện định tuyến. | Giả định logic định tuyến được sở hữu và duy trì bên ngoài mô hình. Cần xác nhận người sở hữu. |
"Dù sao thì các bác sĩ lâm sàng cũng sẽ rà soát lại đầu ra." | Một con người có giấy phép hành nghề bắt buộc phải phê duyệt đầu ra trước khi nó trở thành một phần của bản ghi có hệ quả pháp lý, tài chính hoặc lâm sàng. | Xây dựng bước phê duyệt có con người trong vòng lặp (Human-in-the-loop authorization) làm điểm kiểm soát bắt buộc. | Giả định việc rà soát là một cổng kiến trúc (architectural gate). Cần xác nhận thẩm quyền và thời điểm. |
"Chúng tôi làm trong ngành y tế, nên hãy cẩn trọng với dữ liệu." | Quy trình làm việc nhiều khả năng mang nghĩa vụ chứng minh theo khung quản lý bảo mật y tế (HIPAA). | Đối xử với vết kiểm toán (audit-trail) và bằng chứng xử lý dữ liệu như một yêu cầu cốt lõi ngay từ ngày đầu tiên. | Giả định quy trình thuộc phạm vi kiểm soát có nghĩa vụ chính thức. Cần xác nhận phạm vi với bộ phận tuân thủ. |
Chi phí · Độ phức tạp · Rủi ro
Chi phí (Cost): Một cuộc gọi khai phá chạy đủ lâu để nhận diện các ràng buộc thực sự sẽ rẻ hơn nhiều so với việc phải thiết kế lại giải pháp sau khi một ràng buộc ẩn phát lộ trong đợt rà soát pháp lý hoặc tuân thủ.
Độ phức tạp (Complexity): Làm việc qua 4 danh mục câu hỏi giúp bổ sung cấu trúc cần thiết, và việc chuyển dịch các sở thích thành ràng buộc theo thời gian thực đòi hỏi sự thực hành chủ động.
Rủi ro (Risk): Thất bại đắt giá nhất là ràng buộc không được tuyên bố nhưng vẫn sống sót qua bài kiểm thử và trở thành một rào cản kiểm duyệt khi lên production — thời điểm mà chi phí thay đổi thiết kế đang ở mức cao nhất.
Nội dung bài viết thuộc lộ trình chuẩn bị chứng chỉ Claude Certified Architect, được tổng hợp và biên dịch từ tài liệu đào tạo chính thức của Anthropic PBC. Bản quyền nội dung gốc thuộc về Anthropic PBC. Bản dịch tiếng Việt và chú giải thực hành bởi HungPH Blog.
Thành viên gia nhập từ 19/09/2026