IBA Academy

"🧱 Work Breakdown Structure (WBS) – Chuẩn hóa cách phạm vi công việc được cấu trúc và kiểm soát...

💻 Trong các dự án CNTT, phân tích nghiệp vụ không phải là một tập hợp các hoạt động rời rạc như “đi họp – ghi nhận – viết tài liệu”.

🤷‍♂️ Thực chất, BA đang chịu trách nhiệm cho một phạm vi công việc độc lập, với đầu ra rõ ràng, phụ thuộc lẫn nhau và tác động trực tiếp đến thành công của giải pháp.

👉 Để quản lý được phạm vi đó một cách có hệ thống, chúng ta có thể dùng đến Work Breakdown Structure (WBS).

🌷 WBS là gì?

Work Breakdown Structure (WBS) là cấu trúc phân rã công việc theo dạng phân cấp, dùng để chia phạm vi tổng thể của dự án thành các thành phần nhỏ hơn, có thể quản lý được, và đặc biệt tập trung vào deliverable – những đầu ra cần được tạo ra.

Ở cấp độ học thuật, WBS có ba đặc trưng cốt lõi:

🍁 Hierarchical Decomposition – Phân rã từ tổng thể xuống chi tiết
🍁 Deliverable-oriented – Lấy kết quả đầu ra làm trung tâm, không chỉ là hành động
🍁 Clear Completion Criteria – Mỗi thành phần đều có ranh giới hoàn thành rõ ràng

👉 WBS không trả lời “làm như thế nào”, mà trả lời “cần tạo ra những gì để phạm vi được xem là hoàn tất”.

🌷 WBS trong phân tích nghiệp vụ được hiểu như thế nào?

Khi áp dụng vào hoạt động business analysis, WBS giúp biến một khái niệm trừu tượng như “phân tích nghiệp vụ” thành một cấu trúc công việc cụ thể, có thể lập kế hoạch, ước lượng và kiểm soát.

Thay vì nói chung chung “BA sẽ thu thập và phân tích yêu cầu”, WBS làm rõ:

⚡️ Phân tích nghiệp vụ sẽ bao gồm những giai đoạn nào
⚡️ Mỗi giai đoạn tạo ra những deliverable gì
⚡️ Mỗi deliverable được hình thành từ những work package cụ thể nào

👉 Nhờ đó, phạm vi BA không còn phụ thuộc vào cảm nhận hay kinh nghiệm cá nhân, mà được chuẩn hóa dưới dạng cấu trúc công việc rõ ràng.

🌷 Ví dụ WBS cho hoạt động Business Analysis

Một WBS điển hình cho hoạt động phân tích nghiệp vụ có thể được tổ chức như sau:

1.0 Business Analysis Planning
1.1 Xác định stakeholder và vai trò
1.2 Định nghĩa phương pháp và cách tiếp cận BA
1.3 Xây dựng Business Analysis Plan

2.0 Elicitation & Collaboration
2.1 Phỏng vấn stakeholder
2.2 Tổ chức workshop / focus group
2.3 Thu thập yêu cầu qua survey, questionnaire

3.0 Requirements Management & Analysis
3.1 Tài liệu hóa yêu cầu chức năng
3.2 Tài liệu hóa yêu cầu phi chức năng
3.3 Mô hình hóa quy trình, flow, nghiệp vụ
3.4 Xây dựng user story / use case

4.0 Validation & Sign-off
4.1 Review yêu cầu nội bộ
4.2 Tổ chức họp xác nhận yêu cầu
4.3 Thiết lập traceability

5.0 Solution Evaluation (Post-Implementation)
5.1 Đánh giá hiệu quả giải pháp
5.2 Phân tích gap so với kỳ vọng ban đầu
5.3 Đề xuất cải tiến

👉 Điểm quan trọng:
WBS không mô tả BA “bận rộn thế nào”, mà mô tả giá trị phân tích nào cần được tạo ra trong suốt vòng đời dự án.

🌷 WBS mang lại giá trị gì cho Business Analyst?

Khi được xây dựng đúng, WBS giúp:

✨ Làm rõ phạm vi BA – tránh tình trạng “việc này có phải của BA không?”
✨ Hỗ trợ ước lượng effort – từ đó lập kế hoạch và phân bổ nguồn lực chính xác hơn
✨ Chuẩn hóa deliverable – giúp team hiểu thống nhất về đầu ra mong đợi
✨ Tăng khả năng kiểm soát thay đổi – vì mọi thay đổi đều tác động lên một phần cụ thể của WBS

👉 Với BA, WBS không phải là gánh nặng tài liệu, mà là khung tư duy để quản lý công việc phân tích một cách chuyên nghiệp.

🌷 Giới hạn của WBS

Dù mang lại nhiều lợi ích, WBS cũng có những giới hạn cần nhận thức rõ:

⚠️ Nếu xây dựng quá chi tiết, WBS có thể trở nên cứng nhắc
⚠️ WBS không phản ánh trình tự hay kỹ thuật thực hiện
⚠️ Cần kết hợp với các artefact khác như roadmap, backlog, hay requirement model

👉 Vì vậy, WBS nên được xem là bản đồ phạm vi công việc, không phải kịch bản triển khai chi tiết.

🌷 Cuối cùng

👨‍💼 WBS không đơn thuần là một công cụ chia nhỏ công việc, mà là cách dự án chuyển hóa sự phức tạp thành cấu trúc có thể quản lý.
Trong hoạt động phân tích nghiệp vụ, WBS giúp kết nối mục tiêu kinh doanh với từng đầu việc cụ thể, làm rõ ai làm gì, làm đến đâu và vì sao cần làm như vậy.

