|
Nhiều năm trước, tôi bắt đầu tìm hiểu và quan sát cách thức hoạt động của các dự án phần mềm. Lý do tôi quan tâm đến việc này là vì, nhiều dự án thậm chí đã rất thành công trong việc deliver đúng hạn, đạt được đúng yêu cầu đề ra ban đầu, và hoàn thành trong chi phí cho phép. Tuy nhiên, khi nó được đưa ra thị trường thì không ai sử dụng cả. Sau đó sản phẩm đó cũng chết đi để lại nhiều sự lãng phí trong đầu tư và sức lực của các bên để đảm bảo nó được hoàn thành.
Từ đó, trong đầu tôi luôn tồn tại một câu hỏi: Điều gì tạo ra khoảng cách giữa một sản phẩm thành công, được đón nhận bởi người dùng và một sản phẩm thất bại? Qua nhiều năm quan sát, tôi rút ra được một điều, một trong những lý do sản phẩm không được đón nhận như nó được kỳ vọng đa phần là vì nó bị đánh giá sai giữa "Input", "Output" và "Outcome". 
Input - Output - Outcome
Định nghĩa "Input", "Output" và "Outcome"
Trước khi đi sâu vào chi tiết, tôi xin chia sẻ định nghĩa của "Input", "Output" và "Outcome":
Input: Dữ kiện đầu vào, trong trường hợp của một sản phẩm hay dự án sẽ là: Tiền, thời gian dự kiến, con người hay nỗ lực bỏ ra, kế hoạch, và những tài liệu được chuẩn bị ban đầu cần cho việc thực thi dự án hay sản phẩm đó. Output: Dữ kiện đầu ra của quá trình, trong trường hợp của sản phẩm hay dự án sẽ là: chức năng, sản phẩm, hay dịch vụ có thể sử dụng được bởi người dùng. (có thể định lượng được.) Outcome: Là sự phản hồi hay cảm nhận từ phía người dùng cuối về sản phẩm hay dịch vụ đó và qua đó mang lại giá trị cho sản phẩm hay chức năng đó. (khó định lượng, hay đo lường)
Nếu chúng ta xem xét rõ hơn, khi những đầu tư về tiền, con người, và công nghệ cho những dự án là “Input”, thì kết quả của việc đầu tư đó là sản phẩm, với chức năng đầy đủ với yêu cầu ban đầu, đúng hạn và trong chi phí cho phép là “Output”. Bước cuối cùng, khi sản phẩm được đưa ra thị trường sử dụng bởi người dùng, và cảm nhận của họ với sản phẩm hay dịch vụ đó là “Outcome”.
Nét gãy giữa Input, Output và Outcome
Có nhiều người cho rằng, sản phẩm được xây dựng hoàn thiện, càng nhiều tính năng hơn đối thủ, thì sẽ càng dễ thành công. Điều đó không sai, nhưng còn chịu sự chi phối của một yếu tố khác. Chính là: tính năng hay sản phẩm đó được người dùng sử dụng như thế nào? Điều đó mới là cốt lõi mang lại giá trị. Nếu sản phẩm của bạn có nhiều tính năng hơn, nhưng những tính năng đó lại không được đón nhận hay trở nên vô dụng thì cũng không làm cho sản phẩm của bạn được người dùng ưa thích mà còn lãng phí tài nguyên (Input) để xây dựng nó nữa.
Lĩnh vực phát triển phần mềm vô cùng phức tạp. Bởi “Công Nghệ”, “Con Người” và “Thị Trường” là ba yếu tố khó đoán. Vì vậy, việc xây dựng càng nhiều tính năng, tập trung quá nhiều đề hoàn thiện ý tưởng ngay từ ban đầu, nhưng thiếu liên kết nó với thị trường là một điều rất nguy hiểm. Nó dẫn đến nguy cơ sản phẩm đó không được đón nhận bởi người dùng. (Xem hình bên dưới). 
Input - Output - Outcome with Scrum
Chính vì lẽ đó, làm sao để sản phẩm của bạn kết nối được với người dùng, thu thập được cảm nhận của họ càng sớm và thường xuyên, thì bạn sẽ càng có đủ dữ kiện và thông tin để hoàn thiện Giá trị sản phẩm (Product values) của mình. Thay vì chỉ xây dựng sản phẩm dựa trên những giả định ban đầu, dồn hết nguồn tài nguyên và tiêu tốn một thời gian dài để thực hiện, rồi mới đưa nó ra thị trường như một canh bạc lớn, nơi mà con người và những đối thủ của bạn luôn thay đổi và ngày càng cải tiến hơn. Kết Luận
"Input", "Output" hay "Outcome" đều quan trọng. Nếu quên mất một góc nào hay thiếu sự liên kết giữa chúng sẽ gây ảnh hưởng (Impact) đến khả năng thành công của sản phẩm. Chính vậy, việc xây dựng một vòng lặp có liên kết chặt chẽ, deliver giá trị đến người dùng thường xuyên để kiểm nghiệm và học hỏi từ người dùng là vô cùng cần thiết.
Đó cũng chính là giá trị cốt lõi của Scrum. Qua mỗi Sprint (Time-box không quá một tháng), chúng ta đều có được một Working Product sẵn sàng để test thử trên thị trường. Và từ đó, chúng ta lại có được phản hồi, để cải tiến sản phẩm trong những Sprint tiếp theo, tạo thành một chuỗi liên kết chặt chẽ giữa "Input", "Output" và "Outcome". |
AuthorName: Khoa Doan 
|
