Hello anh em. Bài này mình sẽ note lại những phương pháp moi móc thông tin của một người làm BA mà mình đã “thỉnh giáo” được từ các bậc tiền bối :3

Đầu tiên là cái hình dưới đây.

Các phương pháp moi móc thông tin

Elicitation là việc moi móc thông tin và khai thác thông tin từ khách hàng. Có “n” cách để làm việc này. Tuy nhiên, 11 cách sau đây là những cách thường được Business Analyst dùng nhiều nhất.

1. MEETING

Đầu tiên là phương pháp cực kỳ phổ biến. Có lẽ được dùng đến 96,69% trong các dự án. Thường thì meeting sẽ được chia thành 4 loại như sau:

1.1. Interview

Phỏng vấn 1-1 hoặc phỏng vấn theo nhóm. Nói phỏng vấn vậy cho formal chứ thực ra cũng là một buổi nói chuyện hay trao đổi công việc thôi. Đây là cách mình dùng rất nhiều. Không biết thì hỏi, đơn giản mà.

Tuy nhiên, hỏi sao cho khéo, cho đúng kịch bản mới hay. Làm interview thì dễ nhưng kỹ thuật để interview thì mới khó. Anh em có thể trao đổi với khách hàng qua email, skype hoặc gọi điện thoại.

Với mỗi cách, lại có một phương pháp khác nhau. Thậm chí, gọi điện hỏi người ta để làm rõ vấn đề. Nhưng đôi lúc gọi xong lại càng thấy rối hơn @@

1.2. Workshop

Thường thì người BA phải chuẩn bị rất kỹ và nhiều cho buổi workshop này. Buổi workshop sẽ có sự tham gia của các stakeholders. Và BA hoặc PM sẽ là MC buổi workshop này. Output của buổi workshop có đạt được đúng như kỳ vọng đề ra ban đầu không phụ thuộc rất nhiều vào sự chuẩn bị.

Thường thì người BA sẽ cho tổ chức một buổi pre-workshop trước đó tầm 3-4 ngày. Nhằm mục đích giới thiệu dự án và cung cấp các materials trước cho stakeholder. Để họ đỡ tốn thời gian ngâm cứu tài liệu khi buổi Workshop chính thức diễn ra.

Output của buổi workshop sẽ được BA tập hợp lại và được tiến hành phân tích theo bốn bước: Organize -> Specify -> Verify -> Validate (như trong bài Requirement được xử lý như thế nào? mình có chém).

Buổi workshop của Business Analyst

Cần phải phân biệt rõ, thế nào là Interview, thế nào là Workshop, thế nào là Brainstorm và thế nào là Focus Group?

1.3. Brainstorm

Thường thì mình dùng brainstorm khi cả team đang cần ideas cho một vấn đề nào đó. Anh em sẽ không phê phán hay reject bất cứ ideas nào hết. Và tất cả các ideas, dù củ chuối nhất cũng đều được welcome! Đó mới chính là brainstorm.

Cứ tưởng tượng xem, nếu brainstorm mà mình nói ý gì ra cũng bị chặt hết thì ai mà dám nói gì nữa. Hồi đại học mình hay họp hành câu lạc bộ này nọ cũng rất hay gặp tình trạng này.

Lúc vô thế, cần tìm ideas thì nhiều ca oái ăm lắm. Một ý tưởng củ chuối nhưng lại không hề củ chuối tí nào. Còn 1 ý tưởng “ngỡ” là ổn thì càng bàn càng củ chuối.

Quan trọng nhất là anh em phải ghi nhận lại hết. Một là để tạo tinh thần cho đồng đội mình ra tiếp ý tưởng. Hai là còn có cái để mà bàn.

Thường thì trường hợp cả đám ngồi dòm nhau là hay xảy ra nhất. Chứ không bắn ý tưởng đùng đùng như phim ảnh đâu. Nhưng nếu làm đúng, anh em hợp rơ nhau thì brainstorm lại rất phê.

1.4. Focus Group

