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. /Tàu Genesis của NASA (2004): cảm biến gia tốc lắ…
Số 321Quản lý Chất lượng

Tàu Genesis của NASA (2004): cảm biến gia tốc lắp ngược và bài kiểm tra ly tâm bị thay bằng việc xem bản vẽ

Sau ba năm thu gió Mặt Trời trong không gian, khoang mẫu của tàu Genesis rơi thẳng xuống sa mạc Utah vì dù không bung. Nguyên nhân: cảm biến gia tốc được thiết kế lắp ngược, và bài kiểm tra ly tâm lẽ ra phát hiện lỗi đã bị bỏ, thay bằng kiểm tra bản vẽ. Bài học về kiểm định (verification), quản lý thay đổi phương pháp kiểm thử và cái bẫy "thiết kế kế thừa".

HP
Nguyễn Thu Hà, PMP
13/05/2026
4 phút đọc 0 lượt xem
Bình luận0

Bối cảnh thực tế

Genesis là sứ mệnh thứ năm của chương trình Discovery, phóng ngày 8/8/2001 với tổng chi phí khoảng 264 triệu USD, nhằm thu các hạt gió Mặt Trời và mang về Trái Đất — lần đầu Mỹ mang vật chất ngoài Trái Đất về kể từ Apollo. Ngày 8/9/2004, khoang mẫu (SRC) vào khí quyển đúng giờ, đúng vị trí, nhưng dù hãm không bung và khoang lao xuống sa mạc Utah.

Theo Hội đồng điều tra sự cố (MIB) của NASA và tài liệu bài học kinh nghiệm của NASA:

  • Nguyên nhân trực tiếp: cảm biến gia tốc (G-switch) được bố trí ngược theo một thiết kế sai, nên không cảm nhận được giảm tốc khi vào khí quyển để kích hoạt bộ đếm giờ mở dù.
  • Bốn quy trình trước phóng đều thất bại: thiết kế làm ngược cảm biến; rà soát thiết kế không phát hiện; kiểm định không phát hiện; và nhóm Red Team không phát hiện lỗ hổng trong kiểm định.
  • Thiết kế dựa trên phần cứng kế thừa (heritage) từ tàu Stardust, nhưng cảm biến đã được dời sang bảng mạch khác. Sự thay đổi này không được truyền đạt hiệu quả; nhiều kỹ sư vẫn tin phần kích nổ "giữ nguyên thiết kế kế thừa".
  • Một bài kiểm tra ly tâm để xác minh chiều của cảm biến đã được lên kế hoạch nhưng bị xoá, thay bằng kiểm tra bản vẽ. Dấu vết duy nhất trước quản lý dự án là một gạch đầu dòng trong hai buổi rà soát; không có yêu cầu thay đổi hay ghi nhớ kỹ thuật nào.
  • Triết lý "Nhanh hơn, tốt hơn, rẻ hơn" với trần chi phí, dự phòng tiến độ và ngân sách thấp, cùng nhóm kỹ thuật hệ thống rất mỏng, tạo áp lực lên các quyết định.
  • Một phần mẫu vẫn được cứu và phục vụ nghiên cứu, nhưng nhiều tấm thu mẫu bị vỡ và nhiễm bẩn.

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

  • Thay đổi phương pháp kiểm định không qua kiểm soát thay đổi

    Xoá bài kiểm tra ly tâm là thay đổi đường cơ sở chất lượng (kế hoạch kiểm định), nhưng không có yêu cầu thay đổi (change request) và không ai cấp trên rà soát. Kiểm soát thay đổi tích hợp phải bao gồm cả thay đổi về cách chứng minh chất lượng, không chỉ phạm vi hay tiến độ.

  • Kiểm định bằng xem xét thay cho thử nghiệm thực