👉 Khi được xây dựng đúng, WBS tạo ra ngôn ngữ chung cho cả đội dự án: từ BA, PM đến dev và stakeholder – giúp công việc được dự đoán tốt hơn, phối hợp rõ ràng hơn và ra quyết định dựa trên cấu trúc thay vì cảm tính.

🥰 Nói cách khác, giá trị của WBS không nằm ở sơ đồ, mà ở tư duy hệ thống mà nó mang lại cho toàn bộ dự án.

"

"🏯 Requirements Elicitation ...

💻 Trong phát triển phần mềm, yêu cầu không phải là danh sách mong muốn được ghi chép lại, mà là kết quả của một quá trình khai phá có phương pháp.

🤷‍♂️ Requirements Elicitation chính là giai đoạn mà team dự án chuyển từ nhận thức rời rạc của stakeholder sang một tập yêu cầu có thể thiết kế và xây dựng.

Đây là giai đoạn:

🍂 Giao tiếp nhiều nhất

🍂 Đòi hỏi năng lực phân tích cao nhất

🍂 Và ảnh hưởng trực tiếp đến chất lượng hệ thống về sau

🌷 Requirements Elicitation là gì?

👨‍💻 Requirements Elicitation là quá trình xác định, thu thập, phân tích và làm rõ yêu cầu hệ thống từ người dùng, khách hàng và các bên liên quan.

Trong Software Engineering, elicitation không chỉ trả lời “cần gì”, mà còn làm rõ: Vì sao cần?Trong bối cảnh nào? Với ràng buộc nào ? Và ở mức độ khả thi nào ?

👉 Đầu ra của giai đoạn này là các yêu cầu rõ ràng, nhất quán, có thể xác minh, làm nền cho thiết kế và phát triển.

🌷 Vì sao Requirements Elicitation mang tính học thuật cao

Bởi vì đây là điểm giao thoa của:

🍁 Business understanding

🍁 Human communication

🍁 System thinking

🍁 Engineering constraints

🤷‍♂️ Chỉ “hỏi người dùng” là không đủ. Nhiều yêu cầu quan trọng – đặc biệt liên quan đến an toàn, độ tin cậy, tuân thủ – thường không được phát biểu trực tiếp, mà phải được phát hiện thông qua phân tích và quan sát.

🌷 Các kỹ thuật Requirements Elicitation – dùng khi nào cho đúng?

✡️1️⃣ Interviews: Kỹ thuật thu thập yêu cầu thông qua trao đổi trực tiếp với stakeholder đại diện.

✅ Ưu điểm: Khai thác chiều sâu thông tin, linh hoạt theo từng nhóm stakeholder.

🚫 Hạn chế: Phụ thuộc nhiều vào kỹ năng phỏng vấn; khó mở rộng cho số lượng stakeholder lớn.

☸️2️⃣ Brainstorming: Kỹ thuật thảo luận nhóm nhằm tạo ra danh sách ý tưởng và nhu cầu ban đầu.

✅ Ưu điểm: Tạo nhiều góc nhìn trong thời gian ngắn, khuyến khích tư duy sáng tạo.

🚫 Hạn chế: Dễ chịu ảnh hưởng bởi sự thiên vị hoặc quan điểm cá nhân; cần người có kinh nghiệm kiểm soát thảo luận tốt.

🕉️3️⃣ Facilitated Application Specification (FAST): Workshop có cấu trúc, nơi business và developer cùng xây dựng yêu cầu thông qua trao đổi trực tiếp.

✅ Ưu điểm: Giảm hiểu sai yêu cầu, tăng mức độ đồng thuận sớm.

🚫 Hạn chế: Tốn thời gian tổ chức; khó triển khai với nhóm lớn hoặc phân tán.

🕎4️⃣ Quality Function Deployment (QFD): Kỹ thuật chuyển “tiếng nói khách hàng” thành yêu cầu có thể thiết kế và phát triển.

✅ Ưu điểm: Giúp phân biệt rõ yêu cầu cơ bản, kỳ vọng và giá trị vượt mong đợi.

🚫 Hạn chế: Khó áp dụng nếu stakeholder chưa làm rõ nhu cầu hoặc thiếu dữ liệu đầu vào.

🕉️ 5️⃣Use Case Approach: Kỹ thuật mô tả yêu cầu thông qua các kịch bản tương tác giữa người dùng và hệ thống.

✅ Ưu điểm: Dễ hình dung, hỗ trợ phân tích chức năng và thiết kế hệ thống.

🚫 Hạn chế: Chỉ phản ánh what hệ thống làm, không thể hiện đầy đủ yêu cầu phi chức năng.

🌷 Các bước cốt lõi trong Requirements Elicitation

1️⃣ Xác định stakeholder
2️⃣ Thu thập yêu cầu (functional & non-functional)
3️⃣ Đánh giá sự ưu tiên theo giá trị và ràng buộc
4️⃣ Đánh giá tính khả thi: khả thi – hoãn – loại bỏ

Đây không phải chuỗi tuyến tính, mà là quá trình lặp có kiểm soát.

🌷 Ưu và nhược điểm của Requirements Elicitation

✅ Ưu điểm

⚡️ Làm rõ kỳ vọng

⚡️ Giảm hiểu sai

⚡️ Nâng cao chất lượng hệ thống

⚡️ Hỗ trợ lập kế hoạch và quản lý rủi ro

🚫 Hạn chế

‼️ Tốn thời gian và chi phí

‼️ Phụ thuộc kỹ năng con người

‼️ Dễ bị tác động bởi thay đổi và yếu tố tổ chức

🌷 Cuối cùng

👨‍💼 Requirements Elicitation không phải là việc “chọn đúng kỹ thuật”, mà là chọn đúng cách tiếp cận trong đúng bối cảnh.

👉 Mỗi kỹ thuật chỉ làm rõ một khía cạnh nào đó của nhu cầu, không có phương pháp nào đủ bao trùm để đứng độc lập.

🤷‍♂️ Giá trị thực sự nằm ở khả năng kết hợp có chủ đích các kỹ thuật, dựa trên mức độ mơ hồ của yêu cầu, đặc thù stakeholder và ràng buộc của dự án.

🙋‍♂️ Khi đó, yêu cầu không chỉ được thu thập đầy đủ hơn, mà còn trở nên có thể phân tích, ưu tiên và triển khai một cách kiểm soát.

🥰 Sau cùng, elicitation hiệu quả không giúp “hết thay đổi”, mà giúp đội ngũ hiểu rõ mình đang quyết định điều gì, dựa trên thông tin nào, trong một môi trường mà sự không chắc chắn luôn tồn tại.

"

"📚 Những tài liệu Business Analyst có thể gặp trong dự án phần mềm...

🐣 Trong vòng đời một dự án, Business Analyst không làm việc với một loại tài liệu cố định.

🤷‍♂️ Danh sách tài liệu mà BA tham gia xây dựng phụ thuộc vào phương pháp triển khai (Agile, Waterfall, Hybrid), quy mô dự án, mức độ phức tạp nghiệp vụ và quy chuẩn tài liệu của từng tổ chức.

👉 Không phải dự án nào cũng có đầy đủ tất cả các tài liệu dưới đây, nhưng đây là những loại tài liệu BA có thể gặp, cùng nhau nhìn lại một chút nhé.

🌷 1️⃣ Nhóm tài liệu định hướng và hỗ trợ ra quyết định

👉 Trả lời câu hỏi: Có nên làm không? Làm theo hướng nào?

🍂 Business Case
Phân tích vấn đề kinh doanh, các phương án giải quyết, so sánh chi phí – lợi ích, rủi ro và giá trị kỳ vọng. Đây là cơ sở để tổ chức ra quyết định đầu tư hoặc ưu tiên sáng kiến.

🍂 Business Analysis Plan
Xác định cách BA tiếp cận hoạt động phân tích: phạm vi, phương pháp, kỹ thuật, mức độ chi tiết và sự tham gia của stakeholder.
📌 Giúp hoạt động phân tích có định hướng, tránh làm theo cảm tính.

🍂 Stakeholder Management Plan
Xác định các bên liên quan, mức độ ảnh hưởng, kỳ vọng và chiến lược làm việc với từng nhóm stakeholder trong suốt dự án.

🍂 Gap Analysis Document
So sánh hiện trạng (AS-IS) và trạng thái mong muốn (TO-BE) để làm rõ khoảng cách cần được giải quyết.
📌 Gap là đầu vào cho việc lựa chọn hướng giải pháp, không phải yêu cầu chi tiết.

🌷 2️⃣ Nhóm tài liệu mô tả yêu cầu nghiệp vụ

👉 Trả lời câu hỏi: Doanh nghiệp và người dùng đang thực sự cần gì?

🍂 Business Requirements Document (BRD)
Mô tả yêu cầu từ góc nhìn doanh nghiệp: mục tiêu, quy trình nghiệp vụ, business rules và các ràng buộc.
BRD tập trung vào “cái gì cần đạt được”, không đi sâu vào cách hệ thống sẽ được xây dựng.

🍂 User Requirements Document (URD)
Làm rõ nhu cầu, hành vi và kỳ vọng của người dùng cuối, đảm bảo giải pháp không lệch khỏi trải nghiệm thực tế.

🌷 3️⃣ Nhóm tài liệu phân tích chức năng & đặc tả hệ thống

👉 Trả lời câu hỏi: Hệ thống cần làm gì và được mô tả chi tiết đến mức nào?

🍂 Software Requirements Specification (SRS)

Đặc tả đầy đủ yêu cầu chức năng và phi chức năng.

🍁 Trong Waterfall: SRS thường bao gồm Use Case, Screen, Data, Business Rules.

🍁 Trong Agile / Scrum: nội dung này có thể được thể hiện thông qua User Stories + Acceptance Criteria.

🍂 System Design Document (SDD)

Mô tả thiết kế hệ thống ở góc độ kỹ thuật. BA thường tham gia review để đảm bảo giải pháp không đi chệch yêu cầu nghiệp vụ.

🌷 4️⃣ Nhóm tài liệu trong quy trình Agile / Scrum

👉 Trả lời câu hỏi: Làm sao để quản lý yêu cầu trong môi trường thay đổi liên tục?

🍂 User Story
Đơn vị yêu cầu nhỏ, tập trung vào giá trị người dùng, được làm rõ dần qua trao đổi và phản hồi liên tục.

🍂 Product Backlog
Danh sách các yêu cầu ở mức sản phẩm, được ưu tiên theo giá trị kinh doanh và mức độ sẵn sàng.

🍂 Sprint Backlog
Tập hợp các hạng mục được chọn để thực hiện trong một Sprint, đã đủ rõ để phát triển.

🍂 Burn-down / Burn-up Charts
Theo dõi tiến độ thực hiện và khả năng hoàn thành mục tiêu Sprint hoặc Release.

👉 Trong Agile, tài liệu không biến mất, mà chuyển từ “tài liệu nặng” sang “tài liệu vừa đủ” để phục vụ trao đổi và ra quyết định nhanh.

🌷 5️⃣ Nhóm tài liệu kiểm soát thay đổi & truy vết

🍂 Requirements Traceability Table (RTT)
Theo dõi mối quan hệ giữa yêu cầu, thiết kế, kiểm thử và triển khai.

