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. /Quản lý các bên liên quan
  2. /Khách hàng nhắn thẳng cho lập trình viên lúc 10 …
Quản lý các bên liên quan· Domain: Các bên liên quan

Khách hàng nhắn thẳng cho lập trình viên lúc 10 giờ đêm: thiết kế kênh giao tiếp với khách hàng doanh nghiệp mà không dựng "bức tường"

Khi nhân viên khách hàng nhắn trực tiếp cho lập trình viên, yêu cầu nhỏ được làm ngay, nhưng phạm vi trôi dần và đội mất tập trung. Cấm hẳn thì khách hàng thấy bị cản trở. Bài viết phân tích số kênh giao tiếp, vai trò đầu mối và cách phân luồng thông tin theo loại nội dung.

HP
Nguyễn Thu Hà, PMP
12/05/2026
6 phút đọc 0 0
Khách hàng nhắn thẳng cho lập trình viên lúc 10 giờ đêm: thiết kế kênh giao tiếp với khách hàng doanh nghiệp mà không dựng "bức tường"

Tình huống minh hoạ

Tình huống và số liệu dưới đây là giả định, dùng để minh hoạ.

Một công ty phần mềm phát triển ứng dụng quản lý đội xe cho một doanh nghiệp vận tải. Sau ba tháng làm việc chung, các thành viên hai bên đã kết bạn trên ứng dụng nhắn tin. Trưởng phòng điều độ phía khách hàng bắt đầu nhắn trực tiếp cho hai lập trình viên:

  • "Em ơi, thêm giúp anh cột biển số vào màn hình này nhé, nhanh thôi."
  • "Báo cáo hôm qua sai số liệu xe chi nhánh miền Trung, em xem gấp."
  • "Sếp anh hỏi bao giờ có tính năng định vị, em cho anh ngày nhé."

Lập trình viên vui vẻ làm. Khách hàng hài lòng vì "đội phản hồi nhanh". Sau sáu tuần, PM phát hiện:

  • 17 thay đổi nhỏ đã được đưa vào mã nguồn mà không có trong backlog, không được kiểm thử hồi quy đầy đủ.
  • Một lập trình viên đã hứa ngày có tính năng định vị, ngày này mâu thuẫn với lộ trình đã báo cáo ban chỉ đạo.
  • Velocity của đội giảm khoảng 20% do bị ngắt quãng liên tục.

Khi PM đề nghị "mọi yêu cầu phải qua PM", trưởng phòng điều độ phản ứng: "Bên anh đang làm khó chúng tôi".

Vì sao giao tiếp trực tiếp vừa tốt vừa nguy hiểm

Giao tiếp trực tiếp giữa người dùng và đội phát triển là một giá trị — Tuyên ngôn Agile đề cao cộng tác với khách hàng hơn đàm phán hợp đồng và cá nhân, tương tác hơn quy trình, công cụ. Vấn đề không nằm ở việc nói chuyện trực tiếp, mà ở việc quyết định được đưa ra qua những kênh không ai theo dõi.

Số kênh giao tiếp tăng rất nhanh theo số người. Công thức quen thuộc trong đề PMP:

Số kênh = n × (n − 1) / 2

Với 6 người phía nhà cung cấp và 4 người phía khách hàng thường xuyên liên lạc (n = 10), có 10 × 9 / 2 = 45 kênh. Thêm 5 người dùng chủ chốt (n = 15): 15 × 14 / 2 = 105 kênh. Không PM nào kiểm soát được từng kênh — và cũng không nên. Cái cần kiểm soát là loại thông tin nào được đi qua kênh nào.

Phân tích theo PMBOK® Guide

  • Plan Communications Management xác định ai cần thông tin gì, khi nào, qua kênh nào, ai có thẩm quyền phát hành thông tin. Kế hoạch truyền thông không chỉ là lịch báo cáo; nó còn là quy tắc về thẩm quyền: ai được hứa ngày, ai được nhận yêu cầu thay đổi.
  • Perform Integrated Change Control: mọi thay đổi đường cơ sở phải qua quy trình kiểm soát thay đổi. Thay đổi "nhỏ thôi" vẫn là thay đổi.
  • Trong khung Scrum, Product Owner là người duy nhất quản lý Product Backlog và có thể đại diện cho nhu cầu của nhiều stakeholder; ai muốn thay đổi thứ tự ưu tiên thì thuyết phục Product Owner. Điều này không cấm nói chuyện với lập trình viên — nó chỉ định nơi quyết định ưu tiên.

