PM vs EM vs TPM: Bạn thật sự đang đóng vai nào?

Cuộc trò chuyện đầu tiên về việc ai-làm-gì trong một dự án phần mềm gần như bao giờ cũng bắt đầu từ chức danh, và gần như bao giờ cũng rối. Một người mang chức danh "Senior Engineer" thực ra đang làm việc của PM. Một người tên là "PM" lại đang làm việc của TPM. Còn một "EM" thì lại đang được nhờ ước lượng. Mục đích của chương này là tách ba vai trò đó ra một cách sạch sẽ, để bạn gọi đúng tên việc bạn đang thực sự làm hôm nay và biết việc nào nên uỷ quyền cho người khác.

Khi nào câu hỏi về vai trò thật sự quan trọng?

Có ba thời điểm.

Lúc kickoff dự án. Phải có người đứng tên sở hữu scope, schedule và status. Nếu cả ba người cùng nghĩ "chắc người kia sẽ lo", dự án sẽ trôi đi cả tháng trước khi có ai đó nhận ra. Ghi rõ vai trò ngay trong kickoff doc là cách bảo hiểm rẻ tiền nhất.

Lúc tuyển dụng. Một mô tả công việc trộn lẫn trách nhiệm EM và PM là công thức chắc chắn cho việc tuyển sai người và nhân viên thất vọng sau vài tháng. Tuyển đúng người luôn bắt đầu từ việc biết rõ mình đang cần vai nào.

Lúc trao đổi về sự nghiệp. Câu nói "tôi muốn phát triển" thường rơi vào một trong ba hướng: đóng góp cá nhân sâu hơn, quản lý người nhiều hơn, hoặc điều phối phạm vi rộng hơn. Mỗi hướng tương ứng với một vai trò khác nhau. Sếp bạn không thể giúp được nếu bạn không gọi tên ra được hướng mình chọn.

Cái giá phải trả khi vai trò vẫn còn ngầm là gì?

Có ba kiểu lỗi thường gặp.

Quyết định bị kẹt. Hai người cùng nghĩ "chắc người kia sẽ quyết". Suốt hai tuần liền không có gì xảy ra. Đến lúc cuối cùng có ai đó ép phải quyết, các phương án tốt đã đóng cửa từ lâu.

Sai người làm sai việc. EM rốt cuộc lại đi viết status report vì không có PM; PM lại đi viết code vì không đủ engineering. Cả hai đều làm phần việc tốt thứ hai của mình và bỏ lỡ phần việc tốt nhất.

Stakeholder nhận tín hiệu mâu thuẫn. Sales hỏi PM về ETA, nhận một con số. Sau đó hỏi EM, nhận một con số khác. Khách hàng nghe được cả hai. Niềm tin bắt đầu bào mòn từ đó.

Phân chia vai trò ở team 5 người trông thế nào?

flowchart TB
    Lead[Tech Lead<br/>1 người] --> PM[Việc PM:<br/>scope, schedule, status]
    Lead --> EM[Việc EM:<br/>1-on-1, phát triển, tuyển]
    Lead --> TPM[Việc TPM:<br/>comms đa team]
    Lead --> IC[Việc IC:<br/>code, thiết kế]

Một người gánh cả bốn chiếc mũ. Thử thách lớn nhất là không để rơi chiếc nào: nếu tech lead dành 100% thời gian để code, chiếc mũ PM sẽ rơi xuống và dự án bắt đầu trôi. Cách phòng ngừa là kỷ luật về lịch - chặn buổi sáng cho việc IC, chặn một buổi chiều mỗi tuần cho 1-on-1, và viết status report đều đặn vào thứ Sáu.

Phân chia vai trò ở 50+ người trông thế nào?

flowchart TB
    VP[VP Eng] --> EM1[EM<br/>Team A]
    VP --> EM2[EM<br/>Team B]
    VP --> EM3[EM<br/>Team C]
    PMO[PM Lead] --> PM1[PM<br/>Dự án X]
    PMO --> PM2[PM<br/>Dự án Y]
    TPMO[TPM Lead] --> TPM1[TPM<br/>Initiative Z<br/>vượt A B C]
    EM1 -.cộng tác.-> PM1
    EM2 -.cộng tác.-> PM2
    EM3 -.cộng tác.-> TPM1

Khi tổ chức vượt 50 engineer, các vai trò bắt đầu tách ra. Mỗi EM phụ trách con người của một team (5-8 báo cáo). Mỗi PM phụ trách lịch trình của một dự án (thường trải dài 1-2 team). Mỗi TPM phụ trách một initiative liên team (3+ team hoặc vendor). Các vai trò này phối hợp với nhau theo cách rõ ràng: mỗi dự án đều có cả một EM (cấp engineer cho team) và một PM (chạy lịch trình). Chương về stakeholder sẽ nói tiếp về cách bộ ba này giao tiếp ra bên ngoài.

