Muôn nẻo đường BA (P2)
Muôn nẻo đường BA (P2)
Hế lô anh em. Bài này sẽ tiếp tục về chủ đề Muôn nẻo đường BA – Các con đường sự nghiệp mà BA có thể chọn trên chặng hành trình của mình. Anh em có thể xem lại phần một ở đây nhé.
Ở phần 1, chúng ta đã đi được các phần sau.
- Một câu chuyện hư cấu có thật
- Muôn nẻo đường BA
- Công ty Product | Product Owner?
Ở phần 2, mình sẽ tiếp tục đi các phần còn lại, bao gồm:
Nội dung [Hide]
- 4. Công ty Giải pháp
- 4.1. Business Analyst trong Công ty Outsourcing?
- 4.2. Functional Consultant trong Công ty Services?
- 4.3. Bridge System Engineer trong công ty Outsourcing?
- 5. Công ty Tư Vấn | Business Consultant?
- 6. Tạm kết
4. Công ty Giải pháp
Đối với các công ty giải pháp, mình sẽ chia làm 2 loại công ty có công việc BA.
- Công ty Outsource (chủ yếu làm Software Development)
- Công ty Services (chủ yếu làm Software Implementation, Software Maintenance, và 1 nùi các loại service khác).
Anh em xem lại cái hình overview ở phần 1 cho dễ hình dung nhé.
4.1. Business Analyst trong Công ty Outsourcing?
Công ty Outsourcing là gì?
Outsource nghĩa là gia công. Nghĩa là: thay vì mình làm, thì mình đi thuê thằng khác làm cho mình, chứ mình hổng làm.
Vì thằng khác nó chuyên làm cái đó,
nó làm tốt hơn mình,
và giá nhân công nó rẻ hơn mình.
Quay lại case study phía trên. Công ty ông Hải cần phát triển một Mobile App, giúp khách hàng có thể đặt xe trực tuyến.
Cái này đáng ra ổng phải làm, mà do đội IT của ổng cùi bắp quá, không đủ resources để làm. Nên ổng phải tìm đến Sáu Bảnh Global để làm.
Tuy nhiên vì giá chát quá, nên ổng phải tìm qua một thị trường khác có giá nhân công rẻ hơn Việt Nam để làm, là Campuchia.
Trong công ty Campuchia có một anh BA tên Tony Tèo. Và anh này chính là Business Analyst, trong công ty Outsourcing, công ty Cambodian Technology.
Về công việc của ảnh thì chắc mình không cần giải thích thêm nhiều chứ hả anh em 
Mình chỉ muốn nói rõ cho anh em đỡ lẫn lộn giữa 2 vai trò.
- Product Owner tập trung trả lời câu hỏi nghiêng về Product, là làm gì, tại sao phải làm và làm khi nào?
- Còn Business Analyst tập trung trả lời câu hỏi nghiêng về Requirement, là làm như thế nào?
Cũng như chị Tủn (một Product Owner), công việc của anh Tony Tèo (một Business Analyst trong công ty Outsource) cũng xoay quanh 4 vòng tròn sau.
Cũng như chị Tủn, công việc của anh Tèo cũng dựa trên 4 vòng tròn này.
Sơ bộ thì anh Tony Tèo sẽ làm việc trực tiếp với chị Tủn (Product Owner) để 2 bên cùng hiểu rõ Business Objectives của dự án, cũng như các Stakeholder có trong dự án.
Giai đoạn xác định Business Objective và các Stakeholder anh Tèo không involve vào nhiều, vì đa phần các nội dung này đã được chị Tủn Product Owner bên công ty khách hàng lo rồi.
Cái mà ảnh sẽ tập trung làm, đó chính là Solution. Ảnh phải thật sự nắm rõ về các requirement cần làm, cũng như đưa ra giá trị tư vấn về Mobile App (tức là tư vấn về giải pháp), sao cho giải pháp này thật sự đáp ứng được Business Objective và sự hài lòng của các Stakeholders.
Sau đó ảnh sẽ chuyển giao toàn bộ giải pháp cho chị Tủn, có thể hỗ trợ training sử dụng hệ thống, hoặc hỗ trợ Go-Live, bảo trì khi kết thúc dự án, gọi là Transition.
Liệu Product Owner và Business Analyst có cùng tồn tại trong một dự án?
Như mình nói, Product Owner xuất hiện trong dự án làm theo mô hình Scrum. Mà 1 trong 3 vai trò của mô hình Scrum là Development Team.
Vậy thì: người Business Analyst làm GIẢI PHÁP sẽ nằm ở đâu trong dự án Scrum?
Nằm trong Development Team, ngoài Development Team, hay Business Analyst chính là Product Owner?
Câu trả lời có hay không, tất cả đều phụ thuộc vào dự án. Hai vai trò cùng tồn tại cũng được, mà không cũng được.
Như case study đầu bài của mình là có. Cả 2 role BA (anh Tony Tèo) và PO (chị Tủn) cùng tồn tại trong dự án xây dựng Mobile App đặt xe cho công ty Hải Motor Ôm.
Mình có sưu tầm được 3 hình sau của Roman Pichler cũng có mention về vấn đề này.
Phương án 1, như case study của mình.
Phương án 2, Business Analyst đóng vai trò như một Product Owner.
Phương án 3, nên tránh, làm trung gian kiểu này sẽ làm mất đi tính chất “gọn nhẹ” của Agile, dẫn đến trao đổi thông tin chậm và không hiệu quả.
Ô kê, vậy là nãy giờ anh em đã biết được role thực sự của chị Tủn và anh Tony Tèo.
Vậy thì còn lại, anh Mai-cồ Tom ở đầu bài, ảnh cũng làm công việc BA, nhưng thực sự ảnh đóng vai trò nào?
4.2. Functional Consultant trong Công ty Services?
Thế nào là software implementation
Vâng, chính xác thì vai trò của anh Tom là Functional Consultant. Về cơ bản, công việc của anh Tony Tèo chả khác gì anh Mai-cồ Tom là mấy.
Công việc của Business Analyst trong công ty Outsourcing hay công việc của Functional Consultant trong công ty Services giống nhau đến 96,69%. Còn 69,96% khác biệt còn lại là đến từ GIẢI PHÁP.
Đơn giản vì, công ty Outsourcing thì làm giải pháp khi chưa có gì hết, phải build ngay từ đầu, start from scratch. Bà con hay gọi là Software Development.
Còn công ty Services thì giải pháp họ cung cấp là một sản phẩm đã có sẵn. Nhiệm vụ của họ là triển khai giải pháp đó một cách hiệu quả nhất. Bà con hay gọi là Software Implementation.
Công ty Service hay công ty Outsourcing là do mình tự đặt ra để phân biệt cho dễ giữa Software Development và Software Implementation. Còn về bản chất, Outsourcing vẫn là một loại hình dịch vụ, nên anh em đừng rối bời quá nhé.
Ba cái đồ triển khai cùi bắp, lêu lêu.
Nói về triển khai thì mình cũng đã từng nghe nhiều anh em “bĩu môi chê bai” rằng: “Triển khai thì có cái gì đâu mà hay ho, toàn là có sẵn, giờ chỉ việc đem đi ‘ráp’ cho khách hàng xài thôi chớ có làm gì đâu, lêu lêu…”
Mình xin khẳng định câu trên là hoàn toàn sai!
Comment này có thể đến từ những anh em chưa từng làm triển khai một lần nào trong đời, hoặc trong đời chưa từng làm triển khai bao giờ. (Thực ra 2 ý này như nhau, nhưng blog của mình nên mình thích nói vậy cho nó nguy hiểm )
Mọi thứ đâu dễ ăn của ngoại vậy được. Nói vậy chắc mấy công ty làm software implementation giàu bổ xừ nó hết rồi.
Vậy thì thực sự như thế nào? Cùng quay lại vòng tròn BA huyền thoại để xem công việc của Functional Consultant là gì nhé anh em.
Business Analyst hay Functional Consultant cũng giống y chang, cũng làm như này hết, cụ thể.
Anh Mai-cồ Tom có nhiệm vụ xác định rõ Business Objectives của ông Hải là gì. Rõ ràng là ổng muốn quản lý đội xe của ổng tốt hơn, thông qua việc áp dụng hệ thống “Self-Governing Motor Ôm”.
Anh Mai-cồ này phải xác định rõ cụ thể: tốt hơn là như thế nào. Ảnh sẽ làm việc với các Stakeholder, làm việc với ông Hải CEO, làm việc với bộ phận quản lý đội xe, tài xế, rồi nhân sự, kế toán… để xác định các module/ functions cần có của hệ thống.
Sau đó, anh Mai-cồ mới bắt tay vào làm solution dựa trên hệ thống “Dynamics 365 for Ôm” của Microsoft. Ảnh sẽ configure và customize lại hệ thống sẵn có sao cho phù hợp với những requirements cụ thể từ khách hàng là công ty Hải Motor Ôm.
Và dĩ nhiên, không phải một mình ảnh làm solution, mà phải có cả team cùng làm, nồng cốt nhất vẫn là PM và các anh em Developers.
Sau khi hoàn thiện xong Solution, ảnh sẽ mang đi triển khai bằng các hoạt động training key-user sử dụng hệ thống, hoặc support go-live các kiểu. Đó là Transition.
Một số khác biệt giữa software developement và software implementation
Như anh em thấy, công việc của BA giữa 2 mảng này cũng không khác nhiều. Tuy nhiên, có một vài điểm khác biệt mình nên nói rõ cho anh em như sau.
- BA trong software development thì tập trung sức lực vào build solution là nhiều.
- Còn BA trong software implementation thì tập trung vào khách hàng, vào người dùng nhiều hơn.
Về khả năng tiếp cận người dùng để hiểu họ và đem lại giải pháp thật sự phù hợp, thì mình nghĩ đâu đó BA trong software implementation vẫn nhiều cơ hội hơn, so với BA trong software development.
Nhưng bù lại, thì kiến thức IT của BA trong software development có thể được đòi hỏi cao hơn, so với nhánh ngược lại.
Còn BA trong software implementation thì kỹ năng thuyết phục và thương thảo với khách hàng phải thật sự tốt. Để có thể tư vấn, thuyết phục họ đi theo các best practices có sẵn, ngoài việc lái hệ thống đi theo những quy trình đặc thù của khách hàng.
Ngoài những dự án triển khai mới ra, Functional Consultant còn có thể xuất hiện trong các dự án sau:
- Software Maintenance – Các dự án bảo trì phần mềm
- Security – Các dự án bảo mật hệ thống
- Software Upgrade – Các dự án nâng cấp phần mềm
- Integration – Các dự án chuyên về tích hợp các sản phẩm phần mềm.
Chốt hạ
Business Analyst thì chỉ là cái TÊN CÔNG VIỆC. Còn chức danh là gì, thì anh em phải để ý thật sự kỹ. Có một số công ty đặt chức danh theo đúng công việc họ làm, một số khác thì không.
Có một số công ty tuyển thì tuyển Business Analyst, nhưng vào thì chỉ cho làm các dự án support. Quanh năm suốt tháng chỉ làm support. Chán như con gián.
Do đó anh em phải tìm hiểu thật kỹ. Chức danh có thể tạm gác qua 1 bên, nhưng Job Description thì tuyệt đối phải đọc kỹ.
4.3. Bridge System Engineer trong công ty Outsourcing?
BrSE là kỹ sư cầu nối. Cái tên nói lên tất cả.
BrSE có nhiệm vụ trực tiếp kết nối team offshore (team làm ở nhà, không đi onsite) với khách hàng.
Vì rào cản lớn nhất ở đây là bất đồng ngôn ngữ, nên BrSE phải rất giỏi một ngoại ngữ nào đó. Nếu khách hàng là Nhật thì phải biết tiếng Nhật, là Pháp thì phải biết tiếng Pháp…
Ngoài ra, một BrSE phải biết về kỹ thuật, có thể là rành một ngôn ngữ lập trình nào đó. Vì quá trình “truyền tin” giữa khách hàng và team nhà có thể phát sinh nhiều vấn đề mới, hoặc các requirement cũ phát sinh bug. BrSE cần hiểu rõ các vấn đề này để “dàn xếp” mọi thứ một cách ổn thỏa giữa 2 bên.
Về bản chất, vai trò BrSE cũng tương tự như vai trò Business Analyst. Họ sẽ làm việc với khách hàng, nhận requirement từ họ, phân tích và tài liệu hóa các requirement, deliver cho team nhà, giải thích và quản lý công việc các anh em team nhà. Nhằm đảm bảo mọi thứ được deliver một cách chính xác và chất lượng.
That’s it, đó là những gì mình biết về BrSE 
Anh em có thể đọc thêm bài dưới đây để hiểu hơn về công việc của BrSE nhé.
BrSE – Kỹ sư cầu nối, được gì và mất gì?
Hoặc BrSE là gì từ Hajimari.
5. Công ty Tư Vấn | Business Consultant?
Ô kê anh em, chúng ta đã đi được 4 vai trò:
- Product Owner
- Business Analyst
- Functional Consultant
- Bridge System Engineer
Và vai trò cuối cùng là Business Consultant, và cũng là trùm cuối trong nghề BA. Hay nói đúng hơn, vai trò này có thể là Technology Business Consultant hoặc Principle Business Analyst. Nói chung là chúa tể của những BA.
Họ là ai?
Đây là những người rất khủng, họ đã có hàng chục năm kinh nghiệm chinh chiến, thương tích đầy mình. Lăn lộn đủ lâu với ngành giải pháp phần mềm, đủ để tích lũy cho mình những góc nhìn đặc thù với những vấn đề nan giải nhất, hay xảy ra trong tất cả các loại hình công ty.
Và kèm theo đó luôn là những best practices để xây dựng giải pháp phần mềm mang lại hiệu quả nhất cho công ty khách hàng.
Vậy họ làm những việc gì? Đơn giản là họ làm tư vấn. Tư vấn thực thụ nhé anh em.
Anh em có thể thấy vai trò này i chang Technical Architect, nhưng không chuyên sâu kỹ thuật như TA.
Như mình nói, ý nghĩa của nghề BA là giải quyết vấn đề bằng giải pháp công nghệ thông tin. Giải pháp này có thể là phần cứng, chứ không không nhất thiết chỉ là phần mềm. Và bằng bất kỳ các công nghệ, từ AI, Cloud hay Blockchain, chứ không gói gọn trong bất kỳ phạm vi nào.
Thậm chí, họ còn có thể giải quyết vấn đề bằng cách tư vấn về quy trình, chiến lược phát triển nền tảng CNTT cho khách hàng, chứ không chỉ gói gọn trong 1-2 hệ thống, sản phẩm phần mềm.
Và Technology Business Consultant là vai trò thể hiện giá trị tư vấn rõ nhất, và là đẳng cấp cao nhất của một người làm BA.
Cũng như một BA thông thường, nhưng Technology Business Consultant không làm tiểu tiết đến từng stories hay requirement như BA. Họ chỉ mang lại giải pháp ở tầng high level, vì với kinh nghiệm lâu năm, họ biết đó là điều tốt nhất cho công ty khách hàng.
Vai trò này thường xuất hiện ở các bác principle, chuyên làm tư vấn chiến lược, hoặc thậm chí là làm Pre-Sales. Anh em có thể bắt gặp vị trí này ở các công ty chuyên tư vấn giải pháp công nghệ thông tin.
Thường thì các công ty tư vấn chỉ làm tư vấn, và không được tham gia xây dựng hoặc triển khai giải pháp. Việc “hiện thực hóa giải pháp” phải được một bên thứ ba làm thì mới minh bạch và hiệu quả.
Do đó, thứ mà Technology Business Consultant có thể deliver được cho khách hàng chính là tài liệu tư vấn. Chính xác, chỉ đơn giản là các file pdf, nhưng đáng giá cả triệu đô.
Các công ty mà chuyên tư vấn giải pháp CNTT thì mình không biết nhiều, đếm trên đầu ngón tay thì có: PAT Consultant, PwC, Deloitte, KPMG hay E&Y.
Nói vậy thôi nhưng ở Việt Nam thì các công ty như Deloitte hay KPMG vẫn tư vấn rồi triển khai cho khách hàng luôn nhé anh em.
Best Practices
Nếu đúng bài bản như các công ty nước ngoài hay làm, thì khi có vấn đề/ nhu cầu về một giải pháp phần mềm nào đó, khách hàng họ sẽ chủ động liên hệ với các công ty tư vấn CNTT trước. Sau đó mới đi tìm các đối tác xây dựng hoặc triển khai phần mềm.
Khi đó, khách hàng họ đã biết được họ cần gì trước, cần gì sau, chức năng nào là phù hợp, nên ưu tiên hàng đầu. Hoặc thậm chí là đối tác nào nên tiếp cận, đối tác nào nên né.
Chỉ như vậy, khách hàng mới có thể tự narrow down lại rủi ro có thể họ gặp phải, chi phí bỏ ra hiệu quả hơn và tỉ lệ thành công của dự án cao hơn rất nhiều.
6. Tạm kết
Hi vọng qua bài này, anh em hiểu rõ được các vai trò của công việc BA.
Thực tế thì nó có thể như mình nói ở trên, hoặc không. Vì thực tế thì muôn hình vạn trạng, mình không thể cover hết được. Anh em cứ xem đây là một note tóm gọn lại những vai trò dễ bắt gặp nhất đối với một người làm công việc BA.
Và cuối cùng: nếu anh em vẫn còn đang thắc mắc nên đầu quân cho công ty nào dưới vai trò BA, thì mình hy vọng anh em đã có câu trả lời
Bái bai, và hẹn gặp anh em ở những bài sau
References
Nguồn: thinhnotes.com
