Hợp đồng Agile (Agile Contract)

Một trong các thách thức khi áp dụng Agile là hợp đồng với khách hàng. Cụ thể là vấn đề thỏa thuận và cộng tác. Làm thế nào để khách hàng và nhà cung cấp phần mềm cùng làm việc và chia sẻ rủi ro. Nếu nhà cung cấp phần mềm đã Agile nhưng khách hàng thì không Agile thì phải làm thế nào.

Hợp đồng truyền thống với tư duy khác với Agile

Trước hết, chúng ta quay lại xem xét khái niệm hợp đồng theo truyền thống. Quan điểm truyền thống coi hợp đồng như sự ghi nhớ hợp pháp, trở thành lá chắn bảo vệ mỗi bên khi có điều gì đó sai sai xảy ra.

Theo cấu trúc của hợp đồng truyền thống, khách hàng yêu cầu nhà cung cấp đáp ứng các yêu cầu của mình, thường là rất cụ thể và chi tiết. Đi kèm với yêu cầu này là giá cả và thời hạn hoàn thành.

Tuy nhiên một dự án phần mềm thường đối diện rất nhiều yếu tố rủi ro khó lường. Do đó những yêu cầu quá chi tiết thường hay bị thay đổi và ảnh hưởng đến ngân sách và nguồn lực của dự án.

Khi có thay đổi yêu cầu, sẽ kéo theo hoặc khách hàng phải trả thêm tiền cho phần này, hoặc nhà cung cấp phải tự trả chi phí phát sinh. Nếu không thỏa thuận được sẽ thành mâu thuẫn giữa khách hàng và nhà cung cấp. Để đối phó với khả năng phải tự trả chi phí phát sinh này, nhà cung cấp thường thêm tỷ lệ buffer vào báo giá, thường là 20%.

Trong khi đó quan điểm của Tuyên ngôn Agile và Nguyên tắc Agile là chào đón việc thay đổi yêu cầu. Tranh cãi giữa khách hàng và nhà cung cấp là không cần thiết. Sự thay đổi yêu cầu của khách hàng càng về cuối dự án sẽ càng phản ánh chính xác hơn yêu cầu thực sự của họ và có thể tạo thêm giá trị lớn hơn cho dự án. Với Agile, khách hàng và nhà cung cấp sẽ làm việc cộng tác với nhau để tạo ra giải pháp mang lại lợi ích và giá trị lớn nhất cho cả hai.

Vì vậy, nếu quá tập trung vào quan điểm của hợp đồng truyền thống sử dụng cho việc tranh luận khi có mâu thuẫn, sẽ không thể tạo ra một thắng lợi cho cả hai bên.

Lợi ích của hợp đồng Agile

Khi xây dựng hợp đồng theo quan điểm Agile, cần tập trung vào mức độ tin tưởng và hợp tác giữa khách hàng và nhà cung cấp. Tin tưởng là thứ khó nhất để mô tả trong hợp đồng truyền thống với rất nhiều điều khoản trói buộc về quyền lợi và trách nhiệm khi có rủi ro.

Nếu hai bên mới làm việc với nhau, mức độ tin tưởng và cộng tác thường rất khó đánh giá. Trong khi đó rủi ro cần chia sẻ trách nhiệm từ cả hai phía theo quan điểm cộng tác của Agile khi mà một dự án có quá nhiều điều khó lường. Sự tin tưởng và cộng tác hai bên càng cao, các hiện tượng sau càng giảm:

• Nhà cung cấp sẽ không đưa thêm buffer khiến cho khách hàng bị tăng chi phí.
• Khách hàng cũng không cần phải mất thời gian đưa yêu cầu quá chi tiết.
  

Làm sao xây dựng được hợp đồng Agile

Khi xây dựng hợp đồng Agile, không có nghĩa phải phá bỏ đi hợp đồng truyền thống. Hợp đồng truyền thống được coi là một hợp đồng khung (Master Agreement) với những thỏa thuận chính về nguyên tắc giữa hai bên. Các thay đổi hoặc các yêu cầu mới sẽ được đưa ra như một hợp đồng mở rộng. Các hợp đồng với điều khoản mở rộng này đưa ra theo từng sprint.

Sau đây là các hướng dẫn để xây dựng hợp đồng kiểu này

• Tập trung vào mô tả outcome (lợi ích, giá trị thu được) hơn là output (mô tả tính năng, sản phẩm đầu ra). Nếu chưa rõ, bạn có thể tham khải khái niệm outcome và output trong bài business case là gì. Cách này sẽ hướng khách hàng và nhà cung cấp tập trung thảo luận tìm và điều chỉnh output cho phù hợp. Thách thức là rất khó mô tả Outcome, nên giải pháp trung gian là mô tả Service Level và tốc độ triển khai để hướng dẫn hai bên có sự phản hồi và thay đổi kịp thời.
• Mô tả mức độ khách hàng bỏ thời gian đầu tư sự tập trung vào dự án, nhờ đó giúp bên cung cấp có thể cộng tác tốt hơn. Nếu có sự tham gia dự án chặt chẽ từ khách hàng, việc ra quyết định và sự chính xác của dự án sẽ tiến triển nhanh.
• Thỏa thuận cho phép dừng dự án bất kể lúc nào nếu khách hàng cảm thấy dự án không còn giá trị. Điều này không nên coi là phá vỡ hợp đồng, Khách hàng sẽ thấy có lợi khi thấy chỉ nhận vài outcome trong các sprint đầu mà thỏa mãn yêu cầu, nhờ đó không cần phải trả tiền cho các sprint sau nữa.
• Có thể đưa thêm phần thưởng gia tăng cho việc nhà cung cấp bàn giao sản phẩm sớm hơn hạn định, hoặc giảm phần tiền phải thanh toán nếu bàn giao sản phẩm chậm hơn hạn định. Mức thưởng tùy thuộc vào mức độ tin tưởng giữa hai bên. Nếu mức tin tưởng rất cao, không cần thiết phải có phần thưởng. Nếu mức tin tưởng là thấp, khái niệm phạt nhà cung cấp được đưa vào. Nếu mức tin tưởng là ổn, ta sẽ tránh gọi là phạt và gọi là thưởng hoặc tín dụng.
• Các yêu cầu của khách hàng được định nghĩa trong hợp đồng là ở mức cao và tổng quát, không chi tiết. Khi các yêu cầu không mô tả chi tiết lúc bắt đầu, nó cho phép chỉnh sửa trong sprint mà không cần tiết đến việc quản lý thay đổi yêu cầu.
• Các yêu cầu cần phải được đánh độ ưu tiên (Xem thêm Làm sao sắp xếp ưu tiên User Story trên Backlog). Như vậy yêu cầu nào quan trọng nhất cần phải làm trước.
• Các thay đổi yêu cầu sẽ được coi như những yêu cầu mới đưa vào trong danh sách yêu cầu. Chi phí để đáp ứng yêu cầu mới này có thể bù đắp bởi chi phí của những yêu cầu khác ít quan trọng, chưa làm tới và có thể không cần làm nữa.
• Tùy thuộc mức độ tin tưởng mà có thể thêm hoặc bớt các điều khoản. Như vậy có thể bắt đầu với một hợp đồng nhiều điều khoản khi hai bên còn thiếu tin tưởng. Sau đó các điều khoản không cần thiết nữa sẽ được loại trừ dần khi sự tin tưởng gia tăng.

Nguồn: PRINCE2 Agile - by AXELOS.com

‍