Bài 6

Con người, Lãnh đạo & Công cụ

Quy trình và biểu đồ chỉ là khung sườn — phần lớn công việc của một Project Manager là về con người: dẫn dắt, tạo động lực, gỡ xung đột và giao tiếp rõ ràng, đi cùng bộ công cụ phù hợp để cả nhóm cùng nhìn về một hướng. Bài cuối này tổng hợp các kỹ năng mềm cốt lõi, hệ công cụ thực dụng và lộ trình phát triển nghề.

Lãnh đạo vs Quản lý

Hai mặt không thể thiếu của một PM giỏi

Quản lý (management) là làm cho công việc chạy đúng: lập kế hoạch, phân bổ nguồn lực, kiểm soát tiến độ, vận hành quy trình, đảm bảo mọi thứ đi đúng đường ray. Lãnh đạo (leadership) là làm cho con người muốn đi cùng bạn: đặt ra tầm nhìn, truyền cảm hứng, tạo ảnh hưởng và hướng năng lượng của nhóm về một mục tiêu chung.

Một PM giỏi cần cả hai. Chỉ quản lý mà không lãnh đạo thì nhóm làm việc như cái máy, thiếu động lực và sáng tạo. Chỉ lãnh đạo mà không quản lý thì đầy cảm hứng nhưng dự án trễ hạn, vượt ngân sách.

Các phong cách lãnh đạo

Directive (chỉ huy): ra quyết định nhanh, hướng dẫn cụ thể. Hợp khi khủng hoảng, deadline gấp, hoặc nhóm còn non kinh nghiệm.
Servant leadership (lãnh đạo phục vụ): đặt nhóm làm trung tâm, dọn chướng ngại, tạo điều kiện để nhóm tự tỏa sáng. Đặc biệt hợp với Agile — đây chính là tinh thần của một Scrum Master tốt.
Coaching (huấn luyện): tập trung phát triển năng lực từng người qua phản hồi và đặt câu hỏi thay vì ra lệnh. Dài hạn, xây dựng nhóm mạnh.
Democratic (dân chủ): ra quyết định dựa trên ý kiến tập thể, tăng cam kết và quyền sở hữu. Hợp với nhóm trưởng thành, vấn đề phức tạp cần nhiều góc nhìn.

Quyền lực của PM

Quyền lực của PM đến từ hai nguồn: positional power (quyền do chức danh, vị trí trao cho) và personal influence (ảnh hưởng cá nhân từ chuyên môn, uy tín, mối quan hệ). Thực tế, PM thường quản lý mà không có quyền trực tiếp với nhân sự — họ không phải sếp chấm lương của developer hay designer. Đây là tình huống lead without authority: bạn phải dẫn dắt bằng sự tin tưởng, năng lực thuyết phục và quan hệ, chứ không phải bằng mệnh lệnh.

Hệ quả: đầu tư vào personal influence — chuyên môn vững, giữ lời hứa, bảo vệ nhóm, minh bạch — quan trọng hơn nhiều so với việc trông cậy vào chức danh "Project Manager" trên danh thiếp.

Phát triển nhóm (Team)

Nhóm không tự nhiên mà mạnh — nó trưởng thành theo giai đoạn

Mô hình Tuckman

Bruce Tuckman mô tả nhóm đi qua các giai đoạn có thể đoán trước. Hiểu nhóm đang ở đâu giúp PM biết nên can thiệp thế nào.

