Source: https://www.facebook.com/groups/itbapovn
Có nhiều bạn từng nhắn tin hỏi minh về công việc cụ thể của 1 IT BA trong dư án thực tế từ lúc băt đầu đến lúc kết thúc sẽ bao gồm những bước nào và cách làm ra sao.
Thật sự câu hỏi này rất là hay vì không có sách vở hay khóa học online nào có thể nói rõ cái này cho bạn để khi học xong bạn có thể bắt tay vào làm ngay trong dự án.
Minh cũng may mắn được trải qua nhiều dự án ở nhiều lĩnh vực khác nhau và ở môi trường Outsourcing và Product ở Vietnam lẫn nước ngoài (Singapore & UK). Mãi đến khi minh sang Singapore làm được 2 dự án cực to từ đầu đến khi Go-Live thì mình mới có thể đút kết lại được 17 bước mà BA thường làm trong dự án.
17 Bước này là minh đút kết dựa trên kinh nghiệm cá nhân, nên nó sẽ không có đúng hoặc sai mà chỉ mang tính chất tham khảo. Mình hi vọng các bạn hiểu được phần nào về công việc cụ thể của 1 IT BA trong dự án là gì.
Bước 1: Assess Needs & Current State (Đánh giá nhu cầu và hiện trạng)
Tìm hiểu nhu cầu (Needs) và phân tích hiện trạng (Current State or AS IS Analysis) là khởi nguồn của mọi thứ trước khi bạn bắt đầu hỏi sâu và phân tích yêu cầu của khách hàng. Việc này giúp chúng ta trả lời cho câu hỏi mà ai cũng sẽ hỏi trong dự án “Why the change is needed” hoặc “What are key drivers for change”.
Mình luôn làm việc này ở thời điểm bắt đầu dự án và chỉ làm 1 lần. Xây dựng hệ thống cũng giống như xây nhà, trước khi nói về căn nhà mới thì bạn phải hiểu rõ nhu cầu và hiện trạng căn nhà / mãnh đất đó như thế nào, đập hết đi xây lại hay là sửa 1 phần.
Việc không hiểu được hiện trang thì sẽ gây ra nhiều hệ lụy về sau:
- (1) Tại sao hệ thống mới này không có chức năng ABC giống như trong hệ thống cũ XYZ vậy em?
- (2) Sao hệ thống mới không có trường dữ liệu này vậy em?
- (3) Sao hệ thống mới không ngon như hệ thống cũ?
- …
Các kỹ thuật mình thường làm để phân tích hiện trạng:
- (1) Current Systems (Đánh giá hệ thống hiện tại)
- (2) Current Business Process (Đánh giá quy trình hiện tai)
- (3) Current Business Rules (Đánh giá các quy định luật lệ trong doanh nghiệp)
- (4) Current Business Data (Đánh giá dữ liệu)
- (5) Glossary (Hiểu thuật ngữ chuyên ngành).
Minh sẽ có bài riêng để nói cụ thể cách làm và các deliverables (thành phẩm) của BA.
Bước 2: Plan BA Work and Approach (Lập kế hoạch công việc BA và cách tiếp cận)
Trước khi bắt tay vào chi tiết thì BA phải lập kế hoạch để viết ra những đầu việc chính và thứ tự ưu tiên. Việc lập kế hoạch này thường sẽ do Senior BA / Lead BA trở lên làm. Để lập kế hoạch BA (BA Plan) thì bạn phải biết được những thứ sau và BA Plan sẽ được lồng vào Project Plan do Project Manager làm:
- (1) BA Resource Plan (Nguồn lực BA)
- (2) BA Deliverables (Những tài liệu và thành phẩm mà BA phải làm trong dự án)
- (3) Software Methodologies (Việc triển khai dự án theo mô hình Agile / Scrum hay Waterfall sẽ có những đầu việc và thứ tự khác nhau cho BA)
- (4) Scope of Work (Phạm vi dự án, thường minh sẽ chia ra Modules)
- (5) Estimation (dự toán – sau khi đã có đầu việc chính của BA, thường là các đầu việc như: Run workshops, Wireframes, Documentation…)
Việc lập kế hoạch này để xác định hướng đi cho phù hợp, và bạn nên nhớ rằng không cần phải quá chi tiết và cứng ngắt vì plan luôn luôn thay đổi trong quá trình làm dự án.
Mình sẽ có bài riêng để nói cụ thể về cách làm.
Bước 3: Identify & Evaluate Stakeholders (Xác định và đánh giá các bên liên đới)
Bước kế tiếp là cần xác định các bên liên đới (stakeholders) để cùng chinh chiến với minh trong suốt quá trình dự án. Có những stakeholders bạn chỉ gặp 1 vài lần, nhưng có những stakeholders mà ngày nào cũng gặp, nhìn nhau riết mà chán luôn 
.
(1) Sponsor (chủ chi): ông này chắc hiếm gặp, nếu gặp được ổng chắc lúc bắt đầu và kết thúc dự án.
**(2) Implementation Subject Matter Experts (SME):**đây là nhóm triển khai dự án, thường là nhóm làm việc chung hằng ngày bao gồm: Solution Architect, Technical Architect, Tech Lead, Developers, UX UI Designer…
(3) Tester (Người kiểm thử): người này đám bảo đầu ra của phầm mềm phải đạt được chất lượng nhất đinh và đúng theo bản thiết kế.
(4) Project Manager / Scrum Master: người quản lý để đảm bảo sự thành công cho dự án.
**(5) Operational Support (Business As Usual):**đúng với tên gọi BAU là giữ cho business as usual (ổn định). Thường sau khi mình triển khai hệ thống thành công (go-live) và bàn giao sang đội IT Operation để chuyển sang giai đoạn Warranty (Bảo dưỡng). Sau này có bất cứ vấn đề về vận hành hệ thống sẽ do đội ngũ này trực tiếp hỗ trợ end-users / customers chứ không phải do đội ngũ triển khai. Mình chỉ gặp BAU 1 vài lần trong dự án và khá nhiều ở cuối dự án để bàn giao.
(6) Customers: khách hàng là người dùng dịch vụ hay sản phẩm của mình nhưng ko nhất thiết tương tác với phần mềm minh tạo ra. Ví dụ bạn ra ngoài ngân hàng tạo tài khoản ngân hàng thì customers là người sử dụng dịch vụ ngân hàng còn bankers (bank teller) chính là End-User tương tác với máy tính để thao tác nhập liệu tạo tài khoản ngân hàng cho bạn.
(7) End Users (người dùng cuối): người sẽ tương tác với hệ thống. Sau này các bạn làm UAT (User Acceptance Testing) chủ yếu là làm với Key Users & End Users. Train cho các bạn này xài hệ thống.
( Domain SME (Chuyên gia nghiệp vụ): Vị trí này rất ít khi gặp trong dự án, thường thì đối với nghiệp vụ cực kỳ phức tạp thì mới cần 1 Domain SME để giải thích về nghiệp vụ. Domain SME có thể là người trong công ty (internal) hoặc thuê ngoài (external consultant). Ngoài ra, thường sẽ có 1 bạn Product Owner có nghiệp vụ về business làm cùng BA. Nếu dự án mà có 1 PO ngon thì rất may cho bạn vị họ sẽ làm cầu nói cho bạn với các business users khác về domain, còn dự án không có PO thì BA sẽ phải đi găp từng business users để hiểu sâu về business domain.
(9) Vendors / Suppliers (nhà cung cấp): trong 1 dự án to và đặc biệt bạn là BA trong 1 công ty outsourcing bán dịch vụ cho khách hàng. Thì 1 dự án to có thể chia ra cho nhiều vendors khác làm cùng.
(10) Regulator: minh chưa bao giờ gặp ông này.
Bước 4: Conduct Facilitated Workshops (Chạy Workshops để khơi gợi yêu cầu):
Sau khi bạn đã biết được ai là stakeholders thì bước kế tiếp là găp gỡ và nói chuyện với họ để tìm ra những yêu cầu (business / stakeholder requirements) cho phần mềm mà mình sắp xây dựng.
Là 1 BA thi bạn phải có chuyên môn để khơi gợi yêu câu (elict requirements) và hầu hết mình đều chạy workshop để thuyết trình với sự tham gia của stakeholders để cùng nhau đưa ra ý tường, yêu cầu và cũng như chốt xem cần phải xây dựng cái gì cho phần mềm. Kỹ năng chạy workshop là kỹ năng khó nhất của BA mà bạn cần phải làm được, nó quyết định độ Senority / Maturity của bạn.
Bước 5: Recap and Summarize MoM & Follow-up Actions (Viết MoM để chốt lại yêu cầu)
Sau khi đã workshop xong thì bạn phải ghi lại Meeting of Minutes (MoM) để chốt lại những gì đã thảo luận làm tiền đề tiếp tục phân tích, thiết kế và viết tài liệu. Đồng thời việc này rút minh rất nhiều trong việc
(1) Tránh hiểu sai hoặc hiểu nhầm (nhiều khi stakeholders nói rồi có thể quên rồi lật lộng
(2) Những stakeholders ko tham workshops cũng có thể biết được đã thảo luận cái gì
(3) Đưa ra những actions cần phải làm kế tiếp.
Bước 6: Perform Analysis & Modelling (Phân tích và mô hình hóa yêu cầu)
Có rất nhiều kỹ thuật mà bạn có thể dùng để phân tích và mô hìn hóa yêu cầu. Là 1 BA, sau khi bạn đã ghi chú (dạng note) về yêu cầu thì bạn cần phải chuyển hóa những ghi chú đó thành hình ảnh và biểu đồ (diagrams) nhằm
(1) Tìm ra missing / contradicting requirements (Yêu cầu bị thiếu hoăc không đủ hoặc logic câu trước đá câu sau)
(2) Giải thích 1 vấn đề cho stakeholders cũng dễ hơn rất nhiều (A picture is worth a thousand words)
(3) Viết chữ thì mỗi người hiểu 1 ý khác nhau, nhưng hình thì ít bị hiểu nhầm
Các kỹ thuât minh thường làm là:
- (1) Scope Analysis & Modelling
- (2) Process Analysis & Modelling
- (3) Data Analysis & Modelling
- (4) Rule Analysis & Modelling
- (5) Interface Analysis & Modelling
Bước 7: Use SQL to perform Data Analysis (Sử dung SQL để truy vấn và phân tích dữ liệu)
SQL (Structured Query Language) là ngôn ngữ để truy vấn dữ liệu từ Cơ Sở Dữ Liệu (CSDL – Database). BA nào cũng nên biết SQL để biết cách truy vấn để giúp cho việc phân tích dữ liệu. Cài này không cần phải biết code thì mới viết được đâu, nó cực kỳ dễ bạn nhé. Lên Udemy, PluralSight or Linkedin học 1 course tầm vài tiếng là xong.
Ví dụ mình thường truy vấn vào CSDL kiểm tra bảng dữ liệu Customer có những trường nào (First Name, Last Name, DOB, Email, Phone Number…) và thuộc tính ra sao rồi xây dựng lại trên Data Dictionary rồi mang đi xác nhận lại với stakeholders. Nó sẽ nhanh và hiệu quả hơn rất nhiều là bạn đi hỏi Stakeholers.
Cao cấp hơn thì mình dùng SQL để phân tích 1 số KPIs của hệ thống đang đo lường như là Conversion Rate, Open Rate, New / Existing Customers Ratio để quyết định độ ưu tiên của tính năng và lộ trình sản phẩm (roadmap).
Bước 8: Build Data Model & Data Dictionary (Xây dựng mô hình dữ liệu và đặc tả dữ liệu)
Sau khi đã hiểu được mối quan hệ dữ liệu và đăc tả dữ liệu của hệ thống cũ thì mình tiếp tục xây dựng lại Conceptual Data Model (Mô hình dữ liệu dạng khái niệm) và Data Dictionary cho hệ thống mới. Với ví dụ ở bước số 8, Customers có các trường First Name, Last Name, DOB, Email, Phone Number và công thêm 1 số trường mà stakeholders muốn thêm trong hệ thống mới này: Nickname, Occupation, Gender, Salutation –> Kết hợp lại bạn có những trường sau cho hệ thống mới: First Name, Last Name, DOB, Email, Phone Number, Nickname, Occupation, Gender, Salutation. Và sau đó lại tiếp tuc đặc tả thuộc tính dạng Business cho chúng (Single Line of Text, Lookup, Required? Rule?).
Để làm tốt được bước này bạn phải biết cách phân biệt được giữa Business Data vs. Technical Data
Business data xuất phát từ yêu cầu (requirements) còn Technical Data được sinh ra trong quá trình thiết kế về mặt hệ thống.
Bước này cưc kỳ quan trong để chuẩn bị vẽ wireframes nhé. Vì bạn phải biết Customers phải có trường dữ liêu nào để còn thiết kế lên trên UI (User Interface – màn hinh) cho phù hợp.
Bước 9: Draw wireframes & prepare prototypes (Vẽ giao diện mô phỏng phần mềm và bản chạy thử)
Kế tiếp bạn phải vẽ lên được phần mềm từng màn hình và kế nối lại thành 1 flow hoàn chỉnh (prototype). Để mà vẽ được thì BA cần có
(1) Tư duy về UI UX (Web, Mobile, Responsive)
(2) Kỹ năng vẽ bằng Tool (Balsamiq, Axure, FIGMA…)
Minh khuyên là nên Master 1 tool hơn là tool nào cũng biết mà biết không tới nơi. Ngày trước mình vẽ Wireframes trong lúc vừa workshops với stakeholders ngay trong phòng họp luôn. Nói đến đâu là vẽ đến đó luôn mà level họ là C Level, Director, Head Of. Bạn phải vẽ nhanh và chuẩn xác để có thể chốt luôn trong phòng họp.
Minh recommend là xài Balsamiq (Balsamiq Version 3) vì tool này vẽ cực nhanh và hiệu quả cho BA.
Bước 10: Demonstrate Wireframes to validate requirements (Trình bày bản wireframes hay prototypes để kiểm tra yêu cầu)
Vẽ xong thì phải mang đi demo cho stakeholders xem liệu phần mềm mình vẽ ra vậy đã đáp ừng được yêu cầu họ đưa ra trên bước 4 hay chưa. Rất nhiều khác biệt xảy ra khi stakeholders nhìn thấy bản vẻ và vỡ òa “đây là thứ tôi muốn ư?”. Và đây là cách BA dùng để validate (kiểm tra) thật sự những gì khách hàng diễn tả (requirement) và những gì họ mong muốn có giống nhau hay ko?
Bước 11: Viết tài liệu yêu cầu thông qua SRS, Use cases hoặc User Stories
Sau khi đã chốt đươc hòm hòm Wireframes thì bạn nên chuẩn bị viết tài liệu đặc tả yêu cầu. Có rất nhiều tài liệu mà BA có thể viết và tùy vào dự án và mô hình chạy dự án (Software Methodologies)
Đối với Waterfall (Dự án thác đổ): thương BA sẽ viết Use Case và Software Requirement Specification (SRS). Tài liệu này cực kỳ chi tiết và rất mất thời gian để viết và cập nhật lại khi có thay đổi, vì nó được xem giống như contract (hợp đồng). Khi mâu thuẫn xảy ra thì thường người ta sẽ lôi SRS đã để đối chiếu và quyết định xem là bug (lỗi) hay là new features (chức năng mới). Bug thì minh chịu, new features thì lại được thêm tiền.
Đối với Agile Scrum (cuốn chiếu): ngày nay hầu hết dự án theo mô hình Agile / Scrum và công việc viết tài liệu của BA không còn vất vả như Waterfall. Thường BA sẽ dùng User Stories để viết trên các tool như JIRA, Confluence.
Bước 12: Demonstrate Progressively-built Software (Trình bày phần mềm đã xây dựng 1 phần)
Giống như bước 10, thì bước này chỉ khác là bạn demo trên hệ thống thiệt và có 1 ít dữ liệu. Bước 10 chỉ là hình ảnh liên kết với nhau thì 1 cái flow thôi. Còn bước này là hệ thống bằng da bằng thị sờ vào biêt nhanh hay châm, mượt mà thơm thơ hay không.
Đối với bước này thì mình luôn demo mỗi 2 – 4 tuần 1 lần hoặc khi xong 1 chức năng quan trọng nào đấy và luôn có MoM để chốt lại sau buổi demo:
- (1) Review lại với toàn team xem có nó hoạt động có đúng ý mình không? (Từ thiết kế đến triển khai có rất nhiều khoản cách bạn nhé)
- (2) Khách hàng có feedback gi để còn kịp thay đổi tránh về sau thay đổi thì sửa lại rất là rủi ro và vất vả
Minh từng gặp nhiều khách hàng hay thay đổi yêu cầu đến phút cuối rồi đổ lỗi cho BA không hiểu yêu cầu của họ. Với bước này là chốt chặn thì mình có thể handle những khách hàng khó tính này và minh đã nói với họ rằng “Tôi đã demo chức năng này 3 lần rồi, nếu như anh có feedback tại sao anh không la lên từ đầu “I have demonstrated this feature for 3 times, why you didn’t share any feedback or concern?”) và khách hàng chỉ có im lặng thôi. Nhiều khi phải cứng rắng và chuyên nghiệp bạn nhé chứ đừng đánh khách hàng.
Bước 13: Support System Integration Testing (Hỗ trợ kiểm tra tích hợp phần mềm)
Chắc chắn là hệ thống của bạn không thể nào hoạt động riêng lẻ 1 minh được mà thường sẽ phải tích hợp (integrate) với nhiều hệ thống khac nhau nữa.
Ví dụ nhự bạn xây dựng hệ thống bán hàng (Sales) để cho phép khách hàng nhập đơn hàng, khi thanh toán chốt đơn hàng thì lúc này hệ thống Sales sẽ tích hợp với hệ thống Kế Toán (Accounting System) để ghi nhận giao dịch về mặt kế toán. Dựa trên xác nhận giao dịch từ hệ thống kế toán thì bước kế tiếp bên giao hàng sẽ đi giao cho khách. Rõ ràng phạm vi công việc của BA đang làm là thiết kế cho hệ thống Sales và tích hợp với hệ thống kế toán.
Khi đến giao đoạn System Integration Testing (SIT) thì công việc chính của BA là hỗ trợ đội ngũ Testing về việc tư vấn và trả lời các câu hỏi liên quan đến tích hơp xem dữ liệu và tính huống đã đúng theo yêu cầu hay chưa. Và trong lúc SIT sẽ có rất nhiều trường hợp hy hữu mà Tester họ nghĩ ra (Edge Cases) mà BA phải trả lời xem có cần test hay không?
Bước 14: Conduct End-User Training (Đào tạo người dùng)
Sau khi hệ thống đã tích hợp thành công thì bước kế tiếp là chuẩn bị đưa vào sử dụng thực tế và cho phép người dùng xài thử nghiệm để kiểm tra về tính năng cũng như là tính dễ sử dung (Usability Testing). Để mà người Key / End Users có thể xài đươc thì bạn phải có 1 vài buổi đào tạo sâu về hệ thống bao gồm 4 bước chính: UAT Briefing, UAT Training, UAT Testing, UAT Closure.
Thường mình sẽ đi theo luồng đầu cuối (end-to-end flow) để cho người dùng dễ năm bắt sau đó sẽ chọn ra 1 vài trường hợp rẽ nhánh (alternative) hoăc exceptions (ngoại lệ) thêm vào.
Ví dụ: các bước từ lúc bắt đầu đặt hàng đến giao hàng gồm các bước sau:
(1) Khách hàng chọn mặt hàng
(2) Khách hàng đặt hàng
(3) Khách hàng thanh toán đơn hàng (trả trước)
(4) Kế toán xác nhân
(5) Kho xuất hàng
(6) Lấy hàng đi giao
(7) Khách hàng nhận hàng và ký biên nhận
Bước 15: Support User Acceptance Testing
Đây là bước thứ 3 trong UAT (UAT Testing), với vai trò là BA thì công việc của bạn càng về sau không nhiều mà chỉ là hỗ trợ người dùng hiểu và xài được hệ thống. Với bộ Test Cases cho UAT do Test Lead họ làm ra thì có thể cho End-Users dùng để chay theo và báo cáo kết quả test.
Trong giai đoạn UAT này sẽ phát sinh ra rất nhiều bugs & new requirements (thay đổi yêu cầu), vì lúc này End-Users họ thật sự mới sờ được hệ thống và băt đầu có những trải nghiệm khác so với những gì họ nghĩ –> lại ra 1 danh sách chức năng mới mà cần phải làm trước hoặc sau khi Go-Live.
Bước 16: Data Migration
Nếu như trước đó mà khách hàng đã có hệ thống rồi và đã vận hanh với dữ liệu có sẵn, thì khi bạn xây dựng hệ thống mới lên thì câu hỏi là vậy dữ liệu trên hệ thống cũ sẽ xử lý như thế nào?. Câu trả lời tất nhiên là đưa sang hệ thống mới rồi.
Nghe thì có vẻ đơn giản như để đưa được dữ liệu từ hệ thống cũ sang hệ thống mới thì cần 1 bước chuyển đổi dữ liệu “Data Transformation”. Khác biệt cấu trúc dữ liệu hệ thống cũ và mới khác nhau dẫn đến việc chuyển đổi dữ liệu cực kỳ phức tạp và mất nhiều thời gian. Ngày trước minh phải chuẩn bị rất kỹ cho bước Data Migration này trong vòng 6 tháng cho 1 dự án 1 năm.
Và đến ngày chạy thực tế minh đã thức 3 ngày 2 đêm để đưa toàn bộ dữ liệu từ hệ thống cũ sang hệ thống mới. Nếu không có bước này thì sẽ không thể nào Go-Live được. (Nếu làm product mới hoặc trước đó khách hàng không có hệ thống cũ thì chúc mừng bạn, đỡ đi 1 cơn ác mộng mang tên Data Migration).
Bước 17: Go-Live
Bước này thi chắc chắn là bước mà ai cũng mong đợi. Đi làm phầm mền vui nhất là ngày Go-live vì các anh em trong nhóm ai cũng mệt lừ chinh chiến cùng nhau trong thời gian dài, những buổi họp hành thâu đêm. Sau khi đã UAT, Data Migration thành công thì chỉ cần thông báo Go-Live và bàn giao hệ thống cho đội BAU của khách hàng là xong. Và thương sau Go-Live sẽ có 1 giai đoạn gọi là Hypercare (tầm 2 tuần đến vài tháng) để tập trung sửa bug nếu có trong quá trình vận hành hệ thống trong vài tháng đầu đến khi nó thật sự đã vào guồng ổn định.