🍂 Change Request Log & Impact Analysis
Ghi nhận thay đổi và phân tích tác động đến phạm vi, chi phí, tiến độ và giá trị kinh doanh.

🌷 6️⃣ Nhóm tài liệu kiểm thử & nghiệm thu

🍂 System Test Plan / Test Cases
Hỗ trợ hoạt động kiểm thử dựa trên yêu cầu đã được thống nhất.

🍂 UAT Progress Report
Theo dõi tiến độ nghiệm thu và mức độ đáp ứng nhu cầu thực tế của người dùng.

🌷 Vì sao tài liệu cần thiết trong dự án?

📌 Tài liệu được xây dựng nhằm thiết lập sự thống nhất giữa các bên tham gia dự án ngay từ đầu.

🤷‍♂️ Trong bối cảnh nhiều vai trò cùng phối hợp (business, IT, vendor, đối tác), 9 người 10 ý, tài liệu giúp làm rõ mục tiêu, phạm vi, trách nhiệm và cách hiểu chung, hạn chế diễn giải chủ quan trong quá trình thực hiện.

👉 Cấu trúc và mức độ chi tiết của tài liệu không cố định. Chúng được thiết kế dựa trên:

🍁 Quy mô và mức độ phức tạp của dự án

🍁 Phương pháp triển khai (Agile, Waterfall, Hybrid)

🍁 Phương pháp quản trị và mức độ trưởng thành của tổ chức

Vì vậy:

⚡️ Mỗi doanh nghiệp có hệ thống template khác nhau

⚡️ Mỗi dự án yêu cầu mức độ chi tiết khác nhau

⚡️ Có nơi sử dụng tài liệu truyền thống, có nơi kết hợp công cụ hỗ trợ

👉 Giá trị của tài liệu không nằm ở số lượng, mà ở việc chọn đúng nội dung cần ghi nhận, giữ đủ thông tin để: thống nhất nhận thức, hỗ trợ ra quyết định, kiểm soát thay đổi và rủi ro

🌷 Cuối cùng

📌 Tài liệu không tồn tại để “hoàn thành quy trình”, mà để thiết lập một nền tảng làm việc chung cho toàn bộ dự án.

👩‍💻 Giá trị của tài liệu nằm ở việc giúp đội ngũ hiểu đúng, làm đúng và ra quyết định nhất quán, ngay cả khi bối cảnh và yêu cầu liên tục thay đổi.

👉 Khi được sử dụng đúng cách, tài liệu không làm chậm dự án, mà giúp dự án đi nhanh hơn với mức độ rủi ro được kiểm soát một cách hiệu quả.

"

"🌷 5W–1H trong Business Analysis: không phải lúc nào cũng dùng, nhưng dùng đúng lúc thì rất đáng giá...

🙅‍♂️ Không có technique nào phù hợp cho mọi bài toán, điều đó là chắc chắn luôn

🍁 Có dự án cần Event Storming để lộ quy trình ẩn.
🍁 Có lúc cần User Journey để hiểu cảm xúc người dùng.
🍁 Có khi lại phải quay về Root Cause Analysis vì vấn đề nằm ở vận hành, không phải sản phẩm.

👉 Và cũng có những thời điểm, 5W–1H phát huy giá trị của nó.

👩‍💻 5W–1H không mạnh ở chỗ tạo insight mới, mà mạnh ở chỗ kéo cuộc trao đổi về cùng một mặt phẳng nhận thức. Khi stakeholder nói nhiều nhưng mỗi người hiểu một kiểu, khi yêu cầu nghe có vẻ hợp lý nhưng thiếu bối cảnh, 5W–1H đâu đó sẽ giúp gom lại những mảnh rời rạc của câu chuyện.

🤦‍♂️ Nhưng nếu dùng 5W–1H cho mọi tình huống, nó sẽ nhanh chóng trở nên phản tác dụng. Stakeholder mệt vì bị hỏi dồn, BA mệt vì câu trả lời hời hợt, còn tài liệu thì đầy chữ nhưng rỗng ý. Đó không phải lỗi của technique, mà là lỗi của việc chọn sai công cụ.

🙋‍♂️ Một BA có kinh nghiệm không hỏi theo mẫu. Họ chọn điểm cần làm rõ, và chọn cách đặt câu hỏi phù hợp với con người và bối cảnh. Có lúc chỉ cần một “Why” đủ sâu. Có lúc lại bỏ qua “Why” để tập trung vào dòng chảy nghiệp vụ hoặc ràng buộc thực tế.

🌱 Vì vậy, 5W–1H nên được xem như một trong nhiều lăng kính phân tích, không phải khung mặc định. Nó hoạt động tốt khi mục tiêu là làm rõ bối cảnh, nhưng sẽ kém hiệu quả nếu bài toán đã cần đi sâu vào thiết kế giải pháp hoặc tối ưu trải nghiệm.

👉 Giá trị của BA không nằm ở việc biết bao nhiêu technique, mà nằm ở việc biết lúc nào nên dùng cái nào — và khi nào nên dừng lại.


📸📸 Hình ảnh: Sưu tầm"

📚 Risk Identification Techniques...

🧏‍♂️ Trong dự án, rủi ro không nằm sẵn trong một danh sách để chúng ta tick vào cho đủ hay viết ra cho có đâu..

✨ Chúng xuất hiện dưới nhiều hình thức: trong suy nghĩ con người, trong tài liệu, trong giả định chưa được kiểm chứng, và có thể cả trong bối cảnh tổ chức mà dự án đang tồn tại.

👉 Vì vậy, xác định rủi ro không đơn thuần là áp dụng một kỹ thuật, mà là lựa chọn đúng cách quan sát dự án tại từng thời điểm.

