Chu trình phát triển phần mềm (Software Development Life Cycle) bao gồm hai giai đoạn chính: phát triển và vận hành. Hai giai đoạn này tương đối tách rời nhau, đặc biệt là ở các công ty có quy mô trung bình trở lên.

Tuy nhiên, nhằm tối ưu hóa chu trình phát triển phần mềm, giúp sản phẩm IT được release nhanh và thường xuyên hơn, khái niệm DevOps ra đời.

Định nghĩa DevOps là gì?

DevOps là tên gọi mới, là sự kế thừa và phát triển của một quan niệm về phát triển phần mềm đã tồn tại từ khá lâu.

DevOps là sự kết hợp của từ Development (phát triển tính năng sản phẩm) + Operations (vận hành):

• Giai đoạn phát triển (development) bao gồm phần việc của designer, developer, QA QC…
• Giai đoạn vận hành (operations) có sự tham gia của system engineer, system administrator, operation executive, release engineer, DBA, network engineer, security engineer…

Để cho dễ hình dung, và cũng để trả lời rõ hơn cho câu hỏi “DevOps là gì”, ta cần ngược trở lại lịch sử ngành phần mềm một chút:

• Ở buổi ban sơ của kỷ nguyên máy tính:

Quy trình phát triển phần mềm không hề có sự phân tách rạch ròi giữa hai giai đoạn phát triển (development) và vận hành (operations), nhất là đối với các sản phẩm vừa và nhỏ. Vì là người phát triển sản phẩm, Developer sẽ hiểu rõ về sản phẩm để chọn cách vận hành phù hợp nhất nên anh ta sẽ đảm nhiệm việc develop, đồng thời cũng kiêm luôn việc test, deploy sản phẩm.

• Sau đó, sự bùng nổ về quy mô của các công ty và sản phẩm công nghệ diễn ra:

Từ đó, kéo theo quy mô hệ thống phình ra theo cấp số nhân. Từ một vài server, hệ thống có thể phát triển lên đến hàng chục, hàng trăm, hàng nghìn, hoặc thậm chí hàng triệu server (ví dụ như trường hợp của Google, Facebook).
Yêu cầu chuyên môn hóa trở nên gắt gao, khiến quy trình phát triển phần mềm chia tách thành những giai đoạn riêng biệt. Đây là giai đoạn mà Dev và Ops tách bạch.

Khoảng một thập kỉ trở lại đây, trước nhu cầu phát triển và cải tiến sản phẩm liên tục để đáp ứng thị trường, sự chia tách này lại bộc lộ những nhược điểm rõ rệt.

Ngoài ra, ngành phát triển phần mềm cũng dịch chuyển theo một hướng khác – microservices.

Microservices: Một sản phẩm lớn được chia tách làm rất nhiều service nhỏ, các service này liên kết với nhau tạo thành một sản phẩm hoàn chỉnh.

Ví dụ, đối với người dùng, một trang web thương mại điện tử là một sản phẩm hoàn chỉnh. Nhưng trên thực tế, trang web này được gộp lại từ rất nhiều feature như đăng kí, đăng nhập, tìm kiếm.v.v… Mỗi feature này là một service riêng, có thể sử dụng ngôn ngữ lập trình và database riêng.

Tham khảo thêm: Sự phát triển và tương lai của DevOps

Lợi ích của DevOps

 “Cùng với phương pháp Agile, DevOps giúp hoàn thiện việc chuyển đổi quy trình phát triển và vận hành phần mềm từ mô hình thác nước (waterfall) sang mô hình phát triển/phát hành liên tục (continuous development/releases)”.

Ngoài ra, những lợi ích chính của DevOps là:

• Tăng cường sự cộng tác chặt chẽ giữa nhóm phát triển (development) và nhóm vận hành (operation), cũng như khả năng làm việc liên chức năng (cross-functional).
• Nâng cao tần suất triển khai (deployment), giúp rút ngắn thời gian phát triển/cải tiến sản phẩm.
• Tận dụng các công cụ tự động hóa, giúp hạn chế rủi ro, giảm tỉ lệ thất bại.
• Thời gian phục hồi sản phẩm nhanh hơn.

Tất cả đều phục vụ cho mục đích cuối cùng là cải thiện khả năng cung cấp dịch vụ IT một cách nhanh chóng. Từ đó, tăng khả năng cạnh tranh của sản phẩm/doanh nghiệp.

Công việc của DevOps Engineer là gì?

DevOps Engineer = Tư tưởng mới + Công cụ mới + Kỹ năng mới

Nếu ta hiểu được DevOps là gì – Là một văn hóa làm việc mới, một phương thức tiếp cận để thu hẹp khoảng cách giữa quá trình phát triển và vận hành phần mềm thì ta sẽ hiểu được DevOps Engineer là một vị trí nảy sinh do nhu cầu thực tiễn công việc, có thể tạm định nghĩa gồm tư tưởng, công cụ và kĩ năng mới.

Vậy công việc của một người làm DevOps là gì?

• Về mặt quy trình, DevOps cần đảm bảo làm thế nào để các bộ phận hợp tác trơn tru thuận lợi hơn
• Về mặt sản phẩm, DevOps cần làm thế nào để các service kết nối và giao tiếp với nhau theo rules hiệu quả, cũng như đảm bảo việc scaling được “êm ái”

1. Tư tưởng mới:

Tư tưởng mới ở đây chính là DevOps Engineer cần cần đặt lợi ích doanh nghiệp, lợi ích sản phẩm lên hàng đầu, đồng thời thấy rằng toàn bộ các team thực chất là cùng một “phe”, cùng chia sẻ lợi ích cũng như rủi ro.

Vậy thì, người làm DevOps Engineer là phải có tư tưởng – mindset đúng đầu tiên.

Trong hầu hết các công ty/dự án phần mềm, đội ngũ phát triển và vận hành bị chia tách thành nhiều team làm việc tương đối độc lập với nhau: Developer, Tester, Sysadmin.v.v… Cũng từ đó, kiểu tư duy “chúng ta” – “chúng nó” hình thành, tạo nên nhiều xung đột không đáng có, gây ảnh hưởng xấu đến doanh nghiệp/sản phẩm.

Thay vì đợi team Dev phát triển xong sản phẩm, rồi team Ops mới tham gia vận hành như trước kia. Thì nay, DevOps Engineer nên tham gia ngay từ đầu với đội ngũ phát triển. Nhằm:

• Hiểu sản phẩm hơn, để tối ưu hóa sản phẩm tốt hơn.
• Học ngôn ngữ lập trình mà công ty sử dụng, để nắm được logic code, mài sắc khả năng tư duy, nắm được tiến trình của code chạy như thế nào.v.v…

Khi deploy code, nếu gặp vấn đề ở chỗ nào, DevOps Engineer sẽ có thể chủ động tìm lỗi và fix luôn mà không cần phải chờ developer.

Việc làm DevOps Engineer TPHCM

Việc làm DevOps Engineer Hà Nội

2. Công cụ mới:

Nhiệm vụ quan trọng của DevOps Engineer là tự động hóa hệ thống. Cũng nghĩa là, DevOps Engineer cần liên tục tìm hiểu, chọn, và sử dụng các công cụ mới, hoặc thậm chí tự phát triển các automation tool cho công ty. Ví dụ:

• Để hỗ trợ Agile/Scrum thì sử dụng các công cụ như: JIRA, Redmine …
• Để chuẩn bị cho Infrastructure as code, và xây dựng CI/CD process thì sử dụng công cụ như: Terraform, Ansible, Jenkins, hay Github, Gitlab…

3. Kỹ năng mới:

Nhìn chung, công việc chính của DevOps Engineer rất gần với công việc của Sysadmin, bao gồm: deploy, optimizing, monitoring, analysis… Điểm khác biệt là:

• DevOps Engineer đòi hỏi nhiều kĩ năng mềm hơn, đồng thời phải biết dùng coding, scripting để automate hệ thống.
• Người làm DevOps Engineer cũng cần tìm hiểu về stack mà sản phẩm công ty đang sử dụng, để có thể cùng review bug, viết những unit test thông thường, và để khi phát triển tiến trình CI/CD thì deploy “êm ái” hơn.

Cho nên, nếu coi DevOps Engineer là Sysadmin “kiểu mới” thì cũng không sai.

Tham khảo thêm: DevOps Engineer vs System Engineer có phải là một vị trí?

Tuy nhiên, Sysadmin “kiểu cũ” rất lười code. Nhưng trong bối cảnh hiện nay, để tiếp tục theo đuổi ngành System thì họ cần phải biết automation.

Cũng có nghĩa, họ cần rèn luyện kỹ năng coding, scripting, và thậm chí học cả những ngôn ngữ lập trình mới theo công nghệ/stack mà nhóm phát triển sản phẩm sử dụng.

DevOps cần thành thạo những kỹ năng và tố chất gì?

Dựa trên những chia sẻ của anh Minh Tấn và Đăng Phong, một DevOps muốn thành công cần phải sở hữu những kỹ năng và tố chất sau:

• Kỹ năng lập trình “cứng” là điều bắt buộc

 DevOps Engineer thường là vị trí kiêm nhiệm (Developer kiêm nhiệm thêm phần việc operations, hoặc là System Engineer kiêm nhiệm thêm một phần việc của dev, v.v…) chính vì thế một DevOps cần phải có kỹ năng lập trình cứng.

Ví dụ, Tấn là System Engineer kiêm DevOps Engineer. Tấn muốn deploy version mới của sản phẩm lên 100 server. Nếu thực hiện việc này thủ công thì sẽ mất rất nhiều thời gian, và không tránh khỏi sai sót.

Trong trường hợp deploy thành công 50 con server, còn 50 con thất bại, thì cũng có nghĩa là sản phẩm của mình thất bại. Bởi vì cùng lúc sản phẩm sẽ chạy 2 version khác nhau, mà mình lại không kiểm soát 2 version này được. Muốn khắc phục thì cũng phải có thời gian.

Như vậy, để deploy nhanh hơn, hỗ trợ việc back-up, restore, đồng thời giảm thiểu rủi ro, thì với vai trò DevOps Engineer, Tấn sẽ viết automated script để ship code tự động lên server.

Ngôn ngữ lập trình phổ biến cho DevOps Engineer là Python, shell script.

Ngoài ra, để Ops, DevOps Engineer cũng cần hiểu sâu, thông thạo về hệ điều hành đang sử dụng (Linux, Docker.v.v…)

• Kỹ năng research tốt

Đặc biệt, người làm DevOps phải có khả năng research tốt để nhanh chóng tìm ra giải pháp, xử lý tình huống.
Tấn triển khai services trên nền tảng on premise. Một ngày “đẹp trời” nào đó, hệ thống gặp vấn đề, Tấn muốn move toàn bộ sản phẩm của mình lên cloud. Tuy nhiên, có rất nhiều cloud, nên chọn dùng cloud nào cho phù hợp?

Rõ ràng, trong tình huống này, nếu khả năng research không tốt, không nhanh chóng tìm ra cách để move toàn bộ mọi thứ đang chứa trên on premise lên cloud, thì sản phẩm của mình bị đình trệ rồi.

Hoặc, trong DevOps có rất nhiều bài toán hóc búa liên quan đến phần network, I/O, infra system .v.v… Một anh cứng về develop nhưng không hiểu sâu về phía Infra thì khi làm DevOps sẽ gặp rất nhiều khó khăn. Anh ta buộc phải research về Infra để phục vụ cho công việc.

• Sự cẩn thận, tỉ mỉ là quan trọng nhất

DevOps Engineer thường sẽ đảm nhiệm những công việc như migrate data cho công ty nên họ cần đề cao sự tỉ mỉ. Khi đó, chỉ cần xảy ra một sai sót nhỏ, ví dụ như sai 1 IP server, thì sẽ gây ảnh hưởng đến toàn hệ thống.

• Luôn đặt lợi ích tập thể lên hàng đầu

Tiêu chí này thể hiện qua những việc rất nhỏ nhặt cụ thể. Ví dụ như cách DevOps Engineer suy nghĩ, tổ chức, cấu trúc code/thư mục như thế nào, chia sẻ những best practices,… để mọi người có thể cùng nhau đọc và hiểu code đó, cùng tham gia được với mình.

• Nhìn nhận mọi thứ từ nhiều khía cạnh

Mâu thuẫn giữa nhóm phát triển và vận hành thường nảy sinh từ sự khác biệt về góc nhìn. DevOps Engineer là người cần nhìn nhận mọi thứ từ nhiều khía cạnh, để khách quan, sáng suốt hơn, biết “thông cảm” hơn.

Cụ thể, khi deploy mà code không chạy, thì DevOps Engineer cần xem xét kĩ: vấn đề nằm ở phía code hay phía môi trường.

Ví dụ, trường hợp làm với Laravel (PHP Framework), file config là .env. Sysadmin không có kinh nghiệm thì dễ mắc sai lầm là chỉ lấy phần code đó xuống và chạy và lỗi thì loay hoay và thường nghĩ do code.

Trong khi, lẽ ra cần phải hiểu những cấu hình liên quan đến môi trường và cách thức hoạt động của Laravel, và phải tác động vào file .env trước đã.

• Giao tiếp và hợp tác tốt với các team khác

Trong công việc, mối quan hệ tốt thì cái gì cũng dễ dàng, và ngược lại.

Để xây dựng mối quan hệ tốt, anh Phong nghĩ nên gạt chức danh lead/manager gì gì đó qua một bên, để giao tiếp với họ như là bạn bè bình đẳng.

Bạn tôn trọng họ, thì họ cũng sẽ tôn trọng, dễ dàng chia sẻ với bạn hơn. Mà khi xảy ra chuyện, cần nhờ vả thì họ cũng dễ dàng đồng ý hơn.

Ngoài ra, một DevOps Engineer cũng cần có:

• Kinh nghiệm với system và IT operations, quản lý dữ liệu.
• Nắm vững các tiến trình (CI/CD) và công cụ tự động hóa.
• Khả năng sử dụng nhiều công nghệ và mã nguồn mở, coding/scripting.
  Liệt kê ra thì dông dài như vậy, nhưng tóm gọn lại, tiêu chí để “chọn” DevOps Engineer của anh Phong là: những sysadmin-coder tài năng, có kinh nghiệm, đồng thời hiểu rõ:
• Hai mục tiêu quan trọng của việc viết phần mềm là “kiếm tiền” và “giao hàng”.
• Tất cả chúng ta – manager, dev, tester, DBA, Sysadmin.v.v… đều cùng một phe, cùng cố gắng để đạt mục tiêu chung: cung cấp phần mềm chất lượng tốt, đáng tin cậy, và đem lại lợi nhuận kinh doanh cho khách hàng.

DevOps trước hết là vấn đề mindset, nên bạn cần phải “đả thông tư tưởng” trước đã. Bạn có thể tìm hiểu “DevOps là gì” từ sách báo, qua các trao đổi trên diễn đàn, v.v…

Bạn cũng cần học một số ngôn ngữ lập trình cần thiết cho DevOps như: Python, Ruby, Lua Scripting.

Tiếp đến, bạn có thể lên các trang web tuyển dụng để đọc mô tả công việc của DevOps. Từ đó, bạn sẽ biết thị trường đang cần những kĩ năng gì, xu hướng dùng những tools gì.

Tài liệu DevOps tham khảo

• Sách Devops – The Phoenix Project: Cuốn sách này rất nổi tiếng, cá nhân mình đặc biệt thích vì nó giúp mình có mindset đúng về công việc (luôn hướng đến lợi ích tập thể, lợi ích của doanh nghiệp).
• Những khóa học DevOps của Edward Viaene trên Udemy – đặc biệt là Learn DevOps: Continuously Deliver Better Software: Đây là khóa học đầu tiên về DevOps mà mình theo. Mình thấy rất sáng rõ, dễ hiểu, và thiết thực trong công việc.
• DevOps Tutorials: Cung cấp những kiến thức nền tảng cũng như những công cụ phục vụ cho công việc của DevOps.
• DevOps Việt Nam: Hội nhóm mở trên Facebook, dành riêng cho các DevOps tại Việt Nam. Bạn có thể tìm thấy rất nhiều thông tin từ chia sẻ tài liệu, kinh nghiệm cho đến tuyển dụng DevOps tại đây.
• What is DevOps: Bài viết rất thú vị về sự ra đời cũng như những nguyên lý của DevOps.

DevOps Engineer trong ngành nói gì?

• Phải tuân thủ nghiêm ngặt quy trình QA QC

Để rút ra được bài học này, anh Tấn đã phải “nếm” phải sai lầm và trả giá đắt. Chỉ là sai sót nhỏ trong một dòng code, đã ảnh hưởng nghiêm trọng đến toàn bộ workflow sản phẩm. Sau đó, cả team anh, gồm 7 người, đã phải cày cật lực 10 ngày để khắc phục hậu quả.

Đợt ấy, team phụ trách migrate data sản phẩm, cụ thể là shipping data bằng automated tool.

Do chủ quan “code nhà mình” thì chắc “ngon lành cành đào” rồi, nên Tấn review không thật sự kĩ lưỡng. Tấn cũng chỉ test một phần (chứ không phải toàn bộ) trên môi trường staging – server test mà thôi.

Đến lúc đẩy code lên môi trường production thì, bùm, sự cố xảy ra!

Đại khái là sản phẩm lúc đó có tình trạng 2-3 user sử dụng 2-3 số điện thoại riêng biệt để đăng kí dùng chung 1 ID account. Khi những user này đăng nhập thành công, họ đều được redirect đến cùng 1 account.

Sự cố đã ảnh hưởng nghiêm trọng đến chuyện thanh toán tiền bạc của những ID account dùng chung, cũng như toàn bộ workflow của sản phẩm.

Từ sự cố kể trên, phải cực kì cẩn trọng, tuân thủ nghiêm ngặt quy trình QA QC trước khi release.

• Phải giữ bình tĩnh trong mọi tình huống

Trong lúc làm việc, bạn cần phải giữ bình tĩnh trong mọi tình huống, vì cuống lên cũng không giải quyết được gì, mà chỉ thêm rối.

Có lần team ở lại văn phòng làm việc khuya. Đến khoảng 3 giờ sáng thì xảy ra sự cố. Cả team vừa mệt vừa hoảng, nên cứ cuống lên rồi bị cuốn theo cái “hố đen” sự cố đến tận ngày hôm sau. Nếu bình tĩnh hơn, có lẽ bọn mình đã nhìn ra được giải pháp tốt nhất để xử lý tình huống ngay lúc đó.

• Làm việc nhóm thì phải biết thông cảm, an ủi người khác

Khi sản phẩm bị bug trên production, thì người chịu trách nhiệm về những tính năng đó đang rất áp lực. Lúc này, nếu leader chỉ biết la lối, làm căng lên thì bạn đó sẽ không còn tinh thần để tiếp tục làm việc/giải quyết vấn đề.

Một leader tốt cần giữ bình tĩnh để trấn tĩnh tinh thần anh em, đồng thời phải cùng lao vào giải quyết vấn đề, chứ không phải chỉ đứng đằng sau chỉ trỏ.

© Nguồn: ITViec.com

Bài viết DevOps là gì? DevOps thành công nhất định phải sở hữu 6 kỹ năng và tố chất này đã 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.

Lý thuyết và quy trình thực hiện A/B Testing có thể dễ dàng tìm thấy ở nhiều nguồn, tuy nhiên ví dụ thực tế thì lại không nhiều. Trong bài viết hôm nay, Careerly gửi đến cho bạn 7 kết quả A/B test được thực hiện bởi những công ty công nghệ hàng đầu thế giới như Amazon, Google, Airbnb, kèm một vài phân tích kết quả ngắn. Hy vọng sau khi đọc bài viết này, team của bạn sẽ có thêm động lực tiến hành kiểm chứng thay đổi bằng A/B test nếu vẫn còn chưa thực hiện phương pháp này trước đây.

Amazon: A/B test layout của website – Full width screen vs Fixed width screen.

Thử nghiệm:

• Biến thể A, chiều rộng của cột nội dung chính trang web sẽ được trình bày theo chiều rộng của màn hình người dùng (full width).
• Biến thể B, chiều rộng của cột nội dung chính được cố định (fixed width) ở mức tối đa là 1500 pixels.

Kết quả: Amazon đã chọn biến thể B.

Phân tích: Thực ra, đây là kết quả khá giống với nhiều kết quả A/B test của các dịch vụ/nền tảng online khác. Hiện nay màn hình của người dùng đã được cải thiện nhiều về độ lớn và độ phân giải vì vậy nhiều trang web lựa chọn cách trình bày full width. Tuy nhiên, theo các kết quả AB test thực tế, việc giới hạn chiều rộng và để padding cho layout lại khiến việc theo dõi nội dung tiện lợi và dễ dàng hơn. Với phiên bản full width, nội dung dàn trải quá rộng từ trái sang phải, gây khó khăn cho việc nắm bắt thông tin của người đọc.

