Vai trò Product Owner thường được các thành viên trong team Product xem là chuyên gia và người lãnh đạo chỉ ra đường lối phát triển sản phẩm. Đó là một điều may mắn nhưng cũng là một gánh nặng nếu … bạn chưa sẵn sàng và trưởng thành. Nhưng để đạt được sự trưởng thành thì cọ xát với trải nghiệm đau đớn và thất bại là những thứ tất yếu cá nhân ai cũng phải trải qua.
Sản phẩm là do bạn quyết định và đội ngũ Product Team phục vụ bạn, điều này có thể gây căng thẳng rất lớn cho bạn, đó là trách nhiệm của bạn (người sẽ bị đổ lỗi nếu Product thất bại) cho sự thành công của sản phẩm. Thông thường, tôi đã thấy (bao gồm cả tôi đôi khi khi bắt đầu sự nghiệp) Product Owner không thuyết phục được nhóm làm theo hướng của mình, đơn giản vì anh ấy không biết cách truyền đạt ý tưởng của mình một cách hiệu quả cho những người khác hoặc có thể là anh ấy chưa nắm hết thông tin, điều mà giống như án tử đối với BA/PO/PM.
Tại sao?
Trải qua nhiều đau thương mất mát là nền tảng vững chắc cho sự thành công của PO/PM.
TÔI ĐÃ HỌC ĐƯỢC GÌ TỪ THỜI GIAN Ở VINTECH? LIÊN QUAN NHƯ THẾ NÀO VỚI LẬP LUẬN TRÊN?
Để bắt đầu câu chuyện, tôi đã bắt đầu công việc của mình tại Vintech từ đầu tháng 4 năm 2019 với tư cách là Product Owner cho Cổng đặt phòng (Booking Portal) cho hệ thống khách sạn của Vin.
Thành thật mà nói, đó là một trải nghiệm xấu (cũng có chút tốt) do là vì trong tháng đầu tiên tôi trải qua một đống thông tin quá tải và tôi đã ngất vài lần trong khi làm việc.
6 tháng làm việc tại Vin quả thật là một trải nghiệm tuyệt vời và có lẫn chút đau thương.
Tôi không có lựa chọn nào khác ngoài việc ngừng công việc sau nửa năm, đó là trong cuộc thảo luận đánh giá công việc với CTO và chúng tôi nhận ra rằng việc xử lý một nền tảng lớn và quan trọng như vậy là quá sức đối với tôi, tôi biết thế mạnh của mình , nhược điểm hạn chế của tôi ở thời điểm đó mặc dù tôi đã rất cố gắng nhưng lúc đó, tôi phải bước xuống mới có bước lên, mặc dù lúc đó tôi cảm thấy cả thế giới như đang đóng lại với mình.
Rời bỏ một nhà tuyển dụng có thương hiệu lớn như vậy quả là một điều đáng tiếc, nếu tôi tiếp tục thì có thể tôi sẽ có cơ hội phát triển sự nghiệp hơn nhưng điều đó nằm ngoài tầm với của tôi lúc đó.
Tuy nhiên, 6 tháng ở Vintech tương đương với ít nhất 2 năm làm việc ở những nơi khác, những điều tôi học được là vô số, nhìn lại tôi thấy mình thật gan dạ lẫn chút khờ dại.
Những gì tôi đã đúc kết được sau 6 tháng làm việc tại Vingroup – Vintech với vị trí PO.
- Lập tức khi nhận role, mọi người sẽ xem bạn là chuyên gia của sản phẩm bạn chịu trách nhiệm (own) đồng nghĩa là bạn phải nắm thật rõ sản phẩm và yêu cầu trong thời gian ngắn nhất cùng lúc có thể đưa ra quyết định chính xác điều mà không hề dễ chút nào cho những Junior PO lúc đó. Bản thân mình cũng khá liều lĩnh khi chấp nhận ôm 1 cục tính năng khủng của Vintech lúc đó.
- PO tại Việt Nam (như tôi thấy) thường được yêu cầu sau khi sản phẩm đã ra vài MVP rồi và chỉ xuất hiện khi Tech lead quá tải, có trường hợp sản phẩm go live có user rồi thì PO mới xuất hiện.
- “Họp liên tục ngay sau khi nhận role và ngồi trong cuộc họp tôi chưa hiểu chuyện gì đang xảy ra lúc đó”. Đó chính là điều mà tôi trải qua trong 2 tuần đầu tại Vintech, lúc đó tôi như bị đè bởi stress và thấy cực áp lực từ mọi người, về sau, sau khi qua vài startup và dự án khác nhau thì tôi thấy điều này bình thường vì đã tập được cho não mình nhạy bén và logic hơn. Nếu là một PO hoặc bất kì role nào mới trong team Product thì bạn sẽ phải trải qua cảm giác trên, nhưng rồi sẽ nhanh quen với nó thôi.
- Phải có kiến thức căn bản về technical, cách 1 phần mềm hoạt động như thế nào, hiểu về cách vận hành của những dòng code để có thể biết được những vấn đề mà team tech gặp phải khi dự tính estimate cho 1 tính năng để không phải hứa hẹn với stakeholder quá khả năng mà team có thể mang lại. Ngay sau khi nghỉ Vin thì tôi lập tức đi học 1 khoá lập trình Java để lấp đầy những lỗ hổng này, sau này tôi cảm thấy điều này thật sự giúp ích rất nhiều trong sự nghiệp.
- Product Roadmap là một thực thể sống, vì nó phải thay đổi liên tục để adapt với thị trường và đường lối của stakeholder chính. Có bao giờ bạn dự định tháng này sau khi lĩnh lương mình sẽ chi gì và tiết kiệm được bao nhiêu cho đến kì lĩnh lương sau chưa? nhưng cuối cùng thì tháng đó bị vượt chỉ tiêu chi xài (Vd: Đám cưới bạn, xe hỏng, v.v..), dự định là dự định. Tuy nhiên, product roadmap mà bể hoài thì công ty đó cũng bể luôn :D.
- PO phải là người dám chốt và dám đứng ra bảo vệ chính kiến của mình. Thường thì tham gia họp hành với comment tickets các kiểu xong thì không ai sẽ đứng ra chốt là team sẽ làm gì tiếp theo ngoài PO, bạn phải luôn nhạy bén suy nghĩ và cho ra quyết định để tránh tốn thời gian của mọi người, có 1 lưu ý hay là bạn có thể đặt câu hỏi mớm mọi người thì đôi khi quyết định sẽ tự được chốt bởi các thành viên của team.
- Nhưng cũng phải mềm dẻo chấp nhận cái đúng hơn và hỗ trợ anh em hết mình để đạt mục tiêu đề ra. Giống câu trên, bạn phải luôn open và biết cân đong đo đếm (liệu cơm gắp mắm) sao cho hợp lý nhất trong từng trường hợp.
- PO đại diện team đối ngoại – Một Product mà có nhiều Scrum team thì PO chính là mắt xích để giao tiếp giữa các team, mọi confirmation mọi quyết định đều là giữa các PO chốt với nhau và tốt nhất thì bạn nên gửi email để confirm hơn là nói miệng.
- PO chịu trách nhiệm đối nội trong team – Điều này là đương nhiên, mặc dù trong Scrum Guide thì bạn không phải là manager của team hay gì nhưng ở Việt Nam thì mình thấy đa phần team member sẽ xem bạn như manager nên bất kì tranh chấp thay unclear requirements (product or non product) xảy ra thì bạn luôn có tiếng nói nhé.
- PO thường sẽ ôm luôn role của Scrum Master hoặc QA Process – Product Owner là người phải đội nhiều mũ (wear many hats), ở đây có nghĩa là phải nắm nhiều vị trí trong team. Nếu team theo mô hình hoạt động là Scrum Agile thì Product Owner thường sẽ phải là người cho ra quy trình và support các team member để theo đúng quy trình đó, QA Process role cũng là người đảm bảo team theo process.
- PO thường sẽ cho ra process – giống câu trên, một lưu ý nữa là bạn có quyền sửa lại process (tất nhiên là phải discuss với team) sao cho hợp lý với tính chất của team, sản phẩm và Sprint demo date (nếu có).
- Ai cũng sẽ kiếm Product Owner để giải quyết vấn đề – Từ functional đến non-functional requirements, PO thường sẽ được tiếp
- Các cuộc họp không có meeting note thường sẽ bị lạm dụng về sau – Bạn sẽ thường nghe câu này: “Ủa, tui có nói cái này hả, có hứa hả, hồi nào, vân vân …”. Để bảo vệ team, sản phẩm và mình thì nên có ít nhất 1 cái meeting note theo kiểu bullet point vài ba dòng cũng được gửi lên group chat cho có cái lưu lại làm bằng chứng nếu tranh chấp xảy ra sau này, đẹp thì viết email gửi luôn và nhớ keyword để search cho nhanh lại nhé, kẻo trôi chat kiếm cũng mệt ak.
- Nhiều cuộc họp sẽ không có outcome – Nếu không có agenda trước cuộc họp thì khả năng kết quả của cuộc họp sẽ không như mong đợi và lãng phí thời gian của các thành viên khác. VD: trong một lần họp nọ thì bỗng nhiên 2 ông Dev bàn luận với nhau luyên thuyên về technical (kiến thức lập trình kỹ thuật và để các team member không liên quan khác như PO và QA ngồi nghe… thời gian là thứ quan trọng và nếu được thì nên dành thời gian đó để các thành viên khác làm công việc của họ thì có vẻ là hiệu quả hơn. Để giải quyết những incident khỏi xảy ra thì bạn hãy nhắc những thành viên khác là họ có thể rời cuộc họp nếu possible hoặc có thể kết thúc cuộc họp và mở cuộc họp mới cho những ai muốn bàn luận tiếp.
- Scrum Agile sẽ luôn chỉ được apply 1 phần – Rất khó để áp dụng 100% như sách (Scrum guide), team nào apply được hết thì chỉ có mấy cty outsource cho Nhật hoặc có thể có mà mình không biết, thật sự thì đó giờ đi làm BA-PO-PM 3 năm rồi chưa thấy đâu apply được cả.
- Mỗi team chạy 1 process riêng thường sẽ là 1 mớ bòng bong – Thường thì bạn sẽ nghe là :” Làm sao làm miễn sao cho ra Product theo đúng roadmap, release và UAT cho users sử dụng là ok, process chỉ là một cách để làm thôi.”. Điều này thật sự đúng nha mấy bạn, nhưng là đầu mối giữa các team các bạn sẽ khó khăn để mà align (cân chỉnh) các milestone hay đầu mục công việc của team mình với các team khác.
- Lấy được sự tín nhiệm của team là bước đầu của sự thành công – Đối với các team mà đa phần scrum team members toàn là junior hoặc nhỏ tuổi hơn bạn thì cũng sẽ dễ để bạn nói chuyện nhưng nếu họ lớn hoặc ngang tuổi hoặc nếu họ kinh nghiệm nhiều hơn bạn thì để lấy được tự tín nhiệm và hiểu được mục tiêu của nhau thì đó là một thử thách, nhưng đừng lo lắng quá như mình nói vấp ngã là nền tảng cho những thành công sau này của bạn vì làm Tech là không sợ bị fail và always open to new changes.
- Lấy được sự tín nhiệm của các team khác là một thử thách – Bạn được xem như là đại diện cho team khác ngoài team của họ nên phải nắm vững team mình đang làm gì và có thể làm gì cũng như tuỳ thuộc kỹ năng giao tiếp của bạn để mọi thứ có thể trơn tru.
- Lấy được sự tín nhiệm của Senior Dev là một level up – Senior Dev thì chắc hẳn cuộc đời họ cũng đã từng làm việc với vài PO hay PM giỏi rồi nên chắc chắn sẽ có sự so sánh đối với bạn, luôn nhớ hỏi ý kiến của họ trong các cuộc họp để cho biết rằng bạn luôn lắng nghe, khi có thông tin mới thì nên chia sẽ toàn team và lắng nghe.
- Product Owner mới sẽ thường bị nhìn nhận vấn đề cần giải quyết phức tạp hoá – Đây là điều bất kì BA hay PO nào cũng phải trải qua khi bắt đầu, hãy luôn suy nghĩ đơn giản hoá giải pháp để cho ra impact nhiều nhất có thể cho tính năng.
- Bạn có quyền quit trong 2 tháng thử việc – Nếu bạn thấy công việc không hợp với mình hoặc thấ mức lương bạn nhận được không xứng đáng với công sức bạn bỏ ra cho công việc thì bạn có quyền quit trong 2 tháng này. Có một lần, một PO của một team khác vào cùng đợt với tôi đã quit sau 2 tuần làm việc tại Vintech bởi vì anh ấy thấy không phù hợp, thật sự lúc đó tôi cũng khá thắc mắc do trước đây tôi chưa bao giờ nghĩ rằng mình có thể quit khi không phù hợp, tại sao tôi từng có suy nghĩ rằng nếu mình không làm được công việc đều là do mình dở cả? suy nghĩ này hơi sai, hãy luôn nhìn mọi thứ một cách phản biện và tin vào bản thân.
- Bạn có quyền chọn sản phẩm và team để làm – Nếu công ty có nhiều sản phẩm và bạn chưa biết phải làm sản phẩm nào thì cứ nói cấp trên phân xuống nhưng nhớ deal rằng nếu sản phẩm hoặc team không phù hợp với bạn (có thể là kinh nghiệm trước đây, kĩ năng, domain khó, v.v…) thì sau 2 tuần hay 3 tuần (bao lâu tuỳ bạn deal) bạn có thể confirm theo tiếp hay qua team khác, bạn là chủ cuộc đời bạn khi bạn làm Product. Điều này đúng với ngay cả khi bạn làm BA ở công ty Outsource, trừ phi bạn thiếu kinh nghiệm và cần làm dự – án – gì cũng được để học hỏi thì bạn có quyền chọn team và dự án để theo nhé.
- Thường sẽ không có đầy đủ documents cho bạn đọc ngay từ đầu. Đây là tình huống thường xuyên, vì là làm Product nên thật sự mọi thứ phải được release nhanh nhất có thể và bug fix cũng như phải làm các enhancement xảy ra liên tục nên việc team cho dù có BA hoặc PO thì thườngh sẽ hiếm khi nào có tài liểu đủ chi bạn để đọc và nắm. Trong trường hợp này hãy đi kiếm những tài liệu sống trong team (team member) mà hỏi và moi móc thông tin nhé.
- Phải tự thân mày mò tìm hiểu về sản phẩm của mình. Cũng giống câu trên, 2 loại tài liệu mà bạn có thể tin tưởng là đi kiếm team member hỏi và cách thứ 2 là vào vai tester vài tuần để hiểu hết các flow.
- Tưởng tượng mình là user ngu ngok khi test các flow nhé, rành rành tý rồi thì tưởng tượng mình là hacker để kiếm bug nhé ?, Cương có lần kiếm được nhiều major bugs (funtional và UX bugs) bằng cách này đó.
- Giao tiếp càng nhiều người càng tốt. Là PO hay PM hay BA thì thông tin là oxy để thở của bạn, mù thông tin là một tấm vé để tiễn bạn lên đường, hãy cố gắng giao tiếp càng nhiều người càng tốt và tất nhiên bạn phải dựa vào mức độ ưu tiên của cái bạn làm để xác định nên nói chuyện với ai nhiều nhất, trong những lần giao tiếp vô tình bạn sẽ nắm bắt được rất nhiều thông tin chính thức hoặc không chính thức liên quan đến sản phẩm bạn làm.
- Hỏi hỏi hỏi ngay từ đầu… không thì bạn sẽ đi lạc và mất ý chí. Bất kì bạn làm ở vị trí nào trong team Product, khi không hiểu yêu cầu, hãy hỏi ngay lập tức, thường thì các bạn mới sẽ ngại không hỏi và sẽ không biết phải hỏi gì. Cương có một tip cho các bạn là hãy vận dụng 5W (Who, What, Where, When, Why), 1H (How) và hỏi Why ít nhất 2-3 lần cho bất kì thắc mắc nào của bạn.
- Chấp nhận thua cuộc và rút kinh nghiệm và đứng dậy. They says:” Products fail all the time” và điều này thật sự đúng trong suốt sự nghiệp làm product của bạn, đừng ngại vấp ngã và thay vì ngồi đó buồn và trách bản thân thì tìm hiểu xem chuyện gì đã xảy ra dẫn đến sản phẩm fail và cách làm nào khác có thể làm để tránh việc này lần tới. Sau này, lương bạn được tăng là bởi vì bạn đã trải nghiệm fail nhiều hơn người khác.
- It’s OK to be not OK – Nghe giống tên phim Hàn xẻng nhưng làm Product là vậy á, không bao giờ có việc sản phẩm, team, process ổn 100% cả, thế nào cũng có issue xảy ra và bạn nên học cách chill và bình tâm khi ngồi trên đống lửa và xử lý từ từ theo đúng priority level của từ issue. Có lúc vấn đề sẽ tự mất hoặc nó sẽ ra to nhưng đừng panic, bạn cứ làm tốt nhất có thể trong mọi trường hợp thôi nên nhớ bạn là người, nếu overload thì nói cấp trên để tìm cách support, đừng cứ ôm rồi mọi thứ sẽ fail như domino đó.
Tham khảo thêm:
