Nhưng trước hết, chúng ta cần ôn lại một chút về Roadmap. Có thể hiểu một cách ngắn gọn, Product Roadmap là công cụ không một PM nào không dùng và nó chính là cách mà PM dùng để giao tiếp với những stakeholders khác về hai câu hỏi ‘Tại sao’ và ‘Cái gì’ liên quan đến Product. Một roadmap tuyệt đỉnh công phu có thể giúp PM đạt được những điều sau:

1. Roadmap đảm bảo cả team Product hiểu họ đang làm việc hướng đến điều gì, bằng cách thống nhất các mục tiêu ngắn hạn và dài hạn của công ty.
2. Tối ưu hiệu quả phân bổ thời gian, tiền bạc, nhân lực bằng việc truyền tải những dự đoán, thứ tự ưu tiên và lịch trình của công việc.
3. Đặt nền tảng cơ bản cho các cuộc thảo luận về thứ tự ưu tiên công việc và cung cấp mục tiêu công ty cần tập trung.

Một hình ảnh roadmap tiêu biểu

Roadmap thuộc giai đoạn Chiến lược sản phẩm (product strategy) trong product management. 

Chú ý: Roadmap khác với Product Backlog. Trong khi Product Roadmap định nghĩa “Tại sao” chúng ta nên làm điều này thì Product Backlog trả lời cho câu hỏi “Chúng ta đang xây dựng điều gì”

Product Roadmap là một trong những công cụ quan trọng nhất mà PM có thể dùng thuyết phục các stakeholders.

Product roadmap được sử dụng xuyên suốt vòng đời sản phẩm (Product lifecycle) từ giai đoạn lên ý tưởng, phát triển, đến phát hành, tăng trưởng, ổn định và thoái trào.

PM liên tục sử dụng roadmap để giao tiếp và tạo ảnh hưởng đến các phòng ban khác, giúp gắn nỗ lực từ phía họ vào trong tầm nhìn sản phẩm (product vision). Để có thể làm được điều đó thì Roadmap cần phải trực quan, dễ tiếp nhận và chứa đựng đủ thông tin chi tiết.

Và đây chắc là phần bạn mong chờ nhất! Sau đây là 3 bước để bạn có thể xây dựng một roadmap hiệu quả!

3 bước xây dựng roadmap hiệu quả

Bước 1: Hiểu rõ mục tiêu của công ty và sắp xếp thứ tự ưu tiên trước: 

Bạn cần làm gì?

1. Đặt lịch một cuộc họp 1:1 với các senior stakeholders (ví dụ như CEO, General Manager, người đứng đầu các team)
2. Trong cuộc họp này, thử hỏi họ về mục tiêu cao nhất họ muốn đạt được trong năm nay.
3. Sử dụng các framework như OKR hoặc SMART Goals để hiểu rõ hơn về các mục tiêu của họ.
4. Đề cập với họ rằng bạn sẽ tài liệu hóa những điều này và sắp xếp thứ tự ưu tiên với các leader của những team khác trong tuần kế tiếp.
5. Tài liệu hóa những mục tiêu này sử dụng một số công cụ cho roadmap như Aha, ProductBoard, Product Plan, Trello.

Bây giờ bạn đã có đầy đủ dữ liệu về ý tưởng, mục tiêu của mọi người và một backlog đầy những chiến lược và kế hoạch, vậy thì việc của còn lại của bạn bây giờ là sắp xếp lại thứ tự ưu tiên của chúng.

Kết quả cần đạt sau cuộc họp này là: xây dựng được Initiatives Roadmap – Roadmap chiến lược.

Điều tiếp theo bạn cần làm để chuẩn bị cho cuộc họp này:

1. Dành thời gian để ngồi xuống cùng leader của bạn sắp xếp ưu tiên mục tiêu của vài tháng tới.
2. Chia sẻ mục tiêu và sáng kiến được yêu cầu mức độ ưu tiên cao trước cuộc họp. Đảm bảo mọi người trong cuộc họp hiểu được nó, không một ai thích những điều bất ngờ.
3. Bạn có thể sử dụng một số kỹ thuật như MOSCOW hay Kano để xếp hạng và cho điểm các ý tưởng.

* Bạn muốn tìm hiểu thêm về các kỹ thuật sắp xếp thứ tự ưu tiên dành cho PM? Careerly có bài viết này dành cho bạn: Các kĩ thuật đánh giá ưu tiên công việc cần biết

4. Mỗi initiatives roadmap của bạn cần phải được đính kèm một OKR hoặc Smart Goals rõ ràng.

Một khi bạn đã hoàn thành initiatives roadmap, tiếp theo đó việc còn lại bạn cần làm chính là xây dựng Product Roadmap – Roadmap cho sản phẩm (2)

Bước 2: Sắp xếp thứ tự ưu tiên cho products của bạn, thiết lập tầm nhìn và OKR’s để xây dựng Product Roadmap: 

Dựa trên các mục tiêu của công ty bạn, bạn cần sắp xếp các sản phẩm và tính năng theo thứ tự ưu tiên để có thể đạt được những mục tiêu đó.

Bạn nên làm gì trong giai đoạn này?

1. Xác thực từng ý tưởng product bằng cách sử dụng dữ liệu và thông tin chi tiết.
2. Sau khi các ý tưởng về product được xác thực, hãy làm việc lại với ban lãnh đạo để ưu tiên các sản phẩm dựa trên khả năng bạn sẽ đạt được các mục tiêu đã xác định trong initiative roadmap như thế nào.

Trong quá trình xây dựng roadmap, dưới đây là một số data cơ bản mà bạn nên có trong product roadmap của mình:

• Liên kết đến các sáng kiến/chủ đề/mục tiêu của công ty
• Cập nhật tiến độ (% hoàn thành hoặc # nhiệm vụ đã hoàn thành)
• Timelines
• Tác động liên quan (Cao, Trung Bình, Tương đối)
• Các bên liên quan trong initiative roadmap

Bước 3: Sau đó các sản phẩm sẽ được chia nhỏ thành các feature backlog và backlog này sẽ được chuyển thành Release Roadmap – Roadmap để phát hành (3)

Bạn nên làm gì ở giai đoạn này?

1. Làm việc với team phân phối để chia sản phẩm thành các nhóm tính năng (Phụ thuộc vào framework team bạn đang sử dụng là Agile, Waterfall)
2. Có nhiều cách để xác định phạm vi tính năng của sản phẩm nhưng một phương pháp phổ biến mà team agile hay sử dụng để chia nhỏ công việc chính là lập bản đồ tính năng và ưu tiên tính năng.

3. Cuối cùng, sau khi bạn đã tạo xong backlog cho tính năng sản phẩm thì những tính năng này cần được lên lịch để cho vào Release Roadmap, dựa trên size của tính năng đó và số dev có trong team bạn. Bạn nên làm việc với tech lead trong bước này.

Tổng kết

Và wow, đây là thành quả khi ghép các giai đoạn trên vào với nhau:

1. Initiative Roadmap – Roadmap chiến lược: Bao gồm những mục tiêu và cột mốc được ưu tiên cao mà công ty bạn muốn đạt được.
2. Product Roadmap: roadmap cho các sản phẩm sẽ giúp công ty đạt được những mục tiêu trên
3. Release roadmap: Timeline cấp độ cao, trình bày thời gian dự đoán mà mỗi tính năng của sản phẩm được đưa ra thị trường.

Cuối cùng, đây là một số tips và thủ thuật để điều chỉnh roadmap của bạn:

1. Không bao giờ hứa hẹn một ngày cụ thể: Công việc lập trình không bao giờ đoán trước được. Vì vậy bạn nên dùng khung thời gian ở cấp độ cao hơn như quý 3, tháng 7 2021, nửa đầu năm 2021,…
2. Nên công khai roadmap của bạn để tất cả mọi người trong công ty có thể theo dõi được thứ tự ưu tiên của bạn
3. Quá trình thực hiện theo roadmap của bạn phải là quá trình không ngừng học hỏi, tập trung vào mục tiêu và luôn không ngừng lặp đi lặp lại
4. Đánh giá lại roadmap của bạn sau mỗi lần một tính năng được ra mắt.
5. Nên có một cuộc họp cùng team để đánh giá về roadmap của bạn (Một lần một tháng hoặc một quý)
6. Đảm bảo roadmap của bạn phải cân bằng giữa dự án dài hạn và những thắng lợi nhỏ.
7. Roadmap thì cũng chỉ là 1 chiếc bản đồ, 1 công cụ giúp bạn lên kế hoạch, trên thực tế hãy làm quen với việc thay đổi!

© Nguồn: Careerly.vn
Để tìm thêm những nội dung tương tự, bạn có thể đăng ký tham gia cộng đồng người làm công nghệ trên Careerly App tại: https://try.careerly.vn/welcome/

Bài viết 3 loại Roadmap mà PM cần cho sản phẩm đã xuất hiện đầu tiên vào ngày Công ty cổ phần giải pháp công nghệ fanxipan.

Golden Circle là một trong những lý thuyết cho thấy sự quan trọng của câu hỏi Tại sao (Why), hay nói cách khác, đây chính là động lực để bạn bắt đầu sản phẩm.

1. Đầu tiên chúng ta sẽ tìm hiểu về khái niệm của 5 Whys là gì?

Đây là phương pháp luận để tìm ra nguyên nhân căn bản của một vấn đề trước khi lập ra phương án giải quyết. Không phân tích nguyên nhân vấn đề, chỉ nghĩ “bề mặt” của vấn đề mà không nghĩ đến nguyên nhân sâu xa, “phần chìm của tảng băng” thì sẽ không thể tìm được phương án giải quyết hiệu quả..

Cốt lõi của kỹ thuật 5 Whys chính là không chỉ đặt câu hỏi tại sao 1 lần, mà liên tục đặt tiếp câu hỏi ấy nhiều lần, với 5 là số câu hỏi mà framework này đề xuất, để có thể tìm ra nguyên nhân thực sự của vấn đề. Đầu tiên, bạn đặt câu hỏi “Tại sao vấn đề này xảy ra?”, khi có được câu trả lời thì lại tiếp tục đặt câu hỏi ‘Tại sao vấn đề trong câu trả lời đó lại xảy ra”. Nếu liên tiếp đưa ra câu hỏi tại sao và câu trả lời theo kiểu nối đuôi như thế này thì chúng ta có thể sẽ sớm tìm được nguyên nhân cốt lõi của vấn đề. Thực tế, số câu hỏi có thể được rút gọn nếu đã tìm ra được nguyên nhân căn bản, hoặc cũng có thể tăng lên, tùy theo tình huống.

Để bạn dễ hình dung, dưới đây là một ví dụ áp dụng 5 Whys trong đời sống thực tế. Nghe thì có vẻ đơn giản, nhưng với những vấn đề phức tạp, đặc biệt khi áp dụng vào kinh doanh – công nghệ, kỹ thuật này vô cùng hữu ích trong việc tìm ra “gốc rễ” của một vấn đề.

2. Phân biệt nguyên nhân và tình huống:

| Tất cả những gì chúng ta nhìn thấy được, không phải là tất cả.

Một trong những lỗi thường gặp chính là sự ngộ nhận “vấn đề được phát hiện” chính là “nguyên nhân” chứ không phải là tình huống. Tình huống và nguyên nhân là hai khái niệm độc lập. “Tình huống” chính là vấn đề nhìn thấy được từ bên ngoài và “nguyên nhân” chính là bản chất dẫn đến vấn đề đó, cũng chính là điểm xuất phát của vấn đề. Để có thể xác định đúng nguyên nhân cốt lõi thông qua câu hỏi (Why) và nghĩ ra được cách làm (How) chính xác, chúng ta cần phân biệt được rõ hai khái niệm này.

Để có thể hiểu rõ hơn, chúng ta cùng xem qua ví dụ sau. Chúng ta đặt ra giả thuyết “Nếu người dùng được giới thiệu sản phẩm phù hợp với bản thân thì sẽ click vào nút Mua hàng nhiều hơn” và chuẩn bị chức năng “đề xuất”, tuy nhiên kết quả lại cho thấy không có gì khác biệt. Tại đây, tình huống chúng ta thấy chính là việc “Không có cải thiện ở số click vào nút mua hàng” chứ không phải nguyên nhân. Ngược lại, nguyên nhân có thể nằm ở việc trang sản phẩm mang lại thông tin quá nhàm chán khiến khách hàng không muốn tiếp tục mua hàng. Như vậy ở đây, nguyên nhân chính là thông tin của trang bán hàng quá rườm rà, không đúng quan tâm của khách hàng.

Phương pháp 5 Whys đóng vai trò cầu nối cho “tình huống” và “nguyên nhân”.

3. Ứng dụng thực tế: Tăng contact của khách hàng thông qua trang chủ bằng hai lần sử dụng 5 Whys

a. 5 Whys lần thứ nhất:

Một công ty sử dụng KR (Key Result – kết quả chính) là số contact của “người dùng thông qua trang chủ”. KR bị giảm sút nên team này đã dùng phương pháp 5 Whys để tìm ra nguyên nhân vấn đề (Why) và lập ra phương án giải quyết (How). Trong lần sử dụng 5 Whys lần thứ nhất, cả team đã đưa ra được kết quả như sau:

Đầu tiên, team đã nhìn nhận tình huống, cũng chính là vấn đề ở đây là việc “Số lượng contact của khách hàng thông qua trang chủ không tăng”. Team sử dụng phương pháp 5 Whys để tìm ra nguyên nhân vấn đề, sau nhiều cuộc họp, cả team đưa ra nguyên nhân có thể là do ‘quá trình contact phức tạp gây phiền hà” cho khách hàng. Khách hàng muốn contact với team phải thông qua quá trình khá dài [ (1) Truy cập vào trang chủ -> (2) Kéo xuống dưới cùng của trang chủ -> (3) Xác nhận email từ team -> (4) Soạn email và gửi ] Team phán đoán rằng quá trình này kéo dài khiến khách hàng cảm thấy phiền phức và kết quả là không muốn contact với team và thoát khỏi trang chủ. Team xác nhận “sự phiền phức” chính là nguyên nhân và thiết lập giả thuyết “Đơn giản hóa quá trình contact, số lượng contact trung bình một ngày sẽ tăng 20%” để chứng minh. Ngoài ra team cũng đưa ra 2 option:

1. Đưa nút contact lên đầu trang chủ
2. Bỏ email, thay vào đó gắn một form để khách hàng có thể dễ dàng điền thông tin

Cả team đã liên tục theo dõi trong vòng 2 tuần, tuy nhiên khác với dự đoán, con số contact thông qua trang chủ không có chuyển biến gì. Như vậy, nguyên nhân cốt lõi của vấn đề này không nằm ở “sự phiền phức” mà nằm ở lý do khác. Team lại phải áp dụng 5 whys lần thứ 2 để tìm ra nguyên nhân cốt lõi.

b. 5 Whys lần thứ 2:

Để có thể tìm ra được nguyên nhân tại sao số lượng contact không thay đổi, team sử dụng Google Analytics để kiểm tra và phân tích dữ liệu đăng nhập của người dùng. Người dùng truy cập thông qua kết quả tìm kiếm trang chủ của thời điểm trước khi có contact form và sau khi có contact form không thay đổi. Thay vào đó, lượng thời gian người truy cập lần đầu ở lại trên trang chủ thì có giới hạn tuy nhiên, lượng thời gian ở lại trang chủ của người tái truy cập lại tăng nhiều. Tức là, người tái truy cập có quan tâm đến contact form nhưng vẫn không muốn contact.

Team lại tiếp tục đặt câu hỏi “Vậy lý do ở đây là gì?” Trong contact form ngoại trừ phần điền thông tin khách hàng còn có 2 phần khác: Một, hình ảnh cho thấy hiệu quả giải pháp cung cấp và hai, nút di chuyển sang trang giới thiệu giải pháp. Sau khi kiểm tra Google Analytics, team phát hiện CTR của nút [Xem giải pháp] đạt 23%. Như vậy, nếu người tái truy cập thực sự quan tâm đến contact form thì họ đã nhấn vào nút này nhiều hơn. Qua đó, team xác nhận được rằng hiện tại contact form vẫn chưa cung cấp thông tin đủ hấp dẫn người dùng tái truy cập.

Google Analytics không thể giúp team tìm được câu trả lời cho câu hỏi tại sao contact form chưa đủ hấp dẫn người dùng. Phương pháp có thể giúp team giải quyết là việc tập trung vào meeting log giữa team và khách hàng (biên bản họp). Người tái truy cập là những người có quan tâm đến giải pháp và liên tục truy cập trang web, đây cũng là điểm chung giữa họ với những khách hàng team đã meeting. Team phán đoán rằng cả hai tập người dùng này đều mang đặc điểm giống nhau. Vì vậy, họ gián tiếp phán đoán ý đồ của người tái truy cập thông qua meeting log. Trong meeting log này, team đã kiểm tra được có rất nhiều khách hàng đã trực tiếp đề cập đến đối thủ của team, team cũng gián tiếp suy luận được rằng tập khách hàng này truy cập và so sánh trang chủ của team và đối thủ – nơi cũng cung cấp dịch vụ tương tự.

Từ đó, team phân tích trang chủ của đối thủ đang nhấn mạnh đến những thông tin nào và so sánh với trang chủ của mình. Qua đây, team đã xác định được cả team và đối thủ đều nhấn mạnh toàn diện vào “hiệu quả”. Ngoài ra, “hiệu quả” mà mỗi công ty mang lại cũng thực sự không quá khác nhau. Trang chủ của team và của đối thủ đều đang nhấn mạnh vào những thông tin quá tương tự nhau, và thực sự trong mắt người dùng, những thông tin này có thể nói là khó phân biệt. Trong tình huống này, trang chủ của team thực sự đã không để lại dấu ấn gì khác biệt trong lòng người dùng.

Thông qua phương pháp 5 Whys, team đã tìm ra được nguyên nhân cốt lõi của vấn đề không phải nằm ở “sự phiền phức”, mà chính là “sự tương đồng với hiệu quả mà giải pháp đã có cung cấp không lôi kéo được khách hàng”. Sau khi xác định được nguyên nhân cốt lõi của vấn đề, thì team bắt tay vào hành động đó là thay đổi chiến lược, không nhấn mạnh cho khách hàng thấy “hiệu quả” mà cho khách hàng thấy “những case khách hàng sử dụng thành công” hay testimony. Thay vì nói hiệu quả suôn suôn thì team thay đổi và tập trung nhấn mạnh vào dẫn chứng cho khách hàng thấy “người thật việc thật” sau khi sử dụng giải pháp của team. Họ đưa ra những dẫn chứng khách hàng có background tương tự với người dùng tái truy cập và đang sử dụng giải pháp của team một cách có hiệu quả để thúc đẩy tập người dùng này tin tưởng hơn vào sản phẩm và thực hiện key result mà team mong đợi đó chính là contact thông qua trang chủ. Kết quả thực sự đã cải thiện đáng kể, khi số lượng contact thực tế vượt ngưỡng 20% trong giả thuyết team đưa ra và đã đạt được kết quả tăng lên đến 40%.

Bài viết trên được lược dịch từ: https://brunch.co.kr/@famelee/

© Nguồn: Careerly.vn
Để tìm thêm những nội dung tương tự, bạn có thể đăng ký tham gia cộng đồng người làm công nghệ trên Careerly App tại: https://try.careerly.vn/welcome/

Bài viết 5 Whys – Kỹ thuật giúp PM tìm ra nguyên nhân cốt lõi đã xuất hiện đầu tiên vào ngày Công ty cổ phần giải pháp công nghệ fanxipan.

Khi hỏi các PM/PO về ph khó khăn nhất trong công việc, thường tôi sẽ nhận được một câu trả lời là: “Việc quyết định thứ tự ưu tiên các task trong backlog”. Vì một PM luôn phải chắc chắn rằng chúng ta đang xây dựng một sản phẩm phù hợp với thị trường và khách hàng với lượng tài nguyên có hạn, nếu quyết định ưu tiên sai một công việc cần làm trước thôi cũng có thể khiến cả quá trình xây dựng sản phẩm “chệch khỏi đường ray”.

Người làm PM phải biết hoàn thành hạng mục công việc mang lại giá trị lớn nhất hoặc mang tính logic nhất trong backlog theo thứ tự ưu tiên – đây cũng là nhiệm vụ quan trọng nhất của PM. Thông thường, cách dễ dàng nhất mà các PM hay thực hiện để hoàn thành nhiệm vụ này đó là “Đánh giá các nhóm hạng mục sau đó sắp xếp thứ tự ưu tiên theo tính quan trọng và mức độ khẩn cấp của từng hạng mục đó”. Điều làm việc này trở nên khó khăn không phải là việc thiếu resource (chi phí, nhân lực, thời gian) mà chính là biến số, sự mơ hồ không chắc chắn trong mỗi lựa chọn của PM. 

Tất nhiên để hạn chế được điều này rất nhiều công ty IT đã sử dụng các phương pháp quyết định thứ tự ưu tiên (Prioritization Techniques) khác nhau. Trong bài viết này tôi sẽ đề cập đến 4 phương pháp phổ biến nhất, phân tích đặc điểm và tình huống sử dụng của chúng. 

1. MoSCOW: 

Đây là phương pháp tiếp cận đơn giản, phù hợp nhất cho những dự án/service nhỏ và không phức tạp.

Đặc điểm: 

Đây là phương pháp được sử dụng phổ biến để phân biệt giữa task quan trọng và không khi quản lý các dự án thực hiện theo phương pháp Agile. Thường được sử dụng khi PM/PO muốn truyền đạt nội dung task mình đang thực hiện và giải thích lý do đến các bên liên quan như các managers, team leadership, khách hàng. MoSCOW là viết tắt của Must Have, Should Have, Could Have, Won’t Have. Careerly đã từng có bài viết giải thích kỹ về phương pháp này, các bạn có thể tham khảo tại đây

Trường hợp sử dụng: 

MoSCoW là phương pháp đơn giản tuy nhiên không phải lúc nào nó cũng phát huy hiệu quả. Ví dụ nếu dự án nhạy cảm với thời gian phát hành thì nên sử dụng phương pháp quyết định thứ tự ưu tiên mang tính bao quát trước rồi bổ sung thêm bằng phương án MoSCoW. Ngược lại nếu đây là dự án của sản phẩm cỡ nhỏ không mang tính phụ thuộc và không bị giới hạn về mặt kỹ thuật thì phương pháp MoSCow là phương án hợp lý. 

2. Walking Skeleton:

Phương pháp này thường được sử dụng để quyết định thứ tự ưu tiên các tính năng cần có của MVP (Sản phẩm khả dụng tối thiểu), thông qua phương pháp này PM có thể xác định được tính năng nào quan trọng tuyệt đối để khiến sản phẩm trở nên khả dụng. 

** Để đọc thêm về PoC, Prototype và MVP, bạn có thể đọc bài viết của Careerly tại đây: https://blog.careerly.vn/newsletter/phan-biet-poc-prototype-mvp/

Đặc điểm: 

Phương pháp này quyết định thứ tự ưu tiên của các tính năng sao cho phù hợp với trọng tâm trong user story.  (Tìm hiểu thêm về user story tại đây) https://blog.careerly.vn/newsletter/viet-user-story-bang-invest/

Do đó, chúng ta có thể ứng dụng phương pháp này như sau:

1. Sắp xếp thứ tự ưu tiên cho các user story.
2. Chọn ra những tính năng quan trọng nhất để sản phẩm khả dụng.
3. Sản phẩm phải vừa khả dụng vừa phản ánh đủ được giá trị business, do đó dù sản phẩm còn trong trạng thái giới hạn kỹ thuật nhiều thì PM phải sắp xếp story map hợp lý.

Trường hợp sử dụng:

Walking Skeleton rất hữu dụng để mang lại thành quả nhãn tiền cho MVP. Tuy nhiên để phát hành sản phẩm có tính năng phức tạp hơn và mang giá trị bền vững thì nên hạn chế sử dụng phương pháp này. 

3. RICE (Reach, Impact, Confidence, Effort)

Đây là phương pháp cần một chút tính toán để xác định thứ tự ưu tiên theo điểm số.

Đặc điểm:

RICE là viết tắt của Reach, Impact, Confidence và Effort, đây là các biến cần nhập giá trị khi đánh giá mỗi tính năng và sắp xếp thứ tự ưu tiên cho chúng.

1. Reach – Phạm vi tiếp cận, tức số người dùng sử dụng một tính năng nào đó  trong thời gian nhất định. Các chỉ số đánh giá sản phẩm thực tế có thể là DAU (Daily Active User, lượng người dùng tích cực trong một ngày) hoặc MAU (Monthly Active User, lượng người dùng tích cực trong một tháng). Ví dụ bạn muốn đánh giá các mục cải thiện của trang hỗ trợ khách hàng thì số người dùng truy cập vào trang của bạn trong vòng một tháng có thể là chỉ số Reach của bạn.
2. Impact – Chỉ số mức độ ảnh hưởng khi người dùng sử dụng tính năng này của sản phẩm, giá trị này mang tính tương đối. Có thể tham khảo cách cho điểm như sau:

“Ảnh hưởng rất lớn” 3 điểm, “ảnh hưởng lớn” 2 điểm,”ảnh hưởng trung bình” 1 điểm, “ảnh hưởng thấp” 0.5 điểm, “ảnh hưởng rất thấp” 0.25 điểm.

3. Confidence – Độ tin cậy, tức giá trị này đánh giá độ lớn những “ưu đãi’ mà tính năng này mang đến cho người dùng. Ví dụ độ tin cậy tuyệt đối là 100 điểm, độ tin cậy trung bình 80, độ tin cậy thấp 50. Lưu ý tất cả những chỉ số này nên được đánh giá khách quan. 
4. Effort: Thời gian mà team Product, Design, Engineer dành để xây dựng sản phẩm, có thể tính toán giá trị này theo số thời gian hoặc theo số nhân lực.

Sau khi nhập xong các giá trị cho các biến, áp dụng công thức sau:

ĐIỂM RICE= (Reach*Impact*Confidence)/Effort. 

Điểm Rice càng cao thì thứ tự ưu tiên càng cao. 

Trường hợp sử dụng:

Phương pháp RICE rất hiệu quả để nhìn tổng quát về mọi mặt của sản phẩm khi quyết định thứ tự ưu tiên. Ví dụ: khi sử dụng RICE để xác định ưu tiên tính năng của sản phẩm, khi sản phẩm được phát hành và bắt đầu vòng đời của nó thì chúng ta có thể nhìn rõ ràng hơn về khía cạnh khách hàng. Ngoài ra vì lý do này mà RICE không phải là một phương pháp phù hợp để đánh giá thứ tự ưu tiên khi xây dựng MVP.

4. KANO:

Đây là phương pháp sắp xếp thứ tự ưu tiên dựa trên nền tảng khách hàng. Phương pháp này xuất phát từ sự thật rằng có sự khác nhau giữa mức độ hài lòng và hành động khách hàng về một tính năng của sản phẩm/dịch vụ.

Đặc điểm:

Phiên bản áp dụng mô hình Kano cơ bản nhất chính là chia các tính năng user backlog point theo 4 tiêu chuẩn sau: must-be, performance, attractive, indifferent. Vì phương pháp này sắp xếp thứ tự ưu tiên dựa vào mức độ hài lòng và ý kiến của khách hàng do đó trước khi áp dụng phương pháp này, PM cần thực hiện khảo sát và phỏng vấn khách hàng. 

1. Must-be: Dựa trên ý kiến khách hàng, tính năng này bắt buộc phải có để làm sản phẩm có ý nghĩa.Tính năng Must-be này có thể đồng nhất với tính năng “must have” trong MoSCOW. 
2. Performance: Đây là tính năng không quá cần thiết để sản phẩm/dịch vụ trở nên khả dụng nhưng đây là tính năng khách hàng rất mong muốn được sử dụng. Nếu đưa các tính năng người dùng mong đợi vào sản phẩm thì có thể duy trì được mức độ hài lòng của người dùng ngược lại nếu không thể cung cấp được các tính năng này thì rất có khả năng người dùng sẽ cảm thấy thất vọng, vì vậy đây là một tính năng cần lựa chọn cẩn thận.
3. Attractive: Đây là tính năng làm tăng thêm mức độ hài lòng của người dùng. Về cơ bản, khách hàng không quá mong đợi ở tính năng này nhưng nếu sản phẩm có tính năng này sẽ mang lại một điểm đặc biệt tốt cho sản phẩm. 
4. Indifferent: Đây là tính năng hầu như không ảnh hưởng đến mức độ hài lòng của khách hàng. Tức, đây là sản phẩm khách hàng hầu như không quan tâm.

5. So sánh các kỹ thuật:

Để hiểu rõ hơn về tình huống sử dụng 4 phương pháp trên hiệu quả, tôi có lập một bảng so sánh, hi vọng qua bảng này các PM có thể hiểu rõ hơn về tình huống mình có thể sử dụng các phương pháp xác định thứ tự ưu tiên thực hiện task/tính năng sản phẩm.

Việc biết tới các kĩ thuật trên không đảm bảo khả năng đánh giá ưu tiên một cách hoàn hảo, tuy nhiên nếu kết hợp với việc cân nhắc thời điểm, hoàn cảnh sử dụng cũng như luyện tập , bạn có thể hoàn hiện khả năng đánh giá mức độ ưu tiên công việc và tạo ra được nhiều giá trị hơn cho sản phẩm và công ty.

© Nguồn: Careerly.vn
Để tìm thêm những nội dung tương tự, bạn có thể đăng ký tham gia cộng đồng người làm công nghệ trên Careerly App tại: https://try.careerly.vn/welcome/

Bài viết Các kĩ thuật đánh giá ưu tiên công việc cần biết đã xuất hiện đầu tiên vào ngày Công ty cổ phần giải pháp công nghệ fanxipan.

Bài viết được tóm tắt và dịch từ bài viết “On Writing Product Specs”, viết bởi Gaurav Oberoi, người có kinh nghiệm chục năm làm Product Manager, kỹ sư CNTT và khởi nghiệp ở Seattle và Silicon Valley. 

1. Product Specs là gì?

Product Specs (chỉ dẫn sản phẩm) là tài liệu liệt kê những yêu cầu thiết yếu, các yếu tố ảnh hưởng đến xây dựng và phát triển sản phẩm.

Viết Product Specs đặc biệt quan trọng vì một bản Product Spec chất lượng giúp team giao tiếp hiệu quả, định hướng trước và rõ ràng những yêu cầu nhất định về sản phẩm, từ đó giảm rủi ro nảy sinh những vấn đề liên quan đến sản phẩm trong quá trình thực thi, tiết kiệm thời gian giải quyết những vấn đề ấy.

Hãy thử đặt mình vào tình huống như sau:

Bạn là PM và có một ticket/story/roadmap với nội dung như sau:

Thêm live chat ở giai đoạn checkout để tăng conversion rate:
Conversion rate ở checkout hiện đang là 18% nhưng tiêu chuẩn chung trên thị trường là 30%. Test tính năng live chat khi khách hàng check out để xem có cải thiện được không.
Bên Customer Ops sẽ cho mượn một người.

Thời gian là vàng là bạc nên bạn làm luôn mà không cần spec:

1. Bạn trao đổi với team khi họp sprint về việc này
2. Bạn chọn 1 bên cung cấp giải pháp live chat
3. Bạn cập nhật ticket để yêu cầu 1 dev đóng thêm 1 tí Javascript vào
4. Bạn họp với bên Support để đảm bảo là họ nắm

Bam! Live chat có ngay ai cần spec nữa? Tất nhiên là nếu bạn là một startup nhỏ thì ảnh hưởng ít hơn, nhưng nếu công ty bạn có một kích cỡ nhất định rồi thì việc giải quyết vấn đề phát sinh về sau còn tốt nhiều thời gian và tài nguyên hơn, chẳng hạn như:

• Dev đánh dấu là done nhưng bạn chợt nhận ra họ không hỗ trợ live chat trên mobile → Toang. Mobile là kênh chiến lược của sản phẩm
• Designer dành mấy ngày liền để design animation cho live chat → Đây chỉ là test nhưng mà các bên liên quan không nắm được điều này
• Sau khi test được 1 tuần thì Business Intelligent báo là họ không viết report được vì không đủ metrics → Test lại từ đầu

Đây là một ví dụ đơn giản nên có vẻ không phải là vấn đề gì lớn lắm nếu không có spec, nhưng phải giải quyết những vấn đề phát sinh đột xuất sẽ ảnh hưởng tới tiến độ công việc và kế hoạch khác. Còn nếu là một dự án lớn thì bạn chắc cũng có thể dễ dàng hình dung được ảnh hưởng khi có vấn đề phát sinh đột xuất.

2. Product Specs cần có những nội dung gì?

1. Vấn đề (Problem):
   Nêu vấn đề mà bạn đang muốn giải quyết, đặc biệt là tại sao vấn đề đó nên được giải quyết đi kèm với những dẫn chứng, số liệu cụ thể.
2. Các mục tiêu có thể đo lường được (Measurable Goals):
   Cam kết những mục tiêu mà team cần đạt được. Mục tiêu cần rõ ràng, cụ thể để sau có thể đánh giá được mục tiêu đó có đạt được hay không.
3. Hoàn cảnh của vấn đề (Context):
   Cung cấp thêm dẫn chứng để người nghe đồng thuận với kế hoạch của bạn bằng những giả thiết, ví dụ thực tế, số liệu, v,v
4. Giải pháp chi tiết (Detailed Solution):
   Kế hoạch của bạn cần đủ chi tiết để cả team có thể dễ dàng thực hiện theo – như thể bạn đang viết code cho bộ não con người chạy vậy.
5. Tiến độ (Timeline):
   Liệt kê những mốc thời gian mà cả team cho là quan trọng. Ban đầu, phần này có thể chưa rõ ràng lắm, nhưng nó cần được hoàn thiện qua nhiều lần họp.

3. Các bước để viết một bản Product Spec

Tùy vào quy mô công ty, sản phẩm, dự án mà thời gian có thể khác nhau, nhưng về cơ bản thì bạn cũng có thể viết một bản Product Spec theo tỉ lệ thời gian như bên dưới:

B1: Viết dàn ý (1-2 tiếng):

Viết xuống các ý chính mà bạn nghĩ ra

B2: Thực hiện vài cuộc họp 1-1 30 phút (1-4 tiếng):

Mục đích của phần này là để bạn xem lại những giả thiết mình đặt ra và cải thiện bản kế hoạch. Cuộc họp này nên ít người nhất có thể, lý tưởng nhất là 1-1. Ví dụ, bạn có thể họp với 1 người bên tài chính hay 1 người bên kỹ thuật, v.v.

B3: Viết và chỉnh sửa spec (0.5-3 ngày):

Tổng hợp lại các nội dung mà bạn đã nghĩ ra và kiểm chứng với người khác một cách khoa học. Khi đã có bản nháp, hãy đọc và sửa đi sửa lại nó nhiều lần. Bạn nên chỉnh sửa sao cho spec ngắn gọn, súc tích. Thường spec có thể được viết trong khoảng 0.5-1 ngày, với các dự án lớn cũng có thể mất 2-3 ngày.

B4: Công khai spec và lên lịch họp để đánh giá spec (15 phút):

Gửi spec qua email cho các bên liên quan đến dự án. Sau đó, lên lịch họp khoảng 1 tiếng với những người chủ chốt: những người sẽ thực hiện dự án, và những người có quyền duyệt dự án.

B5: Đánh giá spec (1 tiếng):

Bắt đầu buổi họp bằng cách hỏi xem ai chưa đọc kỹ spec. Thường có thể có 1-2 người chưa đọc kỹ thì bạn có thể dành khoảng 10 phút cho những người ấy đọc còn những người khác có thể nghỉ. Mục tiêu của buổi họp là bạn lấy được sự đồng thuận từ nhà đầu tư và cam kết thực hiện kế hoạch từ các thành viên. Bạn có thể cần chỉnh sửa spec và lặp lại bước này từ những gì bạn học được.

B6: Sau buổi đánh giá, gửi bản cập nhật và soạn thảo các đầu việc (1-2 tiếng):

Gửi email bản spec đã được chỉnh sửa sau buổi đánh giá, các đầu việc cùng thời gian dự tính mà bạn sẽ cập nhật tiếp về tình hình dự án. Thông thường, sau product spec, bước tiếp theo là bên kỹ thuật có thể viết tech spec (chỉ dẫn kỹ thuật), nhưng không phải lúc nào cũng cần tech spec.

4. Một số tips để viết một bản Product Spec hiệu quả

a. Không để bản spec quá dài:

Viết ngắn gọn, xúc tích, cô đọng những thông tin cần thiết nhất

b. Dùng từ và cách trình bày đơn giản, khoa học:

Không dùng những từ hoa mỹ. Dùng các gạch đầu dòng và in đậm các đề mục, thông tin quan trọng. Ngoài ra, hãy viết với văn phong thoải mái, thú vị và thậm chí có thể là hài hước nữa. Có thể sử dụng hình ảnh, biểu đồ, v.v. Mục đích cuối cùng là để product spec của bạn dễ đọc nhất có thể.

c. Bắt đầu viết spec sớm:

Bạn nên bắt đầu viết spec khoảng 2-3 tuần trước khi team dev bắt đầu phát triển sản phẩm để có đủ thời gian review, có được sự thống nhất của các bộ phận và hoàn thiện bản spec.

d. Đặt mình vào vị trí của dev (cũng như các vị trí khác liên quan đến quá trình phát triển sản phẩm):

Thường dev bắt đầu viết code, mọi người bắt đầu xắn tay vào làm thì vấn đề mới nảy sinh. Nhưng bạn cũng có thể ngăn chặn tình trạng này bằng cách đặt mình vào vị trí của các thành viên để nghĩ xem thực tế cần những gì để phát triển được sản phẩm và chuẩn bị xử lý những vấn đề đó từ đầu.

e. Hướng product spec theo tầm nhìn:

Spec không phải chỉ để mô tả, định hình việc phát triển tính năng mới mà còn là để nêu lên tổng thể tại sao cần phát triển tính năng ấy cũng như hướng đi sắp tới của công ty. Hãy chỉ ra dự án này ảnh hưởng gì đến định hướng của công ty và những dự định tiếp theo sau dự án.

f. Hãy đảm bảo những người liên quan đến dự án đều đọc spec:

Đây là một cách để kiểm tra xem bạn có đang viết một spec tốt, không quá dài, khó hiểu hay đơn giản là chọn đúng đối tượng liên quan hay không. Xem lại bước 5 để biết một tip đảm bảo những người liên quan đã đọc spec.

g. Xin feedback từ team về spec:

Hỏi team xem bạn có thiếu chi tiết gì, vấn đề dễ nảy sinh trong tương lai gì không hay bạn có đang phân bổ thời gian, tiến độ hợp lý hay không, v.v

© Nguồn: Careerly.vn
Để tìm thêm những nội dung tương tự, bạn có thể đăng ký tham gia cộng đồng người làm công nghệ trên Careerly App tại: https://try.careerly.vn/welcome/

Bài viết Viết Product Specs như thế nào cho hiệu quả? đã xuất hiện đầu tiên vào ngày Công ty cổ phần giải pháp công nghệ fanxipan.

1. Biểu đồ phân làn (Swimlane) 

Biểu đồ phân làn là một cách tốt để giúp bạn có thể trình bày rõ ràng những ý tưởng, nội dung phức tạp. Sản phẩm công nghệ thường được thiết kế để củng cố chuỗi giá trị (value chain) chung của cả công ty, vì vậy quá trình làm sản phẩm có thể liên quan đến nhiều bộ phận khác nhau. Ví dụ, PM có thể phải dùng đến các công cụ chăm sóc khách hàng hay khi chuẩn bị ra mắt sản phẩm bạn cần phải làm hóa đơn (invoice). Đúng vậy, bạn có thể nghĩ công việc của Product Manager giống như Steve Jobs chỉ đưa ra vision, nhưng thực ra, Product Manager cũng  cần phải giải quyết bất kỳ vấn đề nào có thể xảy ra để hỗ trợ công ty quản lý sản phẩm. Biểu đồ phân làn sẽ là một cách tốt để bạn xác định và sắp xếp nhiều vấn đề cần giải quyết ở nhiều giai đoạn, liên quan đến nhiều mảng trong quá trình quản lý sản phẩm.

Biểu đồ phân làn sử dụng các biểu tượng nhất định để đánh dấu các giai đoạn và các bước chính trong một quy trình. Những biểu tượng được dùng nhiều nhất trong biểu đồ phân làn là:

• Document – Tài liệu: Đánh dấu tài liệu cần được đọc/ xử lý, ví dụ: một đơn cần được điền.
• Decision – Quyết định: Hình kim cương này thường được dùng để đánh dấu một quyết định cần chốt.
• Database: Đánh dấu giai đoạn lưu trữ dữ liệu trong quy trình.
• Process – Giai đoạn: Đánh dấu giai đoạn chính trong quy trình.

Có nhiều biểu tượng khác thường được dùng trong biểu đồ phân làn, nhưng đây là những biểu tượng phổ biến nhất có thể áp dụng được trong hầu hết các case quản lý sản phẩm.

Khi nào nên dùng biểu đồ phân làn? 

Biểu đồ phân làn có ích nhất trong việc thể hiện những quy trình, công việc liên quan đến nhiều stakeholder/bộ phận khác nhau trong công ty hoặc những quy trình phức tạp liên quan đến nhiều phần của ứng dụng.

Nếu còn chưa rõ ai, bên nào sẽ phụ trách phần nào ở một giai đoạn nhất định trong cả quá trình, biểu đồ phân làn có thể giúp nhanh chóng làm rõ vấn đề này. Trong quản lý sản phẩm, các quy trình làm hóa đơn, giao hàng hay chăm sóc khách hàng thường sẽ dùng đến biểu đồ phân làn.

Biểu đồ phân làn giúp bạn hình dung rõ phạm vi của các quy trình, giai đoạn trước khi xây dựng giải pháp để bạn có thể hiểu rõ cả chu trình liền mạch của sản phẩm. Biểu đồ này cũng giúp bạn chú ý đến những “chướng ngại vật” hoặc những yếu tố, công việc cần phụ thuộc vào các stakeholder khác hay các bộ phận khác của công ty mà bạn không có toàn quyền kiểm soát. Nếu công việc của một bộ phận nào đó bạn không kiểm soát được làm bạn phải delay quá trình phát triển sản phẩm, hãy thể hiện rõ trên biểu đồ phân làn.

2. Biểu đồ quy trình có chú thích (Annotated processes)

Cũng như tên của nó, biểu đồ này gồm 2 phần chính:

1. Biểu đồ minh họa quy trình.
2. Chú thích được đánh số tương ứng với các giai đoạn ở trên.

Bước đầu tiên, bạn cần vẽ rõ ràng nhất có thể (không nhất thiết phải vẽ đẹp như Picasso) những bước chính trong quy trình bạn đang cần trình bày với các bộ phận còn lại của công ty hoặc với team, ví dụ như một chu trình phát triển hình thức thanh toán mới hay chu trình làm email marketing. Hãy cố gắng làm biểu đồ đơn giản và giới hạn các bước trên biểu đồ của bạn ít nhất có thể để không làm người xem cảm thấy khó hiểu. Một lỗi mà mọi người thường gặp chính là cố gắng thêm tất cả các khía cạnh của một giai đoạn nhất định vào biểu đồ nhưng tốt hơn bạn nên vẽ biểu đồ đơn giản thôi. Kể cả khi bạn biết có thể có một số bước phụ khác, hay cố gắng chỉ giữ những bước quan trọng nhất với người xem, thể hiện những điểm chính mà bạn muốn truyền tải đến họ.

Sau khi đã biến quy trình thành biểu đồ, hãy xác định các bước mà bạn muốn nhấn mạnh, giải thích kỹ hơn với người xem và đánh số thứ tự cho chúng, sau đó thêm phần chú thích tương ứng với các bước đã được đánh số để người xem có thể hiểu rõ hơn mỗi bước sẽ diễn ra như thế nào, thay vì cố gắng thêm chi tiết trên biểu đồ.

Khi nào nên dùng biểu đồ quy trình có chú thích? 

Bạn có thể dùng loại biểu đồ này trong nhiều trường hợp, nhưng thường sẽ có một số hoàn cảnh mà bạn thấy nó hữu dụng nhất như sau:

• Khi giải thích cho team kỹ thuật một feature hoặc một user story cụ thể nào đó có thể được đặt vào “bức tranh toàn cảnh”, vào sản phẩm hay cả quá trình nào đó như thế nào. Bạn có thể dùng chú thích đánh số để giải thích câu chuyện của mình hoặc thêm các yêu cầu cần thiết (specs).
• Khi các stakeholder liên quan không rõ về một giai đoạn nào đó trong một quá trình.
• Khi bạn tổng hợp nhiều lựa chọn cho các stakeholder quyết định. Bạn có thể dùng chú thích đánh số để thể hiện quan điểm, lập luận của mình.

3. Hành trình trải nghiệm người dùng (User Journey) 

Product Manager thường sẽ làm việc với các team UX để tạo các flow mới được đề xuất cho sản phẩm hay tính năng mới, và một cách hiệu quả để truyền đạt các flow UX đó là tạo một file mềm biểu đồ hành trình trải nghiệm người dùng có thể dễ dàng chia sẻ trong team.

Mục đích của biểu đồ này là tóm tắt những bước chính có trong hành trình trải nghiệm mới của người dùng để các bên liên quan đều có thể tham gia vào quá trình phát triển này, giúp Product Manager làm rõ và hướng dẫn chi tiết từng bước hơn. Đừng quá tập trung vào visual hay câu từ, hãy tập trung vào flow ở các bậc cao mà không cần đi quá sâu vào chi tiết để đảm bảo bạn có thể nắm được vào toàn bộ flow/hành trình trải nghiệm của người dùng nói chung.

Tương tự như với biểu đồ quy trình có chú thích, biểu đồ hành trình người trải nghiệm người dùng cũng có thể chia làm 2 phần: phần trên là biểu đồ hành trình và phần dưới là chú thích giải thích thêm thông tin về từng bước trong hành trình trải nghiệm người dùng.

Khi nào nên dùng biểu đồ hành trình trải nghiệm người dùng?

• Giai đoạn bắt đầu một dự án mới: Biểu đồ hành trình trải nghiệm người dùng thường được dùng khi bắt đầu một dự án mới hoặc để đề xuất một tính năng mới. Bắt đầu từ bậc cao, bạn sẽ dùng biểu đồ hành trình trải nghiệm người dùng để thể hiện rõ các bước trong hành trình đó và tập trung vào làm giảm những “chướng ngại vật” cản trở người dùng trải nghiệm sản phẩm của bạn. Có được một cái nhìn toàn cảnh về trải nghiệm người dùng là điều cần thiết để bạn có thể tìm ra những điểm mà người dùng dễ gặp trở ngại và xác định user flow tổng thể sẽ như thế nào.
• Khi có những thay đổi quan trọng: Biểu đồ này cũng hữu ích khi bạn đang tìm những điểm quan trọng cần thay đổi trong hành trình trải nghiệm của người dùng. Vẽ cả hành trình đó đặt trước mặt sẽ giúp bạn quyết định được phần nào trong quá trình này cần thay đổi cũng như lý do phải thay đổi.

4. Biểu đồ cảm xúc (Emotion Mapping)

Biểu đồ cảm xúc là loại biểu đồ “nâng cấp” hơn của biểu đồ hành trình trải nghiệm người dùng, thêm khía cạnh cảm xúc để bạn có thể hiểu rõ và truyền đạt những nhu cầu, trạng thái cảm xúc của người dùng ở nhiều điểm trong suốt hành trình trải nghiệm.

Đầu tiên, bạn cũng chia hành trình trải nghiệm người dùng thành các bước cơ bản ở đầu biểu đồ, kèm với mục tiêu của người dùng ở các bước đó, sau đó vẽ biểu đồ trạng thái cảm xúc của một người dùng ở nhiều điểm trong suốt hành trình trải nghiệm. Trạng thái cảm xúc cần được vẽ trên biểu đồ theo hai thái cực tích cực (vui) và tiêu cực (buồn) rõ ràng. Ngoài ra bạn có thể tăng/ giảm độ đậm nhạt của màu đỏ và màu xanh để có thể biểu hiện mức độ của mỗi trạng thái cảm xúc (không chỉ vui mà có thể là hơi vui, vui, rất vui).

Khi nào bạn nên dùng biểu đồ cảm xúc?

• Sau Usability Testing: Nếu bạn thường xuyên thực hiện Usability Testing, kết quả nhận được nhiều khi sẽ là một đống feedback không được hệ thống rõ ràng. Biểu đồ cảm xúc là một cách tuyệt vời để bạn đối chiếu các feedback từ nhiều người dùng và tổng hợp kết quả để chia sẻ với team.
• Tác động đến các quan điểm, ý kiến khác – Khi bạn đang tranh luận với đồng nghiệp hay stakeholder về việc có nên chỉnh sửa điều gì đó bạn nghĩ là không ổn, chia sẻ trạng thái cảm xúc của người dùng thông qua biểu đồ cảm xúc là một dẫn chứng rất mạnh để tạo ảnh hưởng đến quyết định cuối cùng. Đơn giản, mọi người thường sẽ dễ muốn làm gì đó sẽ khiến người dùng hài lòng hơn là làm gì đó khiến người dùng không hài lòng.

5. Cây quyết định (Decision Trees) 

Bạn không chắc chắn khi phải trình bày và đưa ra một quyết định phức tạp? Đặc biệt việc xác định hành vi với một khía cạnh nhất định của sản phẩm chưa bao giờ là một “con đường thẳng” đi ngay đến quyết định cuối cùng. Cây quyết định sẽ giúp bạn minh họa những điểm phức tạp của quyết định để có thể thể hiện tất cả những phân tích quyết định đó trong đầu bạn lên trên giấy.

Đây là ví dụ về Cây quyết định Slack đã làm để đưa ra quyết định có nên gửi thông báo cho người dùng hay không, dựa trên những thiên hướng hành vi khác nhau của người dùng.

Cây quyết định thường gồm có 3 yếu tố chính:

1. Quyết định – Quyết định cần đưa ra hay câu hỏi bạn cần trả lời với biểu đồ này.
2. Giai đoạn – Một loạt các bước đắn đo, cân nhắc để bạn đưa ra lựa chọn này hoặc lựa chọn kia.
3. Kết quả – Kết quả có thể có cho một quyết định. Kết quả này có thể ở dạng có/ không hoặc một loạt lựa chọn khác nhau, tùy vào quá trình hoặc tính năng liên quan.

Khi nào nên dùng Cây quyết định? 

Nhìn chung, bạn có thể dùng cây quyết định bất cứ khi nào bạn cần diễn tả các điều kiện để có thể đạt được kết quả này hoặc kết quả khác. Nó cũng giúp đặt giả thuyết thử chọn một hướng đi so với chọn hướng đi khác xem chúng sẽ dẫn đến kết quả gì, trước khi thật sự đưa ra quyết định cuối cùng. Cây quyết định cũng đặc biệt hữu dụng trong các trường hợp sau:

• Các quyết định về kỹ thuật: Cây quyết định thường được dùng khi làm việc với bên kỹ thuật, lập trình để quyết định xem một tính năng sẽ được ứng dụng như thế nào vào hoàn cảnh rộng hơn của cả sản phẩm.
• Các ưu tiên về sản phẩm: Bạn cũng có thể dùng cây quyết định để đưa ra các quyết định về quản lý sản phẩm. Ví dụ, nếu bạn đang định ưu tiên tính năng hay chiến lược này hơn cái khác, hãy liên tục hỏi bản thân một loạt câu hỏi. Lần theo dãy câu hỏi logic này bạn sẽ đi đến được một kết quả hay mục tiêu nào đó có thể giúp bạn đưa ra quyết định cuối cùng.

6. Bonus: Cách để biến bất cứ thứ gì thành biểu đồ

Tuy trên đây là một số biểu đồ hữu dụng nhất với Product Manager nhưng có rất nhiều cách khác để bạn có thể minh họa cho những concept mà bạn muốn chia sẻ với team hay các stakeholder. Sẽ có những trường hợp bạn cần chia sẻ một ý tưởng hay concept nào đó không phù hợp để sử dụng những framework biểu đồ có sẵn. Bạn có thể sẽ cần tạo biểu đồ riêng cho những trường hợp này. Để có thể làm vậy, bạn cần làm quen với cách để biến bất cứ thứ gì thành biểu đồ. Dưới đây là một số bước để bạn có thể làm được điều đó:

Bước 1 – Tìm những thông tin bạn còn chưa nắm rõ

Đầu tiên, bạn cần hiểu rõ concept hay vấn đề trước khi minh họa nó bằng biểu đồ. Hãy liệt kê những ý chính bạn còn chưa hiểu rõ về vấn đề để có thể tìm người hay tài liệu có thể giúp bạn hiểu rõ hơn.

Bước 2 – Nháp lên giấy trước

Một khi bạn tự tin đã hiểu rõ concept, hãy tóm tắt các bước của quá trình hay concept đó lên giấy. Bạn có thể thoải mái sử dụng các hình khối, ký hiệu minh họa mà bạn muốn. Có một tip là bạn hãy hình dung mình đang giải thích concept cho một em bé 7 tuổi. Nếu bạn giải thích một concept gì đó cho trẻ con thì thường vẽ hình khối hay biểu tượng sẽ dễ giúp các bé hình dung hơn đúng không nào?

Bước 3 – Chọn framework phù hợp cho biểu đồ

Khi bạn đã vẽ nháp xong, hãy nhìn vào biểu đồ của mình và nghĩ xem nó có hợp với framework có sẵn nào không. Nó có hợp để làm biểu đồ phân làn không? Hay vẽ biểu đồ có chú thích sẽ hợp lý hơn? Hãy nghĩ đến các framework có sẵn và chọn dùng nó khi phù hợp. Nếu không có framework nào phù hợp thì đừng lo, bạn không nhất thiết phải chọn framework có sẵn.

Bước 4 – Vẽ lên máy (+ Một số công cụ hỗ trợ) 

Khi đã có bản nháp trên giấy và framework phù hợp, hãy chuyển biểu đồ của bạn thành file số để dễ dàng share được với cả team. Có rất nhiều dụng cụ hỗ trợ bước này, hãy chọn một công cụ bạn thấy phù hợp nhất để tạo bản số cho biểu đồ của mình. Dưới đây là một số công cụ bạn có thể dùng:

• Google draw, Google sheets – Công cụ miễn phí, đủ dùng trong 90% các trường hợp cần vẽ biểu đồ.
• Omnigraffle – Phải trả phí hơi cao nhưng công cụ này giúp biểu đồ trông chuyên nghiệp hơn, phù hợp trong trường hợp phải thuyết trình với bên thứ ba hay đối tác, khách hàng ngoài công ty.
• Invision – Công cụ phổ biến với team UX/ design nhưng nó cũng đặc biệt tiện lợi cho việc thêm chú thích để bình luận/ thảo luận.
• Sketch – Cũng phải trả phí hơi cao như Omnigraffle nhưng nó là một công cụ tốt nếu bạn thật sự muốn biểu đồ của mình có visual đẹp.
• Paper by 53 – Một chiếc app nhỏ xinh cho người dùng Ipad/ máy tính bảng có thể vẽ.

Bước 5: Test trước khi chia sẻ 

Trước khi bạn chia sẻ bất cứ thứ gì với các bên liên quan – đặc biệt là trong trường hợp bạn dùng biểu đồ để thuyết trình hay phát biểu trong cuộc họp quan trọng chẳng hạn – bạn nên test biểu đồ với các thành viên trong team trước. Bạn có thể cho đồng nghiệp xem biểu đồ và hỏi ý kiến họ xem biểu đồ diễn tả tốt chưa. Cách tốt nhất là bạn có thể yêu cầu họ nói cho mình nghe biểu đồ đang thể hiện điều gì. Họ có thể không biết background chi tiết về biểu đồ đó nhưng nếu họ nắm được concept chung mà biểu đồ đang diễn tả thì đó là tín hiệu chứng tỏ bạn đã làm tốt rồi đó.

© Nguồn: Careerly.vn
Để tìm thêm những nội dung tương tự, bạn có thể đăng ký tham gia cộng đồng người làm công nghệ trên Careerly App tại: https://try.careerly.vn/welcome/

Bài viết 5 loại biểu đồ hữu ích nhất cho PM đã xuất hiện đầu tiên vào ngày Công ty cổ phần giải pháp công nghệ fanxipan.