Giai đoạn	Đặc điểm	Việc PM cần làm
Forming	Mới hình thành, lịch sự, dè dặt, chưa rõ vai trò và mục tiêu	Làm rõ mục tiêu, vai trò, kỳ vọng; tạo không khí an toàn để mọi người làm quen
Storming	Va chạm quan điểm, tranh giành cách làm, mâu thuẫn cá tính nổi lên	Hỗ trợ xử lý xung đột lành mạnh, thiết lập quy tắc làm việc chung, giữ bình tĩnh
Norming	Bắt đầu ăn ý, hình thành chuẩn mực, tin tưởng và hợp tác tăng	Củng cố cách làm tốt, khích lệ tự chủ, để nhóm tự ra quyết định nhiều hơn
Performing	Vận hành trơn tru, năng suất cao, tự giải quyết vấn đề	Lùi lại, gỡ chướng ngại, giao quyền; tập trung tầm nhìn và phát triển con người
Adjourning	Dự án kết thúc, nhóm giải tán	Ghi nhận đóng góp, tổ chức retrospective, ăn mừng và đúc kết bài học

Lưu ý: nhóm có thể quay lại giai đoạn trước khi có thành viên mới, đổi mục tiêu hay thay đổi lớn — đừng coi tiến trình là một chiều.

Nhóm tự tổ chức (self-organizing)

Trong Agile, nhóm tự tổ chức: tự quyết cách chia việc, ai làm gì, ước lượng ra sao. Vai trò của PM/Scrum Master không phải giao việc chi tiết mà là tạo môi trường để nhóm tự ra quyết định tốt — đặt mục tiêu rõ, cung cấp thông tin và bảo vệ nhóm khỏi nhiễu loạn bên ngoài.

Niềm tin & an toàn tâm lý

Nghiên cứu Project Aristotle của Google chỉ ra psychological safety (an toàn tâm lý) là yếu tố số một của nhóm hiệu quả: thành viên dám nói ra ý tưởng, đặt câu hỏi "ngớ ngẩn", thừa nhận sai lầm mà không sợ bị phán xét. PM xây nó bằng cách: chính mình thừa nhận lỗi, đón nhận tin xấu mà không "bắn người đưa tin", và biến mỗi sự cố thành bài học thay vì cuộc truy tìm tội phạm.

Động lực (Motivation)

Hiểu điều gì thực sự khiến con người làm việc

Tháp nhu cầu Maslow

Con người được thúc đẩy theo các tầng nhu cầu từ thấp đến cao: sinh lý → an toàn → xã hội (thuộc về) → được tôn trọng → tự thể hiện. Người ta chỉ thực sự quan tâm tầng cao khi tầng thấp đã được đáp ứng — đừng nói về "tầm nhìn truyền cảm hứng" với một người đang lo bị sa thải.

Hai yếu tố của Herzberg

Herzberg chia thành yếu tố duy trì (hygiene) và yếu tố tạo động lực (motivators). Hygiene (lương, điều kiện làm việc, chính sách, quan hệ) nếu thiếu sẽ gây bất mãn, nhưng có đủ cũng không tự sinh ra động lực. Động lực thật đến từ motivators: thành tựu, sự ghi nhận, công việc thú vị, trách nhiệm và cơ hội phát triển.

Hệ quả thực tế: tăng lương sửa được bất mãn nhưng không tạo ra hứng khởi lâu dài. Muốn nhóm bứt phá, hãy đầu tư vào công việc ý nghĩa, ghi nhận và cơ hội trưởng thành.

Daniel Pink: Autonomy – Mastery – Purpose

Với người làm tri thức/kỹ thuật, mô hình của Daniel Pink đặc biệt đúng:

Autonomy (tự chủ): được tự quyết cách làm, công cụ, lịch trình — thay vì bị quản lý vi mô.
Mastery (tinh thông): được liên tục giỏi hơn ở thứ mình quan tâm; có thử thách vừa sức và thời gian học hỏi.
Purpose (ý nghĩa): hiểu công việc của mình phục vụ điều gì lớn hơn lương.

Tạo động lực cho nhóm kỹ thuật: giao bài toán thay vì giao thao tác (để họ tự thiết kế giải pháp); dành "slack time" hoặc hackathon để khám phá công nghệ; ghi nhận giải pháp đẹp về kỹ thuật trước cả nhóm; giảm họp vô nghĩa và bảo vệ thời gian tập trung (deep work); kết nối tính năng họ làm với tác động thật lên người dùng.

