Chuyển từ BA, QA, dev sang Product Owner: cần học thêm gì?

Đang làm BA, QA hoặc dev, muốn chuyển sang Product Owner?

Đây là tình huống minh họa. Linh làm QA cho một ứng dụng đặt lịch spa. Minh là BA ở một công ty phần mềm. Tú là dev backend. Cả ba cùng muốn chuyển sang làm Product Owner (PO), và cả ba cùng bị hỏi một câu khi xin chuyển vị trí: “Kể cho anh nghe một quyết định sản phẩm em đã chịu trách nhiệm.”

Cả ba đều có nhiều chuyện để kể. Linh đã chặn được những lỗi nghiêm trọng trước khi ra mắt. Minh đã viết hàng trăm user story (mô tả ngắn một nhu cầu theo góc nhìn người dùng) mà dev đọc là hiểu. Tú đã thiết kế lại một phần hệ thống chạy nhanh hơn hẳn. Nhưng khi nghĩ kỹ, cả ba nhận ra câu chuyện của mình là về việc làm đúng yêu cầu, không phải về việc chọn yêu cầu nào đáng làm.

Một số tin tuyển dụng PO cấp mới yêu cầu 0 đến 2 năm làm BA hoặc vị trí tương đương. Nếu bạn đang làm BA, QA hay dev, bạn đã ở gần công việc sản phẩm. Nhưng sự gần gũi đó chỉ thành kinh nghiệm PO khi bạn bổ sung đúng phần còn thiếu.

Bài này dành cho người đi từ BA, QA hoặc dev. Nếu bạn đi từ thiết kế, bài “Từ Designer sang Product Owner” viết riêng cho bạn. Ở đây bạn sẽ có: bảng thế mạnh và điểm mù cho từng nền, cách tích kinh nghiệm PO ngay trong công việc hiện tại, và cách kể lại nó trong CV mà không nói quá.

• Từ Designer sang Product Owner

Vì sao đã ở trong team sản phẩm mà chuyển sang PO vẫn khó?

Vì thước đo thay đổi. Ở vị trí cũ, việc của bạn được đánh giá bằng độ đúng: tài liệu đủ và rõ, lỗi được tìm ra, code chạy ổn. Ở vị trí PO, câu hỏi đổi thành: việc team vừa làm có đáng làm không, và nó có tạo ra thay đổi như mong đợi không.

Scrum Guide 2020 viết PO chịu trách nhiệm tối đa hóa giá trị của sản phẩm mà Scrum Team làm ra, và quản lý Product Backlog (danh sách việc có thứ tự của sản phẩm). PO là một người, không phải một hội đồng. PO có thể giao bớt việc quản lý backlog cho người khác, nhưng vẫn là người chịu trách nhiệm. Đây là điểm khác lớn so với BA, QA và dev: bạn không chỉ góp ý cho quyết định, bạn là người trả lời cho nó.

Tóm lại trong một câu, sự chuyển đổi là đi từ “làm đúng yêu cầu” sang “chọn việc đáng làm và chịu trách nhiệm kết quả”. Nghe đơn giản, nhưng nó khó vì mấy lý do:

• Bạn quen có người chọn giúp. Việc tới tay bạn thường đã được ai đó quyết là cần làm. Phần chọn diễn ra trước khi bạn nhìn thấy nó.
• Ở gần PO không có nghĩa là đã làm việc của PO. Ngồi chung buổi họp, đọc chung backlog cho cảm giác mình đã hiểu vai trò, nhưng phần khó nhất là chọn và chịu trách nhiệm thì bạn chưa phải làm.
• Thế mạnh cũ dễ thành điểm mù. Thứ giúp bạn giỏi ở vị trí cũ có thể kéo bạn về đúng việc cũ khi làm PO.
• Công ty có thể chưa cho bạn quyền quyết. Bạn cần tìm cách tập ra quyết định mà không giành quyền của PO hiện tại.