Đó cũng là lý do các phương pháp Risk Identification không tồn tại độc lập mà sẽ được kết hợp với nhau làm sao để đạt được hiệu quả một cách tốt nhất.

🌷 Risk Identification ...

‼️ Về mặt học thuật, risk identification là quá trình nhận diện các sự kiện hoặc điều kiện có khả năng ảnh hưởng đến mục tiêu của dự án.

Tuy nhiên giá trị của bước này không nằm ở số lượng rủi ro được liệt kê, mà ở:

🍁 Cách chúng được phát hiện

🍁 Góc nhìn được sử dụng

🍁 Và mức độ phù hợp với bối cảnh tổ chức

Không có kỹ thuật nào đủ toàn diện để bao phủ mọi loại rủi ro. Cái nào mà chả có ưu điểm và nhược điểm. Mỗi technique sẽ phản ánh một lăng kính khác nhau khi quan sát dự án.

🌷 10 Risk Identification Techniques thường gặp

Để dễ tiếp cận, chúng ta sẽ chia các techniques này về từng nhóm để có thể dễ hiểu hơn nha

🕉️1️⃣ Nhóm technique dựa trên con người

Nhóm này tập trung khai thác kinh nghiệm, trực giác và nhận định chuyên môn, bao gồm:

🍂 Brainstorming: Khai thác góc nhìn đa dạng từ tập thể

🍂 Expert Judgment: Tận dụng kinh nghiệm tích lũy của chuyên gia hoặc người đã làm các dự án tương tự

🍂 Delphi Technique: thu thập ý kiến chuyên gia qua nhiều vòng ẩn danh, giúp làm rõ các rủi ro phức tạp mà không bị chi phối bởi vai trò hay cấp bậc.

👉 Phù hợp khi rủi ro mang tính ngữ cảnh, phụ thuộc nhiều vào kinh nghiệm và nhận định.

🕎2️⃣ Nhóm technique dựa trên tài liệu và cấu trúc của dự án

🍂 Document Review: Phát hiện rủi ro từ sự thiếu nhất quán trong scope, plan, assumptions, tài liệu thiết kế, business rules,...

🍂 Assumption Analysis: Kiểm tra các giả định đang được mặc nhiên chấp nhận hoặc bị bỏ sót

🍂 Risk Breakdown Structure (RBS): Phân loại rủi ro một cách có hệ thống

👉 Phù hợp khi dự án cần kiểm soát chặt chẽ, quy mô lớn hoặc chịu nhiều ràng buộc

☸️3️⃣ Nhóm technique dựa trên phân tích bối cảnh

🍂 SWOT Analysis: Cân bằng giữa yếu tố nội tại và cơ hội – thách thức bên ngoài

🍂 PESTLE Analysis: Nhìn rủi ro dưới góc độ môi trường vĩ mô

🍂 Root Cause (Fishbone) Analysis: Truy ngược nguyên nhân cốt lõi thay vì chỉ xử lý hiện tượng

👉 Phù hợp khi rủi ro không chỉ đến từ dự án, mà từ môi trường tổ chức và thị trường bên ngoài, đối thủ,...

♍️4️⃣ Nhóm technique dựa trên kinh nghiệm của tổ chức

🍂 Historical Checklists & Lessons Learned: Tận dụng kinh nghiệm làm dự án từ quá khứ, các bài học được rút ra và được đúc kết lại qua thời gian.

👉 Đặc biệt hiệu quả khi tổ chức có mức độ trưởng thành cao trong quản lý dự án.

🌷 Làm sao để chọn Risk Identification Technique phù hợp...

Trong quản trị rủi ro, không tồn tại một kỹ thuật “tối ưu cho mọi dự án”.

🤷‍♂️ Mỗi risk identification technique được thiết kế để làm rõ một dạng bất định nhất định, trong một bối cảnh cụ thể.

👉 Vì vậy, lựa chọn technique không nên xuất phát từ danh sách phương pháp, mà từ đặc điểm của dự án và mức độ rõ ràng của thông tin tại thời điểm đó.

⚡️ Khi dự án còn nhiều mơ hồ, các kỹ thuật dựa trên tri thức và kinh nghiệm con người thường phát huy hiệu quả.

⚡️ Ngược lại, khi phạm vi và giải pháp đã dần ổn định, các kỹ thuật phân tích cấu trúc, tài liệu và bối cảnh sẽ giúp nhìn rủi ro rõ ràng và hệ thống hơn.

💁‍♂️ Trên thực tế, nhiều team vẫn đang xác định rủi ro đúng cách, dù không gọi tên kỹ thuật một cách chính thức. Điều quan trọng không nằm ở phương pháp được đặt tên gì, mà ở sự phù hợp giữa cách tiếp cận và bối cảnh dự án.

👉 Do đó, cách tiếp cận hiệu quả nhất thường là kết hợp có chủ đích nhiều technique, để bù trừ hạn chế của nhau và tạo ra một bức tranh rủi ro toàn diện, gắn chặt với mục tiêu kinh doanh.

🌷 Cuối cùng

✨ Rủi ro không phải là dấu hiệu của một dự án yếu kém, mà là bản chất tự nhiên của mọi hệ thống đang vận động trong môi trường thay đổi liên tục.

🥰 Vấn đề không nằm ở việc sử dụng bao nhiêu technique, mà ở việc lựa chọn và kết hợp chúng một cách có chủ đích, phù hợp với bối cảnh và mục tiêu của dự án để đưa ra được kết quả tốt nhất.

👉 Quản trị rủi ro hiệu quả, suy cho cùng, không phải để loại bỏ mọi rủi ro, mà để giúp đội ngũ đưa ra quyết định tốt hơn, sớm hơn và có cơ sở hơn – ngay cả khi thông tin chưa bao giờ là hoàn hảo.