Hình thức giống interview theo nhóm. Nhưng Focus Group thường tập trung chuyên sâu về 1 nhóm đối tượng hoặc 1 nhóm các vấn đề. Có thể là làm rõ các chức năng, ở từng bộ phận khác nhau.

Ví dụ cần trao đổi về chức năng tích hợp với 1 hệ thống ABC thì cần tổ chức một buổi Focus Group. Với thành phần tham dự là đội ngũ IT quản trị hệ thống của hệ thống ABC, chứ không cần phải các bộ phận khác.

Nhìn chung thì 4 phương pháp: Interview, Workshop, Brainstorm và Focus Group nhìn rất giống nhau, nhưng lại có 1 mục đích khác nhau:

  • Interview: 1-1 hoặc 1 với 1 nùi.
  • Workshop: truyền đạt thông tin cho một nhóm người cùng một lúc.
  • Brainstorm: khi cần tìm lời giải cho một bài toán.
  • Focus Group: trao đổi thông tin với 1 nhóm cụ thể.

2. DATA MINING, DATA MODELING

Trong bất cứ hệ thống nào thì thông tin là thứ rất quan trọng. Do đó ở cách này, nếu anh em hiểu được information của doanh nghiệp gồm những gì. Là đã một phần hiểu được cách thức hoạt động của doanh nghiệp rồi.

Data Flow Digram

Dùng sơ đồ DFD – Data Flow Diagram để thể hiện luồng thông tin của hệ thống.

Thường thì mình thấy phương pháp này được áp dụng trong các dự án maintain hệ thống cũ, upgrade hệ thống cũ. Hoặc thay thế một hệ thống đã lỗi thời mà doanh nghiệp đang sử dụng.

3. INTERFACE ANALYSIS

Ý tưởng cơ bản của cái này là hiểu được sự tương tác giữa người dùng với hệ thống. Hoặc giữa hệ thống với một hệ thống khác (tích hợp).

Hiểu và phân tích sự tương tác này, anh em sẽ hình dung được process mà doanh nghiệp đang áp dụng. Chí ít là hình dung mờ mờ về những process đó.

Thường thì mình thấy Functional Consultant hay dùng cách này lắm. Vào dọc hệ thống cũng có nhiều cái thú vị mà.

4. PROTOTYPING

Phương pháp prototyping (dịch ra tiếng Việt là tạo mẫu, là làm thử, là demo, abc, xyz…). Cái này mình cũng có chém trong bài Đồ nghề của Business Analyst luôn, là Critical Thinking. 

Nôm na là nói một cái gì đó tổng quan hay trừu tượng quá, khách hàng sẽ khó mà nắm bắt được. Do đó, nên nói cụ thể kết hợp demo hệ thống sẽ giúp người ta mường tượng rõ ràng hơn. Như cái này bấm vào sẽ ra gì, tới bước nào. Để hiện cái đó thì bấm cái gì, quy trình đi ra sao. Đó là khi chúng ta đã sử dụng phương pháp Prototyping.

Một số công cụ hỗ trợ việc thiết kế màn hình, chức năng để phục vụ việc Propotyping như: Axure, Microsoft Visio, Balsamiq Mockups. Cá nhân mình thấy thì:

  • Balsamiq Mockups: giao diện rất đẹp, nhưng hơi…”cartoon”. Vì nó mang tính phác thảo, “sketch” là chủ yếu nên như vậy. Dễ dùng. 100% là kéo thả.
  • Microsoft Visio: một tool huyền thoại cho anh em nào thích vẽ vời. Tool này mình thấy cũng ổn. Anh em dùng Visio để vẽ sơ đồ quen rồi thì chuyển qua vẽ màn hình giao diện cũng không khó lắm. Mà có cái là kho thư viện của Visio khá cũ và không nhiều. Cần update lên bản mới hoặc tải về thêm thì dùng mới đủ áp phê.
  • Axure: một tool powerful so với mấy cái trên. Ngoài những điểm mạnh của các tool trên, như: dễ dùng, kéo thả, chọn được nhiều library. Thì Axure còn có điểm mạnh là “động” được. Tức là Axure cho phép anh em tạo một màn hình với nhiều nút. Khi nhấn nút này thì nó sẽ ra màn hình nào tiếp, gồm những gì. Nhấn nút tiếp thì ra gì tiếp. Mọi thứ hiển thị y chang hệ thống thật. Điểm tuyệt vời nữa là Axure cho phép xuất file kết quả ra html. Điều này có nghĩa là anh em hoàn toàn đem file này chạy trên bất cứ máy nào mà không cần cài đặt Axure. Quá dữ!
Phần mềm Axure hỗ trợ thiết kế giao diện và chức năng hệ thống

Phần mềm Axure hỗ trợ thiết kế giao diện và chức năng hệ thống

Nguồn: lụm trên in-tờ-nét

Đơn giản phải không nào. Nhưng nhớ chỉ nên sử dụng phương pháp này đối với những requirement phức tạp và thật sự khó giải thích. Đòi hỏi độ chính xác cao cả về functional lẫn non-functional.

Nếu áp dụng prototyping một cách vô tội vạ thì cũng nguy hiểm. Vì nó sẽ cuốn khách hàng vào một mớ bồng bông và họ không biết mình đang ở đâu. Và sẽ rất cực cho BA để một lần nữa, hệ thống lại solution cho họ.

Phương pháp prototyping để moi móc thông tin

Mô phỏng màn hình có những gì, thứ tự sắp xếp ra sao, chọn cái này rồi đến cái gì.

Nguồn: cũng lụm trên in-tờ-nét

5. BUSINESS RULES ANALYST

Thường thì doanh nghiệp đều có các quy định riêng. Các quy định này sẽ giúp cho doanh nghiệp hoạt động trơn tru và hiệu quả hơn. Trong quá trình chuyển giao từ trạng thái as-is sang to-be, anh em cần phải bám theo những quy định và luật lệ này của doanh nghiệp.

Do đó, người BA cần phải define được các System Rules sẽ có trong hệ thống. Các System Rules này sẽ đảm bảo hệ thống tuân thủ được đúng các policies và rules của công ty hay không.

Phương pháp này nói đến việc tham khảo và phân tích các policies và rules của khách hàng. Đây là một trong những kênh vô cùng có giá trị với Business Analyst trong quá trình moi móc thông tin.

Thông tin sẽ được khai thác với độ chính xác cao. Vì những gì mình tham khảo đều đã được tài liệu hóa lại thành các quy định, luật lệ hết.

Nắm rõ được quy định và luật của công ty, chúng ta sẽ tránh khả năng làm sai. Làm sai là làm hệ thống hoạt động sai. Làm rõ ngay từ đầu – đỡ cực về sau! (y)

6. OBSERVATION

Quan sát. Là quan sát các End-Users làm công việc mà họ làm hằng ngày. Đối với phương pháp này, BA sẽ tiếp thu thông tin bằng mắt. Quan sát và chỉ quan sát.

Điều này có vẻ đơn giản nhưng không đơn giản chút nào, vì nhiều lý do sau:

6.1. Con người ta luôn có xu hướng hơi giả tạo và làm khác đi 

Thường thì bà con có vẻ làm khác đi một chút khi bị người khác tập trung quan sát. Do đó người BA cần phải có cách tiếp cận khéo léo, tránh thu hút sự tập trung của họ. Cũng như vẫn đảm bảo quan sát được toàn vẹn và đầy đủ nhất hành vi của End-Users.

Tránh tương tác trực tiếp. Anh em đừng nhiệt quá như là bay vô làm phụ người ta :)) Như vậy sẽ làm mất đi tinh thần “chân thật” của đối tượng :3

6.2. Tốn thời gian

Phương pháp này sẽ tốn rất nhiều thời gian là cái chắc rồi. Không chỉ quan sát trong 15-20 phút, đó có thể là quan sát cả một quy trình hay thậm chí có thể là cả một ca làm việc.

Và không chỉ quan sát đối với một End-User. Chúng ta cần sự so sánh hành vi giữa nhiều người khác nhau trong cùng vai trò, để output có được một cách chính xác và chân thật nhất.

