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ý Nguồn lực
  3. /Ericsson chuyển đổi agile quy mô lớn: đội liên c…
Quản lý Nguồn lực

Ericsson chuyển đổi agile quy mô lớn: đội liên chức năng, liên địa điểm trên năm địa điểm và bài học về chuyên môn hoá và huấn luyện

Nghiên cứu trường hợp đăng trên Empirical Software Engineering (2018) theo dõi một chương trình R&D của Ericsson trải rộng năm địa điểm ở hai châu lục khi chuyển sang agile quy mô lớn: thử nghiệm nhiều cách lập đội, từ đội ảo theo thành phần đến đội liên chức năng liên địa điểm. Bài rút ra bốn bài học về thử nghiệm, triển khai từng bước, chuyên môn hoá và huấn luyện.

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

Bối cảnh thực tế

Paasivaara, Behm, Lassenius và Hallikainen công bố nghiên cứu "Large-scale agile transformation at Ericsson: a case study" trên tạp chí Empirical Software Engineering (tập 23, số 5, 2018). Đối tượng là một chương trình R&D xây dựng nền tảng XaaS và các dịch vụ liên quan, trong khi tổ chức mở rộng rất nhanh; tổ chức R&D trải rộng năm địa điểm ở hai châu lục.

Phương pháp: nghiên cứu một trường hợp duy nhất, gồm 45 cuộc phỏng vấn bán cấu trúc tại bốn địa điểm và năm buổi quan sát tại ba địa điểm. Các tác giả mô tả những thử nghiệm về cách lập đội, từ đội ảo theo thành phần tới đội liên chức năng, liên thành phần, liên địa điểm, cùng các khó khăn và cách xử lý.

Bốn bài học được nêu trong phần tóm tắt:

  • Dùng cách tiếp cận thử nghiệm trong chuyển đổi.
  • Triển khai từng bước trong bối cảnh phức tạp.
  • Cần chuyên môn hoá vì khả năng thay thế lẫn nhau giữa thành viên bị hạn chế.
  • Rủi ro khi thiếu khung agile chung cùng với đào tạo và huấn luyện mỏng.

Lưu ý: bài này chỉ dựa trên phần tóm tắt của bài báo và kết quả tìm kiếm; trang nhà xuất bản yêu cầu đăng nhập nên chi tiết trong toàn văn không được dẫn lại.

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

  • Cơ cấu đội phải chọn giữa "theo thành phần" và "theo giá trị"

    Đội theo thành phần dễ có chuyên môn sâu nhưng nhiều phụ thuộc; đội liên chức năng giảm chờ đợi nhưng đòi hỏi kỹ năng rộng. Quá trình Plan Resource Management cần cân nhắc cả hai và chấp nhận thử nghiệm.

  • Đội liên địa điểm tăng chi phí phối hợp

    Năm địa điểm, hai châu lục đồng nghĩa khác múi giờ, khác văn hoá và công cụ. Giao tiếp (Manage Communications) và xây dựng đội (Develop Team) cần đầu tư nhiều hơn so với đội đặt cùng chỗ.

  • Giả định mọi người có thể thay thế lẫn nhau thường sai

    Agile hay nhấn mạnh thành viên linh hoạt, nhưng ở hệ thống phức tạp vẫn cần chuyên gia. Bài học "cần chuyên môn hoá" nhắc PM xây dựng mô hình kỹ năng chữ T thực tế, thay vì ép mọi người làm mọi việc.

  • Thiếu khung chung và huấn luyện làm mỗi đội hiểu agile theo cách riêng

    Nếu không có ngôn ngữ và thực hành chung, các đội khó phối hợp. Kế hoạch đào tạo, huấn luyện và cộng đồng thực hành là một phần của kế hoạch nguồn lực.

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

    1. 1

      Bước 1: Thử nghiệm cấu trúc đội theo từng bước và đánh giá bằng tiêu chí rõ

      Chọn một vài cấu hình, chạy vài chu kỳ rồi đánh giá:

      • Giữ

        Chu kỳ giao hàng ngắn lại, số phụ thuộc giữa đội giảm, đội hài lòng.

      • Điều chỉnh

        Chuyên môn thiếu ở một số đội hoặc phối hợp liên địa điểm còn chậm; bổ sung chuyên gia hoặc vai trò kết nối.

      • Bỏ

        Đội quá tải hoặc chất lượng giảm; quay về cấu hình trước và rút kinh nghiệm.

    2. 2

      Bước 2: Xây khung agile chung và chương trình huấn luyện

      Chuẩn hoá thuật ngữ, nghi thức tối thiểu và huấn luyện viên đồng hành cùng các đội; lập cộng đồng thực hành để chia sẻ kinh nghiệm giữa địa điểm.

    3. 3

      Bước 3: Chấp nhận chuyên môn hoá có chủ đích

      Xác định các kỹ năng không thể thay thế, bố trí đủ người nắm mỗi kỹ năng và kế hoạch chia sẻ tri thức.

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

    Mở rộng agile ở quy mô lớn không phải là sao chép khung mà là thử nghiệm cấu trúc đội, triển khai từng bước và đầu tư vào huấn luyện. Đừng giả định mọi người thay thế được nhau, và đừng bỏ qua chi phí phối hợp của đội trải rộng nhiều địa điểm.

    Nguồn tham khảo

    • Large-scale agile transformation at Ericsson: a case study — Empirical Software Engineering
    • Aaltodoc — bản lưu trữ nghiên cứu
    #Quản lý nguồn lực#Agile quy mô lớn#Ericsson#Đội phân tán#Huấn luyện#Nghiên cứu trường hợp

    Nguồn: Large-scale agile transformation at Ericsson: a case study (Empirical Software Engineering, 2018) ↗ (mở trong thẻ mới)

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

    Câu 1/1
    Công ty mở rộng agile cho 15 đội ở ba châu lục. Nhiều đội hiểu agile mỗi nơi một kiểu và bàn giao giữa đội thường chậm. Cách phản ứng hợp lý nhất của PM chương trình là gì?

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

    Khi lập đội cho hệ thống phức tạp ở nhiều địa điểm, bạn chọn mô hì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 cùng lĩnh vực

    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
    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
    Quản lý Nguồn lực

    Backdoor xz Utils (2024): người bảo trì một mình kiệt sức và chiến dịch gây áp lực nhiều năm để chiếm quyền bảo trì

    Năm 2022, người bảo trì gốc của xz Utils nói công khai mình bị giới hạn bởi vấn đề sức khoẻ tinh thần và dự án chỉ là sở thích không lương, trong khi một số tài khoản liên tục thúc ép bàn giao quyền. Đến tháng 3/2024, backdoor CVE-2024-3094 (CVSS 10) bị phát hiện tình cờ. Phân tích về kiệt sức, bus factor và quản trị quyền truy cập trong dự án.

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