Bàn về quản lý rủi ro trong một dự án Scrum.

Chúng ta cảm thấy có vẻ như Scrum không "ngó ngàng" gì tới risk (rủi ro): không tồn tại một thứ gì đó như "risk log" hay risk cũng không phải là chủ đề chính thức có trong lịch Sprint Review hay Retrospective. Duy nhất chỉ có Development Team là phải chịu trách nhiệm về quality của sản phẩm và cách mà sản phẩm được tạo ra.

Ta có thể thấy chính điểm này là một risk! Nếu không có một cá nhân chụ thể chịu trách nhiệm cho chất lượng, sản phẩm được bàn giao đúng hạn, trong budget cho phép hay sản phẩm phát triển có đúng đắn ... thì risk được quản lý trong Scrum như thế nào?

Thực thế thì Scrum bản thân nó chính là quản lý rủi ro.

Risk là một phạm trù "cá nhân"

Đầu tiên, cần hiểu thế nào là risk. Theo từ điển Oxford English:

(Exposure to) the possibility of loss, injury, or other adverse or unwelcome circumstance; a chance or situation involving such a possibility.

Tạm dịch: là khả năng bị mất mát, tổn thất, hay gặp phải những tình huống không mong muốn; là một cơ hội hay tình huống mà có khả năng xảy ra.

Đây là một định nghĩa rộng. Và khiến risk như trở thành khái niệm chủ quan mà mỗi cá nhân tự diễn giải. Tức là chúng ta mỗi người sẽ nhìn vào risk một cách khác nhau.

Risk thật ra chịu ảnh hưởng lớn rằng việc đó liên quan đến cá nhân đó như thế nào. Ví dụ có một thanh niên nào đó mà chúng ta không quen đang đi dây giữa 2 toà nhà cao tầng, thì rõ ràng đó là risk với thanh niên đó, chứ không phải là risk của tôi :v

Công việc của chúng ta cũng xảy ra theo hướng tương tự, một project có thể mang trong nó risk đối với người này nhiều hơn so với người khác cùng làm việc trong một project.

Có nhiều loại risk khác nhau

Trong công việc, ta thường đề cập đến:

• Risk về tài chính (Financial risk) - liệu rằng ta có đủ trang trải cho nó?
• Risk về kinh doanh (Business risk) - liệu sản phẩm này có được sử dụng? Liệu nó có giúp giải quyết vấn đề?
• Risk về công nghệ (Technical risk) - liệu sản phẩm này có thể làm đc không? (thường thì chủ đề này liên quản đến tài chính, khi một sản phẩm có thể được làm mà không quá tốn kém)

Kiểm soát risk với Scrum

Scrum là một cách vô cùng tốt để chúng ta có thể kiểm soát risk trên nhiều phương diện - nhiều cách khác nhau. Dưới đây sẽ là những phân tích trên từng phương diện rủi ro.

Rủi ro tài chính

Khi ta có kế hoạch xây dựng một sản phẩm - dự án mới, ta có khuynh hướng muốn biết chi phí la bao nhiêu. Nhưng không may những sản phẩm có độ phức tạp cao là nguồn gốc của những điều không chắc chắn (uncertainty) lớn trong tương lai, mà càng không chắc chắn thì làm sao chúng ta có thể dự trù được chi phí một cách chính xác?!

Scrum không phải là không cần phải xác định scope, tính toán tài chính... như những dự án truyền thống khác. Cái khác của Scrum là chúng ta sẽ xây dựng sản phẩm một cách "vừa làm vừa học để cải thiện". Vì đây là cách tốt nhất để kiểm soát tương lai trong những môi trường phức tạp.

Trong Scrum, chúng ta xác định rõ các vai trò và trách nhiệm:

• Chúng ta chỉ định một Product Owner, vai trò của anh/ chị ấy là kiểm soát budget và kế hoạch của sản phẩm
• Chúng ta chỉ định một Development Team biết tự quản lý (self-organized) có đầy đủ chức năng cần thiết (cross-functional) để có thể hoàn thành sản phẩm, từ đầu đến cuối.
• Chúng ta chỉ định và yêu cầu Scrum Master tổ chức và hướng dẫn Scrum Team hoan nghênh quy trình "vừa làm vừa học để cải tiến" và khiến team trở nên tốt hơn mỗi ngày.