Amazon: A/B test giao diện menu – Dropdown vs “Hamburger” 

Thử nghiệm:

• Biến thể A: các category nằm trong label “Department” được trình bày theo dạng dropdown menu.
• Biến thể B: phần menu này được chuyển đổi thành dạng “hamburger menu” phần label mang tên “department” được thay thế bằng một biểu tượng. Ngoài ra, thí nghiệm này không chỉ dừng lại ở chỗ việc thay đổi cách trình bày menu bar mà Amazon còn gắn thêm thông điệp kêu gọi sign-in ở ngay option đầu tiên sau khi người dùng nhấn vào biểu tượng hình hamburger.

Kết quả: Biến thể B với hamburger menu được chọn.

Phân tích: Trên thực tế kết quả của bài test này sẽ khác nhau tùy theo tính chất của sản phẩm/dịch vụ (đây là lí do bạn không nên sao chép các ông lớn một cách mù quáng). Với những trang web có lượng người dùng hầu hết là những người lần đầu truy cập thì menu được trình bày theo hình thức dropdown sẽ mang tính trực quan hơn. Tuy nhiên Amazon là trang web có lượng người dùng đã có kinh nghiệm sử dụng web nhiều lần, nên việc trình bày menu dưới dạng hamburger sẽ giúp rút gọn menu so với cách truyền thống, đỡ rối mắt cho người dùng.

Netflix: A/B test nội dung nút CTA (call to action) trên landing page: 

Thử nghiệm: Đây là một trong những thí nghiệm A/B test rất phổ biến. Trong thí nghiệm này, Netflix đơn giản chỉ thay đổi nội dung trong nút CTA.

• Biến thể A: “Watch free for 30 days” (Trải nghiệm miễn phí trong 30 ngày)
• Biến thể B: “Try it now” (Hãy trải nghiệm ngay).

Kết quả: Biến thể B với nội dung “Try it now” được chọn.

Phân tích: Trong thử nghiệm này, từng đặc điểm của mỗi sản phẩm mà sẽ cho ra kết quả khác nhau. Ở trường hợp của Netflix, nội dung CTA “Watch free for 30 days” có thể khiến cho người dùng thấy được tương lai phải trả tiền cho dịch vụ sau 30 ngày dùng miễn phí, từ đó khiến họ ngần ngại click thực hiện hành động hơn.

Google: A/B test giao diện các hạng mục của bộ lọc tìm kiếm:

Thử nghiệm: Trên thanh menu của bộ lọc kết quả tìm kiếm, Google đã thực hiện A/B test với:

• Biến thể A: chỉ thể hiện tên các bộ lọc trên thanh menu, chỉ đặt icon trên thanh tìm kiếm chính.
• Biến thể B: chèn thêm icon bên cạnh tên của các bộ lọc, icon trên thanh tìm kiếm chính giữ nguyên.

Kết quả: Sau một tháng chạy thử nghiệm, Google đã chọn biến thể B, thay đổi phần nhìn trên trang tìm kiếm của mình.

Phân tích: Biến thể B đã mang lại hiệu quả trực quan hơn, giúp thay đổi thói quen của người dùng, mang lại hiệu quả hơn nhiều với biến thể A. Qua bài học từ Google, khi thiết kế sản phẩm ngoài phần text quan trọng, chúng ta cũng nên bổ sung icon khi trình bày để đạt hiệu quả tốt hơn.

Airbnb: A/B test cách trình bày timeline hoàn tiền khi hủy phòng: 

Thử nghiệm: Airbnb thực hiện A/B test với:

• Biến thể A: trình bày 2 dòng text về thời gian được hủy phòng miễn phí, và thời gian được hoàn tiền 50% khi hủy phòng.
• Biến thể B: thêm phần graphic thể hiện rõ ràng timeline về phần trăm số tiền khách được refund khi hủy phòng. AirBnb hi vọng với graphic này khách hàng sẽ dễ dàng theo dõi timeline về tiền được refund.

Kết quả: Thử nghiệm này lại cho ra một kết quả rất bất ngờ. Việc timeline được trình bày rõ ràng trong biến thể B lại đem đến hiệu quả ngược và Airbnb lại quay về với cách trình bày truyền thống, chỉ có text.

Phân tích: Từ kết quả thử nghiệm này, chúng ta có thể rút ra rằng, không phải lúc nào việc cho khách hàng nhìn rõ mọi thông tin đều tốt, đặc biệt là những dạng thông tin khiến khách hàng cảm thấy bất lợi như tiền phạt họ phải chịu hoặc những giới hạn trong dịch vụ.

Airbnb: A/B test vị trí đặt nút

Thử nghiệm:

• Biến thể A: Airbnb đã đặt nút engagement hình trái tim (like, wish list, favorite) trực tiếp trên ảnh của phòng.
• Biến thể B: Họ tách nút này ra phần rìa phải trên cùng, ngay bên cạnh phần biểu thị tên phòng.

Kết quả: Nút engagement nằm riêng sẽ mang lại hiệu quả hơn.

Phân tích: Thông qua thử nghiệm này có thể thấy rằng, việc đặt tách riêng các yếu tố có mục đích khác nhau giúp người dùng dễ chú ý hơn, khuyến khích họ thực hiện hoạt động tương tác hiệu quả hơn. Ngoài ra, khi có nhiều yếu tố quan trọng cần trình bày trên giao diện, chúng ta nên sắp xếp chúng theo thứ tự quan trọng để bố trí cho phù hợp.

Booking.com: A/B test giao diện cửa sổ modal (modal window): 

Thử nghiệm: Booking.com thường thích bố trí popups, overlays và nudges nhiều hình dạng và kích thước để “nhắc nhở” người dùng của mình. Trong A/B test này:

• Biến thể A: giao diện web truyền thống của Booking.com, bố trí menu chọn ngày giờ phía bên trái màn hình, khi người dùng điền đầy đủ các thông tin, trang web sẽ di chuyển.
• Biến thể B: Booking.com đã chuyển một phần các thông tin cần điền vào cửa sổ modal bên phải.

Kết quả: Ý đồ của Booking.com không thành công, cách trình bày như cũ vẫn mang lại hiệu quả hơn.

Phân tích: Trong thí nghiệm A/B test của Booking.com khi thêm một cửa sổ modal trên 1 trang web như vậy có thể khiến người dùng bị rối mắt, ngoài ra việc trải dài thông tin từ trái sang phải còn làm phức tạp hóa gaze path (hành trình của mắt).

Lời kết:

Thông qua các ví dụ trên, có thể thấy rằng, một số kết quả A/B test mang lại hiệu quả đúng với mong đợi ban đầu của team nhưng cũng có một số kết quả đi ngược lại hoàn toàn, do đó không có gì đảm bảo chắc chắn những gì chúng ta suy nghĩ hoặc những “quy luật” mà chúng ta định ra đã là đúng, chỉ có người dùng/khách hàng mới mang lại đáp án chính xác nhất cho các thử nghiệm. Vì vậy khi thử nghiệm một thay đổi mới cho sản phẩm của bạn, đừng chủ quan loại bỏ đi bất cứ phương án nào chỉ vì nó “không hợp với lẽ thông thường”.

