Giả định (Assumption ) là gì? Tại sao giả định rất quan trọng với dự án?
Last updated: November 03, 2023 Xem trên toàn màn hình
Recommended for you
- 04 Mar 2020
Kinh nghiệm lập dự toán chi phí dự án phần mềm theo phương pháp Man-Month 2507 - 01 Jul 2023 Phương pháp Shuhari - Làm sao học ít hiểu nhiều? 905
- 01 Aug 2022 "Sponsored Content" là gì? Khác nhau giữa Sponsored Content và Native Advertising? 764
- 01 Feb 2022 Thách thức với doanh nghiệp chuyển đổi số trong thời đại VUCA 669
- 04 Jan 2023 Phát triển phần mềm linh hoạt theo mô hình Big Bang 654
- 18 May 2021 Cây cầu hiện đại vô dụng nhất thế giới và câu chuyện cái kết của thay đổi yêu cầu 622
- 15 Apr 2020 Phần mềm BPM là gì? So sánh với ERP và các phần mềm Workflows 533
- 03 Oct 2021 Khác biệt giữa thiết kế phần mềm và thiết kế công trình xây dựng 493
- 18 Mar 2021 Kỹ thuật ước lượng dự án phần mềm linh hoạt dựa vào Story Point - phương pháp T-Shirt Sizing 459
- 14 Aug 2022 Khác biệt giữa tiêu chí hoàn thành DOD (Definition of Done) với tiêu chí nghiệm thu (Acceptance Criteria) 457
- 03 May 2022 Mô hình Hybrid Agile là gì? 443
- 03 Feb 2020 Sản phẩm OEM và ODM là gì? 440
- 14 Apr 2019 Product Backlog là gì? Các đặc điểm cơ bản của một Product Backlog 395
- 02 Aug 2023 Tổng hợp một số project tham khảo khi xây dựng các ứng dụng theo mô hình Microservices 382
- 01 Aug 2023 Phân tích yêu cầu phần mềm sẽ nhìn vào thực trạng (AS-IS) hay tương lai (TO-BE)? 371
- 04 Jan 2023 Đánh giá nhân sự theo chuẩn người Nhật 366
- 12 May 2021 Các yêu cầu thay đổi (Change Requests) - nỗi ám ảnh của team dự án phần mềm 348
- 20 Jul 2021 Quản lý và đánh giá công việc theo quy trình TIGO SmartWork 344
- 02 Aug 2021 Product Owner làm gì trước khi bắt đầu sprint đầu tiên của dự án (Sprint Zero)? 313
- 28 Jun 2024 Tại sao các kỹ sư IT giỏi nhất lại là những người theo thuyết bất khả tri về công nghệ (technology agnostics)? 295
- 24 Mar 2019 Scrum giống như bà mẹ chồng, giúp bạn nhìn ra các lỗi sai 272
- 21 Apr 2020 Bảo trì phần mềm là gì? Phân biệt các loại bảo trì 239
- 18 Mar 2018 Dịch vụ Hosting cho Website là gì? Các lời khuyên chọn Hosting tốt nhất 232
- 08 Jan 2022 Yêu cầu thay đổi (Change Request) là gì? Làm thế nào để kiểm soát Change Request? 226
- 17 Aug 2020 Mục tiêu dự án là gì? Làm thế nào để xác định mục tiêu? 213
- 01 Sep 2020 Co-founder là gì? Vai trò của các Co-Founder khi lập nghiệp. 213
- 14 May 2024 Chiến lược răng lược là gì? Làm thế nào để tận dụng chiến lược răng lược trong kinh doanh? 205
- 10 May 2021 Phát triển Phần mềm Tinh gọn (Lean Software Development) 197
- 08 Mar 2022 Mô hình nguồn mở hoạt động ra sao? 185
- 08 Feb 2021 Quy trình nâng cấp phần mềm quản trị doanh nghiệp TIGO ERP 183
- 14 Dec 2022 Phương pháp kiểm tra Fagan Inspection là gì? 159
- 08 Mar 2020 Vì sao doanh nghiệp cần phải tạo Web bán hàng? 158
- 01 May 2023 [Tư vấn CNTT] Quản lý ngân sách CNTT cho doanh nghiệp 156
- 01 Apr 2022 Chi phí nhà thầu phụ chiếm bao nhiêu phần trăm gói thầu? 151
- 19 Aug 2020 Lift & Shift - Phương pháp tối ưu dịch chuyển hệ thống phần mềm qua đám mây 147
- 25 Apr 2018 Bảo hộ bản quyền phần mềm dưới khía cạnh sở hữu trí tuệ như thế nào? 140
- 17 Feb 2018 Hệ luỵ khi sử dụng Web Hosting từ nhà cung cấp kém chất lượng 130
- 09 Feb 2021 Tầm nhìn là gì? Tí dụ minh họa cụ thể về tầm nhìn 121
- 22 Jul 2020 Quản lý dự án phần mềm trong thực tế và câu chuyện thành công của InfoSys 93
Giả định (Assumption) là gì?
Assumption (giả định) là một phần quan trọng trong truyền thông giao tiếp của một dự án. Giả định đồng nghĩa với kỳ vọng, là những điều không hoàn toàn dựa trên thực tế.
"Assumption is a belief of what you assume to be true in the future."
Giả định (assumption) là xem xét một thực tế, một phán đoán hay nhận định nào đó là đúng. Khi nghiên cứu một hiện tượng hoặc một tình huống, người thường giả định các hiện tượng hay các yếu tố khác không thay đổi. Giả định này cho phép họ tập trung vào phân tích một hiện tượng mà không phải quan tâm tới tác động của các hiện tượng,
Dưới đây là một số ví dụ về assumptions:
- PM có thể lấy tất cả tài nguyên mà yêu cầu.
- Vào mùa mưa, lao động thì rẻ hơn.
- Tất cả các stakeholder quan trọng sẽ đến vào buổi họp tới.
Tại sao giả định rất quan trọng với dự án?
Giả định là một phần quan trọng trong dự án phần mềm. Trong đó, với những giả định này, những bên tương quan (stakeholders) khi nhóm họp hoàn toàn có thể không nhận ra, khiến những ”giả định không đúng mực” đem đến những rủi ro đáng tiếc cho dự án. Do đó, một dự án khi tiến hành mới cần có sự theo sát của giám đốc dự án (PM) và đội nhóm dự án.
Ví dụ:
"Bugfix effort for each screen will not exceed 20% of the development effort for same screen" (khối lượng công việc sửa lỗi cho mỗi màn hình giao diện sẽ không vượt quá 20% khối lượng triển khai cho màn hình đó).
Xác định giả định nhờ ma trận "Biết" và "Chưa biết"
Có bốn danh mục thông tin và mỗi danh mục bao gồm hai từ: “Đã biết” (Knowns) hoặc “Chưa biết” (Unknowns)
Thông qua kỹ thuật “Biết” (Knowns) và “Chưa biết” (Unknowns), trả lời nhanh ba câu hỏi cơ bản để giúp bạn xác định và quản lý các giả định:
- Có những giả định nào mà chúng ta biết (đã được xác thực)?
- Có những giả định nào mà chúng ta có thể biết nhưng chưa xác thực?
- Có những giả thiết nào mà chúng ta không thể biết được?
Các giả định là yếu tố quan trọng đối với quản lý dự án. Chúng thường được gọi là “sát thủ thầm lặng” vì chúng ta không nhận ra chúng cho đến khi quá muộn. Kỹ thuật trên cung cấp một cách tiếp cận nhanh chóng và đơn giản để xác định và xác định những giả định nào bạn cần tập trung vào đầu tiên. Đôi khi, tất cả những gì cần là một cuộc điện thoại hoặc một email để nhận được câu trả lời. Tuy nhiên, rất nhiều team không thực hiện được bước đó.
Đừng trở thành nạn nhân của các giả định. PM phải có trách nhiệm hướng dẫn nhóm dự án các kỹ thuật nhận ra các giả định, phân loại, đánh giá và giải quyết các giả định trong khi PM sẽ tập trung quản lý phần còn lại là rủi ro. Cách chia sẻ công việc quản lý sẽ chuyển trạng thái của nhóm từ bị động sang chủ động hơn, không để xảy ra tình trạng "mất bò mới lo làm chuồng".
Đi cùng với giả định là các ràng buộc (constraint)
Ràng buộc là những giới hạn mà dự án phải chịu đựng, khác với Assumption là có thể xảy ra hay không, Constraints là đã xảy ra và bắt buộc mọi yếu tố khác xoay quanh nó.
Thí dụ đơn giản để chúng ta hiểu rõ hơn về Assumption và Constraint. Tôi muốn đi siêu thị mua đồ, siêu thị này ở rất xa tôi. Để đi đến đó tôi phải đi ít nhất là 1 giờ (nếu phương tiện là ô tô, xe máy, taxi).
Bạn lúc này chưa đi, giả định bây giờ là 6 giờ, bạn bắt đầu đi thì khoảng 7 giờ bạn sẽ tới. Đây là Assumption.
Tuy nhiên bạn dự tính sẽ mua rất nhiều đồ, bạn bắt buộc phải đi ô tô. Đây là ràng buộc (Constraint).
Những ràng buộc sẽ giúp dự án đi đúng “quỹ đạo”. Thí dụ: Với dự án phần mềm thương mại điện tử, thay đổi tính năng Đăng Nhập xác thực qua OTP có thể chỉ mất 3 ngày với 5 nhân sự, nhưng ngân sách cho việc thêm hoạt động giải trí này phải được xem xét, và cả tác động ảnh hưởng đến đường cơ sở (đường găng – Critical Path).
Quan hệ giữa giả định (assumption) và rủi ro (risk)
Rất nhiều người nhầm lẫn về bản chất của giả định và rủi ro, hoặc có thể hiểu chưa đúng về sự khác biệt cũng như quan hệ giữa chúng với nhau.
Giả định là một lòng tin của PM tin rằng một sự kiện gì sẽ xảy ra trong tương lai. Một giả định được giả định là đúng, nhưng thực tế nó không nhất thiết phải xảy ra đúng. Đôi khi nó không xảy ra và ảnh hưởng độ tin cậy dự án. PM cho risk vào dự án vì các giả định có thể xảy ra hay không xảy ra.
Rủi ro được định nghĩa là một mối đe dọa không chắc chắn, trong trường hợp xảy ra rủi ro đó, có thể có tác động tiêu cực đến việc hoàn thành mục tiêu của dự án. Mặt khác, một giả định là điều kiện cần thiết sẽ cho phép hoàn thành mục tiêu hoặc một tác vụ thành công.
Assumption đóng vai trò cực kỳ quan trọng trong xây dựng Risk Management Plan. Vì thế PM cần thu thập càng nhiều Assumption càng tốt.
Đối với giả định, nếu chúng ta không làm gì, thì sẽ không có hậu quả gì xảy ra. Vì PM đã ghi lại giả định đó, nhưng các bên liên quan không xác nhận giả định đó có thể xảy ra, do đó sẽ không đưa vào dự toán dự án, PM không có trách nhiệm phải xử lý phát sinh.
Đối với rủi ro, nếu chúng ta không làm gì, thì rủi ro đó sẽ chuyển hóa thành vấn đề "issue" và đội nhóm phải có trách nhiệm giải quyết.
Hãy quay lại thí dụ đi siêu thị ở trên, giả định đi lúc 6 giờ, nhưng bạn chưa quan tâm đến kẹt xe, và bạn có thể đến trễ hơn, bản kế hoạch mua sắm của bạn sẽ bị trễ "dây chuyền", điều này xem như giả định của bạn bị sai. Đáng nhẽ bạn phải giả định có kẹt xe thì 7h30 bạn mới đến được siêu thị. Giả định này có xảy ra thì bạn cũng đến như hoạch định, giả định này không xảy ra thì bạn cũng sẽ đến sớm.
Điều này có thể khó khăn khi bạn làm dự án, bạn giả định có một công cụ cho bạn thực hiện dự án trong giai đoạn nào đó, nhưng đến khi đó lại không có. Và bạn bị "mắc kẹt" trong tình huống khó khăn này. Thí dụ bạn giả định dự án phần mềm của bạn sẽ kết nối với Zalo để quản lý dữ liệu khách hàng tập trung. Nhưng đến khi vận hành thì bạn mới nhận ra Zalo chỉ cung cấp giới hạn băng thông dữ liệu, hoặc bạn sẽ phải nâng cấp với tài khoản có phí.
Assumption log là gì?
Các Assumptions sẽ được ghi chép lại dưới dạng nhật ký giả định (Assumption log) để tiện theo dõi những điều chỉnh, ghi lại tất cả các giả định và ràng buộc trong suốt vòng đời dự án. Nhật ký này sẽ xuất hiện ở các quy trình lập kế hoạch và kiểm soát dự án.
Assumption log là một kho lưu trữ cả giả định và ràng buộc (constraints), được bắt đầu tại thời điểm ra điều lệ dự án (Project Charter). Giả định và ràng buộc trước tiên được xác định ở mức cao trong tình huống kinh doanh (business case). Assumption và constraints sẽ tiếp tục mở rộng khi dự án đi vào triển khai.
Kết Luận
Khi muốn đánh giá xem một business case có đúng hay không, thì việc kiểm tra tính đúng đắn của các giả định có ý nghĩa quyết định, vì đây là "khâu yếu nhất" của dự án. Giả định đúng là tiền để quan trọng nhất để dự án đi đúng hướng và chịu tổn thất ở mức rủi ro thấp nhất.
Tham khảo: How to use the "Knowns" and "Unknowns" technique to manage assumptions
| Phạm Đình Trường CEO, Software Architect TIGO Solutions |
Khám phá thêm các chủ đề sau
19082021092841_thumb.png "Tại sao các dự án phần mềm sản xuất trong nước chậm nghiệm thu, ngay cả khi đã hoàn thành đúng tiến độ, thậm chí là vượt xa mong đợi? Bài viết sau đây sẽ cho chúng ta câu trả lời.")
Đọc thêm: Hướng dẫn hợp tác viết bài (guest blogging)
Các chủ đề được quan tâm nhiều nhất
CHIA SẺ BÀI VIẾT
Mới cập nhật