Phân hệ PM Study
  • Tình huốngTình huống thực chiến
  • Kịch bảnRa quyết định tình huống
  • Biểu mẫuKho biểu mẫu tải về
  • Thẻ ghi nhớHọc thuật ngữ PMP
  • Công cụMáy tính EVM, PERT, dự phòng
  • Hỏi đápHỏi đáp & thảo luận
  • Thử tháchMỗi ngày một câu hỏi PMP
  • Lý thuyếtBài học PMBOK 8 & ECO 2026
  • Luyện thiThi thử & ôn tập PMP
  • Bài viếtThư viện bài viết PMP
PM Study
Trang chủLý thuyếtTình huốngLuyện thiBiểu mẫuHỏi đáp
6 chuyên mụcXem tất cả bài viết →
  • Quản lý các bên liên quanTình huống về kỳ vọng, giao tiếp và gắn kết stakeholder.
  • Lãnh đạo & đội nhómXây dựng, dẫn dắt và giải quyết xung đột trong đội dự án.
  • Kế hoạch & tiến độLập kế hoạch, ước lượng, nén tiến độ và kiểm soát baseline.
  • Rủi ro & thay đổiNhận diện, ứng phó rủi ro và kiểm soát thay đổi phạm vi.
  • Agile & HybridLựa chọn và vận hành cách tiếp cận Agile, Predictive, Hybrid.
  • Luyện thi PMPChiến lược ôn tập và mẹo xử lý câu hỏi tình huống PMP.
Công cụBài viết
Trang chủLý thuyếtTình huốngLuyện thiBiểu mẫuHỏi đápChuyên mụcCông cụBài viết
/
PM Study

Học quản lý dự án và ôn thi PMP bằng tiếng Việt: lý thuyết PMBOK® Guide 8, tình huống thực tế và đề luyện thi theo ECO 2026.

Chuyên mục

  • Quản lý các bên liên quan
  • Lãnh đạo & đội nhóm
  • Kế hoạch & tiến độ
  • Rủi ro & thay đổi
  • Agile & Hybrid
  • Luyện thi PMP

Tài nguyên

  • Project Management Institute (PMI)
  • PMP Exam Content Outline
  • The Scrum Guide
  • PMI Vietnam Chapter

PM Study

  • Tất cả bài viết
  • Bài viết nổi bật
© 2026 PM StudyPMP® và PMBOK® là nhãn hiệu đã đăng ký của Project Management Institute.Phiên bản 1.12.1
  1. /Tình huống
  2. /Quản lý Chất lượng
  3. /Mars Climate Orbiter (1999): lệch đơn vị đo giữa…
Số 50Quản lý Chất lượng

Mars Climate Orbiter (1999): lệch đơn vị đo giữa hai đội và bài học kiểm chứng giao diện đầu–cuối

Tàu Mars Climate Orbiter trị giá khoảng 327,6 triệu USD bị mất khi tiếp cận sao Hỏa vì một phần mềm mặt đất xuất dữ liệu theo đơn vị Anh (pound-force giây) trong khi bên nhận dùng hệ mét. Phân tích vì sao lỗi nhỏ lọt qua mọi lớp kiểm soát chất lượng và PM nên làm gì.

HP
Nguyễn Thu Hà, PMP
25/09/2026
5 phút đọc 0 lượt xem
Mars Climate Orbiter (1999): lệch đơn vị đo giữa hai đội và bài học kiểm chứng giao diện đầu–cuối
Bình luận0

Bối cảnh thực tế

Mars Climate Orbiter được phóng ngày 11/12/1998, là một phần chương trình thám hiểm sao Hỏa của NASA với chi phí toàn nhiệm vụ khoảng 327,6 triệu USD. Ngày 23/9/1999, khi thực hiện thao tác vào quỹ đạo, tàu đi vào khí quyển sao Hỏa thấp hơn rất nhiều so với kế hoạch và bị mất liên lạc vĩnh viễn.

Nguyên nhân gốc được Hội đồng điều tra sự cố (Mishap Investigation Board) xác định: một phần mềm mặt đất tính xung lực của động cơ đẩy (ứng dụng SM_FORCES) xuất kết quả theo pound-force giây, trong khi đặc tả giao diện yêu cầu newton giây. Sai lệch hệ số 4,45 âm thầm làm méo toàn bộ mô hình quỹ đạo.

Các dấu hiệu bất thường đã xuất hiện trước đó:

  • Trong giai đoạn bay hành trình, ít nhất hai chuyên viên dẫn đường nhận thấy vị trí tính toán lệch với vị trí đo được, nhưng mối lo ngại không được xử lý qua kênh chính thức.
  • Lần hiệu chỉnh quỹ đạo cuối cùng (TCM-5) được bàn đến nhưng không thực hiện.
  • Đội dẫn đường nhỏ, quá tải, liên lạc chủ yếu không chính thức và không có rà soát đồng cấp độc lập.
  • Tàu dự kiến vào ở độ cao khoảng 226 km nhưng thực tế xuống khoảng 57 km — thấp hơn ngưỡng tàu có thể chịu đựng.

