Dân BA có cần phải rành về kỹ thuật???

Thoạt nhìn thì câu trên có vẻ sai, nhưng thực tế thì nó… không đúng tí nào hết anh em.

Mình thấy xung quanh mình hầu như ai cũng nghĩ zậy (rất nhiều người nghĩ zậy). Và đặc biệt là các bạn chẻ trên mạng đang ấp ủ ý định làm BA.

Nó sẽ gây ra một cục hoang mang siêu to khổng lồ và ảnh hưởng ghê gớm đến sự tự tin của anh em…

• Mình không biết tí gì về IT, sao làm BA bây giờ *icon run lẩy bẩy*
• Kỹ thuật là đụng tới lập trình đúng hônggg, em học dở toán với tin lắm, a hu hu.
• Trước giờ em chả biết gì về phần mềm các kiểu hết, giờ làm BA nổi hông…

Bài này mình sẽ note về những gì mình đã từng trải, và về thứ gọi là “kỹ thuật” đối với một người làm BA.

Ô kê lét sờ gâu anh emmm 😎

1. Như thế nào kỹ thuật?

BA á, là phải biết về “kỹ thuật”!

Mình tin là hỏi 10 người thì hết 10 ngàn người trả lời: “kỹ thuật” nghĩa là coding, là lập trình. Tức là phải hiểu, thậm chí phải rành về thuật toán các kiểu… Để nói chuyện với dev người ta còn hiểu nữa, “BA là cầu nối mà”.

Nhưng không, “kỹ thuật” ở đây hoàn toàn không phải là cốt-kiếc gì hết. Mà là: kỹ thuật của công việc BA. Tức là sao?

Bất cứ công việc nào cũng đều có kỹ thuật của nó hết.

• Nghề viết có các kỹ thuật riêng, như: viết lách, viết ký sự, phóng sự…
• Nghề sư phạm cũng có các kỹ thuật riêng của nó, áp dụng cho từng đối tượng
• Chụp ảnh cũng phải có kỹ thuật thì chụp mới ra hồn được
• Thậm chí… chích xì ke cũng phải có “kỹ thuật chích” thì chích mới… phê được. Đâu phải dễ ăn mà bay zô, cầm kim tiêm chích phát một là được.

Do đó, nghề BA cũng phải có các kỹ thuật của nó. Bên cạnh bộ kiến thức chuyên môn và bộ kỹ năng cũng rất quan trọng cho công việc BA này.

Theo từ điển Cambridge (không phải cứ từ điển là đúng, nhưng ít nhiều cũng có cái cho anh em mình tham khảo 😀 )

Technical (adj) = relating to practical skills and methods that are used in a particular activity. Còn theo tiếng Việt mình một cách đơn giản: “Kỹ thuật” là phương pháp được sử dụng để đạt được một kết quả nhất định.

Ví dụ muốn moi móc yêu cầu => sẽ có 11 kỹ thuật thường được áp dụng.

Do đó, mệnh đề trên là mình thấy hoàn toàn sai.

BA cần kỹ thuật không? Cần? Nhưng “kỹ thuật” ở đây không phải liên quan tới lập trình. Mà “kỹ thuật” ở đây là các kỹ thuật trong công việc của BA.

2. “Loại BA” nào thì cần kỹ thuật?

Trên thị trường hiện nay có hằng hà loại BA.

Có người thì chuyên làm về tối ưu quy trình. Có người thì chuyên hẳn về một platform công nghệ. Có người thì tập trung làm product. Hoặc cũng có người chỉ chuyên giải quyết các vấn đề tích hợp…

Nhưng dù có làm gì đi nữa, hễ ai mà làm một loạt các chuỗi công việc: Xác định Business Objective >> Làm việc với Stakeholders >> Đề xuất Solution >> Tiến hành Transition để đưa vào thực tế, thì người đó đều đang làm công việc BA. Bất kể giải pháp có là IT, hay non IT đi chăng nữa.

Bài note này mình nói về: yêu cầu “kỹ thuật” đối với BA. Và khái niệm “kỹ thuật” như nãy giờ anh em mình làm rõ, được áp dụng cho hầu hết các loại BA nhé anh em, bao gồm cả IT BA lẫn Non-IT BA.

3. 4 yêu cầu về kỹ thuật đối với BA

3.1. Use Case

Use Case, thứ có vẻ… “không đụng tới là không được” trong công việc BA.

Vì sao nó lợi hại như vậy? Vì nó giúp anh em mô tả sự tương tác giữa người dùng và hệ thống với nhau.

• Một cách trực quan, nó thể hiện được các actor tương tác những gì, với những ai, trong một môi trường cụ thể – thông qua Use Case Diagram.
• Và cũng một cách rất chi tiết, nó giúp anh em thể hiện được mọi ngóc ngách của sự tương tác đó, như: actor là ai, trigger point là gì, pre-condition ra sao, post-condition thế nào…. thông qua Use Case Specification.

Và đặc biệt là thể hiện được sự tương tác này diễn ra step-by-step như thế nào (Basic Flow)? Hoặc có thể có những cách làm nào khác không (Alternative Flow)? Và cũng thể hiện được luôn: các bước làm nào khiến cho sự tương tác này diễn ra thất bại (Exception Flow)?

…

Xưa giờ anh em hay gói gọn Use Case trong ngữ cảnh “software development”. Giờ thử áp dụng Use Case để phân tích một thứ gì đó trong cuộc sống nhé.

Giả dụ: Mình mở một nhà hàng bán đặc sản Lào ngon nhất Vịnh Bắc Bộ. Và để thu hút 500 anh em tới ăn đông đảo, mình muốn các khâu trong nhà hàng phải thật chỉn chu và kỹ lưỡng. Đặc biệt là khâu tiếp đón khách tới quán ăn.

Vì là BA mà, nên mình muốn phân tích xem thử khâu tiếp đón khách vô quán cụ thể nó ra sao, bao gồm:

• Thực tế nó được bắt đầu khi nào?
• Khi nào thì quán sẵn sàng đón khách?
• Khi nào thì xem như khâu đón khách diễn ra thành công?
• Các bước đón khách diễn ra như thế nào?
• Hoặc có cách nào khác đổi mới để đón khách ngầu lòi hơn hay không?
• Hoặc những thứ cấm kỵ nhân viên làm khi đón khách vào quán?
• Và hàng trăm thứ khác nữa mà mình muốn biết (vì mình muốn làm khâu này thật kỹ) mà giờ chưa nghĩ ra!!!

Ánh xạ qua kỹ thuật Use Case, nó sẽ như thế này (ví dụ nhé anh em):

• Thực tế nó được bắt đầu khi nào? – Trigger
  • Khi khách gửi xe xong và… bước vào quán
  • Hoặc xe taxi/ grab car chở khách tới ngay trước sảnh.
• Khi nào quán sẵn sàng đón khách – Pre-Condition(s)
  • Khi đầu bếp báo đồ ăn đã sẵn sàng
  • Và phục vụ báo bàn ghế đã được dọn dẹp.
• Khi nào thì xem như khâu tiếp đón khách diễn ra thành công – Post-Condition(s)
  • Khi khách đã vô tới bàn của mình
  • Và quay sang cảm ơn hoặc cười với nhân viên (vì service khủng mà, nên điều này là bắt buộc)
• Các bước đón khách diễn ra như thế nào – Basic Flow
  Chào anh/ chị >> hỏi xem có đặt bàn trước chưa >> hỏi xem có bạn chưa >> hỏi đi mấy người >> dẫn vô đến tận bàn >> cảm ơn anh/ chị.
  (Về lý thuyết, anh em có thể mô tả rõ: tương tác giữa nhân viên và khách thế nào. Ví dụ nếu nhân viên hỏi mà khách trả lời A thì sao, trả lời B thì làm gì…. Phân tích chi tiết sẽ giúp anh em cover đủ được các trường hợp hơn nữa ở bước sau)
• Hoặc có cách nào khác đổi mới để đón khách ngầu lòi hơn hay không? – Alternative Flow
  Ví dụ:
  • Mô tả các bước đón khách từ xe taxi/ grab car khi xe dừng ở trước sảnh
  • Hoặc đổi mới cách đón khách: Nếu ngày lễ halloween thì khách vô sẽ cho kẹo, hoặc ngày valentine thì khách vô sẽ tặng sô cô la…
• Hoặc những thứ cấm kỵ nhân viên làm khi đón khách vào quán? – Exception Flow
  • Khi khách vào tới trước cửa quán mà nhân viên còn nói chuyện riêng >> failed
  • Khi hỏi khách mà không cười và nhìn khách >> failed
  • Khi dẫn khách vào mà trang phục lôi thôi, đầu tóc không đúng quy định >> failed.

Trên là ví dụ cho việc áp dụng Use Case để phân tích một thứ gì đó ngoài phạm vi phần mềm.

Khi phân tích ra chi tiết như vầy, mình sẽ có cái nhìn đầy đủ hơn để dễ dàng: training cho nhân viên, hoặc cải thiện các khâu chưa đạt, hoặc cũng có thể tối ưu lại nhân sự…..vâng vâng và mây mây.

Nếu anh em muốn phân tích gì đó thật kỹ lưỡng và chi tiết, hãy thử sử dụng kỹ thuật Use Case này. Nó sẽ giúp anh em nhìn được hầu hết mọi ngóc ngách của vấn đề. Để từ đó tính trước những việc cần làm nếu chẳng may gặp sự cố 🙂

3.2. UML/ BPMN

UML là Unified Modeling Language, còn BPMN là Business Process Model and Notation. Nôm na UML và BPMN sẽ giúp anh em chuyển thể quy trình và hàng tá thứ khác sang dạng hình vẽ.

Hay nói sang hơn, UML và BPMN là các kỹ thuật dùng để “mô hình hóa”.

Mô hình hóa cái gì? Mô hình hóa những thứ phức tạp, rối rắm như:

• Quy trình chẳng hạn (dùng BPMN, hoặc UML Activity Diagram)
• Hoặc để mô tả các bảng dữ liệu quan hệ với nhau ra sao (UML ERD)
• Hoặc để mô tả luồng tương tác giữa người dùng với hệ thống (UML Sequence Diagram)
• Hoặc mô tả luồng dữ liệu đi như thế nào (UML DFD)
• Và còn rất nhiều thứ phức tạp khác, mà anh em sẽ cần chuyển hóa nó thành hình vẽ để có thể “tiêu hóa” dễ dàng hơn.

Nói về UML/ BPMN thì sẽ có 2 thứ:

• Tools để vẽ
• Và cách vẽ.

Đa phần mọi người sẽ rất rành về các tools để vẽ, tools nào cũng biết, cũng đã từng xài. Nhưng để “vẽ không sai” và thể hiện đúng ý đồ thì không phải ai cũng làm được. Nó nằm ở cách vẽ.

Vẽ một diagram chuẩn là 5 người nhìn vào diagram, là cả 5 người cùng hiểu chung một ý. Chứ không phải mỗi người hiểu mỗi ý khác nhau. Nhưng thực tế thì anh em biết đó, thường sẽ là… mỗi người hiểu một ý khác nhau. Vụ này mình bị miết nên rành lắm.

Mấu chốt là diagram mình vẽ, nó còn có những cách đọc, cách nhìn khác nữa, mà mình “chưa nhìn ra”.  À háaaa, kiểu như bị hở chỗ này, hở chỗ kia.

Giống như hình mình vẽ theo cách hiểu A của mình, nhưng thực tế hình này còn có cách hiểu B, C, và thậm chí cách hiểu D nữa. Người khác nhìn vào, chẳng may họ không nhìn theo cách hiểu A của mình, mà lại đi hiểu theo cách B, C, D của họ là toang ngay.

Lúc đó, mô hình hóa không giúp cho vấn đề dễ tiêu hóa hơn, mà còn làm “tan chảy” độ nguyên bản của nó, làm “tam sao thất bản”, làm cho vấn đề trở nên rối rắm hơn khi mỗi người hiểu một ý.

Đó là lý do mà thế giới có các: bộ quy chuẩn để vẽ UML hay BPMN.

Tình huống nào thì dùng cái gì? Dùng diagram này thì có những ký hiệu chuẩn nào, quy tắc dùng ra sao, khi dùng thì chú ý điểm gì…..? Có những chuẩn này, anh em sẽ dễ dàng align cách diễn đạt và cách hiểu với nhau hơn.

Anh em đọc thêm seri mình viết về BPMN tại đây nhé.

Tóm gọn, kỹ thuật UML/ BPMN không chỉ là biết dùng tools để vẽ, mà phải vẽ sao cho đúng và thể hiện được trọn vẹn ý đồ của mình.

3.3. Data Modeling

Ở kỹ thuật này, chủ yếu anh em BA làm phần mềm sẽ dùng nhiều.