Tình huống liên quan

Quản lý các bên liên quanCác bên liên quan

Người quyết định thật không có trong sơ đồ tổ chức: nhận diện và gắn kết stakeholder "ẩn"

Mọi cuộc họp với Phó Tổng giám đốc đều suôn sẻ, nhưng quyết định cứ bị "treo" sau đó. Hoá ra người được hỏi ý kiến cuối cùng là một chuyên gia lâu năm không có chức danh quản lý. Cách vẽ bản đồ ảnh hưởng không chính thức và gắn kết stakeholder ẩn mà không đi đường vòng.

Ngày đăng: 06/10/2026Lượt xem: 1Bình luận: 0
Quản lý các bên liên quanCác bên liên quan

Phòng Pháp chế "xuất hiện" sát ngày go-live: nhận diện stakeholder sớm với mô hình Salience

Một bộ phận chưa từng được mời họp bỗng đề nghị dừng go-live vì rủi ro tuân thủ. Vì sao nhận diện stakeholder phải làm sớm, lặp lại, và cách dùng mô hình Salience để ưu tiên.

Ngày đăng: 01/10/2026Lượt xem: 6Bình luận: 0
Quản lý các bên liên quanCác bên liên quan

Stakeholder quyền lực cao liên tục thay đổi yêu cầu: PM nên làm gì?

Giám đốc khối kinh doanh gửi yêu cầu mới mỗi tuần qua tin nhắn. Làm sao giữ quan hệ tốt mà vẫn bảo vệ được baseline dự án?

Ngày đăng: 01/10/2026Lượt xem: 1.245Bình luận: 3Đánh giá: 4.5
Quản lý các bên liên quanCác bên liên quan

Sponsor được điều chuyển giữa dự án: giữ "người bảo trợ" khi ghế lãnh đạo đổi chủ

Sponsor khởi xướng dự án được điều chuyển, người kế nhiệm chưa từng nghe về business case. Cách PM chủ động "onboard" sponsor mới, tái xác nhận giá trị và tránh để dự án mồ côi.

