Ghi quyết định để có thể review lại

Giữ lại lập luận

Cuộc họp ra quyết định tạo ra lựa chọn. Hồ sơ quyết định giữ lại lý do lựa chọn đó hợp lý.

Nếu thiếu lập luận, nhóm về sau có thể nhầm ràng buộc tạm thời thành nguyên tắc vĩnh viễn. Nhóm cũng có thể lặp lại đánh giá mà tổ chức đã hoàn tất.

AWS mô tả hồ sơ quyết định kiến trúc là cách ghi quyết định và bối cảnh. Cấu trúc ngắn gọn tương tự có thể hỗ trợ mô hình vận hành phát triển bằng AI. Giữ hồ sơ đủ ngắn để những người chịu trách nhiệm đọc.

So sánh phương án thực tế

Một công ty giả định cần bảo trì ứng dụng hợp đồng. Công ty cân nhắc ba phương án:

Dùng cùng phạm vi ứng dụng, khoảng thời gian, giả định dữ liệu và kỳ vọng dịch vụ. Tránh so sánh dịch vụ mua đã trưởng thành với riêng chi phí prototype của hệ thống nội bộ.

Kết hợp cũng có thể phù hợp. Nền tảng hiện có có thể cung cấp môi trường và triển khai, trong khi software factory điều phối phát triển. Giải thích giao diện và trách nhiệm thay vì ép lựa chọn tất cả hoặc không gì.

Viết sáu phần

1. Bối cảnh. Nêu vấn đề và hậu quả nếu giữ nguyên.
2. Yêu cầu. Liệt kê điều kiện phương án phải đáp ứng.
3. Phương án. Ghi các lựa chọn đáng cân nhắc và đánh đổi chính.
4. Bằng chứng. Liên kết đánh giá, giả định chi phí và câu hỏi chưa giải quyết.
5. Quyết định. Nêu phương án được chọn, phạm vi, người phụ trách và giới hạn đã chấp nhận.
6. Review. Xác định ngày hoặc sự kiện có thể quan sát đòi hỏi đánh giá lại.

Phân biệt điều đã quan sát với điều mong đợi. “Đợt đánh giá đã hoàn tất thay đổi bảo trì này” là quan sát. “Dịch vụ sẽ giảm một nửa chi phí bảo trì hằng năm” là dự báo cần bằng chứng và giả định rõ ràng.

Nêu phản biện mạnh nhất

Đối với ứng dụng hợp đồng, dịch vụ mua có thể giảm công việc tích hợp nhưng tạo phụ thuộc vào nhà cung cấp bên ngoài. Ghi phản biện đó và bài thử xuất dữ liệu giải quyết được một phần lo ngại. Không xóa phản biện vì nhóm thích phương án này.

Nêu mục chưa giải quyết nào chặn việc kích hoạt. Phân công các mục còn lại kèm ngày. Quyết định tiếp tục không biến câu hỏi về biện pháp kiểm soát chưa có đáp án thành kết quả đã kiểm chứng.

Review hồ sơ khi yêu cầu hoặc bằng chứng thay đổi. Thêm quyết định mới khi lựa chọn đổi và giữ lại lập luận trước đó. Tiếp tục với tình huống Taiga thực tế để áp dụng các nguyên tắc này vào workflow sản phẩm.