1. Lên kế hoạch và theo dõi tiến độ
Planning và Monitoring, đây là 2 kỹ năng không thể thiếu của một người làm Business Analyst. Đây là hai kỹ năng có ảnh hưởng trực tiếp đến các đầu mối công việc trong dự án.

Nhóm kiến thức về planning và monitoring được đưa lên đầu trong sơ đồ bởi vì tầm quan trọng và độ bao quát của nó.

Anh em cũng biết là planning thì không có sai hoặc đúng, mà chỉ là phù hợp hay không mà thôi. Phù hợp là đảm bảo được những resources hiện có và yêu cầu của dự án.

Resources là cả về nhân lực, vật lực và cả khả năng tiếp cận được công nghệ mới.

PM đưa ra plan cho dự án có sát với thực tế hay không, tùy thuộc rất nhiều vào kinh nghiệm của PM.

Một anh BA lên plan cho internal team cùng làm việc. Hay đơn thuần là những task công việc cho chính bản thân, cũng đòi hỏi phải tích lũy nhiều góc nhìn và trải nghiệm thì mới sát thực tế được.

Thường thì mình sẽ thấy thoải mái và có động lực làm việc hơn khi có mục tiêu rõ ràng.

Từ những mục tiêu nhỏ, đạt được nó, rồi đi tiếp đến một mục tiêu khác. Tiếp tục đạt được nó, rồi lại đi tiếp đến một mục tiêu khác. Đạt được nó, đạt được nó và mình sẽ đạt được mục đích đề ra ban đầu từ việc đạt được những mục tiêu nhỏ này.

Như vậy, mình có thể keep track được tiến độ công việc. Điều này mang lại sự chủ động trong công việc. Và dĩ nhiên, xuất phát điểm phải bắt đầu từ những việc nhỏ.

Điều này giúp mình bám sát kế hoạch và chủ động thay đổi nếu có phát sinh. Và đặc biệt là nó giúp mình luôn ở thế chủ động, không bị task đè.

Chỗ mình ngồi có 2 cái bảng nhỏ. Sáng lên công ty mình hay viết lên bảng 3-4 tasks mà mình muốn làm trong ngày. Ngồi làm là luôn nhìn thấy nó. Đập thẳng vào mặt nên auto nhớ, muốn quên cũng không được.

 
2. Moi móc và cấu kết với anh em
2.1. Moi móc thông tin – Elicitation
Elicit là động từ, danh từ là Elicitation, nghĩa là moi móc, đào bới.

Trong bối cảnh Business Analyst, elicit nghĩa là moi móc thông tin nhằm lấy được requirement. Dùng eilicit chính xác hơn so với get, hay gather.

Elicit là moi móc những thông tin từ khi nó còn “chưa tồn tại”, chưa được hình thành nữa. Thường là thông tin chưa có sẵn, chưa được phát biểu ra (unstated). Mình phải moi móc, phải elicit cho ra được thông tin, thành thông tin đã được phát biểu (stated).

Còn get hay gather thường chỉ dùng cho những thông tin đã có sẵn. Mình chỉ việc lấy về hoặc tập hợp lại thôi. Giống như đi hái hoa bắt bướm thì hoa với bướm có sẵn rồi, chỉ đi bắt, đi lụm về thôi. Còn requirement thì đâu dễ ăn như vậy.

2.2. Cấu kết với anh em – Collaboration
Collaboration, nghĩa là cộng tác, hợp tác, cấu kết với anh em cùng làm 1 cái gì đó, tốt cho dự án.

Không chỉ đơn thuần là teamwork, mà một người BA còn phải làm cho cả team cộng tác với mình và cộng tác với nhau một cách hiệu quả nhất.

Làm việc tốt với mọi người vẫn là chưa đủ. BA cần phải đảm bảo các thành viên khác làm việc trơn tru và hiểu ý nhau nữa.