Scrum.org liệt kê một số hiểu lầm về vai trò PO, trong đó có xem PO chỉ là người viết story hay người gác cổng. Theo cách nhìn của bài này, hai hiểu lầm đó lần lượt là cái bẫy gần nhất với BA và QA. Còn với dev, cái bẫy là quyết luôn cách làm thay team. Nếu bạn chưa rõ ranh giới giữa PO, PM và BA ở công ty mình, đọc bài so sánh ba vai trò trước rồi quay lại đây.

• PO, PM và BA khác nhau thế nào

Từ BA sang PO: mang theo gì, cần bổ sung gì?

BA đã quen làm rõ yêu cầu với nhiều bên và viết lại thành thứ team phát triển dùng được. Đây là nền tốt để quản lý backlog. Phần cần bổ sung là dám đề xuất bỏ bớt và dám chọn. Với Minh ở đầu bài, câu chuyện quyết định đầu tiên có thể bắt đầu từ một yêu cầu bị gửi lại nhiều lần.

Acceptance criteria (AC) là các điều kiện để biết một story đã làm đúng. BA đã quen viết AC, nên phần này bạn đi trước người khác. Điều cần đổi là câu hỏi đầu tiên: thay vì “đã ghi đủ chưa”, hãy hỏi “làm cái này thì điều gì thay đổi, và có đáng làm trước không”.

• Nói không với stakeholder mà không mất lòng

Từ QA hoặc tester sang PO: mang theo gì, cần bổ sung gì?

QA nhìn sản phẩm như người dùng và nghĩ tới những chỗ có thể hỏng. Hai thói quen này giúp PO viết AC kiểm thử được và ít bất ngờ sau khi ra mắt. Phần cần bổ sung là chấp nhận rủi ro có chọn lọc và đo kết quả, không chỉ đo lỗi.

Một câu hỏi giúp QA chuyển góc nhìn: “Nếu tính năng này chạy hoàn hảo mà không ai dùng, mình có coi là thành công không?”. Câu trả lời là không, và đó chính là phần việc PO phải trả lời.

• Làm việc với dev khi không biết code

Từ developer sang PO: mang theo gì, cần bổ sung gì?

Dev hiểu hệ thống, dữ liệu và chi phí kỹ thuật. Bạn thấy sớm phương án rẻ hơn và nói chuyện với Developers rất tự nhiên. Ở đây “Developers” là cách Scrum Guide gọi những người trong Scrum Team cùng tạo ra phần sản phẩm dùng được mỗi sprint, không chỉ người viết code. Phần cần bổ sung là lùi lại một bước khỏi cách làm.

Mountain Goat Software tách rõ: PO quyết làm gì và vì sao, Developers quyết làm thế nào và nhận bao nhiêu việc vào sprint. Với người từng là dev, đây là ranh giới khó giữ, vì bạn biết cách làm và có thể thấy cách nhanh hơn. Hãy nói ý kiến kỹ thuật như một gợi ý, rồi để team chọn. Với Tú ở đầu bài, một vấn đề tốt để nhận có thể là một bước vận hành thủ công lặp lại mỗi ngày, vì Tú hiểu nó tốn bao nhiêu thời gian và có thể bỏ được không.

Làm sao có kinh nghiệm PO ngay trong công việc hiện tại?

Bạn không cần chờ được bổ nhiệm. Cách làm bài này đề xuất là nhận trọn một vấn đề nhỏ và theo nó qua bốn bước. Điểm quan trọng: bạn làm việc này cùng PO hoặc quản lý hiện tại, không thay họ. Họ vẫn là người quyết thứ tự backlog. Phần của bạn là đem tới một vấn đề đã được hiểu rõ, có bằng chứng và có cách đo.

Bước 1: nhận một vấn đề nhỏ. Tìm trong chính công việc của bạn. BA có thể thấy một yêu cầu bị gửi lại nhiều lần. QA có thể thấy những báo lỗi thật ra không phải lỗi mà là người dùng không tìm được chức năng. Dev có thể thấy một bước vận hành thủ công lặp lại mỗi ngày. Đừng chọn thứ lớn như “làm lại cả luồng thanh toán”. Chọn thứ đủ nhỏ để phần làm vừa trong khoảng một sprint, hoặc thử được bằng cách thủ công.