Ví dụ trong bài được lấy từ Leaks A/B testing được chia sẻ trên GoodUI.org. Bạn có thể tìm thêm những kết quả A/B testing thực tế tương tự trên trang web này.

© 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 Học được gì từ 7 ví dụ A/B Test thực 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.

Việc chọn phân khúc thị trường và target khách hàng không phải là một chiến lược gì xa lạ. Chia khách hàng theo nhân khẩu, địa lý hay mức thu nhập, vân vân vẫn là công việc cơ bản của các marketer. Nhưng chỉ như vậy thôi chưa chắc đã đủ để hiểu được những khách hàng này muốn gì để truyền tải thông điệp marketing hay phát triển sản phẩm phù hợp với họ. Những cách chia định tính, phân nhóm số lượng lớn khách hàng dựa trên số liệu thường có điểm yếu là tạo ra một hình ảnh máy móc, không thực tế về khách hàng.

Vậy khi bạn đã thu thập đủ dữ liệu về khách hàng mà vẫn không xác định chính xác được target cho sản phẩm thì bạn phải làm gì? Cách tốt nhất là bạn nên xác định các mẫu hành vi và đặc điểm quan trọng cụ thể của khách hàng, hay trong quản lý sản phẩm công nghệ chính là xây dựng một User Persona (Chân dung người dùng) sống động cho người dùng của sản phẩm. Hôm nay hãy cùng Careerly tìm hiểu về User Persona cũng như cách để tạo một User Persona tốt, và đương nhiên không thể thiếu ví dụ thực tế! Đọc hết bài viết để không bỏ lỡ case thực tế cực hay về cách Nike đã ứng dụng User Persona để cải thiện trải nghiệm cho đối tượng khách hàng là nữ giới hơn nhé!

Persona là gì?

Một persona thể hiện một kiểu hành vi nhất định của một nhóm người trong thực tế, tuy nhiên chính nó không phải là một cá thể có thật. Đó là một nhân vật giả tưởng có các đặc điểm của khách hàng. Đó là một hình ảnh chung miêu tả một phương thức nhất định mà khách hàng tương tác với sản phẩm hay thương hiệu.

Làm marketing cho một công ty tech cũng tương tự như làm phim vậy. Bộ phim bom tấn nào cũng bắt đầu bằng một kịch bản hay, nhưng những mảnh ghép của câu chuyện đó sẽ không thể hài hòa ghép lại thành một bộ phim nếu các nhân vật không hấp dẫn. Cũng như vậy, sản phẩm nào cũng bắt đầu từ hiểu biết toàn diện về khách hàng họ có và khách hàng họ muốn thu hút. Các dữ liệu bạn thu thập được sẽ phản ánh nhiều phân khúc thị trường của sản phẩm, và bạn sẽ cần các avatar (đại diện ảo) thể hiện các kiểu khách hàng khác nhau.

3 loại Persona chính trong UX

1. Proto-persona là chân dung khách hàng đơn giản, chung chung dựa trên cách nhìn nhận, suy nghĩ của riêng bạn hay tổng hợp ý tưởng của team sản phẩm mà chưa qua kiểm chứng với nghiên cứu, thu thập dữ liệu trong thực tế. Loại này phù hợp để dùng trong giai đoạn cần đưa ra những quyết định cơ bản hay những bước đầu trong quá trình phát triển sản phẩm hướng đến người dùng.
2. Marketing persona tập trung vào mục đích, nhu cầu của khách hàng cũng như sự quan tâm của khách hàng với sản phẩm. Nó có thể bao gồm các đặc điểm về khuynh hướng mua sắm, thói quen tiêu thụ thông tin trên các phương tiện truyền thông hay hoàn cảnh quyết định mua hàng. Kiểu persona này sẽ phù hợp để xác định tiềm năng của thị trường, thông điệp và những ưu tiên hàng đầu khi quảng bá sản phẩm.

Về cơ bản, persona cho phép bạn cá nhân hóa hay hướng marketing đến những phân khúc khách hàng khác nhau. Persona sẽ cho bạn insight về cách làm thế nào để xây dựng chiến lược, thông điệp marketing phù hợp và thành công. Persona giúp bạn lên ý tưởng và tạo những nội dung có chủ đích tập trung vào đúng đối tượng, vì vậy việc xác định persona trong quá trình xây dựng chiến lược truyền thông là rất cần thiết cho sản phẩm.

3. Design persona giúp xác định một sản phẩm hay dịch vụ là gì và không là gì, giải quyết vấn đề của người dùng như thế nào và sẽ được sử dụng như thế nào. Dựa trên UX Research, một profile của loại này sẽ bao gồm hành vi và vấn đề (pain point) người dùng đang sử dụng sản phẩm gặp phải. Vai trò của designer là mô hình hóa hành vi thành một nhân vật chung. Việc này sẽ giúp cho họ tập trung thiết kế cho một kiểu người dùng nhất định.

Các bước tạo User Persona

Có 4 bước chính để tạo User Persona và hiểu nhu cầu người dùng

1. Xác định các target group và lựa chọn các đại diện của nhóm đó để làm nghiên cứu.

Những persona tốt nhất là những persona được xây dựng dựa trên insight có được từ các khách hàng thực tế thông qua khảo sát hay phỏng vấn. Nghiên cứu tốt cần tiếp cận nhiều kiểu khách hàng, đối tượng và cả những người nằm ngoài database của bạn nhưng vẫn có thể phù hợp trở thành target cho sản phẩm.

2. Làm nghiên cứu người dùng (phỏng vấn, khảo sát,…). Thu thập thêm thông tin để lấp những khoảng trống hiểu biết về người dùng.

Thiết kế vì mình mà không phải vì khách hàng chưa bao giờ là ý tưởng hay. Hãy cảnh giác đừng đưa ra quyết định dựa trên phán đoán chủ quan của bản thân. Bạn không bao giờ giống người dùng bình thường, bởi vì bạn đã quá quen và am hiểu với lĩnh vực chuyên môn này, nên bạn cần lắng nghe những người không giống như bạn.

3. Biến kết quả nghiên cứu, insight thành những đặc điểm chung, chuẩn bị tạo chân dung.

Giai đoạn phân tích dữ liệu thường là phần khó nhất, bởi vì bạn cần so sánh rất nhiều tổ hợp hành vi và thái độ khác nhau. Thông thường, persona sẽ là một trang slide tóm tắt được những xu hướng và điểm chung quan sát được từ giai đoạn nghiên cứu.

4. So sánh kết quả để tổng hợp hoặc phân nhóm các hồ sơ khách hàng. Tạo một biểu đồ phân khúc khách hàng.

Insight từ tài liệu persona sẽ giúp người đọc hiểu rõ cái gì quan trọng với khách hàng. Những người làm product có thể dùng tài liệu / biểu đồ để thuyết trình, thảo luận nội bộ hoặc khái niệm hóa.

Cách thu thập dữ liệu

