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ý Giao tiếp
  3. /Voyager 1 (2023–2024): sửa phần mềm tàu vũ trụ 4…
Quản lý Giao tiếp

Voyager 1 (2023–2024): sửa phần mềm tàu vũ trụ 46 năm tuổi nhờ tài liệu cũ và những kỹ sư đã về hưu

Từ 14/11/2023, Voyager 1 gửi về dữ liệu không đọc được. Sau khi đọc toàn bộ bộ nhớ hệ thống dữ liệu bay, nhóm JPL tìm ra một chip có bit bị kẹt và phải dời đoạn mã sang nơi khác trong bộ nhớ chỉ khoảng 69 KB. Họ lần theo các ghi chú cũ, hỏi những người từng làm phần cứng. Ngày 18/04/2024 lệnh được gửi, 20/04 dữ liệu hữu ích trở lại. Một ví dụ thành công về chuyển giao tri thức khi tài liệu thiếu và người tạo ra hệ thống đã rời đi.

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

Bối cảnh thực tế

Voyager 1 được phóng năm 1977 và hiện ở khoảng cách hàng chục tỷ kilômét. Máy tính trên tàu, đặc biệt hệ thống dữ liệu bay (FDS), dùng phần mềm và phần cứng thiết kế từ gần nửa thế kỷ trước. Ngày 14/11/2023, Voyager 1 bắt đầu truyền dữ liệu không đọc được, giống như "âm báo máy" trong khoảng năm tháng.

Theo IEEE Spectrum, nhóm JPL đầu tiên thử bật tắt các dụng cụ khoa học nhưng không hiệu quả. Họ sau đó gửi lệnh yêu cầu FDS gửi về toàn bộ nội dung bộ nhớ của nó. Phân tích tháng 3/2024 cho thấy một chip có bit bị kẹt ở giá trị cố định, không thể sửa, nên đoạn mã nằm trên chip đó phải được dời. Vấn đề là không có một vùng trống đủ lớn: mỗi máy tính chỉ có khoảng 69,63 KB bộ nhớ, và theo nhà khoa học dự án Linda Spilker, kích thước bộ nhớ là thách thức lớn nhất. Nhóm giải phóng chỗ bằng cách ghi đè các chế độ dữ liệu không còn dùng (như tốc độ truyền cao từ thời Sao Mộc), đồng thời tránh xoá mã mà các chế độ khác dùng chung.

Để làm được, họ cần hiểu những quyết định thiết kế từ nhiều thập kỷ trước. Theo bài báo, một số người từng làm phần cứng vẫn có thể hỏi, còn phần lớn thông tin phải lần theo các bản ghi nhớ cũ, được ví như một cuộc khai quật khảo cổ. Ngày 18/04/2024 lệnh được gửi qua Mạng Không gian Sâu; tín hiệu mất khoảng 22,5 giờ để tới tàu. Lệnh hiệu quả và dữ liệu kỹ thuật hữu ích trở lại từ 20/04, dù dữ liệu khoa học của giai đoạn sự cố đã mất.

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

  • Tri thức ngầm nằm trong đầu người, không nằm trong tài liệu

    Quản lý tri thức dự án (Manage Project Knowledge) phân biệt tri thức tường minh và tri thức ngầm. Khi chỉ còn ghi nhớ rời rạc và vài người nhớ phần cứng, chi phí dựng lại lý do của một quyết định thiết kế (vì sao mã dùng chung ở đây) cao hơn nhiều so với chi phí ghi lại lúc đó.

  • Tài liệu ghi "cái gì" nhưng thiếu "tại sao" và "ràng buộc"

    Tài liệu thiết kế có giá trị nhất khi nêu lý do, giả định và ràng buộc (ví dụ giới hạn bộ nhớ). Những chi tiết đó giúp thế hệ kỹ sư sau biết có thể động vào đâu mà không phá hỏng chế độ khác.

Rủi ro nhân sự rời đi không được quản lý như một rủi ro dự án

