User story Mapping là gì

Như đã chia sẻ trong bài viết User stories Công cụ lên kế hoạch của Agile, chúng ta đã đề cập đến User stories một trong những công cụ được các nhóm Agile sử dụng để lập kế hoạch làm việc và thể hiện các hạng mục cần thực hiện một cách hiệu quả. Tiếp tục với chuỗi những công cụ, kỹ thuật này, chúng ta sẽ cùng tìm hiểu công cụ thứ 2 không kém phần quan trọng đó chính là Story Points.

Theo tự nhiên thì chúng ta khó có thể đưa ra các ước lượng tuyệt đối một cách chính xác, nhưng sẽ dễ dàng và thoải mái hơn trong việc đưa ra các ước lượng bằng cách so sánh với một yếu tố khác (ước lượng tương đối). Các nhóm Agile cũng vậy, họ đề cao việc ước lượng tương đối. Họ thực hiện hầu hết các ước lượng của họ không phải theo giờ/ngày/tuần, mà bằng một đơn vị tương đối được gọi là Story points.

: story point là gì

Một lý do khác để sử dụng ước lượng tương đối đó là mỗi thành viên trong nhóm làm việc ở tốc độ khác nhau. Ví dụ một user story có ước lượng là 3 points (3 điểm) có thể được hoàn thành bởi một nhân viên có kinh nghiệm trong một buổi sáng nhưng một nhân viên mới có thể phải mất suốt một ngày mới hoàn thành. Nên story point chỉ tập trung vào ước lượng độ lớn, độ phức tạp của story.

Story points là gì?

Story points là một thuật ngữ được sử dụng trong quản lý và phát triển dự án để ước lượng độ lớn, độ khó, độ phức tạp cho công việc triển khai một user story nhất định, là một thước đo trừu tượng về nỗ lực cần thiết để thực hiện nó. Nói một cách dễ hiểu, story points là một con số, một đơn vị đo lường cho cả nhóm biết về độ khó của story, khó khăn có thể liên quan đến khối lượng công việc phải làm, mức độ phức tạp của công việc, rủi ro hoặc sự không chắc chắn của công việc để thực hiện đầy đủ một hạng mục trong Product Backlog (backlog item) hoặc bất kỳ phần công việc nào khác.

Ước lượng bằng story points, một loại ước lượng tương đối, thường được thực hiện tại cuộc thảo luận về Product Backlog.

User story Mapping là gì

Tại sao nên sử dụng story points?

Khi lập kế hoạch cho một dự án Agile, thường thì nhóm sẽ không thể dự đoán được các tính năng của sản phẩm/phần mềm sẽ thực hiện trong bao lâu hoặc ngày hoàn thành chính xác của chúng. Khi ước tính theo giờ/ngày/tuần, bạn phải đưa ra cam kết thời gian chính xác. Thay vào đó, khi sử dụng story point, nhóm chỉ định một giá trị điểm (point) cho mỗi story dựa trên độ lớn của nó. Đó là lý do tại sao hầu hết nhóm Scrum sử dụng story points để lập kế hoạch dự án của họ, cho phép họ so sánh các stories với nhau. Bằng cách tập trung vào độ phức tạp của các tính năng thay vì thời gian chính xác để phát triển chúng, nhóm tham gia lập kế hoạch cùng nhau và đưa ra dự đoán các tính năng gia tăng nào có thể được thêm vào phần mềm/sản phẩm sau mỗi vòng lặp.

(Xem thêm: Khoá đào tạo thực hành Quản lý dự án theo mô hình Agile)

Làm thế nào để ước lượng story point trong Agile?

Story points rất đơn giản: nhóm chỉ cần chọn một số điểm thể hiện độ lớn, độ khó, độ phức tạp, khối lượng công việc cần thiết cho mỗi story và gán số đó cho mỗi user story trong backlog. Thay vì cố gắng dự đoán chính xác sẽ mất bao lâu để xây dựng một tính năng, nhóm chỉ định một giá trị điểm cho mỗi story dựa trên độ phức tạp của nó, sau khi đem đi so sánh với các tính năng khác mà nhóm đã xây dựng trước đó. Ban đầu, các ước lượng sẽ thay đổi rất nhiều từ story này sang story khác, nhưng sau một thời gian nhóm đã quen với quy mô mà nhóm sử dụng để ước lượng thì sẽ dễ dàng hơn để tìm ra độ lớn của mỗi story.

