Trình bày sự đánh đổi để bên liên quan có thể đưa ra hành động, và thiết kế Demo giúp thúc đẩy thương vụ

Khâu Khai phá (Discovery) đã cho bạn biết bên mua cần gì. Biến những yêu cầu đó thành một quyết định mà bên liên quan có thể phê duyệt chính là phần việc tiếp theo.

Kiến trúc sư lúc này sẽ giúp bên liên quan hiểu rõ sự đánh đổi (tradeoff), nhận thấy các hệ quả đối với doanh nghiệp, và tự tin phê duyệt một lộ trình tiến lên.

Nhiệm vụ của bạn không phải là tự mình giải quyết xong sự đánh đổi trước cuộc họp. Nhiệm vụ của bạn là làm cho việc đưa ra quyết định trở nên khả thi.

Nhiệm vụ của bạn là mô tả các tùy chọn một cách đủ rõ ràng để bên liên quan có thể đưa ra một lựa chọn dựa trên đầy đủ thông tin.

Đóng khung Quyết định thành một "Gói lựa chọn" thay vì một "Phán quyết"

Mọi quyết định thiết kế có ý nghĩa đều đi kèm sự đánh đổi. Một tùy chọn có thể giảm chi phí hoặc độ phức tạp nhưng lại làm tăng độ trễ, rủi ro, hoặc gánh nặng tuân thủ. Một tùy chọn khác có thể cải thiện trải nghiệm người dùng hoặc mở rộng tốt hơn nhưng đòi hỏi nhiều công sức ban đầu hơn.

Nếu bạn chỉ trình bày kết luận, quyết định nghe có vẻ rất rõ ràng, nhưng nó lại rất yếu ớt. Khi mặt tối (downside) xuất hiện sau này, bên liên quan có thể cảm thấy họ đã phê duyệt một khuyến nghị mà không thực sự hiểu những gì đi kèm với nó. Vì vậy, hãy sử dụng khung quyết định 4 câu hỏi đơn giản:

1. Chúng ta ĐƯỢC gì? (What do we gain?)

2. Chúng ta MẤT gì / Đánh đổi điều gì? (What do we give up?)

3. Điều gì xảy ra nếu chúng ta chọn phương án này bây giờ nhưng phải ĐẢO NGƯỢC nó sau này? (What happens if we choose this now but have to reverse it later?)

4. Trong các môi trường bị kiểm soát nghiêm ngặt, lựa chọn này tác động thế nào đến thế trận tuân thủ của chúng ta? (In regulated environments, what does this do to our compliance posture?)

Câu hỏi thứ ba là câu hỏi mà hầu hết mọi người thường bỏ qua, và nó thường là câu hỏi làm thay đổi cục diện cuộc họp. Nó chuyển cuộc thảo luận từ "Đâu là câu trả lời kỹ thuật tốt hơn?" thành "Đâu là lựa chọn kinh doanh tốt hơn?".

Chuyển dịch Ngôn ngữ Kỹ thuật sang Ngôn ngữ Kinh doanh

Sự chính xác về kỹ thuật là điều kiện cần, nhưng chưa đủ. Trong các đợt rà soát kiến trúc, khuyến nghị thường đúng về mặt kỹ thuật nhưng vẫn khó hiểu đối với người có thẩm quyền phê duyệt. Kiến trúc sư có thể giải thích các tùy chọn bằng thuật ngữ kỹ thuật (độ trễ, độ sâu ghi log, kích thước ngữ cảnh, mẫu truy xuất, tuyến triển khai), nhưng cấp lãnh đạo lại đang hỏi một câu hỏi đơn giản hơn: "Điều gì sẽ xảy ra với doanh nghiệp nếu chúng ta đưa ra lựa chọn sai?"

Tại thời điểm đó, căn phòng không cần thêm chi tiết kỹ thuật; thứ nó cần là sự chuyển dịch sang điều mà một con người có thể hiểu được. Khi bạn làm tốt điều này, bên liên quan không chỉ đơn thuần nghe khuyến nghị của bạn — họ đang đưa ra một quyết định có đầy đủ thông tin mà họ có thể bảo vệ sau này.

Khả năng Mô tả (Description) là Năng lực giúp "Gói lựa chọn" hạ cánh thành công

Mô tả (Description) là một trong 4 năng lực cốt lõi của Sự thành thạo AI (AI Fluency): truyền thông hiệu quả với AI. Mở rộng sang khía cạnh làm việc với các bên liên quan, kỷ luật tương tự có nghĩa là nói cho khán giả chính xác những gì họ cần, bằng các thuật ngữ họ có thể hiểu.

Áp dụng vào giao tiếp với các bên liên quan, Mô tả có nghĩa là đóng khung hành vi của hệ thống, các giới hạn của nó, và sự giám sát xung quanh nó theo mục tiêu của bên liên quan. Cách đóng khung nên phù hợp với mức độ quen thuộc về AI của họ mà không làm mất đi độ chính xác.