Với sản phẩm sống hàng chục năm, việc người tạo ra nó nghỉ hưu là rủi ro chắc chắn xảy ra. Cần ghi vào sổ đăng ký rủi ro cùng biện pháp: phỏng vấn thu tri thức, song song hai thế hệ, lưu trữ có chỉ mục.

  • Giao tiếp giữa nhiều thế hệ đòi hỏi kênh và quy trình chung

    Nhóm hiện tại phải liên lạc với người đã về hưu, trao đổi giả thuyết và kiểm chứng trên bản mô phỏng trước khi gửi lệnh có độ trễ hơn một ngày. Quy trình xem xét và phê duyệt lệnh là phần của kế hoạch truyền thông mà dự án đã có sẵn.

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

    1. 1

      Bước 1: Lập kế hoạch thu tri thức trước khi người rời đi

      Với từng hệ thống quan trọng, xác định người nắm tri thức và lên lịch buổi ghi lại. Ba cấp độ nên có:

      • Thiết kế

        Sơ đồ, lý do quyết định, ràng buộc bộ nhớ và thời gian — viết sao cho người mới đọc hiểu mà không cần hỏi.

      • Vận hành

        Quy trình xử lý sự cố đã xảy ra, các lệnh đã dùng và kết quả, kèm lưu ý rủi ro.

      • Điểm mù

        Danh sách phần chưa ai nắm rõ, cần ưu tiên khai thác khi còn người để hỏi.

    2. 2

      Bước 2: Kiểm tra tài liệu bằng cách dùng thật

      Tổ chức diễn tập: giao cho người mới xử lý một tình huống giả định chỉ bằng tài liệu. Chỗ nào họ phải hỏi người cũ là chỗ tài liệu thiếu.

    3. 3

      Bước 3: Giữ liên hệ với chuyên gia đã rời đi

      Thoả thuận tư vấn hoặc cộng đồng cựu thành viên giúp kéo họ về khi cần, như cách JPL hỏi những người từng làm phần cứng.

    4. 4

      Bước 4: Ghi lại cả quá trình chẩn đoán sự cố này

      Lưu lại chuỗi giả thuyết, lệnh đã gửi, kết quả và lý do chọn phương án dời mã để lần sau có sẵn tài liệu — biến bài học vào kho tri thức tổ chức.

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

    Tri thức mất đi với từng người nghỉ việc. PM của sản phẩm sống lâu phải xem việc ghi lại "vì sao" như một khoản đầu tư có hạn chót, kiểm tra tài liệu bằng tình huống thật và giữ cầu nối với những người đã tạo ra hệ thống.

    Nguồn tham khảo

    • IEEE Spectrum — Voyager 1 và việc sửa hệ thống dữ liệu bay
    #Quản lý truyền thông#Voyager 1#NASA JPL#chuyen-giao-tri-thuc#Tài liệu kỹ thuật#Phần mềm nhúng

    Nguồn: IEEE Spectrum — Voyager 1 và việc sửa hệ thống dữ liệu bay ↗ (mở trong thẻ mới)

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

    Câu 1/1
    Bạn là PM của hệ thống nội bộ chạy 15 năm. Hai kỹ sư duy nhất hiểu mô-đun cốt lõi sẽ nghỉ hưu sau 6 tháng và tài liệu chỉ có sơ đồ cũ. Hành động nào phù hợp nhất?

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

    Để giữ tri thức của hệ thống chạy lâu năm, bạn đầu tư vào cách nào trước?

    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ý Giao tiếp

    Khách hàng đòi thay thế Tech Lead & Nghệ thuật Bảo vệ Đội ngũ

    Mảng kiến thức trọng tâm: Quản lý Nguồn lực, Quản lý Các bên liên quan & Lãnh đạo Phục vụ (Resource Management, Stakeholder Engagement & Servant Leadership - PMBOK 6/7)

    1 lượt thích 0 lượt đánh giá hữu ích 0 bình luận15/10/2026
    Quản lý Giao tiếp

    "Hố sâu chuyển giao" (Operational Transition Gap) – Khi Đội Vận hành từ chối tiếp nhận hệ thống

    Mảng kiến thức trọng tâm: Chuyển giao từ Dự án sang Vận hành & Quản lý Các bên liên quan nội bộ (Project-to-Operations Transition, Operational Readiness & Internal Stakeholder Engagement - PMBOK 6/7)

    0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận13/10/2026
    Quản lý Giao tiếp

    Slack 22/02/2022: nâng cấp Consul làm bộ nhớ đệm rơi, cơ sở dữ liệu quá tải và cách vừa giảm tải vừa thông tin cho người dùng

    Sáng 22/02/2022, đúng giờ cao điểm, nhiều người dùng Slack không kết nối được. Nguyên nhân là một chuỗi yếu tố: nâng cấp Consul theo từng bước 25%, bộ nhớ đệm mất hiệu quả, truy vấn quét mọi shard làm Vitess quá tải và máy khách thử lại dồn dập. Slack giảm tải có kiểm soát, thông báo trên mạng xã hội rồi công bố bản post-mortem kỹ thuật vào cuối tháng 4. Phân tích dưới góc nhìn quản lý truyền thông sự cố.

    0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận09/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)