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ý Tiến độ
  3. /Final Fantasy XIV: làm lại cả trò chơi trong khi…
Quản lý Tiến độ

Final Fantasy XIV: làm lại cả trò chơi trong khi bản cũ vẫn vận hành — lộ trình 3 năm từ thất bại 2010 đến A Realm Reborn

Bản gốc ra mắt tháng 9/2010 với đánh giá rất tệ. Square Enix thay đội lãnh đạo, tạm ngừng thu phí và quyết định xây lại trò chơi trên động cơ, máy chủ mới trong khi vẫn cập nhật bản cũ. Phiên bản A Realm Reborn phát hành 27/8/2013. Phân tích ở góc nhìn tái lập kế hoạch tiến độ, lộ trình công khai và chuyển đổi không gián đoạn.

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

Bối cảnh thực tế

Final Fantasy XIV ra mắt tháng 9/2010 sau giai đoạn beta ngắn, đầy lỗi, và nhận phản hồi gần như hoàn toàn tiêu cực. Tháng 12/2010, sau hai lần gia hạn dùng thử miễn phí, chủ tịch Square Enix xin lỗi, thay đổi ban lãnh đạo dự án, tạm ngừng thu phí hằng tháng và huỷ bản PS3 dự kiến. Naoki Yoshida được bổ nhiệm làm nhà sản xuất kiêm đạo diễn.

Theo mô tả trên Wikipedia, tháng 1/2011 đội nhận ra mã nguồn cũ cản trở những thay đổi cần thiết, nên bắt đầu lên kế hoạch xây một trò chơi mới từ đầu. Chuỗi mốc:

  • 4/2011: bắt đầu thực sự làm động cơ và cấu trúc máy chủ mới.
  • 7/2011: bản vá 1.18 cải thiện bản cũ (chiến đấu, hầm ngục, bỏ hệ thống mệt mỏi…) — chính là nơi thử quy trình và tính năng sẽ mang sang bản mới.
  • 10/2011: công bố "Phiên bản 2.0" cùng lộ trình; người chơi cũ nhận bản máy khách mới miễn phí và giữ dữ liệu nhân vật; thu phí trở lại để tài trợ.
  • 11/11/2012: máy chủ bản cũ ngừng hoạt động.
  • 2/2013: bốn đợt beta; 27/8/2013: phát hành A Realm Reborn trên PC và PS3; vì sự cố máy chủ, Square Enix tạm ngừng bán bản số một thời gian.