📸📸 Hình ảnh: Sưu tầm

"🏯 Rủi ro trong quá trình phát triển phần mềm ...

🐣 Đôi khi nhiều người vẫn nghĩ rủi ro (risk) là “điều xui xẻo” xảy ra khi dự án có vấn đề.

Nhưng nếu làm qua mấy cái dự án rồi nhìn lại, chúng ta có thể hiểu rằng rủi ro không phải là sự cố – mà là những khả năng hoàn toàn có thể dự đoán trước, nếu chúng ta chịu nhìn đủ sâu vào hệ thống, quy trình và bối cảnh kinh doanh.

💻 Phát triển phần mềm không chỉ là viết code. Đó là một chuỗi SDLC phức tạp: từ phân tích, thiết kế, phát triển, kiểm thử đến vận hành. Và mỗi giai đoạn đều mang trong mình rủi ro riêng – nếu không được quản trị tốt, chúng sẽ âm thầm bào mòn mọi thứ từ chi phí, tiến độ, chất lượng và niềm tin của stakeholder.

🌷 Risk & Risk Management – không chỉ là khái niệm “học thuật”

Risk là một sự kiện chưa xảy ra, có xác suất xảy ra trong tương lai và có thể gây tác động tiêu cực đến dự án: trễ deadline, vượt ngân sách, giảm chất lượng sản phẩm,..

Điều quan trọng là:
👉 Thành công của dự án không phụ thuộc vào việc có rủi ro hay không, mà phụ thuộc vào cách chúng ta nhìn nhận và quản trị rủi ro.

🌷 Các nhóm rủi ro phổ biến trong phát triển phần mềm

✡️ 1️⃣ Schedule Risk – Rủi ro tiến độ

📖 Về mặt học thuật, schedule risk không đơn thuần là trễ kế hoạch, mà là sai lệch giữa kế hoạch ban đầu và thực tế vận hành.

🍁 Sai lệch này thường xuất hiện khi:

🍁 Ước lượng thời gian thiếu cơ sở thực tế

🍁 Phân bổ nguồn lực không phù hợp năng lực

🍁 Scope thay đổi liên tục nhưng timeline không điều chỉnh

🍁 Chức năng chưa được phân rã rõ ràng,...

👉 Do đó, rủi ro tiến độ sẽ phản ánh chất lượng của hoạt động phân tích và lập kế hoạch, chứ không chỉ là năng suất thực thi.

🕉️ 2️⃣ Budget Risk – Rủi ro ngân sách

Ngân sách thường “vỡ” không phải vì chi tiêu hoang phí, mà vì:

⚡️ Dự toán ban đầu chưa phản ánh đúng độ phức tạp của dự án

⚡️ Chi phí phát sinh từ thay đổi yêu cầu hoặc giải pháp kỹ thuật

⚡️ Thiếu cơ chế theo dõi chi phí theo từng quyết định

Ở nhiều dự án, ngân sách bị bào mòn dần qua những khoản nhỏ, cho đến khi nhận ra thì đã quá muộn để điều chỉnh.

🪯3️⃣ Operational Risk – Rủi ro vận hành dự án

Đây là nhóm rủi ro âm thầm nhưng có sức tàn phá lớn:

✨ Thiếu rõ ràng trong vai trò và trách nhiệm

✨ Giao tiếp không đồng bộ giữa các bên

✨ Thiếu nguồn lực hoặc năng lực không phù hợp

✨ Không có quy trình làm việc rõ ràng

Khi rủi ro vận hành xuất hiện, dự án vẫn “chạy”, nhưng chạy trong trạng thái mệt mỏi, rối rắm và dễ nản.

☦️ 4️⃣ Technical Risk – Rủi ro kỹ thuật

Không chỉ công nghệ mới mới tạo ra rủi ro. Ngay cả những công nghệ quen thuộc cũng có thể trở thành rủi ro nếu:

🍂 Yêu cầu thay đổi liên tục nhưng kiến trúc không đủ linh hoạt

🍂 Thiếu năng lực kỹ thuật phù hợp

🍂 Đánh giá thấp độ phức tạp khi tích hợp hệ thống

🍂 Phụ thuộc vào số ít cá nhân then chốt

Rủi ro kỹ thuật thường bộc lộ muộn, nhưng một khi đã xuất hiện thì chi phí khắc phục rất là lớn.

☸️5️⃣ Programmatic / External Risk – Rủi ro từ môi trường bên ngoài

Có những yếu tố nằm ngoài khả năng kiểm soát của bất kỳ cá nhân hay tổ chức nào:

🌟 Thị trường thay đổi

🌟 Chiến lược kinh doanh điều chỉnh

🌟 Ngân sách bị cắt

🌟 Quy định pháp lý thay đổi

Những rủi ro này nhắc chúng ta rằng: một dự án phần mềm không tồn tại trong chân không, mà luôn gắn chặt với bối cảnh kinh doanh và xã hội.

🌷 Một số rủi ro khác có thể gặp ...

🗣️ Communication Risk - Rủi ro giao tiếp

🔐 Security Risk - Rủi ro bảo mật

🧪 Quality Risk - Rủi ro chất lượng

⚖️ Legal & Compliance Risk -Rủi ro pháp lý

🛒 Market Risk - Rủi ro thị trường

🌷 Cuối cùng

🌱 Không có dự án phần mềm nào hoàn hảo 100%. Mỗi dự án mang một bối cảnh riêng, mục tiêu riêng và mức độ bất định riêng, nên rủi ro cũng không bao giờ giống nhau.

Điều quan trọng không phải là tránh rủi ro, mà là nhận diện sớm, hiểu đúng và chủ động chuẩn bị cho chúng.

