Cuộc gọi Khai phá bị biến thành một Buổi Thiết kế

Kịch bản dẫn nhập (Setup)

Khai phá (Discovery) là nơi công việc bắt đầu. Thiết kế (Design) là nơi nó tăng tốc. Một Kiến trúc sư giỏi thường bắt đầu hình thành giải pháp ngay giữa cuộc gọi. Việc phác thảo và trực quan hóa giải pháp mang lại cảm giác rất hiệu quả, và bên liên quan (stakeholder) trông có vẻ rất hài lòng khi thấy tiến độ công việc. Đó chính xác là thời điểm mà các câu hỏi dừng lại.

Phân tích một Cuộc gọi Khai phá bị tái hiện lại: Nơi các câu hỏi bị dừng lại quá sớm

Trong đoạn trao đổi dưới đây, Kiến trúc sư nghe thấy hai phát biểu từ bên liên quan và bắt đầu đề xuất giải pháp ngay lập tức. Bên liên quan xác nhận đề xuất ban đầu vì nghe có vẻ rất chuyên nghiệp. Các ràng buộc lẽ ra sẽ loại bỏ kiến trúc đó lại chưa bao giờ được nhận diện. Chúng chỉ lộ ra 2 tuần sau đó trong đợt rà soát tuân thủ (compliance review).

Đoạn này chỉ ra chính xác vị trí mà câu hỏi lẽ ra phải được đặt ra để bắt giữ từng ràng buộc. Hãy dùng ví dụ này để học cách nhận diện mẫu sai lầm tương tự trong các cuộc gọi của chính bạn.

Đoạn trao đổi được tái hiện lại (Reconstructed exchange):

• Bên liên quan (Stakeholder): "Chúng tôi vận hành một mạng lưới bệnh viện khu vực. Các điều dưỡng viên mất quá nhiều thời gian để viết báo cáo tương tác với bệnh nhân. Chúng tôi muốn Claude phác thảo ghi chú lâm sàng (clinical note) từ bản đọc lời thoại (dictation) của họ."

• Kiến trúc sư (Architect): "Hiểu rồi, đó chỉ là một mẫu gia tăng (augmented pattern) thuần túy. Claude nhận bản đọc lời thoại, phác thảo ghi chú có cấu trúc, sau đó ghi ngược lại hệ thống. Chúng tôi có thể có một bản thử nghiệm (prototype) vào tuần tới."

• Bên liên quan (Stakeholder): "Nghe có vẻ đúng đấy. Có một bước rà soát ở đâu đó trong quy trình, nhưng nó chỉ là một đợt kiểm tra nhanh thôi."

• Kiến trúc sư (Architect): "Chắc chắn rồi, chúng tôi sẽ thêm một bước rà soát. Để tôi bắt đầu phác thảo bản thiết kế nhé."

Hàng loạt Ràng buộc được Nhận diện quá Trễ để có thể Sửa chữa Dễ dàng

• Cổng rà soát bị hiểu sai: Bước "kiểm tra nhanh" không phải là một tính năng tiện ích tùy chọn. Quy trình làm việc của điều dưỡng bắt buộc một bác sĩ lâm sàng có giấy phép hành nghề phải phê duyệt bất kỳ đầu ra nào của mô hình trước khi nó đi vào hồ sơ bệnh nhân. Điều này biến sự phê duyệt của con người thành một cổng kiến trúc bắt buộc (required architectural gate) chứ không phải là một phần bổ sung tùy chọn.

• Xử lý dữ liệu nhạy cảm (PHI): Bản đọc lời thoại có chứa thông tin sức khỏe được bảo vệ (Protected Health Information - PHI). Dữ liệu PHI này đã di chuyển qua cửa sổ ngữ cảnh mà không có các cơ chế xử lý quy chuẩn mà quy trình yêu cầu.

• Ràng buộc lưu trữ đa vùng: Mạng lưới bệnh viện trải rộng trên 2 bang với các quy định lưu trữ bản ghi (record-retention rules) khác nhau, và bản thiết kế đơn vùng (single-region design) ban đầu chưa bao giờ tính đến một trong hai quy định đó.

Không có yêu cầu nào trong số này là bất thường hay khó tìm. Mỗi yêu cầu lẽ ra đã xuất lộ từ một câu hỏi trực tiếp trong các danh mục "Hệ thống phải chứng minh điều gì (must-prove)" và "Hệ thống không được phép làm gì (must-not-do)", nếu như cuộc gọi không chuyển sang giai đoạn phác thảo trước khi các câu hỏi đó được đặt ra.

Tại sao điều này lại gây ra sự cố?

Một bản phác thảo đề xuất có vẻ hợp lý đã chấm dứt sớm các câu hỏi mà một cuộc gọi khai phá sinh ra để hỏi.

Tính hợp lý (plausibility) chính là thứ khiến kịch bản này trở nên nguy hiểm. Một bên liên quan khi nghe thấy một kiến trúc tự tin sẽ giả định rằng Kiến trúc sư đã có đủ thông tin để xây dựng nó.

Thao tác giúp bảo vệ bạn tuy nhàm chán nhưng bắt buộc: Hãy hoàn tất trọn vẹn bộ 4 danh mục câu hỏi trước khi đề xuất bất kỳ điều gì, và hãy đối xử với mọi câu nói "nó chỉ là một đợt rà soát..." như một ràng buộc sinh tử cần phải truy vết đến cùng.