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ở".

Nguyễn Thu Hà, PMP

14/10/2026

4 phút đọc 0

Bình luận0

Bối cảnh thực tế

Longhorn là mã dự án của hệ điều hành Windows kế nhiệm XP. Theo tổng hợp trên Wikipedia, ban đầu nó được xem là một bản phát hành nhỏ dự kiến cuối năm 2003; tại WinHEC tháng 5/2003, Microsoft còn nói tới mốc "đầu 2005". Nhưng dự án liên tục hút thêm tính năng vốn thuộc thế hệ sau (Blackcomb), nên ngày phát hành trượt nhiều lần.

Nhiều công nghệ lớn được xây song song và phụ thuộc lẫn nhau:

WinFS — hệ thống lưu trữ dựa trên cơ sở dữ liệu; một số ứng dụng đi kèm (như Outlook Express) phụ thuộc vào nó, nên người kiểm thử phải tắt WinFS và làm ứng dụng hỏng.
WinFX (về sau là .NET 3.0) và giao diện mới của hệ điều hành đang ở dạng beta.
NGSCB (Palladium) — kiến trúc bảo mật phần cứng, cuối cùng chỉ còn BitLocker được giữ lại.

Cùng lúc, nhiều lập trình viên bị điều sang việc tăng cường bảo mật cho Windows XP. Bản dựng thử bị rò rỉ bộ nhớ lớn ở Explorer và mã không ổn định tích tụ dần. Tháng 12/2003, hai lãnh đạo kỹ thuật được đưa vào để vẽ bản đồ phụ thuộc của toàn hệ điều hành nhằm giảm các ràng buộc chéo. Ngày 26–27/8/2004, Microsoft thông báo tái lập (reset): làm lại trên nền mã Windows Server 2003 SP1 thay vì nền mã đang dùng, đưa vào quy trình chặt hơn.

Kết quả: bản dựng sau tái lập đầu tiên (19/8/2004), Beta 1 ngày 27/7/2005, hoàn thiện bản RTM ngày 1/11/2006 ("sau hơn năm năm phát triển"), bán lẻ ngày 30/1/2007. Một bài blog năm 2006 của một kỹ sư Microsoft (được Wikipedia dẫn lại) nêu khoảng 2.000 lập trình viên và khoảng 50 triệu dòng mã.

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

Phụ thuộc bắt buộc và phụ thuộc nội bộ không được quản lý (Sequence Activities)
Khi ứng dụng đi kèm phụ thuộc vào một thành phần chưa hoàn thiện (WinFS), mọi nhóm bị buộc chờ nhau hoặc phải "tắt" để kiểm thử. Đây là phụ thuộc bắt buộc được xử lý như phụ thuộc mềm; không có bản đồ phụ thuộc và đường găng (critical path) thật sự nên một trễ nhỏ lan khắp hệ thống.
Phạm vi phình dần và không có đường cơ sở ổn định (Control Scope)

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

Bối cảnh thực tế

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

Phụ thuộc bắt buộc và phụ thuộc nội bộ không được quản lý (Sequence Activities)

Phạm vi phình dần và không có đường cơ sở ổn định (Control Scope)

Nợ kỹ thuật và chất lượng bản dựng làm mất khả năng dự báo (Control Schedule)

Nguồn lực bị điều chuyển mà kế hoạch không được cập nhật (Acquire Resources)

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

Bước 1: Lập bản đồ phụ thuộc và chốt các cổng tích hợp theo thời gian

Bước 2: Đóng băng phạm vi bằng kiểm soát thay đổi tích hợp

Bước 3: Trả nợ kỹ thuật trước khi cam kết ngày

Bước 4: Chủ động tái lập đường cơ sở sớm và truyền thông rõ

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

Nguồn tham khảo

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

Chương trình đã trễ nhiều lần, bản dựng không ổn định. Bạn chọn hướng nào?

Tình huống này hữu ích với bạn?

Bình luận (0)