Là một người nắm nhiều thông tin trong dự án, nên kết nối mọi người là “nghĩa vụ cao cả” của một người làm BA.

Nghe có vẻ không liên quan, nhưng anh em hãy thử hình dung như thế này nhé.

Một anh Tester và một anh Dev xích mích với nhau về một tính năng. Ai cũng có lý của mình hết. Lúc này người nắm nhiều thông tin nhất là BA, sẽ nhảy vào can thiệp để giải quyết vấn đề cho mọi người.

BA sẽ cố gắng giải thích theo góc độ lập trình và cả góc độ người dùng để hai bên thấy rõ được góc nhìn của nhau.

Tuy đây không phải là một trong những yêu cầu công việc của BA, nhưng BA nên có nhận thức về điều này. Nó như một trách nhiệm cơ bản (underlying responsibility) của BA.

Điều này sẽ giúp công việc của team trơn tru hơn.

Và dĩ nhiên, làm tốt thì sẽ rất là tốt, làm không khéo có thể gây ra những ảnh hưởng tiêu cực khác. Nên chủ đề của bài này vẫn mong anh em luôn chú trọng nâng cao kỹ năng và kiến thức của mình. Từ đó giúp giải quyết công việc một cách hiệu quả hơn 🙂

3. Quản lý requirements
Có bốn loại requirement trong một dự án:

- Business Objective Requirements
- Stakeholder Requirements
- Solution Requirements
- Transition Requirements

Việc quản lý dòng đời các requirements bắt đầu từ lúc khởi tạo cho đến khi các requirements được xử lý.

Thực tế thì requirement rất hay thay đổi hoặc thêm mới. Thay đổi lớn có, nhỏ có. Tùm lum tùm la hết. Và dĩ nhiên, nếu không kiểm soát tốt, nó sẽ là một mớ hỗn độn, phá nát dự án ở mọi khía cạnh (từ time, budget, scope cho đến resources).

Không phải lúc nào cũng gật đầu “accept” một requirement mới. Và không phải lúc nào cũng “reject” những requirement mới này.

Việc quản lý requirement như thế nào phụ thuộc rất nhiều vào việc dự án được triển khai theo phương pháp nào: Waterfall, RUP hay Agile.

Mỗi phương pháp đều có những đặc điểm riêng. Và requirements trong các phương pháp này cũng được quản lý rất khác biệt.

Thường thì trong dự án triển khai theo kiểu Waterfall hay RUP, requirements được chốt rất rõ ràng ngay từ đầu. Trong quá trình triển khai, sự thay đổi là có nhưng không đáng kể.

Còn Agile thì lại welcome to change. Mật độ thay đổi requirement trong những dự án này khá thường xuyên.

Nhưng quan trọng nhất, anh em BA cần phải học cách:

Hiểu được sự xuất hiện của các requirement.
Kiểm soát được các requirement từ lúc khởi tạo, có sự thay đổi cho tới khi được xử lý >> control được sự kỳ vòng từ phía users.

4. Hiểu về chiến lược của khách hàng
BABOK nó dùng từ Strategy Analysis, dịch trắng ra là “phân tích chiến lược”. Mình thấy dùng từ này nó đao to búa lớn quá, nên mình nghĩ một cách đơn giản: chỉ cần anh em hiểu về chiến lược của khách hàng, là đã đủ để phục vụ công việc của một người làm BA.

Hiểu về chiến lược của khách hàng là sao?

Khi làm giải pháp, rõ ràng anh em phải nắm được giải pháp đó làm ra, để giải quyết vấn đề gì. Và rồi mình mapping vấn đề đó với bối cảnh hiện tại của khách hàng, xem thử có suy ra được điều gì đáng chú ý hay không.

Từ đó, anh em mới có góc nhìn rộng nhất về tổng quan bài toán mà khách hàng đang gặp.

Ví dụ mình đang làm giải pháp CRM cho một doanh nghiệp F&B. Cái sâu sa họ muốn là gì, có phải chỉ đơn thuần là 1 giải pháp quản lý bán hàng? (trong khi thực tế là họ vẫn đang chạy một con local CRM rất ngon).