Bước 2: nói chuyện với người gặp vấn đề. Gặp hoặc gọi 3 đến 5 người. Hỏi về lần gần nhất nó xảy ra, họ đã làm gì, mất bao lâu. Tránh hỏi “bạn có muốn tính năng X không”, vì câu đó dễ nhận được câu trả lời lịch sự hơn là sự thật.

Bước 3: viết tài liệu một trang. Ghi vấn đề trong một câu, bằng chứng bạn có, hai hoặc ba phương án kèm chi phí của từng cái, phương án bạn đề xuất và cách đo. Đem tài liệu cho PO, một người làm phát triển và một người kiểm thử đọc. Câu hỏi họ đặt ra là phần học quý nhất.

Bước 4: đo và kể lại. Ghi số đo trước khi thay đổi, rồi đo lại sau một khoảng thời gian cố định. Ghi cả những điều có thể làm số thay đổi ngoài việc bạn làm. Cuối cùng, viết lại toàn bộ thành một câu chuyện ngắn theo mẫu ở phần dưới.

• Tài liệu yêu cầu một trang
• Phỏng vấn người dùng nên hỏi gì
• Đo lường tính năng sau khi ra mắt

Ví dụ: một QA theo trọn một vấn đề nhỏ

Quay lại Linh, QA của ứng dụng đặt lịch spa “Hẹn Xinh”. Đây là ví dụ minh họa, tên và mọi con số đều là giả định để bạn thấy cách làm.

Bước 1. Linh để ý nhiều báo lỗi từ bộ phận hỗ trợ có cùng nội dung: nhân viên salon “không đổi được giờ hẹn”. Kiểm tra lại, chức năng vẫn chạy đúng. Nút “Đổi giờ” nằm trong menu ba chấm, nhiều người không thấy. Linh đếm ticket ba tuần gần nhất: trung bình khoảng 12 ticket mỗi tuần về đổi giờ (số giả định). Linh trao đổi với PO trước khi làm gì thêm.

Bước 2. Linh gọi 4 nhân viên salon. Cả 4 kể cùng một kiểu: khi khách nhắn xin đổi giờ, họ mở chi tiết lịch hẹn và tìm nút ở đó. Không thấy, họ hủy lịch rồi tạo lịch mới, hoặc gọi hỗ trợ.

Bước 3. Tài liệu một trang của Linh có ba phương án. Một: gửi hướng dẫn cho các salon, gần như không tốn công làm, nhưng nhân viên mới vẫn có thể vấp. Hai: đưa nút “Đổi giờ” ra màn hình chi tiết lịch hẹn, dev ước tính 1 đến 2 ngày. Ba: cho kéo thả lịch hẹn trên lịch tuần, tốn nhiều ngày và có rủi ro trùng lịch. Linh đề xuất phương án hai, cộng gửi hướng dẫn trong lúc chờ. PO đồng ý và xếp việc vào sprint kế tiếp, rơi vào tuần 4 và tuần 5 trong kế hoạch của Linh.

Bước 4. Tuần 6, Linh đo lần đầu, rồi đo tiếp cho đủ hai tuần sau khi ra mắt, tức là quá mốc sáu tuần một chút. Hai tuần sau khi ra mắt, ticket về đổi giờ còn trung bình khoảng 4 mỗi tuần (số giả định). Linh kiểm tra thêm số lịch hẹn của hai tuần đó, thấy tương đương ba tuần trước, nên mức giảm khó là do salon vắng khách. Linh vẫn ghi rõ: mới đo hai tuần, chưa biết sau một tháng có giữ được không.

Khi kể lại câu chuyện này trong CV hay buổi phỏng vấn, cách viết quyết định bạn có bảo vệ được nó hay không. Bảng dưới so sánh câu dễ viết với câu bảo vệ được.