Khi chúng ta ước lượng bằng story points, chúng ta sẽ chỉ định một giá trị điểm cho mỗi mục. Các giá trị thô mà các nhóm sử dụng là không quan trọng. Điều quan trọng là các giá trị đó phải có quan hệ tương đối với nhau. Ví dụ như story được gán điểm 2 nên lớn gấp đôi story được gán điểm 1. Nó cũng phải bằng 2/3 story được ước lượng là 3 story points. Thay vì chỉ định 1, 2 và 3, nhóm đó có thể chỉ định 100, 200 và 300. Hoặc 1 triệu, 2 triệu và 3 triệu. Điều quan trọng là tỷ lệ, không phải là con số thực sự về thời gian (giờ/ngày/tuần).

Trong Scrum, để thực hiện Sprint Planning hiệu quả hơn, Product Owner và Development Team sẽ đưa ra một ước lượng sơ bộ khi thực hiện Product Backlog Refinement, trước khi diễn ra Sprint Planning và kiểm tra xem:

Đã sẵn sàng để thực hiện Sprint Plan một cách hiệu quả chưa?

Có đủ thông tin để hoàn thành những vấn đề này không?

User story đã được phân chia hợp lý chưa?

Có rất nhiều cách để ước tính story points trong Agile và tùy theo từng nhóm sẽ thống nhất với nhau về cách tính. Trong hầu hết các trường hợp, story points sử dụng một trong số các thang đo sau để xác định kích thước:

Định cỡ theo T-shirt size (size áo):

  • Scrum teams có thể dựa vào ý tưởng chia theo T-shirt sizes để xác định độ lớn, độ phức tạp của một story và gắn giá trị điểm cho từng size. T-shirt sizes là một công cụ ước lượng ở high-level mức độ tổng quát, được sử dụng để thực hiện các ước lượng ban đầu về các tính năng sản phẩm và user story trong giai đoạn bắt đầu của một dự án, khi mà chưa có nhiều thông tin chi tiết.
  • Để phản ánh sự không chắc chắn liên quan đến những ước lượng đó, đơn vị ước lượng của chúng ta sẽ là T-shirt sizes, từ Cực nhỏ Extra Small (ES) đến Cực lớn Extra Large (XXL).
  • Chúng ta sẽ không cố gắng ước lượng kích thước tuyệt đối của từng danh mục hoặc thậm chí kích thước lớn hơn hay nhỏ hơn bao nhiêu so với các kích thước khác. Tất cả những gì chúng ta biết sẽ là Extra Small nhỏ hơn Small, nhỏ hơn Medium và tiếp tục như thế.
  • Ví dụ: nhóm có thể quyết định sử dụng 1 điểm cho tính năng rất nhỏ (extra small), 2 điểm cho tính năng nhỏ (small), 3 điểm cho tính năng trung bình (medium), 4 điểm cho tính năng lớn (large) và 5 điểm cho tính năng rất lớn (extra large).

Extra Small

Small

Medium

Large

Extra Large

1 điểm

2 điểm

3 điểm

4 điểm

5 điểm

  • Lũy thừa của 2: Ngoài ra cũng không ít các nhóm cũng sử dụng dãy số 1, 2, 4, 8, 16 được tạo ra bằng cách lũy thừa của 2 để ước lượng story point.
  • Chuỗi Fibonacci cho Story Point: Một khi nhóm quyết định lập kế hoạch theo thang điểm, nhóm cần thống nhất và quyết định sẽ áp dụng theo cách tính điểm nào. Một số nhóm sử dụng chuỗi Fibonacci hoặc một số biến thể của chuỗi này (1, 2, 3, 5, 8, 13, 21) cho story point vì họ nghĩ rằng chuỗi Fibonacci cung cấp cái nhìn thực tế hơn về độ lớn của một story, độ lớn của một story này so với một story khác. Miễn là nhóm của bạn sử dụng thang đo một cách nhất quán, thì đó không phải là vấn đề khi nhóm sử dụng.

User story Mapping là gì

Bất cứ điều gì chưa được thực hiện trong Sprint sẽ được chuyển từ Sprint này sang Sprint tiếp theo. Và tổng số story point được hoàn thành trong mỗi Sprint được theo dõi như Velocity (vận tốc chúng ta sẽ tìm hiểu cụ thể hơn về khái niệm này ở những bài tiếp theo) của dự án. Nếu một nhóm hoàn thành 15 story với tổng số 55 story points trong một Sprint, họ sẽ cho rằng 55 story points này như Sprint velocity và điều này cho nhóm một cái nhìn chung về tốc độ thực hiện công việc của cả nhóm, dự đoán về tổng số story points họ có thể làm trong Sprint tiếp theo.