3 Quy tắc thực tế cần áp dụng:

• Dẫn dắt bằng kết quả kinh doanh thay vì bằng kiến trúc.

• Đóng khung các giới hạn một cách trung thực, vì bên liên quan về an ninh sẽ tin tưởng một hệ thống mà các giới hạn của nó được tuyên bố minh bạch.

• Dự đoán trước nhu cầu bảo vệ quyết định trước đồng nghiệp (peer-proof demand), vì bên liên quan sẽ cần giải trình lựa chọn đó với những người khác và nên rời cuộc trò chuyện với lý do giải trình đó trong tay.

Bảng Chuyển dịch Đánh đổi (Tradeoff Translation Map)

Hãy sử dụng Bảng chuyển dịch đánh đổi để chuyển từ ngôn ngữ đóng khung kiến trúc sang ngôn ngữ quyết định của bên liên quan:

Thiết kế Demo là một Kỹ năng Riêng biệt, và một bản Demo yếu có thể phá hỏng những gì Khai phá đã đạt được

Hãy hình dung một cuộc họp với bên mua mà ở đó khâu khai phá đã diễn ra rất tốt. Đội ngũ đã đồng nhất về bài toán, use case, và giá trị cốt lõi. Sau đó, bản demo bắt đầu. Thay vì trình chiếu thế giới của bên mua, nó lại diễn họa một tập hợp tính năng bóng bẩy nhưng chung chung. Phản ứng thường sẽ là lịch sự — rằng bản demo thú vị, nhưng không hẳn là những gì họ hình dung.

Một bản demo yếu có thể khiến bên mua nghi ngờ liệu đội ngũ có thực sự hiểu bài toán cốt lõi hay không. Điều này xảy ra khi các đội ngũ nhầm lẫn giữa hai công việc khác nhau:

• Demo năng lực (Capabilities demo): Trả lời câu hỏi "Hệ thống này có thể làm được gì?" $\rightarrow$ Tạo ra sự quan tâm.

• Demo theo kịch bản cụ thể (Scenario-specific demo): Trả lời câu hỏi "Hệ thống này làm được gì với bài toán của TÔI, quy trình của TÔI, và các ràng buộc của TÔI?" $\rightarrow$ Tạo ra sự tin tưởng.

Thiết kế minh chứng cho thấy giải pháp phù hợp với ngữ cảnh của bên mua là một phần nhiệm vụ của bản demo. Một bản demo được thiết kế tốt sẽ thúc đẩy cơ hội, trong khi một bản demo yếu có thể xóa sạch niềm tin mà khâu khai phá đã gây dựng.

Nhánh Đối tác (Partner Track): 4 Quyết định Thiết kế Demo

(Nội dung dành cho Nhánh Đối tác, không kiểm tra trong kỳ thi Architect)

Trước khi dựng bất kỳ màn hình nào, hãy đưa ra 4 quyết định thiết kế. Những quyết định đó xác định liệu bản demo mang lại cảm giác được may đo chuẩn xác và đáng tin cậy, hay chung chung và dễ bị bác bỏ:

Việc Đặt vị trí Giới hạn cần sự Chú ý Chủ động

Trong 4 quyết định thiết kế demo, đặt vị trí giới hạn là quyết định thường đi ngược lại bản năng nhất. Trong thực tế, việc chỉ ra điểm yếu có cảm giác rủi ro, do đó cám dỗ thường thấy là che giấu hoặc làm nhẹ nó đi. Điều này thường phản tác dụng.

Hãy hình dung khoảnh khắc bên mua hỏi: "Hệ thống này KHÔNG xử lý tốt điều gì?"

• Nếu câu trả lời mơ hồ, sự tin tưởng sẽ sụt giảm.

• Nếu câu trả lời rõ ràng và có phạm vi cụ thể, bên mua sẽ thấy sự kỷ luật thay vì sự phòng thủ.

Đó là lý do tại sao bạn nên quyết định trước 1 đến 2 ràng buộc mà bạn sẽ xướng tên và cách bạn đóng khung chúng. Hãy cho thấy ranh giới đó là có chủ đích — rằng đây là những gì giải pháp được xây dựng để làm, và đây là những gì nó KHÔNG được xây dựng để làm.

Điều này càng quan trọng hơn trong các ngành bị kiểm soát như y tế, dịch vụ tài chính, và khu vực công. Trong những bối cảnh đó, một ranh giới rõ ràng thường phát ra tín hiệu về sự nghiêm ngặt, trong khi sự né tránh phát ra tín hiệu về rủi ro.

Một cách đơn giản để chuẩn bị là tự hỏi:

1. Giới hạn là gì?

2. Tại sao nó lại tồn tại?

3. Điều gì xảy ra nếu use case vượt quá giới hạn đó?

Đồng xác định Phạm vi (Joint Scoping) Thành công Bắt đầu trước khi Buổi họp Bắt đầu