🥰 Làm dự án, suy cho cùng, là học cách đưa ra những quyết định tốt nhất trong một thế giới luôn không hoàn hảo mà thôi."

"🌷 Business Analysis trong SDLC ...

Hãy cùng nhìn lại những công việc diễn ra trong suốt vòng đời SDLC, và những công cụ, kỹ thuật mà BA có thể sử dụng ở từng giai đoạn.

Trong thực tế, không có hai dự án nào giống nhau.
Mỗi doanh nghiệp có cách vận hành riêng, văn hóa ra quyết định khác nhau, mức độ trưởng thành về công nghệ khác nhau. Vì vậy, cùng một giai đoạn trong SDLC, nhưng cách BA làm việc, cách trao đổi với stakeholder, và công cụ được lựa chọn có thể hoàn toàn khác.

Điểm mấu chốt không phải là “dùng đủ công cụ”, hay “làm đúng theo sách”, mà là hiểu rõ mình đang cần làm rõ điều gì ở giai đoạn đó để chọn ra kỹ thuật phù hợp nhất với bối cảnh dự án, giúp đội ngũ đi nhanh hơn, rõ hơn và giảm rủi ro trong quá trình triển khai.

📸📸 Hình ảnh: Sưu tầm"

"🏯 Single Sign-On (SSO) – Khi trải nghiệm người dùng phản ánh mức độ trưởng thành của hệ thống

Trong một doanh nghiệp, việc tồn tại nhiều ứng dụng là điều hoàn toàn bình thường. Đó không phải dấu hiệu của sự rối rắm, mà là kết quả của việc nghiệp vụ ngày càng chuyên môn hóa, quy định ngày càng chặt chẽ, vì thế nên hệ thống phải thích nghi để đáp ứng.

🌷 Bình thường thì không sao... vấn đề chỉ bắt đầu khi mỗi ứng dụng yêu cầu người dùng phải tự chứng minh mình là ai theo một cách khác nhau.

🌱 Danh tính: thứ tưởng như hiển nhiên nhưng lại dễ bị xem nhẹ. Danh tính số không phải là username hay mật khẩu. Danh tính là câu trả lời cho ba câu hỏi rất cơ bản:

🍂 Bạn là ai trong tổ chức?

🍂 Bạn đang giữ vai trò gì?

🍂 Và bạn được phép làm gì, trong bối cảnh nào?

👉 Khi mỗi hệ thống tự trả lời ba câu hỏi này theo cách riêng, danh tính bị phân mảnh. Trải nghiệm người dùng trở nên đứt đoạn. Việc quản trị quyền truy cập dần dựa vào thói quen, kinh nghiệm và thao tác thủ công — thay vì có nguyên tắc.

🤷‍♂️ Lúc này, vấn đề không còn là dùng nhiều ứng dụng, mà là không có một cách thống nhất để xác nhận và tin tưởng danh tính người dùng trên toàn bộ ứng dụng trong hệ thống quản lý.

🌷 Và đó chính là lý do Single Sign-On (SSO) xuất hiện

Single Sign-On là cơ chế cho phép doanh nghiệp xác nhận danh tính người dùng tại một điểm trung tâm, thay vì để từng ứng dụng tự xác thực theo cách riêng.
Người dùng chỉ cần chứng minh mình là ai một lần; các hệ thống khác dựa vào kết quả đó để cấp quyền truy cập.

🍂 Người dùng xác thực một lần.
🍂 Danh tính được xác nhận ở nơi đáng tin cậy.
🍂 Quyền truy cập được dẫn xuất dựa trên vai trò, không dựa trên trí nhớ của người dùng hay thao tác rời rạc của IT.

Từ đây, trải nghiệm không còn phụ thuộc vào từng ứng dụng riêng lẻ, mà trở nên liền mạch và nhất quán ở cấp tổ chức.

🌷 Giá trị thực sự của SSO

🍁 Với người dùng: ít gián đoạn, ít phải “suy nghĩ về hệ thống”, tập trung vào công việc.

🍁 Với doanh nghiệp: quản lý quyền truy cập rõ ràng, onboarding/offboarding có kiểm soát, giảm rủi ro tồn đọng.

🍁 Với bảo mật: chính sách xác thực, MFA và giám sát truy cập được áp dụng thống nhất, không bị phân mảnh theo từng nền tảng.

👉 SSO không tạo ra bảo mật. SSO tạo ra điều kiện để bảo mật được thực thi một cách nhất quán và có kỷ luật.

🌷 Nhưng SSO cũng không phải “đũa thần”

Khi danh tính được tập trung, điểm xác thực đó trở thành trục sống của hệ thống.Nếu thiết kế hời hợt, SSO có thể khuếch đại rủi ro thay vì kiểm soát nó.

Vì vậy, triển khai SSO không chỉ là bật một tính năng, mà là một quyết định quản trị danh tính và trải nghiệm số.

🌷 Cuối cùng

⚡️ SSO không nhằm làm hệ thống thuận tiện hơn, mà nhằm thiết lập tính nhất quán trong cách các ứng dụng cùng vận hành trong một tổ chức. Khi quy mô và nhu cầu nghiệp vụ tăng lên, thách thức không nằm ở số lượng hệ thống, mà ở việc chúng có được quản trị theo một nguyên tắc chung hay không.

⚡️ Ở góc độ đó, SSO giúp trải nghiệm liền mạch hơn, vận hành có kỷ luật hơn, và các chính sách được thực thi đồng bộ — thay vì phụ thuộc vào thao tác rời rạc hay kinh nghiệm cá nhân. Đây không phải là một quyết định thuần kỹ thuật, mà là dấu hiệu cho thấy doanh nghiệp đã bước sang một giai đoạn trưởng thành hơn trong tư duy quản trị hệ thống.