Phân tích nguyên nhân theo chuẩn PMP

  • Lập kế hoạch chất lượng (Plan Quality Management) bỏ trống phần giao diện

    Đặc tả giao diện có ghi đơn vị, nhưng kế hoạch quản lý chất lượng không biến yêu cầu đó thành tiêu chí kiểm tra bắt buộc cho từng tệp dữ liệu trao đổi giữa hai tổ chức. Chất lượng được lập kế hoạch chứ không phải kiểm tra mà có: khi điểm giao giữa nhà thầu và đơn vị vận hành không có chỉ số chất lượng (quality metrics) cụ thể, lỗi sẽ đi lọt qua khe hở trách nhiệm.

  • Thiếu kiểm chứng đầu–cuối (end-to-end verification)

    Hội đồng điều tra nêu rõ phần mềm dẫn đường và các mô hình máy tính liên quan không được kiểm chứng đầy đủ từ đầu đến cuối. Từng mô-đun có thể "đạt" ở mức đơn vị, nhưng không ai kiểm tra dữ liệu thực khi chảy qua cả chuỗi. Đây là khoảng trống điển hình giữa kiểm chứng (verification — đúng đặc tả) và xác nhận (validation — đáp ứng nhu cầu sử dụng thực tế).

  • Đảm bảo chất lượng (Manage Quality) bị thay bằng liên lạc không chính thức

    Các trao đổi kỹ thuật quan trọng diễn ra qua kênh không chính thức, quy trình báo cáo bất thường (anomaly reporting) không được dùng. Theo tinh thần Manage Quality, quy trình phải tạo được cơ chế để dữ liệu bất thường bắt buộc được ghi nhận, phân tích và đóng lại — thay vì phụ thuộc vào việc một người có đủ kiên trì để lên tiếng hay không.

  • Bỏ qua tín hiệu từ dữ liệu kiểm soát (Control Quality)

    Độ lệch giữa quỹ đạo dự báo và quỹ đạo đo được chính là một "điểm ngoài giới hạn kiểm soát" trên biểu đồ kiểm soát (control chart). Khi tín hiệu đó không kích hoạt phân tích nguyên nhân gốc (root cause analysis), tổ chức đánh mất cơ hội rẻ nhất để sửa lỗi. Phát biểu của lãnh đạo NASA sau sự cố tóm gọn vấn đề: lỗi không đáng sợ bằng việc hệ thống kiểm tra chéo không phát hiện ra lỗi.

  • Chi phí chất lượng (Cost of Quality) bị đảo ngược

    Một bộ kiểm tra đơn vị tự động trên tệp dữ liệu giao diện, hay một buổi rà soát độc lập, có chi phí phòng ngừa rất nhỏ. Chi phí thất bại bên ngoài (external failure cost) ở đây là toàn bộ con tàu và nhiều năm công sức. Đây là minh hoạ kinh điển cho nguyên lý: chi phí phòng ngừa và thẩm định luôn rẻ hơn chi phí thất bại.

  • Lẽ ra PM nên làm gì

    1. 1

      Bước 1: Lập tài liệu kiểm soát giao diện (Interface Control Document) có chủ sở hữu

      Mỗi luồng dữ liệu giữa các nhóm/nhà thầu phải có một người chịu trách nhiệm, định dạng, đơn vị, dải giá trị hợp lệ và cách kiểm tra. Đưa tài liệu này vào đường cơ sở (baseline) và kiểm soát thay đổi.

    2. 2

      Bước 2: Đặt tiêu chí chấp nhận cho mọi tệp dữ liệu trao đổi

      Quy định trong kế hoạch quản lý chất lượng và kiểm tra tự động trước khi dữ liệu được dùng:

      • Đơn vị và định dạng

        Tệp phải khai báo đơn vị trong siêu dữ liệu; sai đơn vị hoặc thiếu khai báo thì bị từ chối tự động.

      • Kiểm tra hợp lý (sanity check)

        So sánh giá trị nhận được với mô hình độc lập; lệch quá ngưỡng đã thống nhất thì dừng và mở phiếu bất thường.

      • Kiểm chứng đầu–cuối

        Mỗi phiên bản phần mềm mặt đất chạy lại kịch bản kiểm thử toàn chuỗi với dữ liệu bay mô phỏng trước khi đưa vào vận hành.

    3. 3

      Bước 3: Chính thức hoá quy trình báo cáo bất thường

      Mọi sai lệch dẫn đường vượt ngưỡng phải được ghi vào nhật ký vấn đề (issue log), có người phân tích, thời hạn đóng và cấp phê duyệt rõ ràng. Không để mối lo ngại kỹ thuật "chết" trong email hay hành lang.

    4. 4

      Bước 4: Bố trí rà soát độc lập và đủ nguồn lực

      Với hạng mục rủi ro cao như dẫn đường, cần rà soát đồng cấp (peer review) độc lập và kiểm toán chất lượng (quality audit) định kỳ. Đội quá tải là tín hiệu rủi ro chất lượng — PM phải đưa vào sổ đăng ký rủi ro và đề xuất bổ sung nguồn lực.

    5. 5

      Bước 5: Huấn luyện và chuyển giao khi đổi đội vận hành

      Hội đồng điều tra ghi nhận khoảng trống kiến thức khi chuyển sang đội vận hành mới. Kế hoạch chuyển giao phải có buổi trình bày khác biệt so với nhiệm vụ trước, danh sách giả định và bài kiểm tra hiểu biết.

    PM Takeaway (Bài học rút ra)

    Lỗi nghiêm trọng nhất thường nằm ở điểm giao giữa các nhóm, nơi ai cũng nghĩ người kia đã kiểm tra. PM phải biến mỗi giao diện thành một hạng mục chất lượng có chủ sở hữu, tiêu chí chấp nhận và kiểm chứng đầu–cuối, và coi mọi dữ liệu bất thường là tín hiệu cần phân tích chứ không phải nhiễu.

    Nguồn tham khảo

    • NASA – Thông cáo kết quả Hội đồng điều tra sự cố Mars Climate Orbiter (Phase I, 1999)
    • Wikipedia – Mars Climate Orbiter
    #Quản lý chất lượng#Kiểm chứng và xác nhận#Quản lý giao diện#Phân tích nguyên nhân gốc#NASA

    Nguồn: Mars Climate Orbiter Mishap Investigation Board – Phase I Report (thông cáo NASA, 10/11/1999) ↗ (mở trong thẻ mới)

    Trắc nghiệm tình huống PMP

    Câu 1/1
    Dự án tích hợp hệ thống có hai nhà thầu cùng cung cấp dữ liệu cho một mô-đun tính toán trung tâm. Trong kiểm thử tích hợp, một kỹ sư phát hiện kết quả mô phỏng lệch nhẹ nhưng nhất quán so với số liệu đo thực tế. Trưởng nhóm cho rằng mức lệch "trong sai số chấp nhận được" và đề nghị tiếp tục theo lịch. PM nên làm gì trước tiên?

    Bạn chọn phương án nào?

    Nếu là PM một dự án có nhiều nhà thầu trao đổi dữ liệu kỹ thuật, ngân sách chất lượng chỉ đủ cho một khoản đầu tư lớn, bạn chọn gì?

    Tình huống này hữu ích với bạn?

    Bình luận0

    Bình luận (0)

    Đăng nhập để tham gia thảo luận.

    Tình huống cùng lĩnh vực

    Quản lý Chất lượng

    Cloudflare 02/07/2019: một quy tắc WAF được đẩy toàn cầu trong vài giây, không qua canary, làm CPU toàn mạng kịch trần

    Ngày 02/07/2019, một thay đổi nhỏ trong bộ quy tắc WAF của Cloudflare chứa biểu thức chính quy gây backtracking khủng khiếp, khiến CPU của mọi máy xử lý HTTP/HTTPS trên toàn cầu gần như 100% và khách hàng nhận lỗi 502 khoảng 27 phút. Bài học về kiểm thử hiệu năng trong CI, quy trình triển khai theo giai đoạn và việc "ngoại lệ khẩn cấp" trở thành đường tắt mặc định.

    0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận15/10/2026
    Số 149Quản lý Chất lượng

    Facebook ngoại tuyến 04/10/2021: một lệnh bảo trì, công cụ kiểm tra có lỗi và hệ thống khôi phục phụ thuộc chính mạng đã sập

    Ngày 04/10/2021, một lệnh bảo trì định đánh giá dung lượng mạng xương sống đã ngắt toàn bộ kết nối giữa các trung tâm dữ liệu của Facebook; công cụ kiểm tra lệnh có lỗi nên không chặn được. DNS biến mất khỏi Internet, công cụ nội bộ hỏng theo và kỹ sư phải đến tận nơi. Phân tích dưới góc nhìn kiểm soát thay đổi, kiểm thử tình huống thảm hoạ và phụ thuộc vòng của công cụ khôi phục.

    0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận11/10/2026
    Số 150Quản lý Chất lượng

    Amazon S3 ngày 28/02/2017: một tham số nhập sai trong lệnh gỡ máy chủ làm gián đoạn dịch vụ lưu trữ khoảng 4 giờ 17 phút

    Trong lúc điều tra hệ thống tính phí S3 chạy chậm, một thành viên được ủy quyền chạy lệnh trong playbook nhưng nhập sai một tham số, gỡ ra nhiều máy chủ hơn dự định ở vùng US-EAST-1. AWS sau đó sửa công cụ để gỡ chậm hơn, chặn việc đưa hệ thống xuống dưới dung lượng tối thiểu và rà soát các công cụ khác. Bài học về thiết kế công cụ vận hành chống lỗi người.

    0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận06/10/2026

    Nội dung

    Bối cảnh thực tếPhân tích nguyên nhân theo chuẩn PMPLẽ ra PM nên làm gìPM Takeaway (Bài học rút ra)Nguồn tham khảoTrắc nghiệmBình chọn
    Quảng cáoBộ đề thi thử PMP (mẫu)