: Phần Thô Tiếng Anh Là Gì ? Từ Vựng Thường Gặp Trong Xây Dựng (Việt

Theo thời gian, nhóm ngày càng tốt hơn trong việc gán story points và ngày càng nhất quán hơn về số story points họ hoàn thành trong mỗi Sprint. Bằng cách đó, nhóm sẽ cảm nhận được họ có thể làm được bao nhiêu trong Sprint và kiểm soát kế hoạch cùng nhau.

Quy trình ước lượng story points

  • Bước 1: Xác định Story cơ sở Base Story

Để tìm được base story, chúng ta cần tìm một user story cơ bản, ứng với tiêu chuẩn về định nghĩa hoàn thành rõ ràng DoD, và gán cho nó một story point. Base story được dùng làm cơ sở khi so sánh các story khác.

  • Bước 2: Tạo ma trận để ước lượng

Nhóm sẽ thực hiện ước lượng story points như đã trình bày ở trên (mục 3). Tiếp theo, nhóm sẽ tạo một ma trận với mỗi hàng cho mỗi story point (ví dụ ở dưới sử dụng dãy số Fibonacci) và stories liên quan của chúng. Sau đó, nhóm tập hợp tất cả stories và bắt đầu phân loại chúng thành các hàng, so sánh các story với nhau và với các story đã hoàn thành khác, hoặc so với base story. Lưu ý rằng base story đã có trong ma trận này, ở hàng đầu tiên với giá trị là một story point.

Story point

Story

1

Với tư cách là khách truy cập vào trang web, tôi muốn truy cập trang giới thiệu để biết thêm về các dịch vụ.

2

3

5

: R square là gì? Công thức tính và Ý nghĩa của r square

8

Để chỉ định story point cho mỗi story, nhóm có một cuộc họp, nơi tất cả các thành viên của development team sẽ sử dụng Planning Poker để đưa ra con số story point cho một story.

Planning Poker là một kỹ thuật ước lượng dựa trên sự đồng thuận, dùng để ước lượng cho Product Backlog. Nó có thể được sử dụng với nhiều đơn vị ước lượng khác nhau, nhưng ở đây chúng ta ví dụ Planning Poker với Story points.

Bước 3: Quy trình ước lượng Planning Poker

  • Mỗi thành viên nhận được một bộ thẻ bài.
  • Tất cả các thành viên chọn Backlog items để ước lượng, thảo luận các tính năng và đặt câu hỏi.
  • Khi một tính năng đã được thảo luận đầy đủ, mỗi người tự đưa ra con số ước lượng cho riêng mình đảm bảo bí mật, và chọn một thẻ bài để đại diện cho ước lượng của mình.
  • Khi tất cả đã có cho mình ước lượng của story, họ sẽ tiết lộ thẻ bài của họ cùng một lúc. Nếu tất cả các ước lượng đều khớp, cả nhóm sẽ chọn Backlog item khác và lặp lại quy trình tương tự. Khi các ước lượng khác nhau quá nhiều, tất cả sẽ thảo luận về vấn đề này để đi đến thống nhất.

Vào cuối Planning Poker, nhóm sẽ điền toàn bộ kết quả có được vào ma trận. Các user story của nhóm được chia thành các hàng theo story point tương ứng cần thiết để thực hiện chúng. Có thể có nhiều story trong một hàng.

Story point

Story

1

Với tư cách là người truy cập vào trang web, tôi muốn truy cập trang giới thiệu để biết thêm về các dịch vụ.

Với tư cách là người truy cập vào trang web, tôi muốn có thể đặt lại mật khẩu của mình trong trường hợp tôi quên mật khẩu.

2

Với tư cách là người dùng đã đăng nhập, tôi muốn có thể xem lịch sử thanh toán của mình trên trang cài đặt.

Với tư cách là người truy cập trang web, tôi muốn có thể gửi phản hồi hoặc báo cáo sự cố bằng cách sử dụng biểu mẫu liên hệ.

3

Với tư cách là người truy cập trang web, tôi muốn đăng nhập / đăng ký bằng email / mật khẩu của mình.

Với tư cách là người dùng đã đăng nhập, tôi muốn thêm nhận xét vào nội dung trên trang web.

5

Với tư cách là người truy cập vào trang web, tôi muốn sử dụng biểu mẫu tìm kiếm với các bộ lọc để tìm kiếm nội dung cụ thể.

Với tư cách là người truy cập vào trang web, tôi muốn xem thông tin chi tiết về nội dung.

: R square là gì? Công thức tính và Ý nghĩa của r square

8

Với tư cách là người dùng đã đăng nhập, tôi muốn có thể thêm nội dung trên tiêu đề trang web, mô tả, nội dung phương tiện (hình ảnh, video, âm thanh), vị trí địa lý.

Với tư cách là người dùng đã đăng nhập, tôi muốn có thể giao tiếp qua tin nhắn với những người dùng khác.

  • Bước 4: Sprint Planning

Tại thời điểm này, nhóm đã có ước lượng về độ lớn dựa theo story points, câu hỏi đặt ra là làm thế nào để nhóm có thể chuyển đổi những story points này thành ước lượng thời gian thực tế (giờ/ngày/tuần). Rất tiếc, nhóm không thể thực hiện việc này cho đến khi hoàn thành Sprint đầu tiên. Trong khi Sprint đầu tiên đang diễn ra, nhóm có thể theo dõi Velocity của nhóm. Ngay sau khi Sprint kết thúc, sẽ biết nhóm có thể hoàn thành bao nhiêu story points cho mỗi Sprint. Nhóm sử dụng những con số này để dự báo khả năng của mình cho những Sprint tiếp theo.

Khi ước lượng được tất cả các công việc trong backlog dựa vào story point, Scrum có thể hiểu nhóm sẽ cần bao nhiêu Sprint để hoàn thành dự án. Và cuối cùng, nhóm có thể chuyển đổi các đơn vị trừu tượng này thành các mốc thời gian thực.

Những lỗi thường mắc phải khi sử dụng Story Point

  • Chuyển đổi story point sang giờ: Bằng cách chuyển đổi story point sang giờ/ngày/tuần, nhóm sẽ bắt đầu làm việc và phải mạo hiểm đưa ra cam kết thời gian hoàn thành chính xác. Giả sử story point được ước lượng có phạm vi thời gian từ 10 20 giờ, nhưng khi ước lượng theo giờ, nhóm phải đưa ra một con số chính xác như 15 giờ, từ đó sẽ dẫn đến sự sai lệch, dẫn đến khó đạt được cam kết hơn khi bạn làm việc theo giờ chính xác.
  • Đưa ra story point trung bình: Trong Planning Poker, một nửa thành viên trong nhóm ước lượng một product backlog item là 3 story point và nửa còn lại ước tính 5 story point. Nhóm giải quyết bằng cách đặt 4 story point làm con số ước lượng. Nhóm không nên làm điều này vì nhóm đang thỏa hiệp với sự cung cấp sai về độ chính xác. Tốt nhất là nhóm nên có một cuộc thảo luận để hiểu rõ hơn thay vì lấy giá trị trung bình.
  • Điều chỉnh ước lượng Story Point của các user story trong Sprint: Khi nhóm bắt đầu giải quyết một vấn đề, nhóm không nên điều chỉnh ước lượng story point ngay cả khi ước lượng của họ không chính xác. Việc ước lượng đôi khi bị sai lệch là điều bình thường, nên nhóm không nên điều chỉnh mà hãy lưu lại thông tin này, để làm cơ sở cho việc xác định story point ở những lần sau chính xác hơn.
  • Ước lượng Story point cho những vấn đề chưa hoàn thành một lần nữa: Khi chuyển một product backlog item chưa hoàn thành sang Sprint tiếp theo, không cần thiết phải ước lượng lại. Ước lượng có thể không chính xác, nhưng đó không phải là vấn đề. Nhờ Sprint Planning, nhóm sẽ biết tất cả các nhiệm vụ (task) cần thiết để hoàn thành user story. Ước lượng của các nhiệm vụ này là theo giờ. Vì vậy, Sprint tiếp theo, nhóm sẽ biết cần bao nhiêu thời gian để hoàn thành product backlog item này.
  • Điều chỉnh ước lượng Story Point dựa vào người làm: User story có thể là 3 story point đối với thành viên nhiều kinh nghiệm, nhưng 8 story point đối với thành viên mới. Đây là cách làm không đúng. Chúng ta không nên điều chỉnh story point vì một người cụ thể sẽ thực hiện công việc. Vì story point chỉ dựa vào độ lớn, độ phức tạp, độ khó của user story.
  • Tuân theo ý kiến của các chuyên gia trong nhóm: Khi thực hiện Planning Poker, có rủi ro là nhóm sẽ tuân theo ý kiến của các chuyên gia mà không phải là sự kết hợp từ phía mỗi thành viên. Nhóm thường giải quyết công việc bằng cách để chuyên gia trình bày chi tiết về công việc. Sau đó, để phần còn lại của nhóm ước lượng mà không cần các chuyên gia. Chúng ta cần nhớ rằng ước lượng story point là sự nỗ lực của cả nhóm không phải của riêng bất kỳ thành viên nào.
  • Không thảo luận lại các vấn đề không chính xác về việc ước lượng story point trong Sprint Retrospective: Thỉnh thoảng, nhóm xác định được những vấn đề rõ ràng là ước lượng story points đã hoàn toàn sai lệch. Điều quan trọng là phải thảo luận về những vấn đề này và cố gắng học hỏi, cải thiện, để những ước lượng trong tương lai chính xác hơn.

Tổng kết

Khái niệm về story point đơn giản nhưng khó áp dụng. Hầu hết mọi nhóm Scrum đều sử dụng chúng, nhưng chúng không phải là một phần các công cụ cốt lõi của Scrum. Bởi vì điều này, mọi người có ý kiến ​​khác nhau về cách bạn nên sử dụng chúng. Ban đầu khi sử dụng story points có thể sẽ làm nhóm ước lượng sai lệch, nhưng sau thời gian hiểu và kiểm soát kế hoạch cùng nhau, nhất quán hơn về số điểm họ cung cấp trong mỗi Sprint giúp nhóm thuần thục hơn và làm cho công việc ước lượng trở nên nhẹ nhàng, dễ dàng hơn rất nhiều.

Kiến thức tổng hợp bởi Trainer Nguyễn Hải Hà (PMP®, PMI-ATP Instructor)

References: PMI-ACP Exam Prep, Head First Agile, Visual-Paradigm, Moutaingoatsoftware, Medium, 25giay.vnge

User story Mapping là gì

Product Backlog là gì? Có quan hệ như thế nào với WBS

Bản tuyên ngôn Agile lịch sử hình thành Agile

12 nguyên tắc của Agile

Trong dự án Agile, công việc ước tính có thật sự cần thiết?

Quản lý dự án với Scrum

Scrum of Scrums

User stories Công cụ lên kế hoạch của Agile

Story points Công cụ ước lượng của Agile

Velocity là gì Công cụ đo lường tốc độ hoàn thành công việc của nhóm Agile

Story Map Lập kế hoạch tổng quát trong Agile

Agile Retrospectives Nhìn lại và cải tiến hiệu quả công việc dự án

Kanban phương pháp giúp cải tiến quy trình làm việc của dự án

PDCA Chu trình cải tiến liên tục

Personas Công cụ xây dựng hình tượng khách hàng trong Agile

Lean Tinh gọn hóa quy trình một cách hiệu quả

Hướng Dẫn Scrum 2020 The Scrum Guide 2020

Bóng đá có 3-5-2, Scrum có 3-5-3

Bắt đầu với Scrum từ đâu đây ta?

Một số cách chạy Daily scrum hiệu quả

: Customer Acquisition là gì? Customer Acquisition có vai trò gì?

  • Chuyên gia nói

Giải đáp UX: User Empathy Mapping là gì? User Story được form như thế nào?

User story Mapping là gì
Facebook
Linkedin
Telegram

AMA (Ask Me Everything) là sự kiện Hỏi đáp diễn ra thường kì trên fanpage Topdev nhằm tạo cơ hội để các bạn lập trình viên tiếp cận được những kiến thức, kinh nghiệm thực tế từ các chuyên gia trong ngành thông qua những màn hỏi đáp trực tuyến nóng hổi. Bắt đầu từ đầu năm 2017, sự kiện AMA sẽ kéo dài nguyên tuần từ 8h sáng thứ 3 đến 24h thứ 6 hằng tuần để cộng đồng dev có nhiều thời gian trao đổi với các chuyên gia hơn.

Khách mời sẽ xông đất năm mới cho sẽ là anh Quang Phowr một Product Manager kỳ cựu đang làm việc tại Websosanh.

Trước tiên chúng ta hãy cùng tìm hiểu đôi nét về khách mời nhé:

  • Anh đã từng kinh qua các vị trí như Product Designer và PM tại VNP
  • Năm 2014 làm PM và Mobile Development Manager tại VNP Group
  • Tháng 7/2014 anh đảm nhiệm vị trí VP Business Development tại CubicWater
  • Tháng 9/2014 đến tháng 5/2015 anh làm Product Specialist tại VinEcom thuộc VinGroup
  • Anh đã có 1 năm nắm giữ vai trò Head of Product ở Haravan và hiện tại anh đang là Head of Product tại Websosanh.vn

Lĩnh vực chuyên môn mà anh trao đổi kì này vẫn là UX trong lĩnh vực thương mại điện tử.

Dưới đây là những thắc mắc đã được anh Quang Phowr giải đáp tuần rồi. Cùng xem qua để rút tỉa kinh nghiệm cho bản thân nha các dev!

Q: Chào anh Quang ạ, anh có thể chia sẻ cấu trúc và cách xây dựng User Empathy Maping, từ đó làm thế nào liệt kê đc triệt để các User Story ạ? Hiện tại team em đang có kế hoạch improve website của mình https://www.tripi.vn/ . Anh có thể cho bọn em 1 vài góp ý, trước hết là ở trang chủ đc ko ạ? Em cảm ơn anh ạ

A: User Empathy Mapping có 2 phần quan trọng nhất là Pain và Gain. Pain là những thứ người dùng đang gặp khó khăn, khó chịu. Gain là những thứ người dùng muốn đạt được.

User story được form dưới dạng cấu trúc, As a [user segment], I want to [do something] so that I can [achieve something]

Có 2 chú ý:
1, Làm user empathy map với từng user segment (nếu có nhiều hơn 1 user segment)
2, Achieve something trong user story có thể đến từ phần GAIN hoặc đã giải quyết được phần PAIN

Ví dụ: Là một người hay bay thường xuyên, tôi muốn tripi có chức năng săn vé tự động, để tôi bay được nhiều chuyến hơn (gain). Là một người bận bịu, tôi muốn tripi có chức năng săn vé tự động, để tôi không mất thời gian đi săn vé (pain)

User segmentation do cách team thống nhất với nhau để dễ phục vụ khách hàng hơn chứ ko có quy chuẩn chung

Q:Hello anh em học chuyên ngành thương mại điện tử về tech e cũng biết 1 ít và về kinh tế cũng biết 1 ít, em rất thích làm 1 product manager như a, a có thể chia sẻ 1 số bước cơ bản để trở thành 1 PM không ạ. Ecũng tò mò là hồi đó anh Quang học chuyên ngành gì ạ hehe.

A: Chào Nam, sry em vì comment bị trôi nên giờ anh mới trả lời.

Trước anh học CNTT ở Bách khoa Hà Nội. Anh cũng background là dev 1 thời gian. Nói chung, product manager phải biết khá nhiều thứ. Tùy vào tổ chức công ty mà vai trò lớn hay nhỏ.

Với PM trong mảng phát triển sản phẩm (product development manager) thì việc chính là đưa ra các giải pháp để phát triển sản phẩm. Lúc này là sự giao thoa giữa business, tech và user experience. Em cần có background của 3 cái này thì giải pháp đưa ra mới hiệu quả (bám sát business, khả thi với tech và ux tốt)

Với PM trong mảng quản lý sản phẩm nói chung (có một số nơi gọi là product owner hoặc product director) thì PM ngoài việc quản lý development còn có thêm 2 phần nữa là product strategy và product operation. Lúc này cần hiểu biết rất sâu về đối thủ, chiến lược thị trường, marketing, sale, vận hành doanh nghiệp để đưa ra các quyết định sản phẩm hợp lý. Thường PM dạng này là CEO công ty hoặc hoạt động như CEO của sản phẩm. Startup thì CEO kiêm PM luôn, vừa định hướng, vừa phát triển, vừa vận hành. Hoặc là các dự án độc lập trong 1 công ty to cũng tương tự như vậy.

Các bước cơ bản thì em nên tích lũy kinh nghiệm công việc, trải nghiệm sống, tự tạo mục tiêu cho bản thân trong việc học (học gì thì anh nói ở phía trên rồi). Tìm các môi trường thực hành và kiểm nghiệm kiến thức của mình như các công ty sản phẩm sẽ hiệu quả. Chúc em thành công

Q:Chào anh, em hiện cũng đang thích theo đuổi UX Designer. Tuy nhiên, em vẫn còn chút chưa rõ về công việc. Vậy anh có thể mô tả công việc cụ thể của chức danh UX Designer tại Websosanh được không ạ?

A:Chào Dương. Anh sẽ trả lời em ở phạm vi rộng hơn là chức danh UX Designer ở các công ty Việt Nam.

Hiện nay có nhiều công ty đặc biệt là các công ty lớn như VNG, Tiki, Viettel, Lazada có nhu cầu về vị trí này nhưng rất khó tuyển người và đãi ngộ các vị trí này tương đối cao so với mặt bằng thu nhập nói chung.

Hiện tại có 2 vị trí phổ biển em sẽ thấy thông qua các mẫu tuyển dụng:
UX/UI Designer
UX Designer hoặc các vị trí có công việc tương tự như product executive, product manager

Với UX/UI Designer (tuyển dụng nhiều) thì em sẽ phải lo cả về mặt đồ họa và giao diện khi thiết kế một ứng dụng di động hoặc một website
Với UX Designer (ở các công ty lớn) thì sẽ có những bạn lo phần đồ họa và giao diện nên em sẽ san sẻ được phần nào công việc.

Công việc chính của UX Designer nói chúng là tìm hiểu vấn đề của phía người dùng thông qua nhiều phương pháp khác nhau như hỏi người dùng, tự cảm thông người dùng, Từ đó đưa ra các giải pháp cải thiện và theo dõi hiệu quả của việc cải thiện

Q:Hiện nay, các công ty lớn đang dần chú trọng vào phát triển đội ngũ UX designer vì họ nhận ra UX là yếu tố cơ bản tạo nên sự thành công trong hoạt động kinh doanh thương mại điện tử. Anh có thể chia sẽ chi tiết hơn là vì sao UX lại là yếu tố cơ bản trong thành công của thương mại điện tử không ạ?

A:Chào Phong, anh nói rộng hơn TMDT mà ngành công nghệ nói chung

Khái niệm user phổ biến trong lĩnh vực phần mềm. Ngoài đời sống thì được gọi với cái tên customer. Trải nghiệm người dùng UX hay rộng hơn là trải nghiệm khách hàng CX (chú ý hai khái niệm này không phải lúc nào cũng tương đương, phụ thuộc vào góc nhìn). Khách hàng quan trọng với doanh nghiệp thế nào thì User quan trọng với phần mềm như vậy. Bên kinh doanh có câu Khách hàng là thượng đế chắc em còn nhớ.

Trước đây phần mềm được xây dựng để sử dụng trong doanh nghiệp, và để sử dụng được thì phải thông qua đào tạo sử dụng. Tuy nhiên xu hướng internet nên các phần mềm lên mây nhiều hơn. Vì lên mây nhiều nên có nhiều sự so sánh cạnh tranh cái này tiện hơn, cái kia tốt hơn v.v. Từ đó UX là một trong các yếu tố giúp phần mềm bán được (phần mềm ở đây em hiểu theo nghĩa rộng là 1 chương trình máy tính cho người sử dụng, tùy cách bán là thu tiền như các dịch vụ SaaS hay miễn phí rồi bán sản phẩm cho đối tượng khác như Facebook bán quảng cáo)

Sales/Marketing có vai trò thu hút khách hàng về, khách hàng kí hợp đồng. Tuy nhiên để giữ được khách hay không thì lại góp công lớn nhờ chất lượng của phần mềm. Phần mềm mà khó sử dụng, không đáp ứng được nhu cầu, nhàm chán thì việc bán lại lần thứ hai rất khó (vì hiện tại có nhiều lựa chọn rồi). UX có vai trò trong việc giữ khách hàng.

Ngoài ra UX cũng giúp khách hàng chi trả nhiều tiền hơn, có nhiều thiện cảm hơn đối với phần mềm, từ đó giúp doanh nghiệp tăng trưởng bền vững hơn (nhiều lợi nhuận tốt vì NPS tăng lên)

Q:Anh có thể chia sẻ một vài thủ thuật nhỏ nhằm giúp website trông thân thiện với người dùng hơn được không ạ?

A:Trước tiên bạn cần xác định nhóm người dùng của website mình là ai?

Bước 2, bạn giả định mình là họ và trả lời một số câu hỏi:
1, Website của mình đã đáp ứng được nhu cầu sử dụng của họ hay chưa?
2, Website của mình có quá khó hiểu với họ không?
3, Website của mình có bị lỗi ở đâu không?
4, Website của mình có hấp dẫn với họ (về nội dung lẫn giao diện)
5, Website của họ có mang lại nhiều giá trị cho họ hơn các website đối thủ không?

Từ những câu hỏi này bạn sẽ cải thiện. Khi ấy website của bạn sẽ ngày càng thân thiện với người sử dụng hơn

Q:Chào @Le Quang!

Theo giới thiệu, bạn hiện đang làm tại công ty so sánh giá lớn nhất hiên nay là http://websosanh.vn

Bạn có thể chia sẻ một số kinh nghiệm khi làm ở đó được không?
Việc thiết kế ui/ux của họ có thực sự hướng đến ngừoi dùng không?
Họ không bán hàng, thì trải nghiệm người dùng trên websosanh.vn dc họ đánh giá thế nào?

Cảm ơn bạn rất nhiều!

A:Chào anh Tú.

Hiện tại websosanh đang dễ dùng hơn trước. Thay đổi cần có thời gian nhưng đang đi đúng lộ trình.

Websosanh.vn không bán hàng nhưng mang lại giá trị là cung cấp nhiều lựa chọn hơn cho người dùng để linh hoạt lựa chọn mua sắm cho phù hợp.

Mình lấy ví dụ anh cần mua Iphone 7 anh phải vào nhiều nơi để khảo giá thì thay vào đó chỉ cần vào websosanh là đủ. Giả sử anh chỉ vào lazada để xem thôi thì anh bị phụ thuộc vào chính sách vận chuyển của lazada, có thể vài ngày anh mới nhận được hàng. Tuy nhiên với websosanh thì anh biết được địa điểm nào gần mình đang bán (có thể giá cao hơn 1 chút) nhưng lại đáp ứng được nhu cầu sử dụng gấp của anh. Đó là giá trị websosanh muốn đem lại.

Cách đánh giá trải nghiệm websosanh thì dựa trên các chỉ số định lượng về việc khách hàng có đáp ứng được nhu cầu mua sắm của mình (như ví dụ nói trên) hay không)