📸📸 Hình ảnh: Bytebytego"

🌷 Sketch – Wireframe – Mockup – Prototype
Không phải vẽ đủ, mà là vẽ đúng thứ dự án cần

💁‍♂️ Trong thiết kế sản phẩm số, hiếm có ý tưởng nào đi thẳng từ suy nghĩ sang sản phẩm hoàn chỉnh lắm. Trước khi được code và đưa vào sử dụng, một giao diện thường phải đi qua nhiều “lớp trưởng thành” khác nhau.
Sketch, Wireframe, Mockup và Prototype chính là những lớp trung gian đó – mỗi lớp tồn tại để giải quyết một câu hỏi khác nhau, ở một thời điểm khác nhau của dự án.

🤗 Vấn đề không nằm ở việc bạn biết bao nhiêu khái niệm, mà ở chỗ: bạn đang dùng đúng mức độ thiết kế cho đúng bối cảnh hay chưa. Vẽ thiếu thì dễ hiểu sai, nhưng vẽ thừa cũng có thể khiến dự án chậm lại mà không tạo thêm giá trị.

✡️ Thiết kế trước hết là công cụ giao tiếp

Bản chất của Sketch, Wireframe, Mockup hay Prototype không phải để “làm cho đẹp”, mà để giúp các bên cùng nhìn sản phẩm theo một cách thống nhất.
Mỗi mức độ thiết kế sinh ra để trả lời một nhóm câu hỏi cụ thể:

🍁 Ý tưởng này có đáng để bàn tiếp không?
🍁 Cấu trúc màn hình và luồng sử dụng đã hợp lý chưa?
🍁 Giao diện này trông sẽ như thế nào khi hoàn thiện?
🍁 Người dùng có thực sự hiểu và sử dụng được không?

👉 Vì vậy, việc chọn vẽ đến mức nào nên bắt đầu từ mục tiêu cần làm rõ, chứ không phải từ việc “quy trình chuẩn là phải có đủ bốn bước”.

☸️ Bốn mức độ – bốn vai trò khác nhau

✏️ Sketch là điểm khởi đầu, nơi ý tưởng được phác ra nhanh và thô. Sketch ưu tiên tốc độ và sự tự do, giúp đội ngũ dễ trao đổi, dễ phản biện và dễ loại bỏ phương án chưa phù hợp ngay từ sớm.

👉 Phù hợp khi cần brainstorm, khám phá ý tưởng, hoặc khi đội phát triển đủ kinh nghiệm để code từ mô tả khái quát.

🧱 Wireframe xuất hiện khi dự án cần nói chuyện bằng cấu trúc. Ở đây, bố cục, thành phần và luồng điều hướng được làm rõ, còn yếu tố thẩm mỹ được đặt sang một bên.

👉 Phù hợp khi BA cần thống nhất requirement, user flow và phạm vi chức năng với team Dev.

🎭 Mockup là wireframe đã được “mặc áo”. Màu sắc, font chữ, phong cách thương hiệu được thể hiện đầy đủ để stakeholder hình dung sản phẩm sẽ trông như thế nào.

👉 Phù hợp khi cần review giao diện, lấy phản hồi về mặt thị giác hoặc chuẩn bị handoff cho developer.

🔁 Prototype là lúc thiết kế bắt đầu “chạy được”. Người dùng có thể bấm, chuyển màn hình và trải nghiệm luồng sử dụng gần giống sản phẩm thật.

👉 Phù hợp khi cần test trải nghiệm, demo sản phẩm hoặc hỗ trợ ra quyết định trước khi phát triển chính thức.

🕉️ Không có mức độ “chuẩn”, chỉ có mức độ “phù hợp”

🤷‍♂️ Trên thực tế, mỗi công ty – mỗi dự án – mỗi giai đoạn sẽ yêu cầu khác nhau:

Có nơi BA chỉ cần sketch là developer đã có thể code.

Có nơi yêu cầu wireframe chi tiết để khóa chặt phạm vi và luồng.

Có nơi cần mockup để đảm bảo đúng brand và trải nghiệm.

Cũng có dự án đòi hỏi prototype hoàn chỉnh trước khi viết dòng code đầu tiên.

👉 Điều quan trọng không phải là bạn vẽ tới đâu, mà là thứ bạn vẽ có đang giúp dự án tiến lên hay không.

🕉️ Thiết kế tốt không nằm ở độ chi tiết

Một thiết kế có giá trị khi nó:
🍁 Trả lời đúng câu hỏi của giai đoạn hiện tại
🍁 Phù hợp với đối tượng đọc (business, tech, stakeholder)
🍁 Giảm rủi ro hiểu sai và tiết kiệm chi phí chỉnh sửa về sau

Vẽ nhiều nhưng không phục vụ quyết định thì chỉ làm nặng tài liệu thêm thôi. Thà vẽ ít nhưng đúng trọng tâm lại có khi lại giúp dự án đi rất nhanh.

🌷 Cuối cùng

Sketch, Wireframe, Mockup hay Prototype không phải là “bộ checklist bắt buộc phải đủ”, mà là những công cụ linh hoạt trong tư duy sản phẩm.
Với BA, giá trị không nằm ở việc bạn vẽ đẹp hay vẽ nhiều, mà ở chỗ:
👉 bạn biết khi nào cần vẽ, vẽ cho ai, và vẽ để làm rõ điều gì.

Khi đó, thiết kế không còn là gánh nặng quy trình, mà trở thành ngôn ngữ chung giúp ý tưởng được hiểu đúng, làm đúng và triển khai hiệu quả trong từng bối cảnh dự án.