Thu gom nhiều yếu tố, mình có thể suy ra được: họ đang muốn chuyển đổi toàn bộ giải pháp IT của họ. Từ nhiều cục, họ muốn tất cả centralize lại thành một cục, một nền tảng, nhưng có nhiều giải pháp trong đó.

Họ vừa chuyển đổi thành công ERP sang nền tảng Microsoft, giờ tiếp theo sẽ là CRM, sau đó là e-Office, POS và kể cả toàn bộ cơ sở hạ tầng.

Đó chính là mong muốn sâu sa nhất của họ. Những giải pháp hiện tại chạy tốt, nhưng về cơ bản, nó đang không tập trung, và data vẫn đang nằm rải rác rất nhiều nơi. Và điều này không đáp ứng được hướng đi lâu dài của BOD (Board of Directors).

Khi hiểu được điều này, anh em sẽ có hướng tiếp cận khách hàng phù hợp hơn. Cách đề xuất và đánh giá giải pháp phù hợp hơn, so với việc, chỉ nghĩ một cách đơn giản cục bộ là họ chỉ đang cần một giải pháp về CRM.

Và một lần nữa, giải pháp mình đề xuất đáp ứng được nhu cầu hiện tại của khách hàng. Nhưng nó cũng phải map được với hướng đi lâu dài của họ trong tương lai.

5. Phân tích và thiết kế
Analysis and Design, chắc chắn ai làm Business Analyst cũng đều làm cái này.

Requirement Analysis and Design để đơn giản thì mình có thể hiểu là một loạt các việc bao gồm:

- Tổ chức và sắp xếp các requirement một cách có cấu trúc.
- Phân loại rõ các loại requirement.
- Verify requirement với internal team.
- Validate requirement với khách hàng.
- Làm tài liệu và mô hình hóa các requirement phù hợp với từng stakeholders cụ thể.
- Cùng với team đề xuất solutions phù hợp.
- Xác định những solution nào đáp ứng được business needs.
- Có thể là ước tính được những giá trị mà solution đó mang lại như thế nào so với các solution khác. Hoặc có thể show cho khách hàng thấy hoàn vốn đầu tư (Return On Investment) là như thế nào.

6. Đánh giá giải pháp
Cái này thì rõ ràng quá rồi chứ hả anh em.

Không thể nào đi thuyết phục khách hàng ăn một món ăn dở, mà ngay cả mình cũng ghét nữa. Mình phải đánh giá một cách rất khách quan và tâm huyết với giải pháp mình đem lại thì mình mới có thể cung cấp (deliver) một cách hoàn chỉnh nhất cho khách hàng được.

Như mình có nói ở trên, không chỉ hiệu quả trong thời điểm hiện tại mà còn phải phù hợp với hướng đi lâu dài của khách hàng.

Mình sẽ tạm kết bài này ở đây. Hi vọng qua bài này, anh em hiểu được: 6 Knowledge Areas của một người làm BA, tức nhóm kiến thức chuyên môn của một người làm BA. Nó bao gồm:

Business Analysis Planning and Monitoring – Lên kế hoạch và theo dõi tiến độ
Elicitation and Collaboration – Moi móc và cấu kết
Requirements Life Cycle Management – Quản lý requirements
Strategy Analysis – Hiểu chiến lược của khách hàng
Requirements Analysis and Design Definition – Phân tích và thiết kế
Solution Evaluation – Đánh giá giải pháp
Mỗi ngành nghề có những kiến thức chuyên môn nhất định, và BA cũng có nhóm kiến thức chuyên môn của riêng mình.

Hiểu và cố gắng áp dụng nó vào công việc và cuộc sống. Mình cũng đang cố gắng từng ngày, nhưng nhớ áp dụng một cách linh hoạt và đừng rập khuôn nhé!