Cần có đủ đối tượng nghiên cứu để có thể khẳng định hay phủ nhận giả thuyết. Các chuyên gia khuyên rằng nên bắt đầu với thu thập dữ liệu từ khoảng 5 đến 30 người để tạo 1 persona. Các phương pháp nghiên cứu thì cũng đã được Careerly đề cập ở nhiều bài trước, bạn có thể phỏng vấn hoặc làm khảo sát. Ngoài ra, sau đó bạn nên xác nhận lại kết quả nghiên cứu bằng cách phỏng vấn với các team khác trong công ty cũng thường tương tác với khách hàng như sales, customer success hay bên hỗ trợ khách hàng.

Những phản hồi, dữ liệu giống nhau cần được gom vào chung một nhóm để bạn thiết kế một hình mẫu chung. Thường Persona có thể được thiết kế bằng cách kết hợp từ hai yếu tố trở lên trong các yếu tố sau:

• Địa lý: quốc gia, vùng miền, thành phố, khu vực trong thành phố, khí hậu
• Nhân khẩu: tuổi, giới tính, thu nhập, học vấn, quy mô gia đình, quốc tịch
• Tâm lý: niềm tin, giá trị, thái độ, địa vị xã hội, lối sống
• Hành vi: nhận thức, hoàn cảnh, sự sẵn sàng hành động của người mua

Thêm một lớp dữ liệu vào bảng phân tích của bạn để theo dõi xem người dùng đến từ nguồn nào, họ dùng những keyword nào để tìm thấy product, và họ thực hiện hành động gì với product. Google Analytics hay Facebook Insights có thể giúp tổng hợp những dữ liệu về nhân khẩu như tuổi, giới tính, thiết bị họ sử dụng.

Nguồn dữ liệu thứ hai có thể dễ dàng thu thập đó là thông tin trên mạng. Bạn có thể lướt qua các trang cá nhân trên các mạng xã hội, blog cá nhân hay các bài đăng về product của mình hoặc product của đối thủ. Tuy nhiên, lướt web chỉ giúp bạn nghiên cứu môi trường sống và hoạt động thường ngày của khách hàng để hiểu họ hơn, chứ giai đoạn nghiên cứu đương nhiên bạn không thể chỉ lướt web không mà đưa ra kết luận được.

Tạo profile cho Persona

Không có một công thức chuẩn cho việc tạo một User Persona, nhưng nó cũng cần có một số yếu tố quan trọng. Một persona hiệu quả nên bao gồm những thông tin cơ bản sau:

• Tên giả và ảnh
• Nhân khẩu: tuổi, giới tính, thu nhập, vị trí, học vấn, gia đình
• Tiêu đề gợi tả
• Công việc hoặc mô tả công việc, với những thông tin quan trọng về công ty (quy mô, cơ cấu tổ chức)
• Châm ngôn
• Một lời kể về cuộc sống thường ngày
• Mục tiêu và thử thách

Persona là một chân dung về mặt tâm lý của một cá nhân và môi trường xung quanh cá nhân đó. Persona cũng là một khái niệm về mặt xã hội, bao gồm tương tác với những người khác hoặc với xã hội, thứ xác định hành vi. Những quan niệm xã hội, quan điểm phổ biến hoặc cả danh tiếng đều có thể là nguồn gốc của hành động. Các giá trị cũng như những nỗi sợ cũng có thể giúp xác định cảm xúc của khách hàng gắn với sản phẩm. Thái độ và cách nhìn cũng thường giúp tìm ra những lý do làm khách hàng không tương tác với sản phẩm. Để tận dụng persona tốt hơn thì bạn cũng có thể thêm cả thông điệp marketing hay elevator pitch cho persona. Thông điệp sẽ mô tả cách sản phẩm giải quyết vấn đề, nhu cầu cho mỗi persona, còn elevator pitch nêu cách để giải thích và bán sản phẩm cho khách hàng tương ứng.

Tùy công ty, tùy sản phẩm hay tùy mục đích sử dụng, các thông tin cụ thể chơi persona có thể khác nhau. Ví dụ kể cả là cùng một công ty, sản phẩm, persona dùng cho blog sẽ khác persona cho người dùng thực tế của app. Bên cạnh đó, số lượng persona cũng linh động tùy từng trường hợp, dù thông thường bạn nên bắt đầu với khoảng 3-5 persona. Ngoài ra, đừng chỉ tập trung vào tìm kiếm chân dung khách hàng lý tưởng của bạn. Ngược lại, hiểu kiểu khách hàng bạn không muốn – ví dụ đối tượng bạn sẽ cần quá nhiều tiền bạc và công sức để biến họ thành người dùng – cũng có thể giúp giảm đáng kể chi phí tăng người dùng mới (acquisition) và duy trì sử dụng (retention). Sau khi đã hoàn thành mô tả cho tất cả các persona bạn cần, đừng quên chia chúng thành persona chính và persona phụ dựa trên mục đích tạo persona nhất định. Ví dụ nếu mục đích của bạn là tăng người dùng mới, persona chính sẽ là những người đưa ra quyết định sử dụng. Nếu mục đích của bạn là giảm churn rate, persona chính sẽ là những người thường xuyên sử dụng sản phẩm.

Các đặc điểm của một Persona tốt

1. Thực tế

Các persona cần được xây dựng dựa trên hoàn cảnh hiện tại, được quan sát từ nghiên cứu với người thật. Miêu tả khách hàng quá lý tưởng chỉ phù hợp để đặt những mục tiêu trong tương lai. Hãy chú ý đến những chi tiết về tâm lý để persona của bạn sống động hơn. Một cách để biết được bạn đang có một persona tốt là khi bạn có thể trả lời các câu hỏi nếu đặt mình vào persona đó. Persona cần có một cá tính riêng, và đó là lý do tại sao bạn cần thiết kế chúng với tên riêng và tiểu sử/ giới thiệu bản thân.

2. Phản ánh những điểm chung để tìm ra/kiểm chứng nhu cầu của người dùng

Để làm được điều này, bạn cần hiểu hoàn cảnh, thái độ và động lực của người dùng. Một persona tốt có thể dùng để chứng minh hay phủ nhận một quyết định nào đó. Bạn có thể nhớ những profile này trong đầu khi lên ý tưởng hay thảo luận ý tưởng. Cuối cùng, persona giúp tăng hiệu quả cho các bước đầu của quá trình thực thi sản phẩm. Chúng ta có thể thử nghiệm sản phẩm với nhiều trường hợp khác nhau bằng cách ghép một persona với một tình huống giả định nào đó – cũng tương tự như việc nghiên cứu người dùng thật với một tình huống giả định. Nếu như ai đó đóng vai làm persona này cảm thấy khó chịu, có lẽ cả nhóm người dùng mà persona này đại diện cũng sẽ có những vấn đề tương tự.

Ứng dụng  User Persona trong thực tế: 2 User Personas cho nữ giới của Nike+