Q: Chào anh trước Tết em có tham gia sự kiện Demo Day của các bạn về việc reDesign UX của web 123phim.vn không biết thì hiện tại anh còn hỗ trợ các đội nhóm đó không anh nhỉ và anh có dự tính muốn mở rộng những mô hình như kiểu khóa huấn luyện UX Design vừa rồi không ạ.

A:Hiện tại mình vẫn đang dạy các khóa ngắn ngày. Bạn follow UX Design 101 để nắm các thông tin. Cảm ơn bạn

Q:Em chào anh Quang ạ. Đối với UX design nói chung và trong thương mại điện tử nói riêng, thì coder sẽ chịu trách nhiệm phát triển UX, cùng với sự hỗ trợ của, marketing, product và sale team. Thì anh có thể chia sẻ chi tiết hơn về những sự hỗ trợ của các team ấy sẽ diễn ra như thế nào vậy anh?

A:Chào Yukay,

Chúng ta sẽ đứng trên góc độ người sử dụng để trả lời câu hỏi này. Anh lấy ví dụ chúng ta vào Amazon.
1, Nếu em vào Amazon mà website không truy cập được thì em sẽ thấy thế nào? Có hài lòng hay không? Lỗi này là lỗi của ai?
2, Nếu em ấn vào nút add to cart mà giá trong cart lại khác với giá hiển thị thì em có hài lòng không? Có thấy amazon mập mờ không? Lần sau còn tin tưởng mua hàng tại amazon không?
3, Nếu em tìm sản phẩm em định mua là iphone 7 nhưng toàn ra các kết quả ốp lưng cho iphone 7 thì em có thấy bực mình không? Có tin tưởng vào chức năng search của Amazon không?
4, Nếu em vào Amazon mà amazon biết ngay thị hiếu mua sắm của em ra sao. Em tìm chung chung từ khóa điện thoại nhưng Amazon lại đưa ra các kết quả hoàn toàn trùng khớp với thị hiếu của em là điện thoại cho nữ, selfie lung linh (anh ví dụ vậy) thì em có dễ dàng lựa chọn hơn không?

4 ví dụ trên để em thấy vai trò của coder đối với UX, không chỉ xoay quanh việc đáp ứng chức năng hoạt động đúng mà còn giúp gia tăng hiệu quả bán hàng. UX là khái niệm trải rộng, mỗi người đều có thể tham gia nhằm phục vụ khách hàng tốt hơn

Một lần, Topdev rất cảm ơn anh Le Quang Phowr với lần xuất hiện thứ 2 trên AMA. Những chia sẻ nhiệt tình, thực tế của anh chắc chắn đã giải tỏa được rất nhiều khúc mắc về UX của các bạn.

Xem thêm: Các công việc ux và việc làm it hấp dẫn tại Topdev.vn

  • TAGS
  • ama
  • event
  • topdev
Facebook
Linkedin
Telegram
User story Mapping là gì
TopDev Blog
https://topdev.vn
Thích chia sẻ về Development, Growthacking, Automation Marketing, bóng rổ...