Đánh giá nhà cung cấp như thế nào? 7 bằng chứng cần xin

Đánh giá nhà cung cấp phần mềm bằng cách xin bảy loại bằng chứng: tài liệu đặc tả, kiến trúc đề xuất, báo cáo kiểm thử, sổ tay vận hành, mã nguồn mẫu, người tham chiếu và biên bản sự cố. Mỗi loại chứng minh một năng lực khác nhau, và mỗi loại có cách đọc riêng.

Tóm tắt nhanh

• Câu hỏi đúng không phải "các anh giỏi không" mà "cho tôi xem một sản phẩm của quy trình này". Bằng chứng là tài liệu hoặc sản phẩm đọc được, không phải lời mô tả.
• Bảy bằng chứng dưới đây xếp theo độ tin cậy giảm dần: sản phẩm chạy được, tài liệu đối chiếu được, người tham chiếu, rồi lời kể.
• Bằng chứng chuẩn bị cho buổi họp thường quá đẹp: không ngày, không tên người viết, không phiên bản. Bằng chứng thật có vết sửa và có lịch sử.
• Một bên từ chối cung cấp bằng chứng đã khử thông tin khách hàng là một câu trả lời, không phải một trở ngại.

Nguyên tắc: xin bằng chứng, không xin lời hứa

Trong một buổi đánh giá, mọi câu trả lời đều đúng. Câu "các anh có quy trình kiểm thử không" luôn nhận được câu "có", nên nó không có giá trị thông tin.

Câu hỏi có giá trị yêu cầu một vật cụ thể: "cho tôi xem một báo cáo kiểm thử của dự án đã khử thông tin khách hàng". Câu trả lời không thể là "có"; nó phải là một tệp, hoặc một lời từ chối.

Nguyên tắc thứ hai: bằng chứng phải có vết. Tài liệu thật có số phiên bản, có ngày và có lịch sử thay đổi; tài liệu làm riêng cho buổi họp thường hoàn hảo bất thường.

Bảy bằng chứng cần xin

Đọc từng loại bằng chứng

1. Tài liệu đặc tả

Đây là bằng chứng quan trọng nhất vì nó dự báo chất lượng của toàn bộ dự án. Đọc ba thứ: mã yêu cầu, tiêu chí kiểm chứng, và mục ngoài phạm vi.

Nếu mỗi yêu cầu có mã như FR-ORD-01 và mỗi mã có tiêu chí kiểm chứng quan sát được, bên đó có quy trình. Nếu yêu cầu viết thành đoạn văn, không mã và không tiêu chí, bên đó đang làm theo cảm nhận và sẽ tranh luận với bạn ở khâu nghiệm thu. Mục ngoài phạm vi là dấu hiệu của kinh nghiệm: một tài liệu không có mục "không bao gồm" là tài liệu chưa từng được dùng để nghiệm thu.

2. Kiến trúc đề xuất

Yêu cầu bên đó viết một trang kiến trúc cho chính bài toán của bạn, không trình bày kiến trúc chung. Trang đó cần bốn phần: các thành phần, ranh giới giữa chúng, luồng dữ liệu chính, và lý do chọn phương án này thay vì phương án khác.

Phần thứ tư phân biệt rõ nhất: bên chỉ liệt kê công nghệ đang dùng là bên chưa thiết kế cho bài toán của bạn, còn bên nêu được "chúng tôi cân nhắc X nhưng loại vì chi phí vận hành" đã làm việc này nhiều lần.

3. Báo cáo kiểm thử

Xin một báo cáo của dự án cũ, đã khử tên khách hàng và tên chức năng nhạy cảm. Đọc bốn con số: số kịch bản kiểm thử, số đạt, số lỗi còn mở, và số lỗi đã đóng trong kỳ.

Một báo cáo có số lỗi mở lớn hơn không là bình thường và đáng tin hơn một báo cáo có số lỗi bằng không, vì không hệ thống nào không có lỗi mở tại một thời điểm.

4. Sổ tay vận hành

Đây là bằng chứng hay bị bỏ qua nhất và cũng dự báo chi phí dài hạn tốt nhất. Sổ tay vận hành cho biết sau bàn giao ai làm gì: cách triển khai phiên bản mới, cách sao lưu và phục hồi, cách xem log, cách xử lý khi dịch vụ chậm.

Nếu bên đó không có sổ tay vận hành cho dự án cũ, khả năng cao họ cũng không viết cho dự án của bạn, và chi phí vận hành sẽ rơi vào đội của bạn.

5. Mẫu mã nguồn và lịch sử rà soát

Không cần xin toàn bộ mã nguồn. Xin một mô-đun nhỏ đã khử thông tin, và xin lịch sử rà soát của mô-đun đó. Đọc ba thứ: cấu trúc thư mục có rõ ràng không, có kiểm thử tự động đi kèm không, và có lịch sử rà soát bởi người khác ngoài người viết không.

Điểm thứ ba quan trọng nhất: một đội không rà soát chéo mã sẽ để lỗi tích lũy, và chi phí sửa tăng theo thời gian. Lịch sử rà soát là bằng chứng khó ngụy tạo nhất trong cả bảy loại.

6. Người tham chiếu

Đừng nhận danh sách người tham chiếu do nhà cung cấp chọn rồi hỏi những câu chung. Soạn ba câu và yêu cầu hỏi đúng ba câu đó:

• "Điều gì khó khăn nhất trong dự án đó?"
• "Khi tiến độ lệch, bên đó xử lý thế nào?"
• "Nếu làm lại, anh chị sẽ thay đổi điều gì trong hợp đồng?"

Ba câu này lấy được thông tin mà câu "anh chị có hài lòng không" không lấy được. Một người chỉ khen mà không nêu khó khăn nào là người được chọn để khen.