Nike vốn thường xây dựng các personas riêng cho các môn thể thao khác nhau như chạy marathon, bóng rổ, bóng đá, đánh gôn,… Ví dụ chúng ta có thể thấy trong môn bóng rổ Nike đã dùng ngay Persona có thật là Michael Jordan để thu hút đối tượng khách hàng là thanh thiếu niên đam mê bóng rổ. Tuy nhiên, cách dùng persona như thế này thường không phù hợp với đối tượng khách hàng là nữ giới, vì phần đông nữ giới thường quan tâm đến các môn thể thao như yoga, khiêu vũ, .. mà phân khúc thị trường cho từng bộ môn này thì không lớn, và cũng ít có các vận động viên nữ có ảnh hưởng để đại diện thu hút khách hàng cho các nhóm.

Vì vậy, dựa trên số liệu bán hàng thực tế của khoảng 145 triệu thành viên Nike+, Nike đã tạo ra 2 persona như dưới đây để bắt đầu nghiên cứu sâu hơn về nhu cầu của hai nhóm đối tượng tương ứng, từ đó tập trung cải thiện trải nghiệm app phù hợp cho hai đối tượng này.

1. Weekend Runner “Jessi”:

• Mô tả Persona: Jessi là một cô gái 30 tuổi sống ở Boston. Sau vài tháng lần đầu cô lần đầu thử sức chạy bán marathon. Cô đang tập luyện chăm chỉ bằng app “Nike Run Club”.
• Các chiến lược cải thiện trải nghiệm:
  • Dựa trên nhật ký tập luyện của Jessi, gợi ý các sản phẩm quần áo, giày thể thao phù hợp với thói quen chạy bộ của cô ấy.
  • Dự đoán độ mòn của giày để thông báo khi nào nên đổi giày sau một thời gian tập luyện.
  • Gợi ý chat tư vấn cùng chuyên gia marathon để tìm ra đôi giày vừa có thể đạt được mục tiêu (đặc biệt trong lần đầu thử sức) lại “vừa túi tiền” (có thể tận dụng để đi làm luôn chẳng hạn).
  • Thêm tính năng ‘Audio Guided Runs’ huấn luyện chạy bộ với giọng hướng dẫn của vận động viên điền kinh hay diễn viên nổi tiếng,…

2. Style Shopper “Alex”:

• Mô tả Persona: Alex là một cô gái 26 tuổi sống ở Los Angeles. Khi chơi thể thao cũng như khi không chơi, cô ấy đều muốn ăn mặc phải thật phong cách. Cô ấy thích lướt xem các sản phẩm trên app Nike.
• Các chiến lược cải thiện trải nghiệm:
  • Để người dùng dễ tìm sản phẩm khoe với bạn bè, thiết kế màn hình chính của app Nike tập trung vào nội dung sản phẩm cá nhân người dùng quan tâm.
  • Quảng cáo các thông tin về sản phẩm Nike được các ngôi sao thể thao, influencer nổi tiếng sử dụng trên họa báo cùng các tip phối đồ với sản phẩm của Nike.
  • Thêm tính năng ‘Reserve For You’ cho phép người dùng đặt trước cho những sản phẩm họ quan tâm tìm kiếm nhưng đã hết hàng.

© 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 User Persona: Hướng dẫn tạo chân dung người dùng đã 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.

Thông thường sau hai bước Nghiên cứu (Research) và Thấu hiểu (Empathize), để tìm hiểu về vấn đề và nhu cầu của người dùng thì team Product sẽ bước vào giai đoạn Lên ý tưởng (Ideation), Thiết kế (Design) , Thử nghiệm (Test) và Phát triển (Develop) sản phẩm cuối cùng. Ngoại trừ hai bước đầu tiên thì các bước còn lại luôn đồng hành cùng các công cụ UI Design. 

Ở giai đoạn Ideation, các công cụ này được dùng trong thiết kế các wireframe (khung sườn) để đưa các prototype (bản mẫu) được brainstorm trên giấy thành giao diện sơ khai trên màn hình hay thiết kế user flow (đường dẫn người dùng) để cụ thể hóa các user scenario (kịch bản người dùng). Và tất nhiên, trong giai đoạn Thử nghiệm, các công cụ này cũng chính là trợ thủ đắc lực để sửa đổi các bản prototype và phát triển các sản phẩm ngày càng thân thiện với người dùng hơn. 

Các công cụ UI Design cần được sử dụng liên tục để thiết kế, chỉnh sửa và nâng cấp sản phẩm, vì vậy những công cụ thiết kế có quá nhiều chức năng nhưng lại xử lý chậm và cồng kềnh như Photoshop hay Illustrator không phù hợp cho UI Design. Thay vào đó, những công cụ UI Design sẽ phải đáp ứng đủ 3 yêu cầu: sử dụng thiết kế vector, có các chức năng chuyên dụng cho UI Design, phần mềm xử lý nhanh và nhẹ. 

Top các công cụ UI Design năm 2020:

Trong một cuộc khảo sát trên 4000 UI designer trên toàn thế giới vào năm 2020 của uxtools.co, kết top 3 công cụ được nhiều designer sử dụng nhất ở các hạng mục như sau: 

Hạng mục UI Design: 

1. Figma
2. Sketch
3. XD

Hạng mục Brainstorming/Ideation:

1. Miro
2. Figma
3. Sketch

Hạng mục User Flow:

1. Figma
2. Miro
3. Sketch

Hạng mục Prototyping Division:

1. Figma
2. Invision
3. XD

Hạng mục Design System Management:

1. Figma
2. Sketch
3. XD  

Có thể thấy 3 công cụ UI Design được sử dụng phổ biến nhất chính là Sketch, XD và Figma, hôm nay, Careerly sẽ tổng hợp một số ưu và nhược điểm của 3 công cụ này, hi vọng các bạn đang muốn tìm hiểu về UI Design có thể tham khảo để lựa chọn công cụ phù hợp với nhu cầu của mình. Thường người mới khi bắt đầu học về Prototyping hay phân vân trong việc lựa chọn công cụ để học, tuy nhiên theo Careerly, khi có khả năng sử dụng được một trong ba công cụ dưới đây thì việc chuyển sang một công cụ khác không phải là việc quá khó nên bạn nếu mới bắt đầu thì cũng không cần phải quá đau đầu về việc học công cụ nào cho phù hợp trong ba công cụ sau. 

1. Sketch: 

Công cụ đầu tiên đáp ứng đủ các yêu cầu khi thiết kế UI, xuất hiện lâu nhất và được biết đến rộng rãi nhất. Sketch là công cụ trả phí, $99 cho bản quyền sử dụng vĩnh viễn.

• Ưu điểm: 
  • Sở hữu kho plug-in (các chương trình ngoài để mở rộng chức năng của ứng dụng) lớn nhất do là công cụ xuất hiện sớm nhất
  • Thiết kế ổn định.
  • Thường xuyên được cập nhật.
  • Sketch đã bổ sung chức năng cộng tác, giúp các cộng sự có thể cùng thao tác đồng thời. 

• Khuyết điểm: 
  • Hiện nay chỉ sử dụng được trên Mac.
  • Nhiều chi phí (chi phí theo dõi, chi phí plug-in)
  • Chức năng hỗ trợ Prototyping còn đơn giản nếu so sánh với XD hay Figma.

2. Adobe XD:

Nhà Adobe đã quá nổi tiếng với Photoshop và Illustrator nhưng mãi đến năm 2016 Adobe XD mới ra đời phục vụ riêng cho thiết kế UI.