(Nội dung dành cho Nhánh Đối tác, không kiểm tra trong kỳ thi Architect)

Kỷ luật tương tự cũng được áp dụng trực tiếp vào buổi đồng xác định phạm vi với đội ngũ Applied AI. Một buổi scoping tốt không phải là nơi để bắt đầu tìm hiểu những điều cơ bản lần đầu tiên. Nó là nơi để tinh chỉnh các lựa chọn, kiểm thử các giả định, và giải quyết các câu hỏi cần sự tham vấn của chuyên gia.

Nếu bản demo chứng minh bạn hiểu bài toán của bên mua, thì buổi scoping chứng minh bạn đã sẵn sàng định hình một giải pháp đáng tin cậy xung quanh bài toán đó. Điều đó chỉ hoạt động nếu bạn đến buổi họp với 3 điều đã chuẩn bị sẵn:

1. Một góc nhìn được tài liệu hóa về các yêu cầu và ràng buộc của khách hàng: Thu thập những gì rút ra từ khâu khai phá (use case, quy trình, các bên liên quan, điều kiện dữ liệu, môi trường kỹ thuật, mối quan tâm tuân thủ, và tiêu chí thành công). Điều này mang lại một điểm khởi đầu chung cho buổi làm việc.

2. Đề xuất một mẫu kiến trúc hoặc một nhóm nhỏ các mẫu ứng viên, với các đánh đổi đã được gọi tên: Hãy bước vào với một quan điểm rõ ràng. Chỉ ra các tùy chọn khả thi, những gì mỗi tùy chọn mang lại, những gì nó phải đánh đổi, và rủi ro nằm ở đâu.

3. Một danh sách ngắn các câu hỏi mở mà đội ngũ Applied AI có vị thế tốt nhất để trả lời: Đây là các câu hỏi đáng để dành thời gian trong buổi họp (hành vi mô hình, hệ quả kiến trúc, ràng buộc mở rộng quy mô, phương pháp đánh giá eval, cân nhắc an toàn, hoặc sự phù hợp của mẫu).

Các Phản bác được chia thành các Danh mục Khác nhau, và mỗi Danh mục đòi hỏi một Phản hồi Khác nhau

Các phản bác kỹ thuật (technical objections) trong một chu kỳ bán hàng thường rơi vào 3 danh mục:

1. Phản bác về Năng lực (Capability objections): Hỏi liệu hệ thống có thể làm được điều đó hay không.

2. Phản bác về Quản trị & Tuân thủ (Governance & Compliance objections): Hỏi liệu bản triển khai có thể được tin tưởng, kiểm soát, và chứng minh theo cách mà bên mua có thể bảo vệ hay không.

3. Phản bác về Lựa chọn Thiết kế (Design-choice objections): Hỏi tại sao bạn lại đưa ra lựa chọn này thay vì lựa chọn khác.

Những phản bác này đòi hỏi nhiều hơn là sự biện minh thuần túy. Bạn cần giải thích sự đánh đổi mà lựa chọn đó tạo ra và phương án thay thế sẽ tốn chi phí thế nào, sử dụng cùng một cấu trúc chuyển dịch mà bạn đã dùng khi trình bày sự đánh đổi ban đầu.

(Nội dung Nhánh Đối tác): Bản đồ tương tác go-to-market nên đối xử với thiết kế demo như một luồng công việc được theo dõi (tracked workstream). Đó là lý do tại sao nó bao gồm một cột thiết kế demo với kịch bản, các giới hạn được nhận diện, nguồn dữ liệu được xác nhận, và sự ký duyệt của đội ngũ bán hàng dưới dạng các sản phẩm bàn giao minh bạch. Điều này quan trọng nhất khi một đối tác đang chạy các cơ hội song song hoặc khi các Kiến trúc sư bàn giao giữa chu kỳ, vì tính liên tục phụ thuộc cốt yếu vào những gì được tài liệu hóa.

Chi phí · Độ phức tạp · Rủi ro

• Chi phí (Cost): Việc chuẩn bị một bài trình bày đánh đổi và một bản demo theo kịch bản cụ thể tiêu tốn thời gian thực sự của Kiến trúc sư, nhưng nó ít đắt đỏ hơn nhiều so với một cơ hội bị đình trệ hoặc một sự phê duyệt mà bên liên quan sau đó rút lại.

• Độ phức tạp (Complexity): 3 kỹ năng riêng biệt nằm bên dưới phần việc này, và 2 trong số đó thường đi ngược lại bản năng: gọi tên chi phí đảo ngược (reversal cost) và đặt vị trí giới hạn một cách minh bạch. Cả hai đều đòi hỏi sự thực hành chủ động để nâng cao.

• Rủi ro (Risk): Thất bại đắt giá nhất là Sự đồng thuận giả tạo (False alignment). Khi một quyết định có vẻ đã được phê duyệt trong phòng họp, nhưng chi phí đảo ngược chưa bao giờ được làm rõ, và hậu quả phát sinh sau đó.