Áp dụng mô hình Kano trong cách code
Bài viết được sự cho phép của tác giả Phạm Bình
Chào các bạn,
Điều đầu tiên mình phải khẳng định luôn Kano không phải là một design pattern, nó cũng không phải là tên một framework hay bất kỳ một khái niệm công nghệ nào. Mà nó là một mô hình cho kỹ thuật phân loại tính năng từ góc nhìn của khách hàng.
Tại sao lại vậy? Mô hình này thì có liên quan gì tới code? Thì mời các bạn hãy theo dõi bài viết này nhé.
I. TÌM HIỂU VỀ KANO MODEL (MÔ HÌNH KANO)
1.1 Mô hình Kano là gì?
Kano là một mô hình dùng để phân loại tính năng từ góc nhìn của khách hàng. Mô hình này được giáo sư Noriaki Kano ứng dụng vào thập niên 80 để giúp đội ngũ thiết kế hiểu được yêu cầu và tầm quan trọng của sản phẩm xét từ góc độ của khách hàng.
1.2 Mô hình Kano hoạt động như thế nào?
Kano phân loại thuộc tính (tính năng) của sản phẩm thành 3 nhóm chính
Nhóm 1: Nhóm tính năng cơ bản
Đây là nhóm tính năng sản phẩm cần phải có, nhất định phải có. Nếu không có nhóm tính năng này thì sản phẩm sẽ mất đi cái bản chất, mất đi cái giá trị cốt lõi. Ví dụ điện thoại thì dùng để nghe – gọi, đồng hồ dùng để xem giờ, đèn dùng để chiếu sáng,…
Đây là nhóm tính năng cần phải đầu tư để thực hiện, nếu sản phẩm tạo ra mà không có các tính năng nằm trong nhóm này thì người sử dụng sẽ không thể dùng nổi và cảm thấy bực bội.
Đây là nhóm tính năng cần phải ưu tiên làm trước. Tuy nhiên có một lưu ý là dù bạn có làm tốt nhóm tính năng này đến mấy thì khách hàng cũng không cảm thấy thỏa mãn hơn là bao. Bởi nghiêm nhiên điện thoại là phải nghe gọi được, đồng hồ phải xem giờ được,…
Chốt: Đây là nhóm tính năng mà sản phẩm nhất định phải có, không có không được. Độ ưu tiên là 1.
Nhóm 2: Nhóm tính năng mong đợi
Đây là nhóm tính năng thiên về hiệu suất của sản phẩm, là các tính năng mà càng có thì càng tốt. Ví dụ điện thoại ngoài nghe gọi thì có thể kết nối internet, nghe nhạc, chụp hình; Đồng hồ ngoài xem giờ thì có thể đo được nhịp tim, đo số bước chân; Máy tính thì càng xử lý nhanh thì càng tốt,…
Đây là nhóm tính năng mà khách hàng không thật sự cần, tuy nhiên sản phẩm càng có nhiều thì khách hàng càng hài lòng. Nhưng cũng cần phải lưu ý, việc triển khai các tính năng nằm ở nhóm này sẽ kéo giá thành của sản phẩm tăng lên. Vì vậy bạn cần phải cân bằng sao cho vừa đảm bảo được sự hài lòng của khách, vừa đảm bảo được giá thành sản phẩm.
Chốt: Đây là nhóm tính năng mà sản phẩm càng có nhiều thì khách hàng càng hài lòng. Độ ưu tiên là 2.
Nhóm 3: Nhóm tính năng vượt qua kỳ vọng của khách hàng, gây phấn khích khi sử dụng
Đây là nhóm tính năng rất bá đạo, rất ưu việt, rất độc đáo mà khi khách hàng trải nghiệm sẽ cảm thấy phấn khích, thích thú. Ví dụ như smartphone có các trợ lý ảo có thể giao tiếp bằng giọng nói với người sử dụng; Công nghệ sạc không dây,…
Vì đây là những tính năng mà khách hàng không ngờ tới, nên khi phát hiển ra họ sẽ cảm thấy vô cùng sung sướng, trầm trồ trước tính năng của sản phẩm. Tuy nhiên đây là nhóm tính năng mà cho dù không có cũng không làm giảm sự thỏa mãn của khách hàng, vì ngay từ đầu họ không nghĩ rằng là sản phẩm của bạn sẽ có.
Chốt: Đây là nhóm tính năng nếu có thì sẽ gây sự phấn kích cho người sử dụng, còn không có cũng không sao. Độ ưu tiên là 3.
II. ÁP DỤNG KANO VÀO VIỆC PHÁT TRIỂN SẢN PHẨM NHƯ THẾ NÀO?
Vậy là bạn đã hiểu về mô hình Kano là gì cũng như cách nó hoạt động rồi chứ. Vậy áp dụng vào code của bạn như thế nào đây.
2.1 Phân tích rõ ràng các nhóm tính năng
Trước khi bắt đầu code, bạn hãy dành thời gian để phân tích yêu cầu bài toán (requirements) thành 3 nhóm như của phương pháp Kano. Làm tốt bước này, bạn sẽ biết rõ đâu là cái ưu tiên phải làm trước, đâu là cái là cái có thể làm sau, để tránh trường hợp cứ tập trung làm những cái đâu đâu trong khi cái quan trọng thì lại bỏ qua.
2.2 Release phiên bản đầu tiên sau khi code xong các tính năng cơ bản
Theo mô hình Kano, các tính năng cơ bản là các tính năng cần phải có. Vì vậy nếu đã hoàn thiện các tính năng cơ bản thì đồng nghĩa với việc sản phẩm cũng phần nào sẵn sàng tới tay người sử dụng. Bạn nên release phiên bản đầu tiên tại giai đoạn này để có thể đón nhận feedback từ người dùng càng sớm càng tốt.
2.3 Release các tính năng mong đợi, tính năng gây “phấn khích” thông qua các phiên bản tiếp theo
Lúc này sản phẩm của bạn đã đáp ứng được yêu cầu chạy đúng, đáp ứng được những nhu cầu cơ bản của người dùng. Từ giờ trở đi, tùy thuộc vào yêu cầu mà bạn sẽ tung ra các bản cập nhật tính năng mới, mục đích giúp người sử dụng có trải nghiệm tốt hơn.
Trong một số trường hợp, nếu bạn cảm thấy việc nâng cấp, cải tiến, bổ sung tính năng mới mà không khiến người dùng cảm thấy thỏa mãn hơn là bao thì bạn có thể dừng luôn tại đây. Coi như nhiệm vụ đã hoàn thành.
III. KẾT LUẬN
Đây là một phương pháp phát triển sản phẩm rất hay mà mình học được kể từ khi đi làm thực tế.
Mình tin rằng đây không phải là một cách làm mới. Trước khi đọc bài viết này, rất có thể bạn đã từng thực hiện một phương pháp tương tự, có điều nó không có tên cụ thể hoặc đơn giản là bạn chỉ làm dựa trên kinh nghiệm mà không thể phát biểu ra thành lời. Thì hy vọng với bài viết này, mình đã giúp bạn cụ thể hóa phương pháp, cũng như giúp bạn biết rằng trên đời này có một mô hình được gọi là Kano.
Cảm ơn bạn đã đọc hết bài viết. Hẹn gặp lại trong những bài viết lần sau.
Bài viết gốc được đăng tải tại phambinh.net
Có thể bạn quan tâm:
- Các cách sử dụng AS, AS?, AS! một cách hiệu quả và an toàn trong code Swift
- Codepen là gì ? Hướng dẫn sử dụng Codepen cơ bản
- Đây là cách Node.js được sử dụng trong năm 2017
Xem thêm các việc làm Developer hấp dẫn tại Station D