Xung đột & Đàm phán

Xung đột là bình thường — quản lý kém mới là vấn đề

Xung đột trong dự án đến từ nhiều nguồn: tranh giành nguồn lực, ưu tiên khác nhau giữa các bên, khác biệt cách làm hay phong cách kỹ thuật, lịch trình chồng chéo, vai trò không rõ, và đôi khi là va chạm cá tính. Xung đột về ý tưởng thường lành mạnh và đáng khuyến khích; xung đột về con người mới cần xử lý sớm.

Năm kiểu xử lý xung đột (Thomas-Kilmann)

Kiểu	Bản chất	Khi nào dùng
Collaborating	Cùng tìm giải pháp thắng-thắng, đào sâu nhu cầu hai bên	Vấn đề quan trọng với cả hai, có thời gian, cần cam kết cao
Compromising	Mỗi bên nhường một phần, gặp ở giữa	Hai bên ngang sức, cần giải pháp nhanh tạm chấp nhận được
Accommodating	Nhường bên kia, ưu tiên quan hệ hơn vấn đề	Vấn đề với bạn không quan trọng bằng giữ quan hệ, hoặc bạn sai
Competing	Áp đặt quan điểm của mình, thắng-thua	Khủng hoảng cần quyết đoán, vấn đề nguyên tắc, không thể nhượng bộ
Avoiding	Né tránh, hoãn lại	Vấn đề nhỏ, cần thời gian hạ nhiệt, hoặc không phải lúc

Không có kiểu nào "đúng" tuyệt đối — PM giỏi đọc tình huống và linh hoạt chọn. Mặc định nên hướng tới collaborating cho những vấn đề thực sự quan trọng.

Giao tiếp & lắng nghe

Nền tảng của mọi kỹ năng trên là giao tiếp. Thực hành lắng nghe chủ động: nhắc lại để xác nhận đã hiểu đúng, hỏi để làm rõ thay vì giả định, tách bạch sự việc khỏi cảm xúc. Khi đàm phán, tập trung vào lợi ích đằng sau lập trường ("vì sao bạn cần điều đó?") thay vì cãi nhau về vị trí ban đầu.

Công cụ quản lý dự án

Chọn theo phương pháp và đặc thù nhóm, không chạy theo trend

Công cụ	Thế mạnh	Hợp với
Jira	Quản lý Agile/Scrum/Kanban sâu, backlog, sprint, board, báo cáo burndown/velocity; tích hợp Git/CI	Nhóm phát triển phần mềm, dev-heavy, làm Agile nghiêm túc
Asana / Trello	Nhẹ, trực quan, dễ dùng; Trello dạng bảng Kanban đơn giản, Asana mạnh hơn về task & timeline	Nhóm nhỏ, dự án không-kỹ-thuật, marketing, vận hành
MS Project	Biểu đồ Gantt, đường găng (critical path), quản lý nguồn lực và phụ thuộc chi tiết	Dự án truyền thống (waterfall), xây dựng, kế hoạch dài hạn
Azure DevOps	Trọn bộ: backlog/board + repo Git + pipeline CI/CD + test, tất cả trong một	Nhóm Microsoft stack, muốn liền mạch từ kế hoạch tới triển khai
Confluence	Wiki/tài liệu, lưu trữ kiến thức, biên bản họp, đặc tả; ghép tốt với Jira	Mọi nhóm cần "nguồn sự thật" cho tài liệu
Miro	Bảng trắng cộng tác trực tuyến: brainstorm, sơ đồ, story mapping, retrospective	Nhóm làm việc từ xa cần cộng tác trực quan thời gian thực

Nguyên tắc chọn: công cụ phải phục vụ phương pháp và nhóm, không ngược lại. Nhóm nhỏ đừng ép dùng Jira phức tạp; nhóm dev nghiêm túc đừng cố nhét sprint vào Trello. Quan trọng nhất là cả nhóm thực sự dùng nó nhất quán.

PM cho dự án Data/Tech

Đặc thù khiến cách quản lý phải khác

Dự án dữ liệu và kỹ thuật có những đặc điểm khiến cách quản lý kiểu kế hoạch cứng dễ thất bại:

Yêu cầu mơ hồ & cần khám phá: nhiều khi không biết trước dữ liệu có gì, mô hình có chạy được không — phải data discovery rồi mới ước lượng được.
Phụ thuộc chất lượng dữ liệu: dữ liệu bẩn, thiếu, lệch chuẩn có thể làm đổ cả kế hoạch; "làm sạch dữ liệu" thường ngốn nhiều thời gian hơn dự kiến.
Môi trường & CI/CD: pipeline cần môi trường dev/staging/prod, kiểm thử dữ liệu, triển khai tự động — hạ tầng là một phần công việc, không phải việc phụ.
Nợ kỹ thuật: giải pháp nhanh ban đầu tích tụ thành nợ, làm chậm dần về sau; PM cần bảo vệ thời gian để trả nợ kỹ thuật.
Phối hợp nhiều vai trò: Data Engineer, Data Scientist, Analyst, BE/FE — mỗi vai trò có nhịp làm việc và "ngôn ngữ" riêng, PM phải làm cầu nối.

Gợi ý: dùng Agile cho khả năng thích nghi, và dành spike (một time-box ngắn để nghiên cứu/thử nghiệm) cho phần không chắc chắn — chạy spike để giảm rủi ro trước khi cam kết ước lượng cho cả tính năng.

Để hiểu sâu hơn bản chất kỹ thuật mà nhóm bạn đang làm, xem các phần khác của site: Data Engineering (pipeline, batch/stream), Spark (xử lý dữ liệu lớn) và các chủ đề về governance / chất lượng dữ liệu — hiểu công việc kỹ thuật giúp bạn lập kế hoạch và đối thoại với nhóm tốt hơn rất nhiều.

Phát triển nghề & Chứng chỉ

Bản đồ các chứng chỉ phổ biến và lộ trình

Chứng chỉ	Tổ chức	Phù hợp với
PMP (Project Management Professional)	PMI	PM tổng quát, có kinh nghiệm; chứng chỉ "vàng" được nhà tuyển dụng công nhận rộng
CAPM (Certified Associate in PM)	PMI	Người mới, đầu vào ngành, chưa đủ kinh nghiệm thi PMP
PSM / CSM (Professional / Certified Scrum Master)	Scrum.org / Scrum Alliance	Người làm Scrum Master, đi sâu vào Agile/Scrum
PMI-ACP (Agile Certified Practitioner)	PMI	PM làm theo Agile (đa phương pháp: Scrum, Kanban, Lean, XP)
PRINCE2	AXELOS	Quản lý dự án theo quy trình; phổ biến ở châu Âu và khu vực công

Lộ trình học gợi ý

Nắm nền tảng trước: đọc PMBOK Guide / Scrum Guide để có khung tư duy chung.
Nếu mới vào nghề, bắt đầu với CAPM hoặc PSM I / CSM — vừa sức, củng cố thuật ngữ.
Tích lũy kinh nghiệm thật trên dự án song song với học lý thuyết.
Khi đủ giờ dự án, thi PMP (waterfall + agile) hoặc PMI-ACP nếu thiên về Agile.
Liên tục cập nhật: cộng đồng, sách, retrospective từ chính dự án của mình.

Sự thật quan trọng: chứng chỉ mở cánh cửa và hệ thống hóa kiến thức, nhưng kinh nghiệm thực chiến — đã từng cứu một dự án trễ hạn, gỡ một xung đột thật, dẫn một nhóm qua giai đoạn Storming — mới là thứ làm nên một PM giỏi. Học chứng chỉ để có ngôn ngữ chung, nhưng đừng coi nó là đích đến.