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.109 người đã truy cậpPhiên bản 1.15.0
  1. /Tình huống
  2. /Quản lý Nguồn lực
  3. /actix-web (2020): người duy trì rời bỏ dự án sau…
Số 448Quản lý Nguồn lực

actix-web (2020): người duy trì rời bỏ dự án sau làn sóng chỉ trích và cuộc chuyển giao cho người kế nhiệm

Tháng 1/2020, actix-web — framework web Rust phổ biến, đứng đầu một số bảng đo hiệu năng — rơi vào tranh cãi về việc dùng mã unsafe và cách người duy trì xử lý báo cáo lỗi. Thảo luận trên mạng trở nên gay gắt, mang tính cá nhân. Người tạo dự án tuyên bố rời bỏ mã nguồn mở, tạm ẩn kho mã, rồi sau đó khôi phục và trao quyền dẫn dắt cho một cộng sự. Bài học về kiệt sức, giao tiếp và kế nhiệm.

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

Bối cảnh thực tế

actix-web là framework web viết bằng Rust do Nikolay Kim tạo ra, nổi tiếng nhờ hiệu năng cao trong các bảng đo TechEmpower. Đây là dự án cá nhân, không phải dự án chính thức của công ty nơi tác giả làm việc.

Theo The Register:

  • Framework dùng nhiều mã unsafe của Rust. Một lập trình viên chỉ ra rằng một số đoạn có thể dẫn tới lỗi bộ nhớ, và cho biết các báo cáo bị từ chối điều tra; tác giả đã xoá một báo cáo lỗi liên quan.
  • Thảo luận trên diễn đàn r/rust trở nên gay gắt và mang tính cá nhân; phàn nàn chính xoay quanh việc báo cáo bị phớt lờ hoặc xoá, hơn là bản thân lỗ hổng.
  • Ngày 17/1/2020, tác giả đăng "Actix project postmortem", bảo vệ quan điểm, chỉ trích cộng đồng, nói đã "xong với mã nguồn mở" và đe doạ chuyển kho sang riêng tư. Sau đó ông thừa nhận việc xoá báo cáo là quyết định kém.
  • Kho mã được khôi phục; tác giả chỉ định một cộng sự đã giúp ông trong năm trước làm người dẫn dắt dự án. Hơn 100 thành viên cộng đồng ký thư ủng hộ, lên án sự công kích nhằm vào ông.

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

  • Một người gánh cả kỹ thuật lẫn quan hệ cộng đồng

    Người duy trì vừa viết phần lớn mã, vừa xử lý báo cáo, vừa trả lời chỉ trích. Khi áp lực tăng, không có ai chia sẻ, dẫn tới quyết định cảm tính.

  • Khác biệt về tiêu chuẩn chất lượng không được thống nhất

    Cộng đồng Rust coi an toàn bộ nhớ là giá trị cốt lõi; tác giả ưu tiên hiệu năng và tin mã unsafe của mình đúng. Không có tiêu chuẩn thành văn cho dự án, mỗi bên dùng thước đo riêng.

  • Xung đột chuyển từ vấn đề sang con người

    Khi thảo luận mang tính công kích cá nhân, người bị chỉ trích phòng thủ và rút lui. Đây là dạng xung đột kém hiệu quả nhất trong đội.

  • Có người kế nhiệm tiềm năng giúp dự án sống sót

Việc đã có cộng sự tham gia trong năm trước cho phép chuyển giao nhanh — một ví dụ về giá trị của kế hoạch kế nhiệm, dù không chính thức.

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

  1. 1

    Bước 1: Phân tách vai trò trong dự án

    Tách người phân loại báo cáo lỗi, người duy trì kỹ thuật, người điều phối cộng đồng — giảm tải cho người sáng lập.

  2. 2

    Bước 2: Thống nhất tiêu chuẩn chất lượng thành văn

    Ví dụ: chính sách dùng mã unsafe, quy trình xử lý báo cáo bảo mật, thời gian phản hồi — để tranh luận dựa trên tiêu chí, không dựa trên cảm nhận.

  3. 3

    Bước 3: Quy tắc ứng xử và điều phối thảo luận

    Áp dụng quy tắc ứng xử cho cả hai chiều: bảo vệ người duy trì khỏi công kích và bảo vệ người báo lỗi khỏi bị phớt lờ.

  4. 4

    Bước 4: Theo dõi dấu hiệu kiệt sức

    Các mức cảnh báo:

    • Khoẻ

      Nhiều người duy trì, báo cáo được phân loại đều, thảo luận đúng trọng tâm.

    • Căng

      Báo cáo tồn đọng, người duy trì phản hồi ngắn, phòng thủ.

    • Báo động

      Xoá báo cáo, tuyên bố rời đi: kích hoạt chuyển giao, giảm áp lực ngay.

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

