Scope Creep and Gold Plating:: The Old Problems Every Software Project Eventually Meets

Một Cái Nút Nhỏ, Một Bài Học Lớn Hơn

Sáng nay tôi có một cuộc trao đổi khá thú vị với một bạn developer trong team.

Bạn ấy đã implement một thay đổi cho đoạn text của một button đã được sử dụng trong hệ thống suốt nhiều năm qua. Khi tôi hỏi lý do, bạn giải thích rằng đoạn text mới chính xác hơn về mặt ngữ nghĩa và phản ánh đúng hành động của người dùng hơn. Về mặt kỹ thuật, bạn ấy không sai. Thậm chí có thể nói là đúng.

Nhưng với vai trò Product Owner, câu hỏi tiếp theo của tôi rất đơn giản:

Lợi ích cho khách hàng là gì? 

• Cả hai cùng im lặng một lúc.

Rồi tôi tiếp tục hỏi.

Người dùng hiện tại có đang hiểu sai ý nghĩa của button này không?

• Không.

Có ticket, complaint hay feedback nào liên quan đến button này không?

• Không.

Có trường hợp nào người dùng bấm nhầm nút vì đoạn text hiện tại không?

• Không.

Nó có gây ra vấn đề nghiệp vụ nào không?

• Không.

Việc đổi text có giúp giảm effort đào tạo người dùng không?

• Không.

Việc đổi text có giúp tăng năng suất làm việc không?

• Không.

Có yêu cầu nào từ khách hàng hoặc business owner không?

• Cũng không.

Đến lúc đó, cả hai đều hiểu cuộc trao đổi đang đi về đâu. Đề xuất này vẫn cần effort để phát triển. Vẫn cần effort để kiểm thử. Vẫn cần cập nhật tài liệu. Vẫn cần cập nhật release note.

Và với vai trò Product Owner, cuối cùng tôi vẫn phải giải thích được giá trị kinh doanh của thay đổi này. Tất cả những việc đó chỉ để thay đổi một button vốn đã hoạt động ổn định suốt nhiều năm. Đúng là đoạn text mới có thể chính xác hơn. Nhưng chính xác hơn chưa chắc đã tạo ra giá trị.

Trong phát triển phần mềm, chúng ta rất dễ rơi vào cái bẫy cho rằng bất kỳ sự cải tiến nào cũng là một cải tiến có giá trị, chỉ vì nó làm sản phẩm trông gọn gàng hơn, đẹp hơn hoặc "đúng" hơn. Nhưng sản phẩm không tồn tại để thỏa mãn cảm giác hoàn hảo của đội phát triển. Sản phẩm tồn tại để giải quyết vấn đề cho khách hàng. Sau khi trao đổi, tôi quyết định từ chối đề xuất này. Không phải vì bạn developer sai. Thực ra ý định của bạn ấy hoàn toàn tốt. Bạn muốn cải thiện sản phẩm. Nhưng quyết định về sản phẩm cần được dẫn dắt bởi giá trị, không phải bởi sở thích cá nhân. 

Cuộc trao đổi nhỏ đó làm tôi nhớ lại một điều mà tôi đã học được nhiều lần trong suốt sự nghiệp của mình:

Không phải mọi cải tiến đều thực sự là cải tiến. 

Đôi khi quyết định tốt nhất là không thay đổi gì cả.

Đặc biệt khi không có vấn đề nào thực sự cần được giải quyết.

Là Product Owner hay Project Manager, trách nhiệm của chúng ta không chỉ là hỏi:

"Chúng ta có làm được không?"

Mà quan trọng hơn là phải hỏi:

"Tại sao chúng ta phải làm việc này?"

Câu kết "Tại sao chúng ta phải làm việc này?" thực ra chính là cốt lõi của Product Management. Developer thường tập trung vào giải pháp. PO phải tập trung vào giá trị. Và rất nhiều Gold Plating bắt đầu từ việc cả team nhảy ngay vào giải pháp trước khi xác định xem có vấn đề nào thực sự tồn tại hay không.