7. Biên bản sự cố

Đây là bằng chứng về văn hoá vận hành. Xin một biên bản phân tích sự cố đã xử lý, đã khử thông tin khách hàng. Đọc xem biên bản có nêu nguyên nhân gốc hay chỉ nêu hiện tượng, có hành động khắc phục kèm người chịu trách nhiệm hay không.

Một bên trả lời "chúng tôi chưa từng có sự cố" là bên chưa từng vận hành hệ thống thật, hoặc đang không trung thực. Cả hai đều là thông tin bạn cần trước khi ký.

Cách sắp xếp buổi đánh giá

Thứ tự trình bày ảnh hưởng tới kết quả. Bốn bước dưới đây giảm hiệu ứng neo.

1. Gửi bộ câu hỏi bằng chứng trước buổi họp. Bên nào chuẩn bị được sẽ thể hiện ngay ở chất lượng tài liệu mang tới.
2. Yêu cầu gửi tài liệu trước, không trình bày trong buổi họp. Bạn đọc trước, ghi câu hỏi, rồi dùng buổi họp để hỏi về chỗ chưa rõ.
3. Bắt đầu bằng câu hỏi của bạn, không bằng phần giới thiệu của họ. Điều này tránh việc khung so sánh do bên trình bày đặt ra.
4. Ghi biên bản ngay trong buổi họp. Biên bản ghi sau sẽ mất chi tiết và bị điều chỉnh bởi ấn tượng chung. Cuối buổi, yêu cầu mỗi bên nêu một điểm họ chưa chắc chắn về dự án của bạn — bên trả lời được câu này có thói quen nêu giả định.

Ba câu hỏi kiểm tra chéo

Sau khi đọc bằng chứng, ba câu dưới đây giúp phát hiện bằng chứng được làm cho buổi họp.

• Tài liệu này có ngày và phiên bản không? Không có nghĩa là nó được tạo gần đây cho bạn, hoặc chưa từng được dùng.
• Tài liệu có vết sửa không? Tài liệu thật có chỗ sửa, ghi chú, mục lịch sử. Tài liệu hoàn hảo không vết là tài liệu trình diễn.
• Người trong biên bản có trùng với người sẽ làm dự án không? Nếu đội trình bày và đội thực hiện là hai nhóm khác nhau, bằng chứng vừa đọc không chứng minh được năng lực của nhóm sẽ làm việc với bạn.

Câu thứ ba là câu quan trọng nhất và cũng ít được hỏi nhất. Trong nhiều công ty, người bán hàng và người làm kỹ thuật là hai nhóm riêng; nếu vậy, cần gặp đúng nhóm sẽ làm.

Câu hỏi thường gặp

Nhà cung cấp từ chối cung cấp tài liệu vì lý do bảo mật thì sao?

Yêu cầu hợp lý, nhưng có cách xử lý. Đề nghị ký thoả thuận bảo mật trước, hoặc đề nghị xem tài liệu tại văn phòng mà không sao chép. Nếu sau hai phương án đó vẫn bị từ chối, hãy coi đó là thông tin về năng lực: một bên có quy trình thường có sẵn tài liệu đã khử thông tin để chia sẻ.

Có cần xin bằng chứng từ tất cả các bên trong danh sách ngắn không?

Có, nhưng mức độ khác nhau. Với ba bên, xin đủ bảy loại từ hai bên có điểm cao nhất sau khi đọc hồ sơ, và xin ba loại quan trọng nhất từ bên còn lại. Cách này giữ được so sánh mà không biến quy trình thành một dự án phụ.

Bằng chứng nào quan trọng nhất nếu chỉ có thời gian xin một loại?

Tài liệu đặc tả. Nó chứng minh cùng lúc ba thứ: bên đó có quy trình, họ viết được yêu cầu kiểm chứng được, và họ hiểu rằng nghiệm thu phải dựa trên tiêu chí. Nếu chọn loại thứ hai, chọn sổ tay vận hành, vì nó dự báo chi phí dài hạn.

Người tham chiếu do nhà cung cấp giới thiệu có đáng tin không?

Đáng tin ở mức trung bình, với điều kiện bạn hỏi đúng ba câu về khó khăn thay vì hỏi về mức hài lòng. Người tham chiếu do nhà cung cấp chọn thường có quan hệ tốt với họ nên sẽ không nói điều bất lợi lớn. Nhưng câu trả lời về cách xử lý khi tiến độ lệch vẫn cho thông tin cụ thể, và thông tin đó kiểm tra được bằng cách so với biên bản phỏng vấn kỹ thuật.

Cập nhật và kiểm chứng

Cập nhật tháng 10/2026. Nội dung được rà soát theo thông lệ mua sắm phần mềm đang áp dụng và quy trình bốn chặng WinSell áp dụng — Khám phá, Đặc tả, Xây dựng, Bàn giao và đo lường. Bài viết không nêu giá dịch vụ và không sử dụng số liệu khách hàng của bất kỳ bên nào.

Cách chấm điểm bảy loại bằng chứng này thành một quyết định được trình bày trong đánh giá nhà cung cấp; trình tự hồ sơ mời thầu nằm trong quy trình chọn nhà cung cấp; thang điểm đầy đủ để so sánh các bên nằm trong chọn nhà cung cấp; và các mốc dự án mà tài liệu đặc tả phải bám vào nằm trong quy trình phát triển phần mềm là gì.

Nếu bạn muốn nhận bảy loại bằng chứng này từ WinSell trước khi quyết định, xem dịch vụ xây dựng phần mềm theo yêu cầu. Báo giá sau khi chốt phạm vi.