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ý Phạm vi
  3. /Alphagov (Anh, 2011): thu hẹp phạm vi còn 100 nh…
Quản lý Phạm vi

Alphagov (Anh, 2011): thu hẹp phạm vi còn 100 nhu cầu người dùng hàng đầu để dựng bản mẫu công trong 12 tuần

Đội Government Digital Service dựng bản alpha công khai của cổng chính phủ duy nhất (tiền thân GOV.UK) với kinh phí khoảng 261.000 bảng và 12 tuần. Đội nhận ra cách tiếp cận ban đầu quá tham vọng và thu hẹp trọng tâm về 100 nhu cầu người dùng hàng đầu. Ví dụ về phạm vi hướng nhu cầu người dùng và phát hành sớm để lấy phản hồi.

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

Bối cảnh thực tế

Năm 2011, chính phủ Anh muốn kiểm chứng khả năng gộp các dịch vụ trực tuyến của nhiều cơ quan vào một tên miền duy nhất. Theo dòng thời gian trên blog GDS, đội alpha tập hợp từ tháng 1, bắt đầu làm việc trong tháng 3 và dự án alphagov được công bố công khai ngày 29/3 với Tom Loosemore dẫn dắt.

  • Đội tự nhận ban đầu "nhắm quá cao" và quyết định cách tiếp cận đầu tiên là sai.
  • Họ thu hẹp trọng tâm của alpha vào 100 nhu cầu người dùng hàng đầu, viết lên thẻ và sắp xếp theo nhóm trên một bức tường.
  • Đến khoảng tuần thứ năm, đội gặp khó vì khối lượng việc và thiếu người.
  • Bản alpha ra mắt công khai ngày 11/5/2011, trễ một ngày so với kế hoạch; đội xem đây là cách lấy phản hồi thực từ người dùng.

Tom Loosemore sau đó cho biết bản mẫu tốn 261.000 bảng và 12 tuần xây dựng. Đội mô tả alpha là để chứng minh một ý tưởng chứ không phải làm sản phẩm hoàn chỉnh; phản hồi nhìn chung tích cực nhưng cũng có chỉ trích, chẳng hạn việc chưa tuyển chuyên gia thiết kế trải nghiệm. Sau đó dự án chuyển sang giai đoạn beta.