Vì Data Modeling sẽ giúp anh em đi sâu vào cách dữ liệu được lưu như thế nào dưới database của một giải pháp phần mềm. Rộng hơn một chút dưới góc nhìn của BA, Data Modeling sẽ giúp anh em nắm được:

• Những đối tượng nào được “ghi lại” dưới database, mức độ chi tiết của từng đối tượng?
• Quan hệ giữa các đối tượng ra sao => phần nào sẽ giúp anh em mường tượng được function liên quan đến những đối tượng đó
• Những business rules nằm sau các bảng dữ liệu là gì?

Data Modeling có thể được sử dụng để anh em tiếp cận vấn đề => phân tích xem thử có những đối tượng nào cần mổ xẻ >> lưu trữ >> phân tích. Hoặc cũng có thể là phương tiện để anh em catch up một system nào đó.

“BA giải quyết vấn đề”, giả sử nếu cần một giải pháp công nghệ để giải quyết một bài toán bất kỳ đi chẳng hạn.

Giả dụ: bạn mình đang gặp vấn đề trong việc quản lý hồ sơ ứng viên. Có một số “pain points” như sau:

• Trung bình một bộ hồ sơ có quá nhiều thông tin. Trong đó có những thông tin bắt buộc lẫn những thông tin không bắt buộc.
• Bộ hồ sơ có những “rules” liên quan ăn nhậu với nhau rất chặt chẽ, ví dụ:
  • Ứng viên nữ thì không quá 30 tuổi, ứng viên nam thì phải dưới 35
  • Ứng viên nữ cho bộ phận Admin thì tối thiểu phải IELTS 7.0, kinh nghiệm tối thiểu 4 năm, và chưa có gia đình
  • Ứng viên cho bộ phận Purchasing thì không được có kinh nghiệm làm ở các công ty: ABC và XYZ.
• Ngoài ra còn phải check trùng thông tin ứng viên theo một bộ thông tin định danh, bao gồm: Họ và tên, CMND, Giới tính và DOB.
• Và đặc biệt là: vì quản lý hồ sơ giấy nên mỗi lần check thông tin là mất cả buổi và rất dễ sai sót.

Nắm được một mớ pain points trên, chiếu qua lăng kính Biz Analyst, mình sẽ rõ được Business Objectives ở đây là phải có “một cái gì đó” giúp giải quyết gọn lẹ những yêu cầu trên.

“Một cái gì đó” ở đây sẽ là: Excel.

Đầu tiên mình sẽ xem bộ hồ sơ sẽ có những thông tin nào, tức bao gồm những đối tượng nào? Ví dụ có 5 đối tượng cần lưu trữ: Ứng viên, Kinh nghiệm làm việc, Học vấn, Sơ yếu lý lịch, và Lịch sử trao đổi.

5 đối tượng này sẽ tương đương với 5 sheets trong file excel.

Tiếp theo, 5 đối tượng này quan hệ với nhau như thế nào? Ví dụ ứng viên sẽ có nhiều kinh nghiệm làm việc, nhiều học vấn và nhiều lịch sử trao đổi công việc với nhau… Nếu quan hệ như vậy thì record giữa các sheet sẽ “link” với nhau như thế nào?

Chưa hết, mỗi thông tin trong bộ hồ sơ có quy định gì đặc biệt không, hay có dây mơ rễ má tới các thông tin khác như thế nào không? Mình sẽ liệt kê ra hết, thành một bộ validation rules cho từng dữ liệu.

Và sau cùng mình sẽ build một file Excel, sử dụng VBA để làm một cái form. Bạn mình sẽ nhập hồ sơ qua form, và validate thông tin ngay trên form nhập liệu này.

Kỹ thuật Data Modeling sẽ giúp anh em tóm gọn một mớ thứ rối rắm bên trên dưới góc nhìn data. Nó có thể thông qua Entity Relationship Diagram, Data Flow Diagram, hoặc Data Dictionaries.

Hoặc ở một ví dụ khác, khách hàng cần quản lý quy trình: Bước A >> Bước B >> Bước C >> Bước D.

Cơ bản anh em có 2 cách để thiết kế dữ liệu chỗ này:

• Cách 1: Làm 4 tables, tượng trưng cho 4 objects: A, B, C, D. 4 đối tượng này link với nhau (quan hệ với nhau) theo một rules nhất định.
• Cách 2: Chỉ cần 1 table, tượng trưng cho cả 4 objects: A, B, C, D. Và phân biệt từng chặng trong quy trình dựa vào 1 field status của table này. Status = A là đang ở bước A. Status = B là đang ở bước B, tượng tự cho C, và D.

Nếu requirement chỉ cần quản lý quy trình này thôi thì cả 2 cách đều ổn.

Nhưng nếu sau này khách hàng cần phân tích dữ liệu theo dạng Pipeline Chart thì có vẻ: cách 2 sẽ… khó hơn một tí so với cách 1. Vì rõ ràng, tổ chức dữ liệu như cách 1 sẽ tự nhiên hơn cách 2, nhưng lại tốn nhiều effort để thực hiện hơn cách 2.

Do đó, anh em cần phải hiểu và làm được Data Modeling để nhìn nhận những vấn đề tương tự như vầy.

Khi đã hiểu về data, hiểu về thứ nhỏ nhất xây nên một giải pháp phần mềm, hiểu về từng viên gạch nhỏ nhất để xây nên một ngôi nhà. Anh em mới có cơ hội làm đúng được khái niệm “phân tích và thiết kế” trong công việc BA của mình 🙂

3.4. Wireframe

Kỹ thuật cuối cùng là thiết kế Wireframe cho giao diện phần mềm. Cũng giống Data Modeling, kỹ thuật này áp dụng cho anh em IT BA là nhiều.

Nôm na thì Wireframe sẽ giúp anh em thể hiện được CẤU TRÚC và NHÓM THÔNG TIN có trên UI của phần mềm. Điều này giúp anh em truyền tải được yêu cầu người dùng đến Development Team, một cách chính xác và rõ ràng hơn bao giờ hết.

Vì kỹ thuật này cũng không quá đặc biệt. Và theo mình cũng không quá khó.

Với những thứ chưa biết, chưa rõ nó có thể chạy ra sao, behaviour như thế nào, anh em có thể xem thêm các framework hoặc các thư viện sẵn có về UI như Ant Design, hoặc Semantic-UI để tham khảo các components sẵn có của họ cũng rất hay.

Mình có note một bài về: Sketch – Wireframe – Mockup – Prototype ở đây. Anh xem thêm nhé.

4. Tạm kết

Nói về “kỹ thuật”, nhưng bài này không nói về lập trình, hay cách một application hoạt động.

Thực tế mình quan sát, đa phần những BA chính hiệu xung quanh mình thường ít khi quan tâm đến những thứ sâu xa về kỹ thuật, lập trình. Nếu có thì cũng đâu đó tìm hiểu thêm, chứ hiếm khi chủ động tìm hiểu vì phạm vi công việc.

Vì đơn giản, ai trong team cũng có vai trò riêng của mình.

Họ nhận thức rõ được phạm vi công việc của họ, họ không care (không thể và cũng không muốn care) đến những chuyện thuần về giải pháp kỹ thuật. Đó là nhiệm vụ nên làm và sẽ được làm tốt nhất bởi Solution Architect và các anh em Developer.

Nếu ai cũng rõ nhiệm vụ của mình, và tập trung hoàn thành tốt nhiệm vụ, sản phẩm làm ra sẽ trơn tru và hoàn thiện hơn rất nhiều.

Tuy vậy, mình không phủ định hoàn toàn chuyện kiến thức về lập trình có ảnh hưởng tích cực đến công việc của BA.

Như đầu bài, note này hy vọng sẽ giúp anh em đỡ lo lắng, và căng thẳng hơn khi nhắc đến 2 chữ “kỹ thuật” đối với BA. Thay vào đó, hãy cứ nắm vững 4 “kỹ thuật” trên là mình tin anh em có thể làm tốt được vai trò BA của mình trong bất kỳ công ty nào.

Hi vọng bài note này sẽ có ích với anh em. Tương tác và chia sẻ góc nhìn của anh em bên dưới nhé.

See yaaaa 😎 !!!

Bài viết gốc được đăng tải tại thinhnotes.com

Xem thêm:

• Để trở thành Data Analyst cần học gì? Học như thế nào?
• Top câu hỏi phỏng vấn vị trí Business Analyst mới nhất
• Chuyện nghề của một Data Analyst

Xem thêm công việc CNTT hấp dẫn trên TopDev