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. /Netscape 6: quyết định viết lại trình duyệt từ đ…
Quản lý Tiến độ

Netscape 6: quyết định viết lại trình duyệt từ đầu năm 1998 và hai năm không có bản phát hành mới

Tháng 3/1998 Netscape mở mã nguồn Communicator, kỳ vọng bản 5.0 trong khoảng một năm. Cuối tháng 10/1998 đội Mozilla quyết định bỏ mã cũ và xây lại trên công cụ hiển thị Gecko; Netscape 6.0 ra ngày 14/11/2000 trong tình trạng bị nhận xét là quá thiếu ổn định. Phân tích quyết định "viết lại từ đầu" dưới góc nhìn ước lượng, chi phí cơ hội và cửa sổ thị trường.

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

Bối cảnh thực tế

Tháng 3/1998 Netscape phát hành phần lớn mã của Communicator theo giấy phép mã nguồn mở, đặt tên dự án là Mozilla và kỳ vọng nó cho ra trình duyệt phiên bản 5.0 trong khoảng một năm, theo Wikipedia.

Chuỗi diễn biến:

  • Cuối 1998: Netscape điều một số kỹ sư sang bản Communicator 4.5, làm giảm nguồn lực cho Mozilla; bản 5.0 bị bỏ, kế hoạch 5.0 dựa trên nhánh 4.x cũng bị huỷ.
  • Cuối 10/1998: kỹ sư Mozilla quyết định bỏ mã Communicator và xây lại từ đầu trên công cụ hiển thị Gecko; nguồn lực chuyển sang Netscape 6.0.
  • 2000: các bản xem trước công khai (4, 8, 10/2000); những bản Mozilla đầu chạy chậm, nhất là trên máy tầm trung.
  • 14/11/2000: Netscape 6.0 phát hành, bị mô tả là "quá thiếu ổn định để dùng thực tế".
  • 2001: bản 6.1 và 6.2 sửa nhiều lỗi nhưng số người dùng vẫn nhỏ; Internet Explorer 6 ra mùa hè 2001.

Wikipedia ghi một số cựu nhân viên coi đây là một trong những sai lầm lớn của công ty. Bài này không đánh giá tính đúng sai về kỹ thuật, chỉ nhìn quyết định dưới góc quản lý tiến độ: khi viết lại, giá phải trả là khoảng trống thị trường và rủi ro ước lượng.

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

  • Ước lượng cho công việc chưa từng làm (Estimate Activities)

    Viết lại một trình duyệt hoàn chỉnh là việc có độ bất định rất cao. Kỳ vọng ban đầu "một năm" dựa trên việc cải tiến mã hiện có, không còn đúng khi phạm vi đổi thành làm mới toàn bộ; ước lượng cần được làm lại với khoảng tin cậy rộng.

  • Chi phí cơ hội của khoảng trống phát hành (Control Schedule / Business Case)

    Trong lúc làm lại, thị trường tiếp tục chuyển động mà sản phẩm không có bản mới. Quyết định đổi hướng cần so sánh chi phí kỹ thuật với doanh thu và thị phần mất đi trong thời gian trống.

  • Điều chuyển nguồn lực giữa các nhánh (Manage Team)

Việc đưa kỹ sư sang bản 4.5 rồi sang bản mới cho thấy nguồn lực bị kéo giữa các ưu tiên mà không có một kế hoạch tổng thể rõ.

  • Phát hành khi chưa đạt tiêu chí chất lượng (Control Quality)

    Sau hai năm, áp lực thị trường dẫn đến phát hành bản 6.0 trong tình trạng thiếu ổn định. Mốc nén cuối cùng đã chuyển rủi ro chất lượng sang người dùng.

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

    1. 1

      Bước 1: Đánh giá viết lại so với tái cấu trúc dần dựa trên tiêu chí

      Trước khi chấp thuận "bỏ đi làm lại", đánh giá theo các ngưỡng:

      • Chấp thuận viết lại

        Nợ kỹ thuật chặn mọi hướng đi chiến lược, có sản phẩm cũ vẫn tiếp tục cập nhật trong lúc làm mới.

      • Tái cấu trúc dần

        Có thể thay từng module mà không dừng phát hành; ưu tiên khi thị trường thay đổi nhanh.

      • Không làm

        Không có đội, thời gian và vốn để giữ sản phẩm cũ trong thời gian trống: viết lại là đặt cược cả công ty.

    2. 2

      Bước 2: Giữ bản đang bán tiếp tục phát hành trong lúc làm mới

      Duy trì một dòng phát hành nhỏ để giữ người dùng và doanh thu, tách nguồn lực khỏi dòng viết lại.

    3. 3

      Bước 3: Ước lượng theo khoảng và đặt cổng quyết định định kỳ

      Công bố ước lượng ba điểm, kiểm tra tiến độ thực so với dự báo theo quý và sẵn sàng dừng hoặc đổi hướng.

    4. 4

      Bước 4: Đặt tiêu chí chất lượng trước khi phát hành lớn

      Không phát hành bản đầu của kiến trúc mới như bản chính thức khi chưa đạt ngưỡng ổn định; dùng bản xem trước công khai để thu thập phản hồi.

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

    Viết lại từ đầu là một dự án mới với độ bất định cao, không phải bản sửa lớn của dự án cũ. Hãy định giá khoảng trống thị trường, giữ một dòng phát hành sống và ước lượng theo khoảng — đừng để "chỉ thêm một năm nữa" trở thành quy luật.

    Nguồn tham khảo

    • Wikipedia — Netscape 6
    #Quản lý tiến độ#Netscape#Mozilla#Viết lại từ đầu#Chi phí cơ hội#Trình duyệt

    Nguồn: Wikipedia — Netscape 6 ↗ (mở trong thẻ mới)

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

    Câu 1/1
    Đội kỹ thuật đề xuất bỏ toàn bộ mã nguồn cũ của sản phẩm đang cạnh tranh gay gắt và viết lại từ đầu, hứa kết quả tốt hơn sau khoảng một năm. Bạn nên làm gì ĐẦU TIÊN?

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

    Mã cũ khó mở rộng, đối thủ đang tiến nhanh. 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
    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.

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

    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)