Trong một lần phỏng vấn, Py may mắn có dịp được trao đổi thêm với anh Sếp về những tiêu chí anh đang tìm kiếm ở một Product Owner (PO) cho dự án chuẩn bị triển khai. Câu trả lời của anh giúp Py phần nào định hình rõ hơn “phẩm chất” của PO. Dĩ nhiên, ở mỗi dự án hay công ty, phạm vi công việc (SoW – Scope of Work), trách nhiệm, kỹ năng chuyên môn,… đòi hỏi ở PO sẽ có sự khác nhau, dù vậy, chắc chắn giữa các PO cũng sẽ có một vài điểm chung tạo nên chất riêng của những người làm nghề.
Cụ thể hơn một chút, anh Sếp tuyển PO cho dự án công nghệ hoàn toàn mới. Mặc dù domain1 không quá mới, nhưng vì là dự án “build from scratch” – tức là bắt đầu và tạo dựng một sản phẩm từ đầu mà không dựa vào bất kỳ cơ sở nào có sẵn – nên theo Py vị trí PO này khá thách thức. Và đây là chia sẻ của anh Sếp – được viết lại theo ký ức của Py:
Anh có 3 tiêu chí dành cho bạn PO của dự án này:
Đầu tiên là ownership. Rõ ràng trong “PO đã có từ “owner” rồi. Ownership ở đây tức là em phải luôn trong tinh thần nhận trách nhiệm và làm mọi thứ để deliver thành công sản phẩm của em.
Thứ hai, PO phải có kỹ năng manage expectations của stakeholders. Đối với dự án hoàn toàn mới và mang tính platform như thế này, PO phải là người cân bằng được benefit của các teams, đồng thời phải có kỹ năng giao tiếp (communication skills) đủ tốt để get requirements và đề xuất giải pháp vừa đáp ứng yêu cầu vừa đảm bảo tính khả thi và thời gian deliver.
Thứ ba, anh muốn tìm một bạn PO có principle khi làm sản phẩm. Hiện tại thì anh chưa ưu tiên tuyển dụng các bạn có kinh nghiệm quá lâu ở một domain, vì người ta thường copy-paste lại những gì mình đã làm. Thật ra là việc đó cũng không phải là điều gì không tốt, do thời gian tiếp xúc lâu nên ảnh hưởng đến cách tư duy và thói quen thôi. Ví dụ, một người làm Facebook quá lâu thì có thể khi qua công ty mới, họ sẽ có xu hướng build một sản phẩm chat giống giống với Facebook. Còn một bạn PO có principle tức là bạn sẽ có bộ skill set riêng và có thể điều chỉnh để giải nhiều bài toàn khác nhau.
Sau khi cẩn thận suy nghĩ và liên kết với các trải nghiệm tương tự, dưới đây là những những nhiều “phẩm chất” – mà theo Py – nên có ở một PO.
1. Ownership
Dĩ nhiên là chỉ nói đến khía cạnh tinh thần, vì PO không “own” sản phẩm/tính năng – những gì thuộc sở hữu của “công ty”, do đó, chỉ có người chủ công ty mới là “owner” thực sự. Dù vậy, PO là người chịu mọi trách nhiệm liên quan đến sản phẩm, trong nhiều trường hợp, PO cũng là người đưa ra quyết định cuối cùng về sản phẩm. Có thể vì thế nên PO cũng được ví von với hình ảnh “Mini-CEO”2. Nghe thì hay đó nhưng diễn nghĩa đơn giản tức là: sản phẩm thành công thì cả team thành công, nhưng sản phẩm thất bại thì lỗi ở PO. Vậy việc “chọn” tinh thần Ownership có ý nghĩa gì đối với PO?
Với Py, Py học được cách quan sát vấn đề một cách tổng quan hơn, về cả khía cạnh làm sản phẩm và quá trình triển khai. Khi phân tích một user journey3, Py sẽ cố gắng bám theo E2E flow, từ lúc user bắt đầu có nhu cầu (need4) đến khi yêu cầu (demand4) được đáp ứng và sau đó nữa. Khi đề xuất giải pháp, Py cũng sẽ ưu tiên các giải pháp “tốt nhất” – tức là vừa có thể giải quyết được vấn đề, vừa phù hợp với nguồn lực (con người và thời gian) ở thời điểm hiện tại, đồng thời chuẩn bị sẵn một vài hướng “tốt hơn” để tiếp tục cải tiến trong tương lai.
Py cũng học được cách tập trung vào mục tiêu cuối cùng. Điều này đòi hỏi trong giai đoạn phân tích, PO cần tìm hiểu vấn đề đủ sâu, đủ kỹ để đặt ra hoặc xác nhận lại những mục tiêu “đúng” cho dự án/sản phẩm. Mục tiêu còn là cơ sở để PO sắp xếp thứ tự ưu tiên trong backlog. Ví dụ, nếu mục tiêu là các tiết kiệm nguồn lực thì các giải pháp đơn giản, có thể triển khai trong thời gian ngắn sẽ được ưu tiên; mục tiêu là số lượng new users thì những tính năng như onboarding sẽ được thực hiện trước. Mục tiêu cũng giúp PO loại được các requests gây nhiễu, giữ sản phẩm ở trạng thái tinh gọn và tập trung đáp ứng nhu cầu của người dùng. Chẳng hạn, đối với một app đặt vé xem phim thì mục tiêu hàng đầu là giúp user dễ dàng đặt được vé, còn các tính năng hỗ trợ như group chat để chia sẻ vé sau khi đặt có thể được thực hiện thông qua app chat khác, không nhất thiết phải có sẵn trong app đặt vé này (trừ “siêu ứng dụng”).
Mang tinh thần ownership khi làm product, Py học được cách cân bằng giữ nhiều yếu tố để đảm bảo tính bền vững. Điển hình nhất, đối với PO thì việc tiếp nhận và xử lý change requests là chuyện rất thường xuyên. Vì những yêu cầu này thường phát sinh trong quá trình làm (In Dev), nên đa số sẽ đáp ứng được tiêu chí “hướng đến mục tiêu” và có impact (ảnh hưởng), nhưng mà nên thực hiện yêu cầu nào để vừa tận dụng được những gì đã làm, vừa đảm bảo được tính linh hoạt để có thể tiếp tục thay đổi trong tương lai thì không hề đơn giản, buộc PO cần nắm cả chi tiết để thực thi trong ngắn hạn, đồng thời phải hiểu được tổng quan để hạn chế tối đa các giải pháp mang tính hardcode – tức là chỉ xử lý được số ít trường hợp nhất định.
Vậy làm thế nào để có tinh thần ownership khi rõ ràng chỉ có người chủ công ty mới là “owner” thực sự? Đây là cách Py tự trả lời cho bản thân mình: Py là “owner” của cách Py phân tích vấn đề, trình bày giải pháp, trao đổi với đồng nghiệp, xử lý mâu thuẫn… hay gọi chung là cách “làm nghề”, nên đến tận cùng, Py cần có trách nhiệm với loại “sản phẩm” này do bản thân mình tạo ra. Dĩ nhiên, sẽ có nhiều cách lý giải khác, nhưng nhìn chung, Py cho rằng việc bồi dưỡng tinh thần ownership đối với những “người làm thuê chuyên nghiệp” nằm nhiều ở cách tự trao đổi và thỏa thuận với chính mình, hơn là được điểm mặt chỉ đích danh bằng chức vị trong công ty5.
2. Manage expectations
Ý tưởng không có hình dạng cụ thể nên mỗi người sẽ có những hình dung khác nhau, và dĩ nhiên, kỳ vọng cũng sẽ có nhiều điểm chênh lệch. Khoảng hơn 50% dự án Py tham gia thường ở giai đoạn Lập kế hoạch và phân tích yêu cầu (Planning and Requirement Analysis)6 dạy cho Py bài học về việc bình quân kỳ vọng của stakeholders.
Để có thể xác lập rõ kỳ vọng của mỗi stakeholders, PO cần lấy “tương đối” đúng và đủ yêu cầu, đồng thời có những hoạch định cơ bản về giải pháp tương ứng. Cả kỹ thuật lấy yêu cầu7 hay ý tưởng giải quyết vấn đề đều đòi hỏi kinh nghiệm, và với những phạm trù liên quan đến kinh nghiệm thì cách tốt nhất là dấn thân tự trải nghiệm hoặc học hỏi từ kinh nghiệm (kể cả thành công và thất bại) của người khác. Nên Py cũng thường chia sẻ với các bạn trẻ: đọc nhiều vào, quan sát nhiều vào. Như hiện tại, nếu có thời gian, Py cũng thường tìm đọc docs của các dự án khác để làm giàu vốn hiểu biết về “tech”, hướng giải quyết những use case khó nhằn; “nằm vùng” trong các group để học hỏi cách các PO khác giải quyết vấn đề; hay lang thang tìm đọc các case studies hoặc bài phân tích8.
Đồng thời, PO cần giao tiếp liên tục để tiếp nhận và phản hồi vấn đề/thông tin từ các bên, nên kỹ năng giao tiếp dần trở thành yêu cầu bắt buộc cho những người làm nghề. Bài học vỡ lòng của Py về giao tiếp là “nghe để nghe” thay cho việc “nghe để phản hồi” – một quan điểm từng được tác giả Stephen R. Covey nhắc đến trong quyển 7 Thói quen hiệu quả. Bài học đắt giá tiếp theo là nói theo ngôn ngữ của người nghe. Ví dụ, stakeholder là BU (business unit) sẽ không quan tâm nhiều đến việc có những công nghệ mới nào đang được sử dụng, họ cần biết giải pháp này đáp ứng được nhu cầu nào của user, đo lường ra sao và có thể được commercialize (thương mại hóa) như thế nào; stakeholder là CS (customer support) thường sẽ quan tâm nhiều đến việc những gì user đã tự làm được và những gì cần CS hỗ trợ, chứ không hẳn đi sâu về việc hiểu các bên trong hệ thống truyền gửi những data nào. Đoạn này, Py xin mượn phát biểu của Cựu Tổng thống Nelson Mandela để tóm lại tầm quan trọng của việc nói theo ngôn ngữ người nghe – không chỉ riêng về khía cạnh “ngôn ngữ”: “If you talk to a man in a language he understands, that goes to his head. If you talk to him in his language, that goes to his heart.” (Tạm dịch Nếu bạn nói bằng ngôn ngữ mà người nghe được học, anh ta sẽ ghi nhớ bằng não bộ. Nếu bạn nói bằng ngôn ngữ mẹ đẻ của anh ý, anh ý sẽ nhớ bằng cả trái tim.)
“Hành” của việc không làm rõ kỳ vọng của các bên là những buổi họp triền miên trong quá trình làm (In Dev), mỗi lần meeting lại phát sinh change requests, timeline điều chỉnh liên tục, docs cập nhật theo mỗi lượt trao đổi. Cách chữa cháy nhanh nhất và đơn giản nhất là kéo các team liên quan vào họp, thậm chí vừa trao đổi vừa điều chỉnh wireframe, vẽ lại các flow chi tiết nhất có thể (thường là activity/sequence diagram) để làm rõ scope của mỗi bên; sau mỗi buổi họp cần làm rõ bộ ba Action – PIC – Timeline. Tuy nhiên, cách chữa cháy khi nào cũng sẽ tốn nhiều resource (thời gian + con người) hơn hẳn, do đó ưu tiên của PO vẫn nên là quản lý kỳ vọng của các bên ngay từ đầu.
3. Product Principle
Đối với Py, PO là người làm sản phẩm, “a product guy”, chứ không phải là người làm sản phẩm A, B, C… Trong suốt con đường sự nghiệp, PO có thể sẽ gắn bó với một hoặc rất nhiều domains dù ở một hay nhiều công ty, nên điều mà PO mang theo theo qua mỗi dự án là tư duy làm sản phẩm, là cách tiếp cận, là bộ dụng cụ làm nghề.
Đến thời điểm hiện tại, Py đã gắn bó với mảng ví điện tử được gần 4 năm, nhưng trong thời gian này, kinh nghiệm của Py lại trải dài từ các dự án về e-com đến customer service chứ không gói gọn trong các mảng thuộc fintech (điển hình là payment). Tùy vào giai đoạn, PO cũng cần perform nhiều nhóm skill sets khác nhau. Ví dụ, với nhóm dự án hoàn toàn mới, PO cần trao đổi thường xuyên với các bên để nắm rõ tìm hiểu, tiến hành các bước tìm hiểu về thị trường, người dùng, và cả đối thủ cạnh tranh để vạch ra hướng đi phù hợp; với sản phẩm đang vận hành ổn định, PO cần tập trung nhiều hơn vào việc tracking và monitoring để đảm bảo mọi nỗ lực (UI/UX improvements, fix bugs,..) để bám sát mục tiêu ban đầu và tác động tích cực với người dùng… Khi kinh nghiệm trải dài nhiều dự án thuộc nhiều domain và giai đoạn khác nhau thì việc nên làm là ngồi lại để hệ thống hóa lại những kỹ năng/bài học quan trọng theo chiều sâu, cũng có thể tự khái quát hóa lên thành bộ khung chung (framewrok) để áp dụng cho những bài toán tương tự trong tương tự. Từ quan sát của Py, đây cũng có thể được xem là điểm nhận diện của một PO lành nghề.
Sâu hơn một chút, principle cũng đâu đó phản ánh phong cách làm sản phẩm của một PO. Ví dụ, các design của Apple luôn hướng đến các tiêu chí như đảm bảo tính thẩm mỹ, tập trung giải quyết vấn đề quan trọng… phần nào phản ánh con người của chính Steve Jobs, cực đoan với những gì ông cho là không cần thiết, điển hình ở việc liên tục cải tiến để tinh gọn dần màn hình điện thoại đến mức không còn bất kỳ nút bấm nào (hoặc đội ngũ thiết kế của Steve Jobs cũng đã rất vất vả thuyết phục ông đồng ý thêm nút Menu trong những bản thiết kế đầu tiên của iPod).
Dù vậy, có được một sản phẩm mang dấu ấn cá nhân có thể được xem là hoài bão lớn đối với những người “làm thuê chuyên nghiệp”, nên ít nhất, xây dựng bộ dụng cụ làm nghề có thể được xem là mục tiêu ngắn hạn, cũng là năng lực giúp mỗi PO định vị bản thân trong thị trường “lao động” cạnh tranh như hiện nay.
Hiển nhiên, để tạo thành khái niệm PO sẽ còn cần tập hợp thêm nhiều phẩm chất khác nữa, nên chắc chẳn đây chỉ là một trong nhiều bài viết về chủ đề này. Mong rằng phần nào sẽ giúp bạn đọc góp nhặt những từ khóa quan trọng để “gọi tên” năng lực chuyên môn của bản thân, hay có thể là một ánh đèn nhỏ soi dần con đường vào nghề của những bạn trẻ mới vào ngành.
[1] “Domain”, ý nói về lĩnh vực, ví dụ như tài chính, giáo dục, y tế, bất động sản… (fintech, edtech, proptech…)
[2]“Mini-CEO”, ý từ bài viết Who is the Professional Scrum Product Owner.
[3] “User Journey”, tham khảo thêm tại User Journey – Hành trình đi đến trái tim người dùng của blog LemonTribe, một blog chia sẻ các bài viết về product management và “more”.
[4] “Need”, “Demand”, ý từ bài viết Phân biệt Need, Want, Demand – dù đây là bài viết thuộc lĩnh vực Marketing, nhưng cũng giúp Py rất nhiều trong việc xác định “đúng” nhu cầu (demand), thay vì bị “trap” trong nhiều mong muốn khác nhau của người dùng.
[5] “Lập kế hoạch và phân tích yêu cầu”, tham khảo thêm tại Software Development Life Cycle (SDLC).
[6] “Kỹ thuật lấy yêu cầu”, tham khảo thêm tại Dân chơi lấy yêu cầu với 3 nguyên tắc sau của blog Thinhnotes, một blog chia sẻ rất nhiều bài viết về nghiệp vụ và nghề BA.
[7] Các web Py thường đọc là:
Tương tự như những bài viết khác, Py cũng để ngỏ nhiều luận điểm (vẫn chưa) giải quyết triệt để, ví dụ như đoạn “sản phẩm mang dấu ấn cá nhân”, hy vọng sẽ nhận được thêm phản hồi để cùng mổ xẻ thêm về chủ đề này.
Cám ơn bạn đã nán lại cho đến những dòng cuối cùng này.
Chúc bạn nhiều may mắn và bình an.
Anpy
Leave a Reply