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ý Các bên liên quan
  3. /io.js (2014–2015): những người đóng góp tách nhá…
Số 445Quản lý Các bên liên quan

io.js (2014–2015): những người đóng góp tách nhánh Node.js vì quản trị, rồi hợp nhất dưới Node.js Foundation

Tháng 12/2014, một nhóm người đóng góp chủ chốt của Node.js — không hài lòng với cách công ty Joyent quản trị dự án và tốc độ cập nhật engine V8 — tách nhánh thành io.js với mô hình quản trị mở. Tháng 2/2015, Node.js Foundation được công bố để hợp nhất hai bên; tháng 9/2015, Node.js 4.0 ra đời từ việc gộp Node 0.12 và io.js 3.3. Bài học về cân bằng quyền lợi giữa nhà tài trợ và cộng đồng đóng góp.

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

Bối cảnh thực tế

Node.js là môi trường chạy JavaScript phía máy chủ, được công ty Joyent bảo trợ và nắm thương hiệu. Đến năm 2014, Node.js được nhiều doanh nghiệp lớn dùng, và một phần đáng kể người đóng góp tích cực không làm việc cho Joyent.

Theo tổng hợp trên Wikipedia:

  • Tháng 12/2014, Fedor Indutny tạo io.js, một nhánh của Node.js, xuất phát từ sự không hài lòng với cách Joyent quản trị dự án.
  • io.js áp dụng mô hình quản trị mở với một uỷ ban kỹ thuật riêng, và đặt mục tiêu theo kịp các phiên bản mới của engine V8 mà Node.js khi đó chưa cập nhật.
  • Tháng 2/2015, Node.js Foundation được công bố nhằm hợp nhất Node.js và io.js.
  • Tháng 9/2015, việc hợp nhất hoàn tất: Node.js v0.12 và io.js v3.3 gộp thành Node v4.0.

Trong khoảng chín tháng, hệ sinh thái có hai nhánh song song, khiến người dùng và tác giả thư viện phải theo dõi cả hai.

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

  • Người đóng góp chính không có tiếng nói tương xứng

    Nhóm tạo ra phần lớn giá trị kỹ thuật thuộc nhóm "quan tâm cao, quyền lực chính thức thấp". Khi kênh tham gia ra quyết định không có, họ dùng quyền lực ngầm duy nhất: tách nhánh.

  • Kỳ vọng về tốc độ phát hành lệch nhau

    Một bên ưu tiên ổn định cho doanh nghiệp, bên kia muốn theo kịp nền tảng V8. Không có diễn đàn chung để đánh đổi, xung đột kỹ thuật biến thành xung đột quản trị.

  • Chi phí của sự chia tách đổ lên người dùng

    Hai nhánh song song làm hệ sinh thái phân mảnh, tác giả thư viện phải kiểm thử trên cả hai. Đây là bên liên quan gián tiếp chịu thiệt.

  • Hợp nhất thành công nhờ thay đổi cấu trúc quản trị

    Node.js Foundation đặt quyền kỹ thuật vào một uỷ ban mở, tách khỏi quyền của một công ty — giải quyết nguyên nhân gốc thay vì chỉ thoả hiệp từng việc.

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

  1. 1

    Bước 1: Định kỳ phân tích lại các bên liên quan

    Khi dự án lớn lên, cơ cấu người đóng góp thay đổi; quyền tham gia quyết định cần được điều chỉnh theo.

  2. 2

    Bước 2: Tạo diễn đàn quyết định kỹ thuật mở

    Uỷ ban kỹ thuật có đại diện người đóng góp ngoài công ty tài trợ, quy trình công khai về lộ trình phát hành.

  3. 3

    Bước 3: Nhận diện tín hiệu sớm của nguy cơ chia tách

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

    • Ổn

      Người đóng góp chính tham gia lộ trình, bất đồng được giải quyết trong quy trình.

    • Cảnh báo

      Bất đồng kéo dài, người đóng góp chủ chốt giảm hoạt động hoặc công khai phàn nàn.

    • Chia tách

      Nhánh song song xuất hiện: ưu tiên đàm phán cấu trúc quản trị chung.

  4. 4

    Bước 4: Khi đã chia tách, hướng tới hợp nhất có cấu trúc

    Một tổ chức trung lập, quy tắc quản trị rõ và lộ trình kỹ thuật chung, như Node.js Foundation đã làm.

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