Câu bảo vệ được nghe khiêm tốn hơn, nhưng mạnh hơn khi bị hỏi tiếp. Người phỏng vấn có thể muốn biết bạn có nhận ra vấn đề, hỏi ra bằng chứng, cân phương án và đo kết quả hay không. Câu chuyện của Linh có đủ bốn phần đó, kể cả khi Linh không phải người quyết cuối cùng.

Mẫu kế hoạch sáu tuần và mẫu câu chuyện một quyết định

Hai mẫu dưới đây dùng cùng nhau. Mẫu đầu để làm, mẫu sau để kể lại. Bạn copy rồi điền theo việc của mình. Nếu việc chưa được xếp vào sprint, dùng tuần 5 để thử bằng cách thủ công hoặc gửi hướng dẫn, rồi đo như bình thường.

Vấn đề tôi nhận: [một câu: ai gặp gì, khi nào]
Người đồng ý cho tôi theo việc này: [tên PO hoặc quản lý]
Thời gian dành ra mỗi tuần: [số giờ]

Tuần 1: Ghi lại bằng chứng hiện có (ticket, tin nhắn, số liệu). Ghi số đo trước thay đổi: [số đo, khoảng thời gian]. Xin đồng ý của [tên].
Tuần 2: Nói chuyện với 3 đến 5 người gặp vấn đề. Hỏi về lần gần nhất nó xảy ra, họ đã làm gì, mất bao lâu.
Tuần 3: Viết tài liệu một trang: vấn đề, bằng chứng, 2 đến 3 phương án kèm chi phí, phương án đề xuất, cách đo. Gửi PO, một người làm phát triển và một người kiểm thử đọc.
Tuần 4: Sửa tài liệu theo câu hỏi nhận được. Thống nhất phạm vi nhỏ nhất và tiêu chí xong với PO.
Tuần 5: Theo việc qua làm, kiểm thử và ra mắt trong sprint đã xếp (sprint có thể bắt đầu từ tuần 4), hoặc chạy bản thử thủ công. Ghi lại những điều phát sinh.
Tuần 6: Đo lần đầu sau khi ra mắt. So với số đo trước. Ghi điều có thể làm số thay đổi ngoài việc này. Viết bản nháp câu chuyện theo mẫu một quyết định.
Sau tuần 6: Đo tiếp cho tới hết [khoảng thời gian đo đã chọn], rồi cập nhật câu chuyện bằng số cuối cùng.

Điều kiện dừng sớm: [ví dụ: PO quyết không làm, hoặc vấn đề tự hết]. Nếu dừng, vẫn viết lại điều đã học.

Bối cảnh: [sản phẩm, người dùng, vai trò của tôi lúc đó]
Vấn đề: [ai gặp gì, khi nào]
Bằng chứng: [số liệu, số người đã nói chuyện, điều họ kể]
Các phương án đã cân nhắc:
1. [phương án] - chi phí: [công sức, thời gian, rủi ro]
2. [phương án] - chi phí: [...]
3. [phương án] - chi phí: [...]
Quyết định: [phương án được chọn và vì sao]
Phần tôi làm: [việc tôi trực tiếp làm]
Phần người khác làm hoặc quyết: [ai, làm gì]
Kết quả: [số đo trước] -> [số đo sau], trong [khoảng thời gian]
Điều tôi chưa chắc: [yếu tố khác có thể ảnh hưởng, thời gian đo còn ngắn]
Nếu làm lại, tôi sẽ: [một điều làm khác]

Khi dùng mẫu thứ hai để chuẩn bị phỏng vấn, hãy tự hỏi trước hai câu dễ bị hỏi: “Nếu PO không đồng ý thì bạn làm gì?” và “Sao bạn biết kết quả là nhờ thay đổi này?”. Trả lời thật, kể cả khi câu trả lời là “mình chưa chắc, và đây là cách mình sẽ kiểm tra”.

Những lỗi dễ gặp khi chuyển từ BA, QA hoặc dev sang PO

