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. /Basecamp và Shape Up: ngân sách thời gian cố địn…
Quản lý Phạm vi

Basecamp và Shape Up: ngân sách thời gian cố định, phạm vi thay đổi và "cầu dao ngắt mạch" để dự án không kéo dài vô tận

Khi công ty lớn dần, nhóm Basecamp thấy dự án như không có vạch đích và tính năng ra chậm hơn thời đầu. Phương pháp Shape Up của họ đặt ngân sách thời gian cố định (chu kỳ sáu tuần), cho phạm vi co giãn và mặc định huỷ dự án không xong trong một chu kỳ thay vì tự động gia hạn. Một cách tiếp cận lai (hybrid) quản lý phạm vi từ góc nhìn "khẩu vị".

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ế

Shape Up là cuốn sách miễn phí của Basecamp mô tả cách họ làm sản phẩm. Theo phần mở đầu, khi công ty lớn lên từ khoảng năm 2015, các thành viên cảm thấy dự án không có vạch đích và những người sáng lập hỏi vì sao tính năng không còn ra nhanh như thời đầu. Họ nhớ lại giai đoạn đầu khi chỉ có khoảng mười giờ lập trình mỗi tuần: lúc đó họ "đóng búa" vào phạm vi để vừa khung thời gian cố định.

Từ đó họ hình thành các nguyên tắc:

  • Khẩu vị (appetite) thay cho ước lượng: ước lượng bắt đầu từ thiết kế và kết thúc bằng một con số; khẩu vị bắt đầu từ một con số (thời gian một đội chuẩn sẵn lòng đầu tư) và kết thúc bằng một thiết kế.
  • Thời gian cố định, phạm vi thay đổi: thời hạn cố định buộc phải đánh đổi, tách phần lõi khỏi phần ngoại vi.
  • Chu kỳ sáu tuần: đủ dài để hoàn thành việc có ý nghĩa, đủ ngắn để cảm nhận hạn chót từ ngày đầu; việc nhỏ được gom thành nhóm cho vừa chu kỳ.
  • Cầu dao ngắt mạch (circuit breaker): dự án không xong trong một chu kỳ mặc định bị huỷ, không tự động gia hạn.
  • Cuốn sách cũng coi "xong" là đã triển khai (done means deployed).

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

  • Đổi cách ràng buộc "tam giác": cố định thời gian, linh hoạt phạm vi

    Trong tam giác phạm vi – thời gian – chi phí, nhiều dự án phần mềm cố định phạm vi và để thời gian trượt. Shape Up làm ngược lại: thời gian và đội là ngân sách cố định, phạm vi là biến điều chỉnh, giúp tránh scope creep tự nhiên.

  • Phạm vi được hình thành trước khi giao cho đội (shaping)

    Việc làm rõ vấn đề, ranh giới và rủi ro trước khi bắt đầu một chu kỳ tương tự Define Scope ở mức vừa đủ chi tiết: đủ rõ để đội làm, đủ thoáng để đội tự quyết cách làm.

  • Cổng dừng mặc định thay cho gia hạn mặc định

Cầu dao ngắt mạch ngăn chi phí chìm tiếp tục tăng. Nếu dự án không xong, nó phải được đánh giá lại: đúng vấn đề chưa, phạm vi còn hợp lý không, thay vì kéo dài để cố "xong".

  • Định nghĩa hoàn thành là sản phẩm thật sự đến tay người dùng

    Khi "xong" được hiểu là đã triển khai, các phần việc lẻ (thiết kế đẹp nhưng chưa chạy, mã chưa phát hành) không được tính là hoàn thành, giúp tiến độ phản ánh đúng giá trị.

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

    1. 1

      Bước 1: Đặt khẩu vị và tiêu chí cắt phạm vi trước khi bắt đầu

      Mỗi hạng mục cần một ngân sách thời gian và quy tắc phân loại phạm vi:

      • Phải có

        Phần lõi làm cho tính năng dùng được và phát hành được trong ngân sách thời gian.

      • Tốt nếu có

        Phần bổ sung, chỉ làm khi còn thời gian; mặc định bị cắt khi hạn chót gần.

      • Ngoài chu kỳ

        Phần phát sinh khiến vượt ngân sách; chuyển thành đề xuất mới để cân nhắc cho chu kỳ sau.

    2. 2

      Bước 2: Áp dụng cổng dừng có chủ đích

      Khi dự án chưa xong ở hạn chót, tổ chức họp đánh giá: huỷ, định hình lại, hay lập chu kỳ mới; không tự gia hạn.

    3. 3

      Bước 3: Định nghĩa hoàn thành gắn với triển khai

      Gộp tiêu chí kiểm thử, tài liệu và triển khai vào cùng một đích "xong" để tránh tồn đọng việc dang dở.

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

    Muốn dự án có vạch đích, hãy cố định thứ khó thay đổi nhất (thời gian và đội) và để phạm vi co giãn có kỷ luật. Cầu dao ngắt mạch là cách biến "gia hạn thêm chút nữa" thành một quyết định có ý thức.

    Nguồn tham khảo

    • Basecamp — Shape Up, Chương 3: Set Boundaries
    • Basecamp — Shape Up, phần giới thiệu
    #Quản lý phạm vi#Shape Up#Basecamp#Ngân sách thời gian#agile#Cầu dao ngắt mạch

    Nguồn: Basecamp — Shape Up, Chương 3: Đặt ranh giới (Set Boundaries) ↗ (mở trong thẻ mới)

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

    Câu 1/1
    Một hạng mục được giao với ngân sách sáu tuần nhưng đến tuần thứ năm đội báo chỉ xong khoảng một nửa và đề nghị gia hạn thêm sáu tuần. Theo nguyên tắc "thời gian cố định, phạm vi thay đổi", PM nên làm gì?

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

    Dự án trễ hạn một chu kỳ, bạn sẽ làm 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)