PO, PM và BA khác nhau thế nào? Đọc JD để biết vai trò thật
Phân biệt PO, PM và BA theo trách nhiệm thật, cách ranh giới thay đổi theo từng loại công ty ở Việt Nam, và cách đọc tin tuyển dụng để biết vị trí đó thực chất là gì.
Viết bởi Phan Lâm Duy Khôi
Product Owner là một trách nhiệm trong Scrum: người chịu trách nhiệm tối đa hóa giá trị sản phẩm và quyết thứ tự backlog. Product Manager và Business Analyst là chức danh công việc: PM thường lo vì sao và làm gì cho sản phẩm, BA lo làm rõ nhu cầu và yêu cầu, nhưng ranh giới thật phụ thuộc vào từng công ty.
Ba tin tuyển dụng, ba chức danh, một kiểu công việc?
Bạn đang làm QA được hai năm và muốn chuyển sang mảng product. Tối nay bạn lưu ba tin tuyển dụng. Tin thứ nhất ghi “Product Owner” ở một công ty làm dự án phần mềm cho khách nước ngoài, yêu cầu viết tài liệu đặc tả và họp với khách mỗi tuần. Tin thứ hai ghi “Business Analyst” ở một công ty có sản phẩm riêng, yêu cầu quản lý backlog và chọn tính năng cho từng sprint. Tin thứ ba ghi “Product Manager” ở một startup năm người, yêu cầu vừa nói chuyện với khách, vừa viết user story, vừa theo dõi số liệu.
Đây là tình huống minh họa, nhưng rất gần với cảm giác của nhiều người khi mới tìm việc: chức danh nói một đằng, mô tả công việc nói một nẻo. Bạn không biết nên học gì, nên ứng tuyển tin nào, và lỡ vào rồi thì công việc hằng ngày sẽ ra sao.
Bài này giúp bạn tách ba khái niệm hay bị trộn lẫn, thấy ranh giới thay đổi thế nào theo từng loại công ty, rồi dùng một checklist để đọc tin tuyển dụng theo việc thật thay vì theo tên gọi. Nếu bạn chưa rõ một ngày của PO trông thế nào, có thể đọc trước bài Product Owner thực sự làm gì mỗi ngày.
Vì sao PO, PM và BA dễ bị nhầm?
Lý do đầu tiên: ba cái tên này không cùng một loại. Product Owner (PO) xuất phát từ Scrum. Scrum Guide 2020 gọi PO là một trong ba “accountabilities”, tức trách nhiệm, của Scrum Team. PO chịu trách nhiệm tối đa hóa giá trị sản phẩm mà team làm ra, và là một người, không phải một hội đồng. Product Manager (PM) và Business Analyst (BA) thì là chức danh công việc, không có một bộ quy tắc chung nào định nghĩa.
Lý do thứ hai: phần việc chồng lên nhau thật. IIBA, hiệp hội nghề nghiệp của BA, định nghĩa phân tích nghiệp vụ là việc giúp tổ chức thay đổi bằng cách làm rõ nhu cầu và đề xuất giải pháp mang lại giá trị. Chính IIBA cũng liệt kê Product Manager và Product Owner trong số những chức danh có làm công việc phân tích nghiệp vụ. Nói cách khác, PO và PM giỏi đều phải phân tích, và BA giỏi cũng phải nghĩ về giá trị.
Lý do thứ ba: mỗi công ty tự chia việc theo cách của mình. Bài viết của Scrum.org về PO và PM ghi nhận rằng ở công ty lớn, PM thường lo nghiên cứu thị trường và chiến lược, còn PO tập trung vào backlog và đội phát triển. Bài đó cũng cảnh báo một kiểu thất bại phổ biến: PO bị giới hạn quyền tới mức chỉ còn là người quản trị backlog.
Ở Việt Nam, bức tranh còn nhiều lớp hơn vì có nhiều mô hình công ty cùng tồn tại: công ty làm dự án outsourcing cho khách nước ngoài, công ty có sản phẩm riêng, startup, và các doanh nghiệp lớn, trong đó có một số ngân hàng, đã áp dụng Agile ở một số nhóm. Cùng chữ “PO”, mỗi nơi có thể giao cho bạn một phần việc rất khác.
Product Owner, Product Manager và Business Analyst khác nhau ở đâu?
Bảng dưới mô tả phần lõi của từng vai trò khi được chia rõ. Ngoài thực tế, một người có thể ôm hai hoặc cả ba cột, nhưng hiểu phần lõi giúp bạn biết mình đang thật sự làm vai trò nào.
| Tiêu chí | Product Owner | Product Manager | Business Analyst |
|---|---|---|---|
| Tập trung vào | Giá trị của sản phẩm qua từng sprint, thứ tự công việc của team | Vì sao làm và làm gì: thị trường, chiến lược, hướng đi của sản phẩm | Nhu cầu và yêu cầu: hiện trạng, quy trình, quy tắc nghiệp vụ |
| Đầu ra điển hình | Product Goal, backlog có thứ tự, user story, acceptance criteria | Tầm nhìn, roadmap, phân tích thị trường, mục tiêu kinh doanh | Tài liệu đặc tả, sơ đồ quy trình, use case, user story |
| Làm việc nhiều nhất với | Đội phát triển, designer, stakeholder nội bộ | Lãnh đạo, kinh doanh, marketing, khách hàng | Khách hàng hoặc bộ phận nghiệp vụ, đội phát triển, QA |
| Quyền quyết định chính | Thứ tự backlog, phạm vi của từng lần phát hành | Hướng sản phẩm, thị trường nào, vấn đề nào đáng giải | Thường đề xuất, ít khi là người quyết cuối |
| Được đánh giá bằng | Thứ đã ra mắt có tạo ra giá trị không | Kết quả kinh doanh và sự tăng trưởng của sản phẩm | Yêu cầu có đúng, đủ, rõ để team làm không phải làm lại |
Điểm đáng nhớ nhất nằm ở hàng “Quyền quyết định chính”. BA thường làm rõ và đề xuất. PO quyết thứ tự và chịu trách nhiệm cho giá trị. PM quyết hướng đi ở tầm rộng hơn. Khi đọc một vị trí, hãy hỏi người đó được quyết gì, vì đó là chỗ ba vai trò khác nhau rõ nhất.
Ở từng loại công ty, ranh giới nằm ở đâu?
Đây là những kiểu thường gặp, không phải quy tắc. Hai công ty cùng loại vẫn có thể chia việc khác nhau, nên luôn kiểm tra lại khi phỏng vấn.
- Công ty outsourcing: Khách hàng thường giữ quyền quyết sản phẩm. “PO” phía công ty hay làm việc gần với BA: nhận yêu cầu, viết đặc tả, giữ phạm vi theo hợp đồng.
- Công ty sản phẩm: Có sản phẩm riêng nên PO hoặc PM thật sự quyết ưu tiên. Ở quy mô lớn, PM lo chiến lược, PO lo backlog, BA hỗ trợ phần yêu cầu.
- Startup nhỏ: Thường một người làm cả ba: nói chuyện với khách, chọn việc, viết story, xem số liệu. Chức danh có thể là bất kỳ tên nào.
- Doanh nghiệp lớn, ngân hàng: BA thường là vai trò lâu đời. PO xuất hiện khi chuyển sang Agile, có khi là BA được đổi tên mà quyền quyết vẫn ở cấp trên.
Với người chuyển nghề, không có kiểu nào tốt hơn hẳn. Outsourcing giúp bạn luyện kỹ năng làm rõ yêu cầu và giao tiếp với khách. Công ty sản phẩm giúp bạn học cách ra quyết định và đo kết quả. Startup cho bạn làm mọi thứ, đổi lại ít người hướng dẫn. Điều quan trọng là bạn biết mình đang học được gì ở đó.
Làm sao đọc tin tuyển dụng để biết vai trò thật?
Một cách làm đơn giản là đọc tin tuyển dụng (JD, job description) qua bốn bước, và tạm quên chức danh cho tới cuối.
- Che chức danh: Đọc phần trách nhiệm như thể không biết tên vị trí
- Gạch động từ: Viết, phân tích, quyết định, xây dựng chiến lược
- Tìm người quyết: Ai chốt ưu tiên, ai chốt phạm vi
- Tìm thước đo: Thành công được đo bằng gì
Không tìm ra người quyết hoặc thước đo trong tin? Ghi thành câu hỏi để hỏi khi phỏng vấn.
Ở bước gạch động từ, hãy để ý nhóm từ xuất hiện nhiều nhất. Nhiều động từ như “thu thập yêu cầu”, “viết tài liệu đặc tả”, “vẽ quy trình”, “làm việc với khách hàng để xác nhận yêu cầu” là dấu hiệu của công việc BA. Nhiều cụm như “quản lý và sắp xếp backlog”, “viết user story và acceptance criteria”, “làm việc hằng ngày với team phát triển”, “tham gia sprint planning” là dấu hiệu của PO. Còn “xây dựng roadmap”, “nghiên cứu thị trường”, “định giá”, “chịu trách nhiệm chỉ số kinh doanh” thường thuộc về PM.
Bước tìm người quyết quan trọng nhất. Nếu tin ghi “phối hợp với khách hàng để chốt yêu cầu” thì người quyết là khách. Nếu ghi “báo cáo cho Head of Product, người đặt ưu tiên” thì quyền quyết có thể nằm ở cấp trên. Scrum Guide nói để PO thành công, cả tổ chức phải tôn trọng quyết định của PO. Nếu tin không cho thấy bạn được quyết gì, vị trí đó có thể gần BA hơn tên gọi của nó.
Ví dụ: phân tích ba tin tuyển dụng đầu bài
Quay lại ba tin bạn lưu tối nay. Bảng dưới là phân tích minh họa, các tin đều là tin giả định.
| Tin tuyển dụng | Dấu hiệu trong mô tả | Người quyết ưu tiên | Vai trò thật gần với |
|---|---|---|---|
| Product Owner, công ty outsourcing | Viết đặc tả, họp khách mỗi tuần, quản lý thay đổi yêu cầu theo hợp đồng | Khách hàng | BA, có thêm phần quản lý phạm vi |
| Business Analyst, công ty sản phẩm | Quản lý backlog, chọn tính năng cho sprint, theo dõi phản hồi sau khi ra mắt | Chính vị trí này, cùng trưởng nhóm | PO |
| Product Manager, startup năm người | Nói chuyện với khách, viết user story, theo dõi số liệu, đề xuất hướng đi | Vị trí này cùng founder | Cả PM, PO và BA |
Sau khi phân tích, thứ tự ưu tiên của bạn có thể đảo ngược. Nếu mục tiêu là học cách quyết ưu tiên, tin “Business Analyst” ở công ty sản phẩm có khi lại sát với việc của PO hơn tin mang đúng chữ “Product Owner”. Nếu bạn muốn luyện kỹ năng làm rõ yêu cầu trước, tin outsourcing lại là bước đệm hợp lý.
Cũng đừng vội đánh giá thấp tin nào. Một vị trí PO ở công ty outsourcing vẫn có thể cho bạn nhiều quyền nếu khách hàng tin tưởng team. Bảng chỉ cho bạn câu hỏi cần hỏi, không thay cho câu trả lời của nhà tuyển dụng.
Nên chọn PO, PM hay BA?
Không có vai trò nào cao hơn vai trò nào. Câu hỏi đúng là bạn muốn chịu trách nhiệm cho điều gì. Đi qua các câu hỏi dưới đây theo thứ tự, dừng ở câu đầu tiên bạn trả lời “không”.
Bạn muốn làm việc gần sản phẩm và đội phát triển
- Bạn có thích làm rõ một yêu cầu mơ hồ thành mô tả chính xác không? Có thể bạn hợp với QA, design hoặc vận hành hơn. Thử một dự án nhỏ trước khi quyết.
- Bạn có chịu được việc chọn thứ tự và nói không với người khác không? BA là điểm bắt đầu hợp lý: bạn làm rõ và đề xuất, người khác quyết.
- Bạn có muốn chịu trách nhiệm cho kết quả sau khi ra mắt không? BA trong team Agile, hoặc vị trí hỗ trợ một PO, là bước hợp lý: bạn tập quyết ở phạm vi nhỏ và tập nhìn số liệu dần.
- Bạn có muốn nghĩ về thị trường, chiến lược và kết quả kinh doanh không? PO là vai trò hợp nhất lúc này: quyết ưu tiên cùng team, đo giá trị qua từng lần phát hành.
PM là hướng đáng thử, thường sau khi đã có kinh nghiệm làm PO hoặc làm sản phẩm ở startup.
Nếu bạn đến từ thiết kế, phần lớn kỹ năng làm rõ vấn đề đã có sẵn. Bài Từ designer sang Product Owner nói rõ hơn những gì cần học thêm. Nếu bạn đến từ BA, phần cần tập nhiều nhất thường là ưu tiên khi việc nào cũng gấp và nói không mà không mất lòng.
Checklist phân tích tin tuyển dụng
Copy checklist này vào ghi chú, mỗi tin tuyển dụng điền một bản. Phần cuối là câu hỏi để hỏi khi phỏng vấn, cho những ô bạn chưa điền được.
Tin: [tên công ty hoặc mã tin] | Chức danh ghi trên tin: [ ] 1. Loại công ty [ ] Outsourcing [ ] Công ty sản phẩm [ ] Startup [ ] Doanh nghiệp lớn [ ] Chưa rõ 2. Động từ xuất hiện nhiều nhất (chép 5 cụm) - - - Nghiêng về: [ ] BA (làm rõ, đặc tả) [ ] PO (backlog, sprint, team) [ ] PM (chiến lược, thị trường, chỉ số) 3. Ai quyết [ ] Ai chốt thứ tự ưu tiên: [ ] Ai chốt phạm vi mỗi lần phát hành: [ ] Vị trí này báo cáo cho ai: 4. Thước đo thành công [ ] Tin có nêu thành công được đo bằng gì không: [ ] Thước đo là việc hoàn thành, hay kết quả sau khi ra mắt: 5. Làm việc với ai mỗi ngày [ ] Khách hàng [ ] Đội phát triển [ ] Lãnh đạo [ ] Kinh doanh, marketing [ ] Vận hành Kết luận: vai trò thật gần với [ ], khác chức danh ở điểm [ ]. Câu hỏi khi phỏng vấn (cho các ô còn trống): - Khi hai yêu cầu cùng gấp, ai là người quyết làm cái nào trước? - Kể giúp em một quyết định gần đây mà người ở vị trí này đã đưa ra. - Sau khi một tính năng ra mắt, team biết nó thành công bằng cách nào? - Một tuần của vị trí này thường dành thời gian cho những việc gì?
Câu “kể một quyết định gần đây” thường cho bạn nhiều thông tin nhất. Nếu người phỏng vấn kể được một lần vị trí đó chọn bỏ một tính năng hay đổi thứ tự backlog, bạn biết quyền quyết là thật. Nếu câu trả lời chỉ xoay quanh tài liệu và họp, vị trí đó có thể nghiêng về BA.
Những nhầm lẫn thường gặp
- Chọn việc theo chức danh. Chữ “Product Owner” trên tin không bảo đảm bạn được quyết ưu tiên. Hãy đọc phần trách nhiệm và hỏi ai là người quyết.
- Nghĩ PM là “cấp trên” của PO, hay PO là “cấp trên” của BA. Ở nhiều nơi đó là ba trách nhiệm khác nhau, không phải ba nấc thang. Có công ty PM quản lý PO, có công ty thì không.
- Nghĩ BA chỉ viết tài liệu. BA giỏi phải hiểu vì sao một yêu cầu tồn tại và đề xuất giải pháp mang lại giá trị. Đó cũng là nền rất tốt để chuyển sang PO.
- Học chứng chỉ trước khi hiểu việc. Chứng chỉ có thể giúp bạn hiểu khung làm việc, nhưng nhà tuyển dụng thường hỏi bạn đã làm rõ vấn đề và ra quyết định thế nào. Một case study nhỏ có lập luận giúp bạn trả lời câu đó.
- Bỏ qua kỹ năng viết. Dù là vai trò nào, bạn vẫn cần viết user story và acceptance criteria đủ rõ để team làm được.
Tóm tắt
- Product Owner là một trách nhiệm trong Scrum: tối đa hóa giá trị sản phẩm, quyết thứ tự backlog. PM và BA là chức danh công việc.
- Phần lõi khác nhau ở quyền quyết: BA làm rõ và đề xuất, PO quyết thứ tự và chịu trách nhiệm cho giá trị, PM quyết hướng đi rộng hơn.
- Ranh giới thay đổi theo loại công ty: outsourcing, công ty sản phẩm, startup và doanh nghiệp lớn chia việc rất khác nhau.
- Đọc tin tuyển dụng bằng bốn bước: che chức danh, gạch động từ, tìm người quyết, tìm thước đo. Ô nào trống thì hỏi khi phỏng vấn.
- Chọn vai trò theo điều bạn muốn chịu trách nhiệm, không theo tên gọi.
Mình đang soạn thêm các tình huống PO khác theo cùng khung này, kèm mẫu dùng ngay. Nếu bạn muốn nhận khi có bài mới, đăng ký bản tin bên dưới.
Câu hỏi thường gặp
Product Owner có phải là chức danh không?
Trong Scrum Guide, Product Owner là một trách nhiệm, không phải chức danh: người chịu trách nhiệm tối đa hóa giá trị sản phẩm và quản lý backlog. Ngoài thực tế, nhiều công ty dùng luôn nó làm chức danh, nên cùng tên gọi có thể là những công việc khác nhau.
BA có chuyển sang PO được không?
Được, và đây là hướng nhiều người đi vì BA đã quen làm rõ yêu cầu, viết user story và làm việc với đội phát triển. Phần phải học thêm là quyết định ưu tiên, nói không và chịu trách nhiệm cho kết quả sau khi ra mắt.
Người mới nên chọn PO, PM hay BA?
Hãy chọn theo việc bạn muốn chịu trách nhiệm, không theo tên gọi. Thích làm rõ và mô tả chính xác thì hợp BA, thích quyết thứ tự và đi cùng team phát triển thì hợp PO, thích nghĩ về thị trường, chiến lược và kết quả kinh doanh thì hợp PM.
Nguồn kiểm tra
Bài liên quan
- 30 ngày đầu làm Product Owner: mỗi tuần nên làm gì?: Kế hoạch bốn tuần cho PO mới: nghe và vẽ bản đồ, hiểu người dùng và số liệu, nhận một phần backlog nhỏ, rồi ra quyết định đầu tiên và chốt kỳ vọng với quản lý.
- Không biết code có làm Product Owner được không?: PO không cần viết code, nhưng cần đủ hiểu biết kỹ thuật để hỏi đúng câu, tôn trọng quyền quyết “làm thế nào” của Developers và bàn đánh đổi một cách rõ ràng.
- Chuyển từ BA, QA, dev sang Product Owner: cần học thêm gì?: Thế mạnh nào của BA, QA và dev mang sang PO được, điểm mù nào cần để ý, và cách tích kinh nghiệm PO ngay trong công việc hiện tại.
- Câu hỏi phỏng vấn Product Owner: trả lời bằng tình huống: Các nhóm câu hỏi khi phỏng vấn vị trí PO, cách trả lời bằng một tình huống cụ thể, cách xử lý câu không biết và những câu nên hỏi lại nhà tuyển dụng.