6.3. Chính vì tốn thời gian, nên nó sẽ tốn luôn cả năng lượng để moi móc thông tin

Chắc chắn là anh em sẽ rất mệt. Có mấy lần mình qua công ty khách hàng ngồi cả ngày mà oải lắm. Ngồi support người ta, rồi quan sát người ta làm. Liệu solution của mình có map vào thực tế được hay chưa. Lâu lâu gặp trúng mấy case oái ăm cũng ớn lắm.

Nói chung là mệt chứ không ngon ăn gì đâu. Sau đó về còn phải tổng hợp, rồi hệ thống lại toàn bộ những gì quan sát được nữa.

Quan sát là một phương pháp không như trong mơ :v

7. BENCH MARKING

Bench là một cái bảng mẫu. Marking là đánh dấu, là cho điểm. Bench Marking cốt là phương pháp so sánh.

So sánh quy trình A với quy trình B, hệ thống A với hệ thống B, sản phẩm A với sản phẩm B, hay nói cách khác là solution A với solution B. Nắm rõ B, mình sẽ nắm gần rõ A. Và ngược lại. Hiểu rõ A, mình sẽ hiểu gần rõ B.

8. CÒN LẠI

Những phương pháp này chắc cũng quá quen thuộc với anh em rồi.

8.1. Mind Mapping

Mình cũng thích dùng mind mapping vì nó rất dễ tạo cảm hứng. Người ngoài nhìn vô thấy vẽ vời quá trời, nhìn cho nó nguy hiểm :))

Nhưng vẽ như thế nào cho hiệu quả thì mình vẫn đang… ngâm cứu.

8.2. Process Analysis and Modelling

Một trong những phương pháp truyền thống và cơ bản nhất. Cái này hồi đại học học quá trời, mà giờ chữ nghĩa chắc rớt gần hết.

Cái này thì ai cũng dùng, ai không dùng… cũng được :)) nhưng có vẻ hơi hiếm gặp. Thường thì modelling hay dùng các sơ đồ UML phổ biến như: ERD, Use Case, DFD, Activity Diagram, Workflow. Hoặc là dùng BPMN, vâng vâng và mây mây.

8.3. Survey

Nếu cần khai thác thông tin trên diện lớn và lấy ý kiến tập thể thì Survey là phương pháp phù hợp nhất. Nhưng vì trên diện lớn, nên chất lượng kết quả Survey có thể không đạt chất lượng cao lắm. Đòi hỏi sau giai đoạn khảo sát, anh em BA phải chịu khó ngồi lọc lại dữ liệu.

Hồi thực tập mình được join vào 1 dự án làm cho 1 công ty xăng dầu Việt Nam. Nó có tới hơn 2 nghìn điểm bán lẻ. Và mỗi điểm bán lẻ là cả mấy phiếu khảo sát.

Lúc khảo sát về thì không phải dữ liệu nào trên phiếu khảo sát cũng đúng cả. Lúc chạy số liệu dựa trên data thô thì thông tin ra tùm lum tùm la hết. Team mất gần cả tháng để xử lý mớ data này.

Dựa vào nhiều thông tin bên lề mới xác định được cái nào đúng hoàn toàn, cái nào tham khảo và cái nào là sai lệch. Rồi lúc đó mới dựa vào kết quả Survey mà đi tiếp được.

Xử lý số liệu sau khi thu thập.

Dữ liệu chắc chắn cần được xử lý sau khi thu thập. Và độ “cực nhọc” trong khâu xử lý sẽ nói lên được kinh nghiệm của người làm bảng câu hỏi 😀

Do đó làm Survey rất cần kinh nghiệm của các bật tiền bối trong việc build bảng câu hỏi. Bảng câu hỏi có 15 câu không có nghĩa là mình kỳ vọng 15 câu đó, người làm khảo sát sẽ trả lời đúng hết. Có những câu mình biết họ sẽ “né” hoặc sai số liệu. Nhưng hỏi sao cho họ dễ trả lời, tránh hỏi trực diện là cả một bầu trời nghệ thuật.

8.4. Document Analysis