Ngày đăng: 01/10/2026Lượt xem: 2Bình luận: 0
  • Ma trận RACI cho từng loại quyết định (hứa ngày, nhận yêu cầu, xử lý lỗi khẩn) giúp mọi người biết ai là "A".
  • Cách làm: phân luồng theo loại thông tin

    Thay vì "mọi thứ phải qua PM", hãy thiết kế ba làn:

    Làn 1 — Làm rõ nghiệp vụ: trực tiếp, khuyến khích

    Câu hỏi kiểu "trường này nghĩa là gì", "quy trình này xử lý xe thuê ngoài thế nào" — lập trình viên và người dùng trao đổi trực tiếp, nhanh nhất có thể. Kết quả quan trọng được ghi lại vào story hoặc tài liệu yêu cầu.

    Làn 2 — Yêu cầu mới, thay đổi, cam kết ngày: qua đầu mối

    Mọi thứ thay đổi phạm vi, ưu tiên hoặc lịch đi qua một đầu mối duy nhất (single point of contact) mỗi phía — thường là PM/Product Owner phía nhà cung cấp và đầu mối dự án phía khách hàng. Lập trình viên được hướng dẫn một câu trả lời chuẩn, lịch sự: "Ý này hay, em ghi lại và chuyển anh Minh (PO) để xếp ưu tiên, anh Minh sẽ báo lại anh ngày cụ thể."

    Làn 3 — Sự cố khẩn cấp: kênh riêng có trực

    Lỗi ảnh hưởng vận hành đi qua kênh hỗ trợ có người trực và thời gian phản hồi rõ ràng, không đi qua tin nhắn cá nhân của một lập trình viên.

    Bảng phân luồng tóm tắt

    Loại nội dungKênhAi quyết địnhThời gian phản hồi cam kết
    Hỏi đáp nghiệp vụ, làm rõ storyTrực tiếp hoặc kênh nhóm chungNgười dùng và lập trình viênTrong ngày
    Yêu cầu mới, thay đổi giao diện, báo cáo mớiĐầu mối hai bên → backlogProduct Owner / PMĐánh giá trong 2 ngày làm việc
    Hỏi ngày bàn giao, lộ trìnhĐầu mối hai bênPM (theo lộ trình đã duyệt)Trong 1 ngày làm việc
    Lỗi ảnh hưởng vận hànhKênh hỗ trợ có trựcTrưởng nhóm trựcTheo mức độ nghiêm trọng đã thống nhất

    Bảng này nên nằm trong kế hoạch truyền thông và được dán ở đầu kênh nhóm chung, để người mới tham gia phía khách hàng cũng biết.

    Công bố quy tắc cùng nhau, không đơn phương

    Trình bày ba làn với đầu mối và trưởng các phòng phía khách hàng; giải thích bằng lợi ích của chính họ: thay đổi được kiểm thử, ngày hứa là ngày thật, đội không bị ngắt quãng nên làm nhanh hơn. Một kênh nhóm chung (thay cho tin nhắn riêng) giúp minh bạch mà không làm chậm.

    Cho thấy luồng mới vẫn nhanh

    Nếu yêu cầu qua đầu mối mất hai tuần mới có phản hồi, khách hàng sẽ quay lại nhắn riêng. Cam kết thời gian phản hồi (ví dụ: yêu cầu mới được đánh giá trong 2 ngày làm việc, xếp vào buổi refinement gần nhất) là điều kiện để quy tắc sống được.

    Sai lầm thường gặp

    • Dựng "bức tường": cấm mọi liên lạc trực tiếp, mọi câu hỏi phải qua PM — PM thành nút cổ chai, khách hàng thấy bị cản trở.
    • Đổ lỗi cho lập trình viên: họ làm vì muốn giúp khách hàng; vấn đề là thiếu quy tắc, không phải thiếu kỷ luật.
    • Hợp thức hoá im lặng 17 thay đổi: cần rà soát, ghi nhận vào backlog, kiểm thử hồi quy và báo cáo minh bạch cho ban chỉ đạo — kể cả ngày đã bị hứa sai.
    • Không có kênh khẩn cấp: khách hàng buộc phải dùng tin nhắn cá nhân vì không còn cách nào khác.

    Góc ôn thi PMP

    • Công thức số kênh giao tiếp n(n − 1)/2. Câu hỏi hay gặp: "đội tăng từ 8 lên 12 người, số kênh tăng thêm bao nhiêu?" → 66 − 28 = 38 kênh.
    • Khi phát hiện thành viên làm thay đổi theo yêu cầu trực tiếp của khách hàng: PM tìm hiểu, đánh giá tác động, đưa vào quy trình kiểm soát thay đổi, và cập nhật kế hoạch truyền thông để tránh lặp lại.
    • Trong bối cảnh agile, đáp án thường là hướng stakeholder tới Product Owner để ưu tiên backlog, không phải PM tự quyết hay đội tự làm.

    Nguồn tham khảo

    • Wikipedia – Brooks's law (số kênh giao tiếp tăng nhanh theo số người)
    • The Scrum Guide 2020 – vai trò Product Owner và Product Backlog
    • Manifesto for Agile Software Development
    #khach-hang-doanh-nghiep#kenh-truyen-thong#ke-hoach-truyen-thong#single-point-of-contact#Scope creep

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

    Câu 1/1
    Trong buổi rà soát mã nguồn, PM phát hiện một lập trình viên đã thêm ba thay đổi nhỏ theo tin nhắn trực tiếp của trưởng phòng phía khách hàng. Các thay đổi chưa có trong backlog và chưa được kiểm thử hồi quy. Khách hàng rất hài lòng với các thay đổi này. PM nên làm gì?

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

    Khách hàng doanh nghiệp quen nhắn trực tiếp cho lập trình viên; đội phản hồi nhanh nhưng phạm vi trôi. Bạn chỉ được chọn một thay đổi chính để bắt đầu. Nếu là PM, bạn chọn gì?

    Bài viết hữu ích? Chia sẻ cho đồng nghiệp nhé!

    Đánh giá bài viết

    Bình luận

    Mục lục

    Tình huống minh hoạVì sao giao tiếp trực tiếp vừa tốt vừa nguy hiểmPhân tích theo PMBOK® GuideCách làm: phân luồng theo loại thông tinSai lầm thường gặpGóc ôn thi PMPNguồn tham khảoTrắc nghiệmBình chọn
    Quảng cáoBộ đề thi thử PMP (mẫu)
    Quảng cáoTemplate quản lý dự án (mẫu)