Software Business Analyst và Product Owner
Hôm nay Phát sẽ nói về sự khác biệt giữa BA và Product (tạm gọi là PO nha), xem hai cái công việc này giống và khác nhau ở điểm nào, nghề nào “xịn”hơn, cơ hội thăng tiến của bên nào tốt hơn, etc… Bài này mất 6 phút để đọc.
Nói về việc này là vì có nhiều bạn vẫn còn chưa rõ hai môn học này nó khác nhau ra sao, nhiều bạn nghĩ là BA thì có thể qua làm PO được luôn, và ngược lại làm PO thì chắc chắn làm được việc của BA. Lại có nhiều bạn bè mình nói chuyện thì cho rằng thôi, tao muốn đổi từ BA sang làm PO vì nghe đâu làm PO nhàn hơn(!!!) mà lại lương cao hơn (!!!x2, WTH).
Vậy thì mấy suy nghĩ đó có đúng không? Sao cứ phải rạch ròi khái niệm làm gì trong khi hai cái này “same same” nhau?
Trước hết mình đi một vòng xem nó giống nhau ở đâu.
Chính vì có nhiều điểm giống nhau quá nên mới tạo sự lầm tưởng là “scope” và tính chất công việc của hai bên giống nhau.
1. Một, những người mình làm việc cùng
Cả BA hay PO đều là cầu nối giữa user/stakeholder và development team (tạm hiểu là mấy anh chị Dev hoặc QC). Không phải đơn thuần là làm việc cùng thôi, mà phải nói là làm rất rất gần gũi, không những là hiểu mà còn phải đồng cam cộng khổ cùng user và team.
2. Thứ hai là đều làm việc với requirement (yêu cầu nghiệp vụ)
Phải đi từ bao quát đến chi tiết, gọi là làm requirement, sao cho dễ hiểu, thể hiện đúng yêu cầu, team dev nghe xong phải hiểu và làm đúng cái mình mong đợi. Rồi phải quản lý tài liệu, cập nhật document sao cho dễ tìm, sau này não có rớt thì kiếm lại để nạp vô được.
3. Cái đến nữa là tập trung vào việc “product delivery”
Nói cho dễ hiểu là làm sao hiện thực hóa được mấy yêu cầu ở trên. Làm gì làm, cái kết quả làm ra mới là quan trọng, có đảm bảo các yếu tố về thời gian, chi phí và chất lượng hay không.
4. Về quy trình software development life cycle
Cả hai đều rất tinh thông quy trình và nghiệp vụ, code xong rồi tới test, test có UAT có production, rồi từ Scrum đến Kanban ra sao chắc cũng không cần phải nói quá nhiều.
5. Kế tiếp là nói về kĩ năng mềm
Kĩ năng giao tiếp, thuyết trình, kĩ năng đặt câu hỏi, meeting note, bla bla… Thậm chí là tiếng Anh cũng phải lưu loát để dễ làm việc. Và còn nhiều hơn thế nữa.
6. Cuối cùng
Đa phần mấy anh đều làm việc vì tiền. Một số anh khác còn lại làm vì đam mê, đam mê tiền.
Còn vài điểm tương đồng nữa nhưng sơ sơ là vậy cho dễ hiểu, nói nhiều quá mất hay.
Giờ mình đi tới câu chuyện khác nhau
1. Cái dễ thấy nhất là tính chất công ty
Đa phần (chỉ là đa phần thôi nha) là BA sẽ làm việc ở các cty outsourcing còn PO thì làm ở các cty sản phẩm.
Cty outsource họ phải đi kiếm dự án về, kiếm càng nhiều càng tốt. Mỗi dự án mỗi domain khác nhau, mỗi khách hàng khác nhau (người trả tiền cho cty để làm dự án mà họ mong muốn như phần mềm kế toán, phần mềm quản lý bán hàng, ERP, vân vân). Mấy phần mềm này làm xong có thể họ tự xài cho nội bộ (ví dụ mấy bệnh viện hay ngân hàng hay thuê cty outsource để viết phần mềm cho họ), hoặc họ đem sản phẩm này đi bán tiếp cho nhiều khách hàng khác nữa. Outsourcing sẽ giúp họ tiết kiệm chi phí, không phải nuôi một đội ngũ mấy anh dev hút lương như cá voi hút nước; vừa đỡ mất công tuyển, mà outsource lại là chuyên gia, họ sẽ đáp ứng nhanh chóng và chất lượng mấy yêu cầu này.
Và mấu chốt chính ở chỗ này, cty outsource cần người đứng ra “chuyển thể” mấy yêu cầu của khách hàng tới đội dev (vì không phải ông dev nào cũng nghe và hiểu hết một cách dễ dàng, nhất là mấy khách hàng thích chia động từ). Chưa kể, ông khách hàng kia, điều ổng nói ra chưa chắc là điều ổng thực sự muốn, mà có những cái ổng muốn thì ổng lại không chịu nói ra, nó chết con chim én ở chỗ đó. Lúc này chính là lúc mấy anh BA xuất chiêu. BA sẽ cực kì mạnh ở khúc này, ảnh khai khác khách hàng đến tận xương tủy, Khách hàng nói 1 ảnh hiểu tới 8, 9. Rồi ảnh bắt đầu làm bản vẽ, modeling, workflow, diagram, làm mockup prototype các thể loại, để cuối cùng anh hỏi anh Khách hàng, nè, phải cái này là cái mày muốn hông! Siêu cái nữa, là một anh BA ảnh có thể cùng lúc tiếp tới 3.14 lũy thừa N ông khách hàng cùng lúc, mấy anh BA dày kinh nghiệm còn nắm được Khách hàng trong lòng bàn tay, nhiều anh làm tốt tới nỗi Khách hàng khoái quá tuyển anh này về cty mình làm luôn.
Product thì khác, ảnh làm cho cty về sản phẩm. Một cty sản phẩm có thể có một hoặc nhiều sản phẩm (Grab thì có Grab car, Grab bike, Grab food, etc..), một anh PO ảnh có thể ôm một hay nhiều sản phẩm là tùy theo sếp ảnh muốn sao và cty trả lương thế nào.
2. Kế đến là hiểu thị trường
Đặc trưng của PO là ở chỗ này. Nhiệm vụ chính của anh PO chính là phải hiểu được cái sản phẩm mình đang làm cho thị trường nào, người dùng nào, thị trường đó muốn gì, cần cái gì, đối thủ có những ai. Để cuối cùng là phải đảm bảo được sản phẩm của mình đáp ứng được nhu cầu, đem về lợi nhuận cho cty. Khác với BA ở trên, chỉ có một Khách hàng (thuờng sẽ có 1 hoặc vài bạn đại diện đứng ra gửi yêu cầu), cái chữ thị trường ở đây cực kì rộng. Giờ ha, tui nói tui làm Chợ Tốt cho thị trường Việt Nam xài? Vậy ông nào tên Việt Nam? Giờ không lẽ đi hỏi hết 98 triệu dân? Lúc này, kĩ thuật của PO phải làm làm sao hiểu được 2 tiếng thị trường đó, ví dụ làm market research, quali/quanti feedback, phân tích đối thủ, đánh giá market size, persona, SWOT analyse đồ.
Từ cái hiểu thị trường đó, sẽ dẫn tới việc hiểu người dùng. Trở lại ví dụ ở trên, BA sẽ phải quan tâm Khách hàng của mình là ai và ông nội đó thực sự muốn gì. BA có thể đi sâu vào việc hiểu vì sao Khách hàng của mình muốn cái đó, rồi từ đó thậm chí có thể tư vấn thêm giải pháp cho ông khách đó.
Còn PO, ảnh phải hiểu end-user của anh đang gặp khó khăn gì, đâu mới là khó khăn hay nhu cầu cấp thiết nhất. Để làm được cái đó, ảnh phải lăn lộn làm user validate, chạy tới tận nơi ông end-user sống và làm việc, để ngoài việc lắng nghe feedback của họ, thì còn coi môi trường xung quanh ảnh hưởng đến họ như thế nào. Ví dụ vầy, để hiểu được một anh “Cò” đất, mình phải đi theo họ, xem họ suốt ngày lăn lộn ở mấy quán cafe, dang nắng dang nôi để tiếp Khách hàng… Chính những context đó sẽ giúp PO design được một giải pháp phù hợp và đúng đắn hơn cho end-user.
Khác với PO, anh BA nói thiệt ảnh chỉ cần quan tâm có đúng yêu cầu của anh đại diện Khách hàng kia hay không thôi, còn làm ra có ai xài không, bao nhiêu người xài, vv… hỏng phải việc của ảnh. Có muốn quan tâm ảnh cũng không có thời gian, nhà bao việc.
3. Định nghĩa XONG (definition of done)
Thời mình còn làm BA, xong có nghĩa là test tiết xong hết, làm demo cho KH, KH hài lòng, release lên môi trường production, xong, đi nhậu. Cứ như thế cuốn chiếu liên tục cho đến khi deliver được hết các yêu cầu của Khách hàng trong roadmap.
Nhưng với PO, lúc release lên production, game mới chính thức bắt đầu. Vì sao? Vì thứ anh PO cần là outcome sau khi cái sản phẩm đó release, bao nhiêu người xài, user bị drop ở bước nào, tỉ lệ adoption bao nhiêu, etc… Ảnh và team gần như phải monitoring liên tục mấy con số này, có fail cũng phải biết lý do tại sao fail, để từ đó tiếp tục revise tính năng cho tốt hơn. Đó là còn chưa kể, ảnh và team còn phải tính toán coi release như thế nào (Go to Market Strategy), làm sao để người dùng biết đến tính năng đó, làm sao và làm sao.
4. Scope
Cũng như BA, PO cũng quản lý danh sách các tính năng, quản lý backlog, quản lý roadmap. Tuy nhiên, khác nhau ở chỗ, nếu PO trong quá trình monitor kết quả của sản phẩm, ảnh thấy phát sinh một nhu cầu nào đó (ví dụ KH cần thêm tính năng nhớ tài khoản ngân hàng), nhiệm vụ của ảnh là note cái đó lại vào backlog để xem có nên làm tính năng đó hay không…
Còn BA, mục tiêu là đáp ứng đúng scope của Khách ảnh muốn, nếu có phát sinh thêm tính năng mà ảnh nghĩ là cần, thì cũng không được làm (ảnh có thể hỏi Khách hàng xem có muốn làm không thì được). Vì sao, Khách hàng của cty ảnh chỉ trả tiền cho đúng cái họ yêu cầu. Kinh nghiệm của mình, nhiều khi team mà thấy ngứa mắt, tức mình quá, làm luôn, anh khách hàng ảnh sẽ chửi một trận, tao không yêu cầu ai cho mày làm?!?
Nói tóm lại, BA thì mục tiêu là làm sao deliver được kết quả như Khách hàng mong muốn, đảm bảo được các tiêu chí về time-scope-cost. Còn nhiệm vụ của PO là làm sao cho sản phẩm của ảnh đáp ứng được nhu cầu của thị trường mà sản phẩm đó đang nhắm tới.
BA vs. PO
+ Requirement roadmap vs. Product roadmap
+ Stakeholder liaison vs. Customer liaison
+ Solution focus vs. Market focus
+ Project acceptance criteria vs. Competitive market analysis
+ Requirement analysis vs. Strategy analysis
Và trả lời cho câu hỏi ở đầu bài viết, nghề nào “xịn” hơn. Thưa rằng, nghề không xịn, quan trọng là người làm nghề có xịn hay không. Nếu bạn mê BA, hãy theo đuổi nó tới cùng, và PO cũng vậy. Nếu bạn đang làm BA mà nghĩ PO ngon hơn, xong qua cty product làm đúng như scope của một BA thì thật sự cũng không tới đâu, bạn chỉ là một BA cô đơn trong cty product.
Nhiều đàn anh đàn chị của mình theo nghiệp BA bao nhiêu năm trời, giờ nhìn cực kì đáng ngưỡng mộ. Có tiếng tăm trong giới, được nể trọng, lương cao, biết rất nhiều domain knowledge, được đi bao nhiêu nước từ Mỹ tới Âu. PO thì được làm và theo đuổi đúng một field mình thích, được làm cho cty về sản phẩm mà mình yêu thích. Thị trường việc làm và cơ hội thăng tiếng của 2 jobs không thua gì nhau (cả BA và PO đều ra làm CEO hay founder được).
Và nếu bạn đang cân nhắc nhảy từ cái này qua cái kia, hãy luôn đặt câu hỏi vì sao mình muốn nhảy, bạn sẽ tự trả lời được.
P/s: bài viết dựa trên kinh nghiệm cá nhân. Phát từng có 2 năm làm BA cho một cty lớn, và khoảng hơn 7 năm làm về product. Rất welcome bạn bè feedback hoặc bổ sung hoặc chỉnh sửa nếu Phát sai điều gì nha.