So sánh bản vẽ chỉ chứng minh hai tài liệu nhất quán với nhau, không chứng minh thiết bị hoạt động đúng chiều trong điều kiện bay. Nguyên tắc "kiểm thử như khi bay" (test as you fly) là một kỹ thuật kiểm soát chất lượng then chốt trong hệ thống an toàn cao.

  • Giả định "kế thừa" tạo cảm giác an toàn giả

    Phần cứng kế thừa được coi là đã kiểm chứng, nhưng thiết kế thực tế đã thay đổi. Mỗi thay đổi so với thiết kế gốc phải được đưa vào nhật ký giả định (assumption log) và kiểm định lại.

  • Áp lực ràng buộc làm giảm chất lượng

    Trần chi phí, dự phòng thấp và nhóm kỹ thuật hệ thống mỏng làm các bài kiểm tra trở thành thứ dễ bị cắt. Đây là minh hoạ của tam giác ràng buộc: khi chi phí và tiến độ bị khoá cứng, chất lượng trở thành biến điều chỉnh âm thầm.

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

    1. 1

      Bước 1: Đưa kế hoạch kiểm định vào đường cơ sở

      Ma trận kiểm định (verification matrix) liệt kê phương pháp cho từng yêu cầu quan trọng; đổi phương pháp phải qua yêu cầu thay đổi và được kỹ thuật hệ thống phê duyệt.

    2. 2

      Bước 2: Chọn phương pháp kiểm định theo mức hệ trọng của chức năng

      Dùng tiêu chí để quyết định khi nào phân tích hoặc xem xét là đủ:

      • Bắt buộc thử nghiệm thực

        Chức năng chỉ có một cơ hội và hỏng là mất sứ mệnh (mở dù, kích nổ): kiểm thử như khi bay, không thay bằng bản vẽ.

      • Phân tích có thẩm định

        Chức năng có dự phòng hoặc có thể sửa sau: phân tích được chấp nhận nếu có người độc lập rà soát.

      • Xem xét là đủ

        Chức năng không ảnh hưởng an toàn hay mục tiêu chính và giống hệt thiết kế đã bay.

    3. 3

      Bước 3: Đánh giá lại mọi thành phần kế thừa bị chỉnh sửa

      Lập danh sách khác biệt so với thiết kế gốc và yêu cầu kiểm định riêng cho từng khác biệt, kèm truyền đạt rõ cho mọi nhóm liên quan.

    4. 4

      Bước 4: Bảo vệ dự phòng cho kiểm thử

      Tách ngân sách và thời gian kiểm thử then chốt thành hạng mục không được cắt khi dự án chịu áp lực chi phí.

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

    Một gạch đầu dòng "không cần kiểm tra riêng" đã thay cho bài thử nghiệm duy nhất có thể cứu sứ mệnh. Thay đổi cách kiểm định cũng là thay đổi đường cơ sở và cần được kiểm soát; với chức năng chỉ có một cơ hội, hãy kiểm thử đúng như khi vận hành.

    Nguồn tham khảo

    • NASA — Genesis Mishap Investigation Board Report, Volume I (PDF)
    • NASA NTRS — Bài học kinh nghiệm từ tai nạn Genesis (PDF)
    • Science News — Tracing the origin of Genesis' crash
    • Wikipedia — Genesis (spacecraft)
    #Kiểm định#Kế hoạch kiểm thử#Thiết kế kế thừa#Kỹ thuật hệ thống#NASA#Hàng không vũ trụ

    Nguồn: NASA — Genesis Mishap Investigation Board Report, Volume I (2006) ↗ (mở trong thẻ mới)

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

    Câu 1/1
    Giữa dự án chế tạo thiết bị bay, trưởng nhóm phân hệ đề xuất bỏ một bài thử nghiệm chức năng đắt tiền, thay bằng so sánh bản vẽ với thiết kế đã từng bay thành công. PM nên làm gì?

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

    Nếu là PM của Genesis khi ngân sách sát trần và còn vài tháng tới ngày phóng, bạn xử lý bài kiểm tra ly tâm thế nào?

    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)