Phân tích theo chuẩn PMP và Agile

  • Thu hẹp phạm vi theo nhu cầu người dùng (Collect Requirements)

    Thay vì cố bao phủ toàn bộ dịch vụ của chính phủ, đội chọn 100 nhu cầu hàng đầu làm khung phạm vi. Đây là cách lấy nhu cầu người dùng làm tiêu chí ưu tiên, đồng thời tạo đường cơ sở đủ nhỏ để chứng minh khả thi.

  • Phạm vi nhìn thấy được: tường thẻ nhu cầu

    Viết nhu cầu lên thẻ và xếp lên tường biến phạm vi thành thứ cả đội cùng nhìn, tương tự một kho tồn đọng trực quan; người ngoài đội cũng dễ hiểu điều gì trong và ngoài phạm vi.

  • Phát hành sớm, công khai để học (Validate Scope theo cách mới)

    Mở alpha công khai giúp nghiệm thu bởi người dùng thật thay vì chỉ bên tài trợ. Phản hồi hai tháng cho phép điều chỉnh trước khi cam kết xây bản beta.

  • Rủi ro nguồn lực khi thời gian cố định

    Việc đội thiếu người ở tuần thứ năm cho thấy khi thời gian bị cố định, phạm vi và nguồn lực phải điều chỉnh liên tục. Quản lý nguồn lực cần theo dõi tải công việc, không để phạm vi "ngầm" tăng.

  • PM có thể áp dụng thế nào

    1. 1

      Bước 1: Chọn bộ nhu cầu cho bản đầu bằng tiêu chí rõ ràng

      Khi nguồn lực hữu hạn, nhóm cần quy tắc quyết định nhu cầu nào vào bản đầu:

      • Vào bản đầu

        Nhu cầu được nhiều người dùng gặp nhất và đủ để chứng minh ý tưởng cốt lõi.

      • Bản sau

        Nhu cầu hợp lệ nhưng ít gặp hoặc phụ thuộc hệ thống ngoài; đưa vào kho tồn đọng theo thứ tự ưu tiên.

      • Ngoài phạm vi

        Nhu cầu làm phình dự án mà không giúp trả lời câu hỏi cốt lõi của giai đoạn này.

    2. 2

      Bước 2: Công bố mục tiêu học hỏi của từng giai đoạn

      Nêu rõ alpha để kiểm chứng điều gì và không hứa điều gì, giúp bên liên quan hiểu kỳ vọng và tránh áp yêu cầu của sản phẩm hoàn chỉnh.

    3. 3

      Bước 3: Theo dõi công suất đội mỗi vòng lặp

      Dùng tốc độ thực tế và tải công việc để cắt phạm vi sớm, thay vì dồn lại cuối chặng.

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

    Phạm vi nhỏ, rõ và hướng nhu cầu người dùng giúp một đội nhỏ chứng minh ý tưởng lớn trong thời gian ngắn. Hãy dám nhận mình nhắm quá cao, thu hẹp sớm và phát hành công khai để học.

    Nguồn tham khảo

    • GDS — The story of GOV.UK, 2011
    #Quản lý phạm vi#Chính phủ điện tử#GOV.UK#Nhu cầu người dùng#agile#Alpha công khai

    Nguồn: GDS — The story of GOV.UK, 2011 ↗ (mở trong thẻ mới)

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

    Câu 1/1
    Đội của bạn phát hiện cách tiếp cận ban đầu bao phủ quá nhiều dịch vụ và sẽ không kịp hạn của giai đoạn thử nghiệm. Bạn nên làm gì?

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

    Bạn dựng bản alpha cho dịch vụ công mới. Bạn ưu tiên điều gì?

    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ý Phạm vi

    Duke Nukem Forever: 14 năm phát triển khi phạm vi là một mục tiêu di động và không ai định nghĩa "xong"

    Công bố năm 1997 với kỳ vọng ra mắt cuối 1998, tựa game Duke Nukem Forever chuyển động cơ đồ hoạ nhiều lần, khởi động lại và chỉ phát hành tháng 6/2011 sau khi Gearbox tiếp quản. Phân tích dưới góc nhìn quản lý phạm vi: khi chủ dự án tự quyết mọi thay đổi, không có đường cơ sở và không có tiêu chí hoàn thành.

    0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận14/10/2026
    Quản lý Phạm vi

    FBI Sentinel (2006–2012): yêu cầu sáu năm tuổi, tạm dừng nhà thầu và cuộc đặt lại phạm vi theo hướng agile

    Sau thất bại của Virtual Case File, FBI giao Lockheed Martin xây hệ thống hồ sơ điện tử Sentinel theo bốn giai đoạn. Đến 2010, mới xong hai giai đoạn, thanh tra Bộ Tư pháp cảnh báo yêu cầu đã cũ và kế hoạch mới chưa được văn bản hoá. FBI dừng nhà thầu, tự phát triển theo agile với phạm vi thu hẹp và hệ thống được dùng toàn cơ quan từ 7/2012. Bài học về xếp hạng lại yêu cầu khi đã tiêu hao phần lớn ngân sách.

    0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận12/10/2026
    Quản lý Phạm vi

    Phoenix/Firefox (2002–2004): cắt gọt phạm vi của một bộ ứng dụng cồng kềnh để làm ra trình duyệt gọn nhẹ

    Một nhóm nhỏ trong cộng đồng Mozilla cho rằng áp lực thương mại và việc tính năng chồng chất đã làm Mozilla Suite phình to. Họ làm một trình duyệt độc lập, tối giản (Phoenix, sau đổi tên Firefox), ra bản 1.0 ngày 9/11/2004 và đạt 60 triệu lượt tải trong chín tháng. Ví dụ thành công của việc dám loại bỏ.

    0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận04/10/2026

    Nội dung

    Bối cảnh thực tếPhân tích theo chuẩn PMP và AgilePM có thể áp dụng thế nàoPM 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)