Lưu ý rằng đây cũng là trải nghiệm của cá nhân vị trí của mình tại OMD, sẽ có sự khác biệt nhất định với các bạn Product Owner khác trong OMD, trong tập đoàn hoặc thậm chí trong ngành nữa. Hy vọng sau bài viết này các bạn trẻ sẽ có cái nhìn cận cảnh hơn về ngành và có thêm thông tin để ra quyết định nghề nghiệp cho bản thân.

1.Daily meeting

Áp dụng kĩ lưỡng Agile Framework vào quy trình xây dựng sản phẩm, scrum team của mình luôn luôn gặp nhau trong 15 phút đầu tiên của ngày. Buổi họp nhằm mục đích cập nhật những gì team đã làm trong ngày hôm trước và lên kế hoạch cho ngày hôm đó, vì vậy mọi người sẽ điểm qua rất nhanh tình hình công việc. (Thậm chí một số scrum team khác còn có tips họp đứng thay vì ngồi, để đảm bảo mọi người chỉ nói những nội dung thật sự cần thiết, tránh kéo dài buổi họp quá lâu) Và bất cứ vấn đề nào được đưa ra cũng chỉ được điểm qua chứ không đi sâu bàn bạc, để các member liên quan cùng lên kế hoạch giải quyết trong ngày hôm đó.

2.Check mail

Cá nhân mình thường tập trung check mail vào 2 khoảng thời gian trong ngày: Sau buổi daily của team và cuối ngày làm việc. Ngoài những email cập nhật về tình hình chung và chính sách mới của công ty, phần lớn các email bay đến thường là một trong hai loại:

- Các box mail triển khai tính năng/dự án mới của công ty, ở đó PO sẽ có vai trò dẫn dắt xuyên suốt từ lúc một dự án mới đang hình thành cho đến lúc sản phẩm thực sự được đưa ra triển khai với đội vận hành của công ty/người dùng

- Các mail ad-hoc về các vấn đề cần giải quyết từ các đội vận hành/nghiệp vụ, PO sẽ là người lắng nghe và đưa ra các giải pháp, từ ngắn hạn đến dài hạn, cũng như sát cánh với các đội khác trong việc triển khai giải pháp đó và quan sát kết quả cuối cùng.

Tuy nhiên với tinh thần Agile, tụi mình thường cố gắng trao đổi trực tiếp với nhau trước rồi mới chốt với nhau qua email, để đảm bảo các bên thực sự thông suốt và đồng thuận.

3.Họp tiếp

Nói vậy cho vui chứ không hẳn ngày nào mình cũng phải họp thêm, tỉ lệ chỉ khoảng 95% thôi ^^. Các cuộc họp trong ngày thường chia làm hai loại:

- Họp định kỳ theo chuẩn Scrum: Ngoài daily meeting thì còn có những buổi backlog refinement , grooming, demo, retrospective hầu hết thực hiện trong phạm vi Scrum team

- Các buổi họp ad-hoc: Gọi là ad-hoc nhưng cũng có thể liệt kê ra một cách tuần tự và logic như sau:

• Họp với stakeholder để lắng nghe vấn đề và cùng tìm ra giải pháp (có thể là một chuỗi các buổi họp liên tục)
• Họp với technical leader/solution architecture để tìm ra giải pháp kỹ thuật cho yêu cầu tính năng mới
• Họp với product owner khác để phối hợp xây dựng tính năng
• Họp với stakeholder về kế hoạch triển khai tính năng với người dùng nội bộ

Ngoài ra với những dự án lớn cần sự phối hợp của nhiều bên, còn có những buổi họp kick-off dự án, hoặc sync-up định kỳ giữa các scrum team khác về tình hình dự án…

Viết đến đây mình tự hỏi không biết có bạn nào thấy họp nhiều quá mà sợ không muốn làm PO nữa luôn không ^^, nhưng thực tế thì là như vậy. Vừa là thử thách nhưng cũng vừa là cơ hội, đòi hỏi PO phải xây dựng cho mình một số kĩ năng để họp hành sao cho hiệu quả, hoặc thậm chí đứng ra định hướng cho các buổi họp chung giữa các phòng ban, mà có lẽ mình nên viết chi tiết hơn ở một bài viết khác…

4.Viết tài liệu về sản phẩm

Giữa vòng xoáy họp hành và giao tiếp liên tục với mọi người từ scrum team/các đội nghiệp vụ, vận hành, có thể nói đây là giây phút mà một Product Owner cần ngồi xuống tĩnh tâm để cho ra những sản phẩm vừa logic và vừa tỉ mỉ nhất. Mặc dù tinh thần Agile coi trọng con người hơn tài liệu, coi trọng việc trao đổi trực tiếp với nhau hơn là thông qua văn bản, nhưng khả năng viết tài liệu, mô hình hóa, trực quan hóa những thứ trừu tượng thành cụ thể, khả năng tổ chức tài liệu của PO vẫn đóng vai trò then chốt đối với thành công của sản phẩm. Đây cũng là lúc PO vận dụng tập hợp các kĩ năng để cho ra đời:

• Những flowchart để tổng quát hóa journey trải nghiệm của người dùng, quy trình phối hợp phòng ban, quy trình làm việc trong và ngoài hệ thống…

• Những wireframe/mockup hình dung cụ thể từng bước trải nghiệm người dùng
• Những văn bản mô tả tính năng một cách tuần tự, logic nhưng cũng phải đủ trọng tâm và dễ hiểu…

Vì để tiện dụng cho làm việc nhóm, mình thường sử dụng các công cụ online, dễ dàng chia sẻ và cho phép team member cùng tham gia xây dựng tài liệu như DrawIO, Google Sheet, Confluence,...

5.Giải đáp thắc mắc, hỗ trợ người dùng/stakeholder

Bản thân OMD nói riêng và One Mount Group nói chung có thể được coi là Product company, là nơi có đội sản phẩm in-house tự xây dựng sản phẩm cho người dùng bên ngoài lẫn nội bộ, vì thế nên PO cũng đóng vai trò chính trong việc triển khai và hỗ trợ người dùng.

Bên cạnh những công việc hỗ trợ định kỳ đã được quy trình hóa và được chuyển giao cho Internal Service desk, vẫn có kha khá những trường hợp phát sinh từ những tính năng/sản phẩm mới đòi hỏi PO phải sắp xếp thời gian để xử lý.

Kinh nghiệm ở đây là cần tỉnh táo để phân biệt đâu là những vấn đề cần xử lý, trong đó đâu là vấn đề ad-hoc chỉ cần giải pháp tạm thời, đâu là vấn đề cần xử lý có tính hệ thống và triệt để để không lặp lại nhiều lần. Chỉ có vậy PO mới có thể sử dụng thời gian hiệu quả...

Tóm lại, business analyst/product owner đối với mình là một cái duyên, cũng là một thử thách. Việc phải phối hợp nhiều kĩ năng từ logical đến emotional, từ làm việc với logic đến làm việc với con người đã cho mình những trải nghiệm vô cùng ý nghĩa.

Hy vọng sau bài viết này, các bạn trẻ đã có thêm những kiến thức mới, hoặc nguồn cảm hứng mới để đặt chân lên con đường khó khăn nhưng cũng vô cùng hay ho này. Và nếu có duyên, hãy kết nối 1:1 với mình tại đây để mình có thể chia sẻ sâu hơn nhé.