Quản lý rủi ro dự án là phạm trù rộng lớn, theo đó trong dự án chúng ta cần quản lý rủi ro tới từ nhiều phía. Rủi ro từ phía khách hàng, rủi ro từ nguồn lực thực hiện dự án (nhóm phát triển), rủi ro tới từ quy trình phát triển sản phẩm, rủi ro từ hiểu biết về công nghệ, rủi ro tới từ thị trường, rủi ro tới từ các quyết định của các cấp quản lý…
Trong mô hình phát triển sản phẩm truyền thống, các rủi ro này được quản lý dự án định nghĩa và quản lý trong suốt quá trình thực hiện, và mặc dù nó là một công việc có khối lượng khổng lồ cần rất nhiều thông tin để đưa ra các đánh giá và quyết định, quản lý dự án thường rất bị động trong việc tiếp nhận thông tin tới từ các bộ phận trong dự án và các bên liên quan: đôi khi nó quá chậm, hoặc đôi khi, độ chính xác của nó cần được lên án!Vậy Scrum thực hiện quản lý rủi ro dự án bằng cách nào? Hay như thế nào?
Scrum framework được tổ chức gồm 3 vai trò: product owner, scrum master, development team; cả 3 vai trò trên đều thực hiện việc quản lý rủi ro dự án theo các công việc mà mình đảm nhận, được thiết kế thông qua các sự kiện trong framework. Thông qua đó, việc đánh giá và xử lý các rủi ro được trao cho các vai trò cụ thể. Mỗi vai trò sẽ có trách nhiệm giải quyết những vấn đề ảnh hưởng tới sự thành công của dự án liên quan công việc mà mình đảm nhận.Các sự kiện giúp xác định rủi ro và hạn chế rủi ro
Dailly Meeting tuân theo framework, với các sự kiện, scrum team sớm phát hiện các vấn đề cần xử lý để lập kế hoạch hành động nhằm thích ứng hoặc giải quyết.
Ví dụ với Daily Meeting nhóm đồng bộ thông tin sau mỗi 24h, tự lên kế hoạch để thích nghi và giải quyết các vấn đề ảnh hưởng tới mục tiêu của nhóm. Hoặc lúc này scrum master sẽ có trách nhiệm hỗ trợ giải quyết các vướng mắc từ bên ngoài tác động tới công việc của nhóm. Việc trao quyền cho nhóm tự giải quyết các khó khăn lúc đầu có thể là thách thức với các bên: nhóm quản lý, PO, SM và chính cả nhóm phát triển. Tuy nhiên về lâu dài, điều này khuyến khích nhóm tự quản lý, nâng cao trách nhiệm, tính chủ động và tăng khả năng dự đoán của nhóm. Một nhóm tự quản lý, có trách nhiệm và khả năng dự đoán có thể tin tưởng được chắc chắn sẽ hạn chế rủi ro cho bất kì dự án nào.Sprint Planning cùng với Dailly meeting, sprint planning cho phép nhóm lập kế hoạch ở mức sản phẩm, trong khoảng thời gian ngắn dưới sự tối ưu giá trị công việc từ product owner.
Product owner sắp xếp các công việc, theo độ ưu tiên để nhóm phát triển thực hiện trong Sprint. Điều này giúp sản phẩm luôn mang tới giá trị lớn nhất cho khách hàng và các bên liên quan. Các thông tin được nhóm lập kế hoạch dựa trên kinh nghiệm đã trải qua trong quá khứ (các sprint trước) dẫn tới tính tin cậy cao hơn. Việc trao quyền lập kế hoạch phát triển cho nhóm phát triển cũng giúp các bên có trách nhiệm liên quan nhìn nhận thực tế, tránh đi vào việc kì vọng vượt quá khả năng thực tại và gây ra những quyết định sai lầm. Nhóm lập kế hoạch dựa trên những user story là đại diện cho những yêu cầu của người dùng, điều này giúp nhóm phát triển hiểu đúng mong muốn của khách hàng, giảm thiểu lãng phí nguồn lực trong quá trình phát triển. Sprint planning không phải là kế hoạch hoàn hảo 100% nhưng nó là kế hoạch đáng tin cậy để thực hiện những tác vụ quan trọng nhất.Sprint refinerment là một sự kiện dễ bị bỏ qua nhưng lại rất quan trọng.
Có thể hiểu đây là một buổi lập kế hoạch cho buổi lập kế hoạch. Tuân theo scrum framework, mọi thứ đều được chuẩn bị và trù liệu nhằm tăng khả năng thành công của dự án. Để đổi lại điều này, chúng ta cần dành ra thêm thời gian để meeting, tuy nhiên nó đáng giá để đánh đổi.Sprint review nơi mà scrum team cộng tác với khách hàng nhằm thích nghi với sản phẩm và lên kế hoạch cho những gì thực hiện tiếp theo.
Không giống cách làm truyền thống, sau quá trình phát triển, kiểm thử khách hàng mới được tiếp cận sản phẩm, đôi khi lúc này phản hồi của khách hàng là quá trễ cho sự thay đổi của thị trường hoặc nhu cầu. Chu trình lặp đi lặp lại, phát triển, kiểm thử, phản hồi (quá muộn). Việc này đặt khách hàng và nhóm phát triển vào các tình thế khó khăn khác nhau. Scrum framework xử lý vấn đề này bằng sự kiện sprint review, nơi khách hàng có thể “dùng” sản phẩm sau mỗi 2-4 tuần. Đánh giá tính khả thi và đưa ra quyết định. Ngoài ra điều này cũng kéo khách hàng gần hơn với nhóm phát triển để thông qua đó, hiểu nhóm đang nỗ lực; và có thể cung cấp thông tin phản hồi sớm hơn. Điều này giúp giảm thiểu các rủi ro từ phía khách hàng, từ việc hiểu sai yêu cầu, thay đổi và phản hồi; hoặc đôi khi là nhận xét nhóm phát triển đang không nỗ lực.Sprint restropective scrum team cải tiến chất lượng.
Tại buổi hợp restropective, scrum team tìm giải pháp để cải tiến các vấn đề về con người và quy trình, lấy ra ít nhất một cải tiến được đánh độ ưu tiên để thực hiện trong sprint tiếp theo. Việc không ngừng cải tiến và thực thi cách tương tác, và quy trình làm việc giúp giảm thiểu rủi ro cho những việc được phát hiện, nhưng bị “bỏ quên”.Các Role quản lý rủi ro
Scrum team định nghĩa 3 vai trò: Product Owner, Scrum Master và Development Team. 3 vai trò thực hiện những công việc khác nhau, theo quy trình Scrum giúp giảm thiểu rủi ro.
Product owner giảm thiểu rủi ro cho dự án bằng cách lập kế hoạch phát hành sản phẩm, tối ưu hoá ROI, và năng suất làm việc của nhóm.
Product Owner quản lý product backlog hay những “yêu cầu” từ phía khách hàng, thị trường hoặc bên liên quan. Việc quản lý product backlog bao gồm các nhiệm vụ: Thêm mới yêu cầu, phân tách chức năng thành những yêu cầu nhỏ hơn, đặt tiêu chí hoàn thành, tiêu chí chấp nhận cho user story; và quan trong là việc sắp xếp lại độ ưu tiên cho các user story. Việc này giúp scrum team ưu tiên tập trung vào các công việc có giá trị cao trước, thêm nữa, các công việc này khá rõ ràng để hiểu và thực hiện. Product owner cũng là người làm việc nhiều với các bên liên quan, tìm kiếm những yêu cầu để đưa vào product backlog, hạn chế việc một developer với ngôn ngữ kĩ thuật làm việc với một khách hàng có ngôn ngữ end user, điều này có thể gây conflix không cần thiết trong nhóm phát triển.Development team giảm thiểu rủi ro thông qua việc thích nghi với quy trình, phát lộ các vấn đề trong các sự kiện Scrum và giải quyết chúng. Tập trung vào sprint backlog và sprint goal.
Giống product owner chỉ tập trung vào product backlog, development team chỉ tập trung vào sprint backlog. Nơi mọi công việc đã được lập kế hoạch trong sprint planning. Mọi thay đổi không nằm trong kế hoạch sẽ được đánh giá và thảo luận với sự đồng thuận của nhóm phát triển. Việc này duy trì khả năng cam kết của nhóm, khả năng tự tổ chức. Điều này giúp các kế hoạch ban đầu luôn có khả năng hoàn thành cao hơn. Và các dự đoán của nhóm phát triển ngày càng trở nên tin cậy hơn.Scrum Master đảm bảo quy trình được vận hành đúng, hỗ trợ tháo gỡ các khó khăn trong quá trình làm việc cho PO và Development Team. Ngoài ra Scrum Master cũng là người chịu trách nhiệm để 3 trụ cột của Scrum được tuân thủ: minh bạch, thanh tra và thích nghi. Việc thực hiện thanh tra và thích nghi giúp tạo ra sự minh bạch. Minh bạch cuối cùng sẽ giảm thiểu rủi ro khi thực hiện dự án.
Thông qua Agile và Scrum framework, việc quản lý rủi ro được “điều phối” cho 3 vai trò và các sự kiện thay vì tập trung việc quản lý rủi ro cho vị trí Project Manager như cách làm truyền thống.
Thế giới của những người làm phần mềm tồn tại một quy trình sản xuất từ lâu đời. Ở đó, quy trình gồm các bước xác định vấn đề, lập kế hoạch, thực thi, kiểm tra, và cuối cùng đưa ra sản phẩm cho người dùng sử dụng. Đó là quá trình liên tục, có hệ thống, có trật tự từng bước. Người dùng chỉ nhận được giá trị ở cuối của chu trình sản xuất.
Song song với đó, một cách làm khác, được dân phần mềm gọi là Agile (tức là linh hoạt) giúp phát triển phần mềm theo các vòng lặp, các bước ở quy trình sản xuất phần mềm cũ được lặp đi lặp lại trong một khoảng thời gian ngắn, cố định. Điều này giúp liên tục đưa ra các giá trị (nhỏ, có thể sử dụng ngay) cho khách hàng. Sự khác biệt trong cách tiếp cận này là giá trị được tạo ra liên tục và trong thời gian ngắn, đón nhận các phản hồi. Điều này giúp tất cả các bên tham gia vào quá trình dự án thích nghi với các thay đổi, đồng ý với nhau về các hiệu chỉnh nhanh và dễ dàng hơn, đón nhận thông tin sớm và kịp thời hơn để ra quyết định.
Rủi ro được quản lý theo các vòng đời ngắn, giúp giảm thiểu các nguy cơ
Agile – cách tiếp cận linh hoạt này được thiết kế ra từ nhu cầu làm dự án của các công ty phần mềm theo brief (yêu cầu đặt hàng) của khách hàng. Theo cách tiếp cận thứ nhất, khi mất quá nhiều thời gian tập trung xây một giải pháp cho đến cùng, khi release – phát hành thì có thể cả tính năng và công nghệ đều đã lạc hậu so với sự thay đổi quá nhanh chóng của thời thế. Do đó, ngành phần mềm tạo ra cách tiếp cận thứ 2, vừa xây vừa cập nhật vừa hiệu chỉnh vừa tối ưu và mang lại giá trị tức thì.
Sau này, agile đã trở thành một tư duy, cách tiếp cận trong kinh doanh và công việc. Thay vì đổ một chiều như thác từ cấp trên xuống cấp dưới hay từ phòng ban này sang phòng ban kia, chúng ta có thể sử dụng cách tiếp cận cùng nhau đặt vấn đề, cùng bàn bạc giải quyết, tạo ra giá trị tại từng chặng nhỏ, và cùng nhau cập nhật những thay đổi mới nhất vào dự án trong suốt quá trình thực hiện. Với cách tiếp cận này, đội ngũ sẽ làm việc linh hoạt hơn, đội nhóm hơn, giải quyết vấn đề nhanh và cập nhật hơn, và tạo ra giá trị nhanh và nhiều hơn.