Những người tạo ra giá trị cho dự án sẽ đòi quyền tham gia quyết định — nếu không được trao, họ sẽ tự tạo ra. Hãy để cấu trúc quản trị lớn lên cùng dự án, và khi đã xảy ra chia tách, giải quyết bằng thay đổi cấu trúc chứ không chỉ bằng thoả hiệp tạm thời.

Nguồn tham khảo

  • Wikipedia — io.js
#Quản lý các bên liên quan#Phát triển phần mềm#Mã nguồn mở#Quản trị cộng đồng#Giải quyết xung đột#JavaScript

Nguồn: Wikipedia — io.js ↗ (mở trong thẻ mới)

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

Câu 1/1
Sản phẩm mã nguồn mở do công ty bạn bảo trợ có nhiều người đóng góp chủ chốt từ bên ngoài. Họ nhiều lần đề nghị phát hành nhanh hơn nhưng bị từ chối mà không có quy trình thảo luận; gần đây có người nhắc đến khả năng tách nhánh. PM nên làm gì?

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

Nếu bạn là tác giả thư viện Node.js năm 2015, bạn hỗ trợ nhánh 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 tương tự

Số 498Quản lý Các bên liên quan

Dengvaxia ở Philippines (2016–2019): chương trình tiêm vắc-xin sốt xuất huyết cho khoảng 800.000 học sinh và cuộc khủng hoảng niềm tin kéo theo dịch sởi

Năm 2016, Philippines là nước đầu tiên đưa vắc-xin sốt xuất huyết Dengvaxia vào chương trình tiêm chủng công cho học sinh, với kinh phí 3,5 tỷ peso. Tháng 11/2017, nhà sản xuất thông báo vắc-xin có thể làm bệnh nặng hơn ở người chưa từng nhiễm sốt xuất huyết. Chương trình bị dừng, các cuộc điều tra, khởi tố và tranh cãi công khai làm niềm tin vào vắc-xin sụt giảm; năm 2019, Philippines có hơn 31.000 ca sởi xác nhận và 415 ca tử vong. Bài học về quản lý bên liên quan trong chương trình y tế công.

0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận23/10/2026
Số 488Quản lý Các bên liên quan

Volkswagen và bê bối khí thải diesel (2014–2017): phần mềm gian lận và cái giá của việc né tránh cơ quan quản lý

Năm 2014, một nghiên cứu độc lập phát hiện xe diesel Volkswagen thải NOx khi chạy trên đường cao gấp nhiều lần giới hạn. Hơn một năm sau, khi cơ quan quản lý doạ không chứng nhận xe đời 2016, hãng mới thừa nhận dùng phần mềm nhận biết lúc bị đo kiểm. Khoảng 11 triệu xe trên toàn thế giới bị ảnh hưởng, CEO từ chức và tổng chi phí vượt 33 tỷ USD tới năm 2020. Bài học về quản lý bên liên quan: cơ quan quản lý và khách hàng không phải là trở ngại để vượt qua.

0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận22/10/2026
Số 201Quản lý Các bên liên quan

Digg v4 (2010): viết lại toàn bộ sản phẩm trong một lần ra mắt và cuộc nổi dậy của chính người dùng nòng cốt

Tháng 8/2010, mạng tin xã hội Digg ra mắt phiên bản 4 với nền tảng viết lại và nhiều tính năng quen thuộc bị gỡ bỏ. Người dùng nòng cốt tổ chức "ngày bỏ Digg", nhà xuất bản báo cáo lượng truy cập giới thiệu giảm, và lưu lượng mất hơn một phần tư chỉ sau một tháng. Phân tích dưới góc nhìn quản lý các bên liên quan: ai là người tạo ra giá trị của nền tảng, và họ được tham vấn đến đâu.

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