Sau đó Scrum Team sẽ được hỏi mất bao lâu để có thể hiện thực hóa "điều ước" đầu tiên của stakeholder vào trong sản phẩm. Và khoảng thời gian này càng ngắn thì càng được hoan nghênh vì đó là tiền bạc và hơn nữa ta sẽ kiếm chứng được sớm rằng chúng ta có đang mất tiền xây dựng một sản phẩm sai hay không?!

Ta có thể kêu gọi các nhà tài trợ, đầu tư trước vào vài Sprints và xem kết quả sau từng Sprint để kiếm chức sự đầu tư của họ là đúng đắn hay không. Lúc này chi phí là ước tính được (vì chắc chắn ta biết mất bao nhiêu cho vài Sprint)

Sản phẩm càng sớm được tung ta thị trường bao nhiêu thì rủi ro tài chính càng được giảm thiểu bấy nhiêu.

Rủi ro về kinh doanh

Rủi ro về kinh doanh có nghĩa là user không thực sự sử dụng sản phẩm, đồng nghĩa không cải thiện được vấn đề mà sản phẩm này nên giải quyết từ đầu. Chuyện này thì xảy ra như cơm bữa. Lý do không phải là Development Team bị dốt hay ngu si mà đa phần là user chỉ thực sự biết họ muốn gì giây phút mà họ thực sự chạm tay dùng sản phẩm. Mọi nỗ lực trước đó như làm mịn Product Backlog, survey, làm requirements... không khiến rủi ro rằng user có sử dụng sản phẩm này mất đi.

Trong Scrum, vai trò của Product Owner là giữ liên lạc mật thiết với các stakeholder và Development Team, từ đó để xây dựng sản phẩm một cách đúng đắn.

Product Owner không phải là stakeholder, mà là đại diện của mảng kinh doanh trong Scrum Team để quản lý và theo dõi các risk kinh doan từ đó tạo ra các sản phẩm phù hợp nhất có thể.

Rủi ro công nghệ

Rủi ro mặt công nghệ có thể được chia thành 2 nhóm sau:

• Liệu sản phẩm có thể được hoàn thành với kết quả ROI (Return On Investment) tốt?
• Liệu chúng ta có thể bảo trì (maintain) sản phẩm về sau không?

Đây là 2 câu hỏi quan trọng mà bạn sẽ muốn hỏi bản thân trong suốt hành trình phát triển sản phẩm.

Hằng ngày các quyết định được Development Team tạo ra xem liệu rằng công sức bỏ ra cho tính năng này có đáng với giá trị mà Product Owner đang định hướng hay không. Do đó mà vấn đề giao tiếp là vô cùng quan trọng.

Câu hỏi thứ 2: về việc bảo trì có khả thi hay không. Chúng ta cần phải để mắt cẩn trọng đến những vấn đề về công nghệ, kĩ thuật. Có nghĩa là khi phát hiện chất lượng kĩ thuật không tốt, chúng ta cần phải sớm giải quyết nó (dù cho chỉ là một chút đi chăng nữa).

Definition Of Done - DoD (Định nghĩa của hoàn thành) là câu trả lời cho vấn đề này. Trong Scrum, những hạng mục được quy định trong DoD là nhân tố quan trọng trong việc kiểm soát vấn đề kĩ thuật.

Scrum values

Ngoài ra các Scrum values (các phẩm chất mà mỗi thành viên Scrum Team nên có mà Scrum xem trọng) là yếu tố quan trọng để chắc chắn các risk được minh bạch, và được xem xét vào đúng thời gian bởi đúng cá nhân có trách nhiệm với nỗ lực hợp lý.

Các bạn hãy dành thời gian đọc thêm/ đọc lại về những values này và xem chúng có ảnh hưởng ra sao đến các risk trong dự án nhé.

Trong những môi trường phức tạp như phát triển phần mềm, có muôn vàn các rủi ro - risk. Chúng ta có thể lựa chọn hoặc là sợ hãi chúng, phân tích, tính toán chúng hay cách khác là xây dựng từng phần của sản phẩm, đánh giá và thích ứng, đưa chúng đến với user sau mỗi Sprint.

Nguồn: https://www.scrum.org/resources/blog/managing-risk