Người chủ chốt kiệt sức không phải vì một lỗi kỹ thuật mà vì họ phải một mình gánh mọi vai trò dưới áp lực công khai. Hãy chia sẻ vai trò, thống nhất tiêu chuẩn bằng văn bản, giữ thảo luận ở vấn đề chứ không ở con người, và luôn có người sẵn sàng tiếp quản.

Nguồn tham khảo

  • The Register — Người duy trì framework actix-web rời dự án rồi chuyển giao
#Quản lý nguồn lực#Phát triển phần mềm#Mã nguồn mở#Kiệt sức#Phụ thuộc người chủ chốt#Rust

Nguồn: The Register — Người duy trì actix-web rời dự án (21/1/2020) ↗ (mở trong thẻ mới)

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

Câu 1/1
Trưởng nhóm kỹ thuật của một thành phần quan trọng liên tục bị các nhóm khác chỉ trích về cách viết mã; gần đây anh ấy bắt đầu đóng các yêu cầu sửa lỗi mà không giải thích. PM nên làm gì?

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

Khi một dự án mã nguồn mở nhận chỉ trích gay gắt về chất lượng, người duy trì nên làm 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 tương tự

Quản lý Nguồn lực

Heartbleed và OpenSSL (2014): hạ tầng bảo mật của cả Internet dựa vào một nhóm tình nguyện viên, chỉ một người làm toàn thời gian

Lỗi Heartbleed trong thư viện OpenSSL khiến khoảng 17% máy chủ web có chứng thực tin cậy bị coi là dễ tổn thương khi công bố. Phía sau là một dự án do vài tình nguyện viên duy trì, chỉ một người làm toàn thời gian và quyên góp hằng năm chỉ khoảng 2.000 USD. Phân tích dưới góc nhìn quản lý nguồn lực: phụ thuộc trọng yếu vào một "nguồn lực" không ai phân bổ ngân sách.

0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận14/10/2026
Số 475Quản lý Nguồn lực

Đường dây 500 kV mạch 3 Quảng Trạch – Phố Nối (2024): 519 km trong hơn 6 tháng khi nhà thầu chỉ đáp ứng khoảng một nửa nhân lực

Dự án đường dây 500 kV mạch 3 dài 519 km qua 9 tỉnh, tổng mức đầu tư khoảng 22.356 tỷ đồng, được đóng điện toàn tuyến cuối tháng 8/2024 sau hơn 6 tháng thi công. Lúc cao điểm, công trường cần khoảng 10.000–12.000 thợ lành nghề nhưng các nhà thầu chỉ đáp ứng được khoảng 50%. Chủ đầu tư phải huy động thêm hàng nghìn người từ các đơn vị trong ngành, doanh nghiệp nhà nước khác, lực lượng vũ trang và đoàn viên thanh niên. Một tình huống về lập kế hoạch và bổ sung nguồn lực dưới áp lực tiến độ.

0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận14/10/2026
Quản lý Nguồn lực

Mozilla 2020: cắt giảm khoảng 250 nhân sự, đội Servo bị ảnh hưởng và bài toán giữ tri thức khi tái cơ cấu đội kỹ thuật

Ngày 11/08/2020 Mozilla công bố cắt giảm khoảng 250 nhân sự với lý do doanh thu giảm do đại dịch; đội phát triển công cụ trình duyệt Servo nằm trong số bị ảnh hưởng. Dự án chuyển sang Linux Foundation Europe và được kích hoạt lại năm 2023 nhờ nguồn tài trợ ngoài. Phân tích về giải tán đội, chuyển giao tri thức và kế hoạch cho dự án nghiên cứu dài hạn.

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