• Chờ được bổ nhiệm mới bắt đầu. Không có câu chuyện quyết định nào thì chức danh mới cũng khó tới. Một vấn đề nhỏ theo trọn vẹn cho bạn một câu chuyện để kể, điều mà học lý thuyết không cho được.
• Giành việc của PO hiện tại. Đi thẳng tới stakeholder hứa hẹn, hay tự sửa thứ tự backlog, dễ làm mất niềm tin. Hãy đem bằng chứng và phương án tới PO, để PO quyết.
• Chọn vấn đề quá lớn. Vấn đề lớn kéo dài nhiều tháng và phụ thuộc nhiều người, bạn khó theo được tới lúc đo kết quả.
• Đo bằng việc đã xong. “Ticket đã đóng” hay “đã ra mắt” là đầu ra, chưa phải kết quả. Hãy đo điều thay đổi với người dùng hoặc với vận hành.
• Nói quá phần của mình. Nhận việc của cả team là của mình, hoặc đưa một con số không kèm thời gian đo, sẽ lộ ra ngay ở câu hỏi thứ hai trong phỏng vấn.
• Bỏ hẳn thế mạnh cũ. Bạn không cần quên cách viết AC, nghĩ tới lỗi hay ước lượng chi phí. Chỉ cần đặt chúng sau câu hỏi “việc này có đáng làm không”.

• 30 ngày đầu làm Product Owner

Tóm tắt

• Chuyển sang PO là đi từ “làm đúng yêu cầu” sang “chọn việc đáng làm và chịu trách nhiệm kết quả”.
• BA mang theo khả năng làm rõ yêu cầu, cần tập đề xuất bỏ bớt và tự chọn một thứ tự ưu tiên. QA mang theo góc nhìn rủi ro, cần tập đo kết quả và chấp nhận rủi ro có chọn lọc. Dev mang theo hiểu biết kỹ thuật, cần tập để team quyết cách làm.
• Tích kinh nghiệm bằng một vấn đề nhỏ: nhận việc có sự đồng ý của PO hoặc quản lý, nói chuyện với người gặp nó, viết tài liệu một trang, đo và kể lại.
• Khi kể trong CV, giữ đúng chức danh, tách phần mình làm với phần người khác quyết, và đưa số liệu kèm thời gian đo cùng điều chưa chắc.
• Khi đã nhận vai trò PO, bài “30 ngày đầu làm Product Owner” giúp bạn đi tiếp tháng đầu tiên.

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.

• Nhận bài mới qua email

Câu hỏi thường gặp

BA, QA hoặc dev chuyển sang Product Owner cần học thêm gì?

Phần cần học thêm giống nhau ở cả ba nền: chọn việc nào đáng làm trước, nói chuyện trực tiếp với người dùng, đo kết quả sau khi ra mắt và chịu trách nhiệm cho lựa chọn đó. Thế mạnh cũ như làm rõ yêu cầu, nghĩ tới rủi ro hay hiểu chi phí kỹ thuật vẫn dùng được, chỉ cần không để nó thay cho việc ra quyết định.

Làm sao có kinh nghiệm Product Owner khi chưa có chức danh PO?

Nhận một vấn đề nhỏ trong công việc hiện tại khi PO hoặc quản lý đồng ý, nói chuyện với người gặp vấn đề, viết tài liệu một trang có phương án kèm chi phí, rồi đo kết quả và kể lại. Với một vấn đề nhỏ, một vòng như vậy có thể vừa trong khoảng sáu tuần, còn việc đo có thể kéo dài thêm sau đó.

Chưa làm PO chính thức thì ghi kinh nghiệm vào CV thế nào?

Ghi đúng chức danh hiện tại, rồi mô tả một việc bạn đã theo từ vấn đề tới kết quả, tách rõ phần bạn làm và phần người khác quyết. Số liệu nên kèm khoảng thời gian đo và điều bạn chưa chắc, để bạn bảo vệ được khi bị hỏi.

Nguồn kiểm tra

• Scrum Guide 2020: Product Owner
• Scrum.org: What is a Product Owner?
• Mountain Goat Software: Product Owner Role and Responsibilities

Bài liên quan

• 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ì.
• 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.
• 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.