Lại là một phương pháp truyền thống và cơ bản khác. Cái nào cũng truyền thống & cơ bản hết :)))

Nhưng để làm tốt phương pháp này, mình nghĩ anh em phải có kỹ năng đọc tốt và giữ mình không đi lạc vào mớ bòng bong của khách hàng. Đặc biệt là tài liệu của các doanh nghiệp nhà nước.

Cũng trong dự án làm cho công ty xăng dầu mình có kể ở trên. Công ty này có rất nhiều cửa hàng, đại lý nên việc tổ chức là không hề đơn giản tí nào. Kéo theo đó là bộ thập cẩm các quy trình cũng rất “màu mỡ” và “phong phú”.

Từ quy trình xuất kho, nhập kho, chuyển ca, sục bể, xả gió đến quy trình pha chế, tùm lum hết. Phải mất gần cả tháng team mới có thể hệ thống lại toàn bộ những quy trình này. Lúc đó tụi mình đọc rất nhiều tài liệu. Nhiều lúc đọc mấy tài liệu mà mặt ngu thấy rõ. Đó là lúc dùng phương pháp Document Analysis.

9. Các bước để tiến hành việc moi móc thông tin

Các bước để moi móc thông tin

Cũng không có gì ghê gớm lắm, đơn giản chỉ gồm:

9.1. Prepare 

Phải chuẩn bị thật tốt. Với mỗi phương pháp trên đều có cách chuẩn bị khác nhau. Chuẩn bị sao cho phù hợp và hiệu quả với từng phương pháp là cái mà mình nên hướng đến.

Chuẩn bị luôn là điều quan trọng nhất. FAIL PREPARE = PREPARE FAIL.

Fail prepare to prepare fail

9.2. Conduct 

Đầu tiên là luôn nắm rõ mình cần gì và mục tiêu của mình là gì. Đừng để rơi vào tình trạng: “tôi là ai và đây là đâu” thì oải lắm :v

Thứ hai là mỗi phương pháp đều có cách tiếp cận riêng. Chọn cách tiếp cận sai là coi như thua. Đúng phương pháp mà sai cách tiếp cận thì là tiêu chắc chắn. Cố gắng chú ý quan sát đối tượng rồi chọn cách tiếp cận phù hợp.

Và, cần phải tinh chỉnh cách tiếp cận sao cho phù hợp ngay cả TRƯỚC, TRONG VÀ SAU quá trình moi móc thông tin.

9.3. Document 

Ở bước này, BA có nhiệm vụ sắp xếp lại các tài liệu thu thập được. Vì dữ liệu thu thập được là vô cùng “thập cẩm”.

Có loại thì ghi note, có loại thì hình ảnh, có loại là video hay có loại là ghi âm. Tất cả đều rất lộn xộn và chưa được hệ thống hóa. BA cần phải sắp xếp mọi thứ lại cho ngăn nắp và gọn gàng để đi đến bước tiếp theo.

9.4. Confirm 

BA sẽ gửi những tài liệu này cho stakeholder để họ xác nhận: à, đây đúng là những gì mà chúng ta đã trao đổi”. Mục đích của bước này là đảm bảo thông tin mà chúng ta elicit thật sự chính xác. Và đảm bảo được sự đồng thuận giữa các stakeholder với nhau. Cái này quan trọng lắm anh em. Cái gì mà đã được confirm thì cũng đều phải document lại hết. Tránh trường hợp khách hàng “lật bàn tay” sau này :))

That’s all. Chém gió dài quá rồi. Bài này mình viết ra những gì mình được học và tìm hiểu để khỏi quên. Mai mốt có cái đọc lại, rồi tìm cách áp dụng dần dần.

Cảm ơn anh em đã đọc tới đây 🙂

Nguyen Hoang Phu Thinh

Hello anh em! Mình là Thịnh, hiện tại mình đang làm Business Analyst tại RBVH. Mình đang tập viết, tập đọc sách và góp nhặt những trải nghiệm trong nghề BA trên blog này. Hi vọng những chia sẻ của mình sẽ giúp ích được anh em 🙂 Read more about me