Một bản đề xuất đẹp có thể che giấu một mô hình triển khai mù mờ. Mười hai câu hỏi làm mô hình đó lộ ra, và cách chấm điểm các câu trả lời.
Chỉ là thông tin chung, cập nhật tại thời điểm đăng bài, không phải tư vấn pháp lý hay tư vấn mua sắm. Ghi chú đầy đủ ở cuối bài.
Bản đề xuất được viết ra để đem ra so sánh, và chính vì thế chúng hết tác dụng đúng vào lúc so sánh. Hai đội báo giá cùng một phạm vi với mức giá tương đương vẫn có thể mang rủi ro hoàn toàn khác nhau, và sự khác biệt đó không nằm trong tài liệu. Nó xuất hiện bốn tháng sau, ở cách công việc thực sự vận hành.
Các câu hỏi dưới đây được thiết kế để làm lộ sự khác biệt đó trước khi ký chứ không phải sau. Chúng bao quát bốn mảng: discovery, triển khai, kiểm soát và bàn giao. Mỗi câu có một kiểu trả lời giúp phân biệt đội có mô hình triển khai với đội chỉ có một bộ slide bán hàng. Chúng tôi sẵn sàng được hỏi cả mười hai câu, và chúng tôi kỳ vọng bất kỳ đối tác software engineering nghiêm túc nào cũng vậy.
Câu 1 đến 3 nói về discovery, và mọi thứ phía sau đều phụ thuộc vào chúng. Một đối tác làm sai discovery sẽ không biết cho đến khi bản ước tính đổ vỡ, lúc đó ngân sách discovery đã tiêu hết.
Một đối tác đáng tin sẽ tách bạch dữ kiện, giả định và các quyết định còn bỏ ngỏ, và nói được họ cần chốt những mục nào trước khi xác nhận phạm vi, kiến trúc hay chi phí. Hãy cảnh giác với điều ngược lại: một bản ước tính đưa ra nhanh và tự tin, còn các giả định thì để ngầm. Con số đó chưa sai, nhưng không ai nói được điều gì sẽ khiến nó sai.
Màn hình và user story chỉ mô tả bề mặt. Đội ngũ cần hỏi về trigger, quyết định, ngoại lệ, dữ liệu, người sở hữu và hệ quả vận hành, đặc biệt là đường xử lý ngoại lệ, nơi chứa phần lớn chi phí thật và cũng là nơi hầu hết câu hỏi dừng lại. Nếu bạn đã có lập trình viên nội bộ, hãy hỏi cụ thể đội của đối tác sẽ làm việc cùng họ ra sao, vì một câu trả lời không được nói rõ thường biến thành tranh chấp ranh giới vào tháng thứ hai.
Hãy tìm bản đồ phụ thuộc, phân tích giao diện, quyền sở hữu dữ liệu và kế hoạch chuyển tiếp. Hãy thận trọng với đề xuất mặc định viết lại từ đầu mà không có bằng chứng rằng viết lại là con đường rẻ hơn. Viết lại là cách đắt nhất để khám phá vì sao hệ thống cũ lại làm một việc kỳ lạ.
Câu 4 đến 6 chuyển từ discovery sang triển khai. Chúng kiểm tra cùng một điều từ các góc khác nhau: liệu bạn có biết dự án đang đi thế nào mà không cần ai nói cho biết.
Câu trả lời phải vượt xa "chúng tôi có QA". Hãy hỏi về tiêu chí chấp nhận, review code và thiết kế, kiểm thử tự động và exploratory, kiểm thử hiệu năng và bảo mật, xu hướng lỗi và bằng chứng phát hành. Câu hỏi nối tiếp hữu ích là mục nào áp dụng cho một thay đổi chạm tới tiền hoặc dữ liệu khách hàng và mục nào không. Một đội áp dụng mức khắt khe y hệt ở mọi nơi là đội chưa nghĩ về rủi ro, họ chỉ mua một quy trình.
Các quyết định quan trọng cần ghi lại bối cảnh, các phương án đã cân nhắc, đánh đổi, người sở hữu và hệ quả, và bạn phải có thể rà soát và giữ chúng. Điều này quan trọng nhất vào đúng lúc bất tiện nhất: khi hai năm sau có người hỏi vì sao hệ thống làm một việc mà bây giờ trông có vẻ sai.
Tiến độ nên hiện ra qua các increment chạy được, rủi ro, quyết định và kết quả, chứ không phải qua tỷ lệ sử dụng nhân sự hay phần trăm hoàn thành. Phần trăm hoàn thành là con số duy nhất không thể kiểm chứng từ bên ngoài, và nó che giấu rủi ro tích hợp lâu nhất. Các chỉ số giao phần mềm của DORA là một tham chiếu bên ngoài hợp lý cho việc sức khỏe của quá trình giao hàng trông thế nào, dù chúng mô tả thông lượng và độ ổn định của một đội chứ không cho biết đội đó có đang xây đúng thứ cần xây hay không.
Câu 7 đến 9 nói về kiểm soát: điều gì xảy ra khi có chuyện hỏng, hoặc khi có người hỏi. Đây là nơi khoảng cách giữa một bài thuyết trình và một mô hình vận hành rộng nhất, vì câu trả lời phụ thuộc vào việc đã từng làm chứ không phải đã lên kế hoạch.
Hãy hỏi yêu cầu nào đi vào kiến trúc, backlog, kiểm thử, phê duyệt phát hành và giám sát, và xin các artifact mẫu đã xóa chi tiết bí mật. Hướng dẫn systems security engineering của NIST là một điểm tham chiếu hữu ích cho việc điều đó trông thế nào về mặt cấu trúc. Dấu hiệu cảnh báo là bảo mật chỉ được mô tả qua chứng chỉ: chứng chỉ cho biết một tổ chức đã qua một đợt kiểm toán, chứ không cho biết một yêu cầu sẽ đi vào backlog của dự án của bạn.