WAY TO ENTERPRISE
Lesson 6
Các bước thực hiện khai thác
yêu cầu
Agenda
I. Khó khăn khi khai thác yêu cầu
II. Các bước khai thác yêu cầu
III. Bắt đầu khai thác yêu cầu
I. Khó khăn khi khai thác yêu cầu
=> Nếu phân tích không tốt dẫn đến hiểu lầm yêu cầu thì việc sửa chữa sẽ trở nên rất tốn kém. Chi phí để sửa chữa sai sót về yêu cầu sẽ tăng lên gấp bội nếu như sai sót đó được phát hiện muộn.
Khai thác và phân tích yêu cầu giữ một vai trò đặc biệt quan trọng trong phát triển phần mềm:
- Đảm bảo chất lượng của phần mềm
- Phần mềm thực hiện được chính xác, đầy đủ yêu cầu của người sử dụng
I.I Khó khăn về kinh nghiệm
Ít kinh nghiệm
Nhiều kinh nghiệm
I.I Khó khăn về kinh nghiệm
Những cái khách hàng yêu cầu và chúng ta nhìn thấy đôi khi chỉ chiếm khoảng 30% nhu cầu thật sự của họ mà thôi.
Và 70% còn lại có thể nằm ở đâu?
• Business case khác có thể xảy ra, mà mình chưa cover được hết.
• Vấn đề kỹ thuật tiềm tàng như việc tích hợp, technical mới chưa phát triển bao giờ…
• Yếu tố con người, cả từ phía khách hàng, lẫn team dự án.
=> Trao đổi, học hỏi người đi trước. Theo sát một dự án từ đầu đến cuối.
I.I Khó khăn về cách diễn đạt
I.I Khó khăn về cách diễn đạt
Nói A => khách hàng hiểu B, C……
Điều này là do đâu?
• Cách truyền đạt không rõ ràng, chung chung ko cụ thể.
• Cách truyền đạt không đúng vào trọng tâm vấn đề.
• Vấn đề phức tạp đôi khi ko diễn tả được bằng lời.
=> Sử dụng tool để diễn tả bằng hình ảnh trực quan, ví dụ như tool https://excalidraw.com/
I.I Khó khăn về người dùng, khách hàng
• Không hiểu mình muốn gì?
• Không tuân theo các yêu cầu đã được tài liệu hóa
• Không hiểu kĩ thuật
• Không hiểu quy trình phát triển
• Đặc biệt là luôn đòi hỏi các yêu cầu mới sau khi chi phí và kế hoạch phát triển đã được hoạch định xong.
II. Các bước khơi gợi yêu cầu
Sai lầm thường gặp:
• Lên list câu hỏi
• Gặp khách hàng/ stakeholder
• Hỏi và yêu cầu khách hàng trình bày mong muốn
• Ghi chép
• Phân tích
II.I Phân tích BACCM
Sử dụng mô hình để phân tích yêu cầu của khách hàng ngay từ khi bắt đầu dự án
II.II Xác định Need
Sau khi phân tích BACCM, chúng ta đưa ra danh sách các Stakeholder trong dự án và các Need của từng Stakeholder
II.III Đưa ra giải pháp
Với từng Need sẽ đưa ra các Solutions, với mỗi Solution sẽ đưa ra các User story để giải quyết từng Solution
II.IV List câu hỏi cần làm rõ
II.IV List câu hỏi cần làm rõ
• No: số thứ tự
• Date: Ngày đặt câu hỏi
• Who’s question: Người đặt câu hỏi
• Category: Đang hỏi về phần nào (về technical, spec hay plan, deadline…)
• Questions: Câu hỏi
• Answer: Câu trả lời
• Who’s answer: Người trả lời
• Status: Trạng thái của câu hỏi (New, Inprogress, Done..)
=> Những câu hỏi này nên có sự review của Leader hoặc những bạn Senior trong team dự án.
II.IV List câu hỏi cần làm rõ
Ngoài list các câu hỏi để xác nhận, có thể chúng ta sẽ chuẩn bị một bài thuyết trình để trình bày
II.V Xác nhận và làm rõ yêu cầu
Khách hàng có thể xác nhận bằng cách trả lời của List câu hỏi hoặc khi chúng ta gặp trực tiếp để trình bày giải pháp thì cũng có bước ngồi trao đổi để xác nhận và làm rõ thêm nhu cầu của
II.V Xác nhận và làm rõ yêu cầu
Khách hàng có thể xác nhận bằng cách trả lời của List câu hỏi hoặc khi chúng ta gặp trực tiếp để trình bày giải pháp thì cũng có bước ngồi trao đổi để xác nhận và làm rõ thêm nhu cầu của
II.V Xác nhận và làm rõ yêu cầu
Sau khi đã xác nhận thì mang những thông tin thu thập được về phân tích và triển khai
III. Bắt đầu phân tích nghiệp vụ
Có nên: Business Analysis => System Analysis => Tài liệu hóa?
Trước khi bắt tay vào phân tích Business, chúng ta cần đưa ra quyết định về các yêu cầu trước:
• Xác định Business case
• Xác định Stakeholder
• Xác định nguyên nhân gốc rễ
• Đưa ra quyết định
III.I Xác định Business case
• Một dự án khả thi là dự án đảm bảo bàn giao được sản phẩm trong điều kiện ràng buộc về chi phí, thời gian, tài nguyên.
• Business case giúp nhóm quản lý dự
án đưa ra quyết định trước các thay đổi hay rủi ro bằng cách phân tích các tác động dưới góc nhìn kinh doanh.
III.I Xác định Business case
• Reason: tiền đề cho sự ra đời của dự án
• Business option: Để đáp ứng thách thức và cơ hội trong Reason sẽ có nhiều các giải quyết khác nhau
• Expected Benefit: là mục đích cuối cùng của dự án. Tất cả các lợi ích nên được đo lường đo khách quan, ví dụ doanh thu, chi phí tiết kiệm được, thị phần.
III.I Xác định Business case
• Expected Dis-Benefit: ước tính hậu quả xảy ra khi thực hiện dự án. Hậu quả là điều chắc chắn xảy ra, tác động đến ai hoặc cái gì đó theo chiều hướng xấu.
• Timescale: Dự án sẽ chạy trong khoảng thời gian nào? Khi nào thì lợi ích của dự án sẽ xảy ra?
• Cost: chi phí của dự án và chi phí vận hành để vận hành output của dự án, cũng như nguồn ngân sách cho dự án.
III.I Xác định Business case
Ví dụ: Xác định Business case ”Giả định mình muốn mua một chiếc oto”
III.II Xác định Stakeholder
• Đội dự án: Có làm được business case hay ko? (time, nguồn lực, chi phí…)
• Khách hàng: nhiều yếu tố phân tích, xác định nhu cầu
• Nhà cung cấp: đủ trang thiết bị, hạ tầng để làm ko
• Cán bộ nhân viên: có bị ảnh hưởng ko
• Tổ chức: có phụ thuộc tổ chức ko? Cần giấy phép gì ko? ( ký cam kết security)
III.IV Phân tích nguyên nhân gốc rễ
• Xác định vấn đề: Đưa ra danh sách vấn đề trong dự án mà thu thập được
• Nghiên cứu và xem xét vấn đề: thu thập thông tin về các vấn đề mà đã xác định được từ các Stakeholder liên quan
• Xác định cái gì đã xảy ra: Từ các vấn đề trên đã xảy ra sự cố/sai sót nào?
• Xác định nguyên nhân
III.IV Mô hình 5 Why
Để tìm nguyên nhân của một vấn đề bằng cách trả lời lần lượt các câu hỏi why? Có nguyên nhân sẽ được xác định sau 1 why, 2 why… nhưng có những vấn đề phải đến 5 why mới phát hiện ra
được.
=> Vậy nếu qua 5 Why vẫn chưa tìm được nguyên nhân gốc rễ thì sao?
III.IV Mô hình 5 Why
Ví dụ: Tìm hiểu nguyên nhân gốc rễ của vấn đề sau “Khách hàng không thấy hài lòng”
III.IV Mô hình xương cá
• Biểu đồ Ishikawa tạo nên một sự tách biệt giữa nguyên nhân và hệ quả.
• Ở phía bên phải của biểu đồ Ishikawa là các vấn đề được mô tả, và ở bên trái là các nguyên nhân sâu xa được chỉ ra.
• Những nguyên nhân gốc rễ (hay nguyên nhân sơ cấp) này được chia thành các loại loại. Sau đó, mỗi loại được phân nhánh thành các nguyên
III.V Đưa quyết định
• Business case là gì?
• Các bên liên quan
• Danh sách nguyên nhân gốc rễ vấn đề
=> Ra quyết định có làm hay không? Nếu làm thì sẽ làm theo phương án nào?
Việc ra quyết định này ko chỉ ở giai đoạn đầu tiên là phân tích xem có làm dự án hay không mà trong bất kỳ yêu cầu nào chúng ta cũng sẽ phải phân tích để ra quyết định cho từng yêu cầu cụ thể chứ ko phải là đưa yêu cầu thế nào thì sẽ làm theo thế đó.