Template định nghĩa vai trò cụ thể là gì?

Đây là một block markdown ngắn, để trong README.md hoặc trong kickoff doc của dự án:

## Vai trò

| Vai trò     | Người        | Trách nhiệm                                     |
|-------------|--------------|-------------------------------------------------|
| Sponsor     | {{ Tên }}    | Phê duyệt scope và budget, gỡ blocker          |
| Tech Lead   | {{ Tên }}    | Sở hữu kiến trúc, mentor engineer              |
| PM          | {{ Tên }}    | Sở hữu schedule, status, đổi scope             |
| EM          | {{ Tên }}    | Sở hữu nhân sự, hiệu suất, giữ người           |
| TPM         | {{ Tên }}    | Sở hữu phối hợp đa team (nếu 2+ team)          |
| Engineer    | {{ Tên }}    | Xây cái này                                    |
| QA          | {{ Tên }}    | Kế hoạch test, tiêu chí ra mắt                 |
| Designer    | {{ Tên }}    | UX, tuân thủ design system                     |

## Quyền quyết định

- Đổi scope: PM (cần Sponsor duyệt nếu ảnh hưởng tới budget)
- Kiến trúc: Tech Lead (peer review cho thay đổi lớn)
- Tuyển dụng: EM (panel của team + sponsor)
- Chọn vendor: PM (có Tech Lead tham vấn)

## Đường escalation

Engineer -> Tech Lead -> EM -> VP Eng -> Sponsor

Phần "Quyền quyết định" là phần mà phần lớn các team bỏ qua, và cũng là chỗ phần lớn dự án bị kẹt. Khi không có nó, mọi quyết định mặc định sẽ bị đẩy ngược lên sponsor - vừa chậm, vừa không scale được.

Vai trò mơ hồ tạo ra những kiểu lỗi nào?

Có bốn kiểu lỗi cổ điển:

• Hai PM cùng dắt một dự án. Một PM được tuyển vào mà không kiểm tra xem ai đã đang dẫn dự án. Họ kéo dự án về hai hướng khác nhau suốt cả quý trước khi có ai đó nhận ra. Cách phòng: mỗi dự án có đúng một người chịu trách nhiệm chính, ghi rõ trong kickoff doc.
• EM lại đi làm việc của PM. Một người-quản-lý tiêu tốn 60% thời gian để viết status report vì không có PM nào cả. Các buổi 1-on-1 của họ vì thế bị ảnh hưởng; tỉ lệ nghỉ việc trong team bắt đầu tăng. Cách phòng: hoặc tuyển một PM, hoặc rút khỏi dự án.
• TPM không có thực quyền. Một TPM được chỉ định để "điều phối" nhưng không có budget, không có quyền quyết, cũng không có đường báo cáo qua các team. Họ gửi lời mời họp mà không ai nhận. Cách phòng: vai trò TPM cần được trao thực quyền rõ ràng, có sponsor cấp cao đứng sau.
• Tech lead né tránh chiếc mũ PM. Một engineer senior thật lòng chỉ muốn code, nên cứ hoãn lại các quyết định về scope. Team bắt đầu đi hỏi PM của team bên cạnh để xin hướng dẫn, và quyền sở hữu dự án cứ thế trôi đi. Cách phòng: chặn lịch rõ ràng cho công việc PM hàng tuần và duy trì checklist.

Khi nào việc phân biệt vai trò là quá liều?

Có hai tình huống.

Team hai người. Hai engineer xây một side project chẳng cần chính thức hoá gì cả về PM, EM hay TPM. Việc cần làm là ship.

Prototype có hạn thời gian rõ. Một spike hai tuần không có rủi ro lịch trình nào đáng để quản lý chính thức. Engineer senior cứ quyết và ghi lại kết quả là đủ.

Phân vai trò chỉ thật sự đáng phức tạp khi team vượt qua khoảng 5 engineer, khi dự án bắt đầu vượt biên giới của một team, hoặc khi không còn ai có thể giữ hết bối cảnh trong đầu được nữa.

Đi tiếp từ đây như thế nào?

Chương tiếp theo: ước lượng cơ bản - artifact đầu tiên và cụ thể nhất mà mọi PM đều phải sở hữu. Sau đó, theo dõi rủi ro và issue sẽ nói về cách giữ cho dự án an toàn khi đã bắt đầu chạy.