Điểm đáng chú ý là việc "xây mới" không có nghĩa dừng dịch vụ: bản cũ được giữ vận hành và cải thiện, đóng vai trò vừa giữ người chơi vừa là bãi thử.

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

  • Phát hành không đạt tiêu chí sẵn sàng (Release readiness)

    Beta ngắn và nhiều lỗi nhưng vẫn ra mắt theo lịch. Không có tiêu chí vào/ra giai đoạn kiểm thử rõ ràng nên mốc được ưu tiên hơn chất lượng, và rủi ro uy tín bị đẩy cho người dùng.

  • Phân tích nguyên nhân gốc dẫn đến quyết định đặt lại đường cơ sở (Control Schedule / Change Control)

    Việc kết luận mã nguồn cũ cản trở thay đổi là kết quả của phân tích gốc rễ chứ không phải vá triệu chứng. Đó là cơ sở để đổi từ "sửa dần" sang "xây lại", với phạm vi, đội và lịch mới được nhà tài trợ phê duyệt.

  • Hai dòng việc song song cần điều phối (Integrate Schedules)

    Dòng duy trì bản cũ và dòng xây bản mới dùng chung nhân lực và tri thức. Việc dùng bản cũ làm nơi thử nghiệm là cách giảm rủi ro tích hợp, nhưng đòi hỏi lịch tích hợp để hai dòng không giẫm chân nhau.

  • Truyền thông lộ trình để khôi phục niềm tin (Manage Stakeholder Engagement)

    Công bố lộ trình 2.0, giữ dữ liệu nhân vật, miễn phí bản máy khách mới là cam kết cụ thể với người chơi; thu phí chỉ quay lại khi có thứ để trao.

  • Lẽ ra PM nên làm gì (và đã làm tốt gì)

    1. 1

      Bước 1: Đặt tiêu chí ra mắt dựa trên chất lượng chứ không chỉ ngày

      Trước khi ra mắt, đặt cổng go/no-go theo mức độ sẵn sàng:

      • Ra mắt

        Beta đủ dài, tỉ lệ lỗi nghiêm trọng dưới ngưỡng và máy chủ qua kiểm thử tải.

      • Ra mắt mềm

        Một số tiêu chí chưa đạt: mở giới hạn, không thu phí, giữ kênh phản hồi hai chiều.

      • Hoãn

        Lỗi nghiêm trọng hoặc máy chủ chưa qua tải: hoãn và công bố ngày mới có lý do rõ.

    2. 2

      Bước 2: Đặt lại đường cơ sở bằng phân tích nguyên nhân gốc

      Khi nhận ra nền tảng là chướng ngại, trình nhà tài trợ phương án xây lại với phạm vi, nguồn lực và lịch rõ ràng, kèm tiêu chí thành công.

    3. 3

      Bước 3: Dùng sản phẩm đang chạy làm nơi thử nghiệm rủi ro thấp

      Đưa quy trình, công cụ và tính năng mới vào bản cũ trước để phát hiện vấn đề sớm và giữ người dùng.

    4. 4

      Bước 4: Công bố lộ trình và các cột mốc kiểm chứng được

      Lịch alpha, beta, ngày tắt bản cũ và quyền lợi người dùng cũ được công bố sớm để các bên liên quan chuẩn bị.

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

    Sản phẩm thất bại không phải là hết: nếu tìm được nguyên nhân gốc, đặt lại đường cơ sở và công khai lộ trình, một dự án có thể làm lại hoàn toàn mà vẫn giữ người dùng. Nhưng nên tự đặt cổng chất lượng trước khi ra mắt để khỏi phải trả giá ba năm.

    Nguồn tham khảo

    • Wikipedia — Final Fantasy XIV
    #Quản lý tiến độ#Final Fantasy XIV#Square Enix#Lộ trình phát hành#Dịch vụ trực tuyến#Game

    Nguồn: Wikipedia — Final Fantasy XIV ↗ (mở trong thẻ mới)

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

    Câu 1/1
    Sản phẩm dịch vụ trực tuyến vừa ra mắt với đánh giá rất tệ. Phân tích cho thấy mã nguồn hiện tại không thể sửa để đạt yêu cầu. Bạn nên làm gì?

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

    Nếu nền tảng hiện tại cản trở mọi thay đổi, bạn chọn hướng 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ý Tiến độ

    Windows Longhorn thành Vista: "tái lập" năm 2004, khi phụ thuộc chéo giữa các đội làm mọi mốc trượt dần

    Longhorn ban đầu được hình dung là bản phát hành nhỏ vào cuối 2003, rồi dần gánh thêm cả những tính năng vốn dành cho thế hệ sau. Tháng 8/2004 Microsoft quyết định làm lại từ nền Windows Server 2003 SP1, cắt hoặc hoãn WinFS và phần lớn Palladium; Vista chỉ đến tay người dùng tháng 1/2007. Phân tích dưới góc nhìn quản lý tiến độ: phụ thuộc giữa các đội, nợ kỹ thuật và quyết định "đặt lại đường cơ sở".

    0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận14/10/2026
    Số 120Quản lý Tiến độ

    Tên lửa SLS và chuyến bay Artemis I: khi lần tái lập kế hoạch che mất 19 tháng trượt tiến độ

    Báo cáo IG-20-012 (03/2020) của Văn phòng Tổng Thanh tra NASA cho thấy chương trình Space Launch System vượt đường cơ sở cam kết với Quốc hội ít nhất 33%, trong khi một lần tái lập kế hoạch năm 2017 đã rút gần 1 tỷ USD chi phí ra khỏi đường cơ sở mà không hạ mức cam kết — làm mờ tác động của 19 tháng trượt tiến độ. Phân tích theo góc nhìn quản lý tiến độ và đường cơ sở.

    0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận01/10/2026
    Số 80Quản lý Tiến độ

    Big Dig (Boston): trễ 9 năm so với mốc 1998 và cái giá của một kế hoạch tiến độ lạc quan

    Dự án Central Artery/Tunnel ở Boston được lập kế hoạch hoàn thành năm 1998 nhưng đến cuối 2007 mới xong, chi phí từ khoảng 2,6–2,8 tỷ USD (ước tính ban đầu) lên 14,6 tỷ USD. Phân tích vì sao đường cơ sở tiến độ thiếu thực tế và PM lẽ ra nên làm gì với rủi ro hiện trường, phê duyệt môi trường và thay đổi thiết kế.

    0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận01/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ì (và đã làm tốt 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)