Tuy sinh sau đẻ muộn so với người anh em cùng nhà Photoshop và Illustrator nhưng tốc độ phát triển của XD rất đáng gờm, nhanh chóng chiếm được cảm tình của nhiều UI designer. 

• Ưu điểm:
  • Cùng một nhà với đàn anh Photoshop và Illustrator do đó môi trường sử dụng và các nút tắt trong XD tương tự như với anh em của mình.
  • Có thể sử dụng Cloud của Adobe.
  • Sử dụng linh hoạt trên cả Window và Mac
  • Công cụ tất cả trong một, có thể tạo Prototyping mà không cần thêm plug-in. 
  • Có thể dựng Animation đơn giản.
  • Có thể tạo link chia sẻ để cộng sự cùng feedback.
  • Miễn phí Starter Plan cho người dùng cá nhân (Kể từ tháng 10 năm 2020, Adobe XD giới hạn 1 project có thể chia sẻ được cho tối đa 2 editor)

•  Khuyết điểm: 
  • Chi phí lớn khi sử dụng ở mức độ chuyên nghiệp.

3. Figma:

Là công cụ thiết kế UI được mong chờ nhất năm 2020, Figma xây dựng hình tượng “công cụ thiết kế UI tối ưu hóa hiệu quả hợp tác thiết kế”, để làm nổi bật bản thân với các công cụ khác. 

• Ưu điểm:
  • Hiệu quả hợp tác thiết kế vượt trội.
  • Có thể sử dụng trực tiếp trên trình duyệt web, không cần tải app về máy.
  • Tài nguyên (resource) được lưu trực tiếp trên Cloud, tiết kiệm không gian lưu trữ của máy. 
  • Nhiều người có thể thao tác thiết kế đồng thời trên artboard.
  • Tự động lưu theo thời gian thiết kế.
  • Có thể để lại comment trực tiếp trên artboard, vừa nhận feedback vừa cải thiện thiết kế.
  • Quản lý các phiên bản của sản phẩm bằng chức năng history.
  • Miễn phí Starter Plan (giới hạn 3 project, không giới hạn số file trong cùng 1 project và có thể có 2 editor).

• Khuyết điểm:
  • Hoạt động trên trình duyệt web, vì vậy thiết kế có thể bị gián đoạn nếu internet có vấn đề hoặc khi server của Figma gặp vấn đề. 
  • Vấn đề về bảo mật.

© 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 So sánh Top 3 Công cụ UI Design đã 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 dưới đây giới thiệu cơ bản về UX Writing, một nhân tố rất quan trọng trong việc tối ưu trải nghiệm của người dùng với sản phẩm mà các Product Manager nhất định phải biết. Bằng cách giới thiệu về định nghĩa của UX Writing, giới thiệu cách viết UX Writing tốt cũng như phân biệt UX Writing với Copywriting, sau bài viết này, Careerly tin rằng bạn sẽ có được cái nhìn khá rõ ràng và đầy đủ về bản chất cơ bản của UX Writing.

1. UX Writing là gì?

UX Writing là phần nội dung bằng chữ xuất hiện trong trải nghiệm của người dùng (user journey) nhằm mục đích chỉ dẫn, giải thích, trình bày cho người dùng về sản phẩm. Ví dụ như phần nội dung của thông báo nhập sai mật khẩu hoặc thông báo hoàn tất giao dịch.

2. Phân biệt UX Writing và Copywriting

Copywriting thường đi với mục đích marketing như tăng doanh thu, tăng thị phần hoặc tăng độ nhận diện. Copywriting có thể là những câu xuất hiện trên biển quảng cáo hoặc một bài viết giới thiệu sản phẩm và có khả năng đứng độc lập với sản phẩm mà không mất đi ý nghĩa.

UX Writing xuất hiện trên các giao diện số với mục tiêu là tối ưu hóa trải nghiệm của người dùng với sản phẩm. Nếu Copywriting mang mục đích thu hút sự chú ý của người đọc trong thời gian ngắn nhất có thể thì UX Writing mang mục đích truyền tải thông điệp rõ ràng nhất có thể.

3. Làm thế nào để viết UX Writing hay

Tại hội thảo <Google I/O> năm 2017, UX writer Allison Rung của Google đề xuất một bảng quy tắc cho UX Writing gồm các yếu tố như tính rõ ràng (clarity), tính cô đọng (conciseness), tính khả dụng (usability).

3.1. Tính rõ ràng (Clarity)

Ảnh minh họa là màn hình thông báo lỗi khi người dùng nhập sai mật khẩu.

Màn hình bên trái chưa đạt được tính rõ ràng ở hai điểm: 1. Báo “Lỗi” chung chung khiến người dùng gặp khó khăn trong việc khắc phục vấn đề. 2. Cụm từ “xác thực” có thể gây khó hiểu cho người đọc không quen với các từ ngữ về công nghệ.

Màn hình bên phải là phiên bản đã được cải thiện về tính rõ ràng bằng cách trình bày loại lỗi và thay cụm “xác thực” thành hành động cụ thể đã dẫn tới lỗi này. Trình bày nội dung ở dạng hành động cụ thể là một phương pháp để đảm bảo tính rõ ràng.

3.2. Tính cô đọng (Conciseness)

Tuy nhiên thông báo lúc này vẫn còn gặp vấn đề về tính cô đọng.

Tính cô đọng ở đây không đơn thuần là ngắn mà phải hiệu quả trong việc truyền tải thông điệp. Mọi nội dung nên đóng vai trò cụ thể và riêng biệt.

Có thể thấy phần tiêu đề “Lỗi đăng nhập” thể hiện cùng một thông điệp với “Bạn đã nhập sai mật khẩu”. Bạn có thể loại bỏ phần “Lỗi đăng nhập” để thông báo trở nên cô đọng hơn.

3.3. Tính khả dụng (Usability)

Hiện tại thông báo thể hiện được cho người dùng hiểu rõ vấn đề, nhưng chưa cung cấp được thông tin nào về cách giải quyết – thông tin hữu ích hơn với người dùng.

Cải thiện tính khả dụng của thông báo này bằng cách thay đổi nội dung của nút “OK” để đưa ra thông tin hữu ích hơn về hành động mà người dùng có thể thực hiện.

Thông báo bên trái gồm hai hành động mà người dùng có thể thực hiện để giải quyết vấn đề nhập sai mật khẩu “Thử lại” và “Khôi phục mật khẩu”. Ngoài ra, thông báo này cũng đặt phân cấp thị giác (visual hierarchy) hành động đơn giản hơn là “Thử lại” cao hơn.

Đăng ký nhận tin tại https://www.careerly.vn/  để nhận được những nội dung tương tự trên bản tin Careerly về Product Management bằng tiếng Việt.

Ngoài ra, bạn có thể tham khảo thêm bài viết về UX Writing sau:
https://xd.adobe.com/ideas/process/information-architecture/four-cornerstones-writing-ux-microcopy/

Bài viết UX Writing là gì và làm thế nào để viết UX Writing tố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.

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.