Loading...
Tìm kiếm

Tag Archives: Case Study

Categories Business Analyst

15 điểm UI/UX cho mảng banking hay và cần lưu ý – phần 1

by hoangphan Posted on

Giới thiệu profile

Mình có khoảng gần 2 năm làm việc tại VNPay với vị trí Business Analyst (chuyên viên phân tích nghiệp vụ), với khoảng thời gian này mình được tham gia nhiều dự án từ Mobile Banking/Internet Banking, Mảng thẻ ngân hàng/thẻ thanh toán, Thanh toán vé máy bay, Đặt và thanh toán vé xe, vé tàu, topup, billing, payment gate,… Nhưng phần lớn thời gian thì mình tập trung vào các dự án với các Bank – đa số là các Bank nằm trụ sở trong miền Nam, với kinh nghiệm của bản thân – mình rút ra được 15 điểm UI/UX cần lưu ý cũng như mình thấy hay và chia sẻ lại cho mọi người. Mọi người đọc qua nếu thấy điểm nào chưa hợp lý thì góp ý giúp mình nhé.

1. Ứng dụng chơi được nhiều thể loại font-size

Ý tưởng của bài viết này cũng từ ý đầu tiền này, khi cháu mình đang học đại học dùng điện thoại với font-size rất to, mình mới hớ ra là khi mình làm việc cũng gặp một vài khách hàng báo lỗi ứng dụng khi họ sài font-size to, đặc biệt là một số KH lớn tuổi – mắt kém.

Do chỗ lỗi khi xưa đã được fix, nên mình dùng tạm hình trên mạng để bạn hình dung normal size và big size

Do chỗ lỗi khi xưa đã được fix, nên mình dùng tạm hình trên mạng để bạn hình dung normal size và big size

Khi KH đó thực hiện tải ứng dụng có giao diện mới trên 1 Bank mình làm hồi đó, tại các màn hình giới thiệu giao diện mới này, thì khi ở kích thước font-size bình thường hoặc nhỏ thì ứng dụng vẫn hoạt động bình thường, KH có thể nhấn nút tiếp tục hoặc skip để bỏ qua. Nhưng nếu KH cài đặt font-size lớn (trên thiết bị), thì nút Skip và nút tiếp tục bị ẩn đi, và không thể nào scroll để đi tiếp màn hình tiếp theo.

Dĩ nhiên cách khắc phục tạm thời cho KH sử dụng là chỉnh font-size của thiết bị nhỏ lại theo kích thước bình thường, rồi xem xong phần giới thiệu giao diện mới, rồi vào app sài bình thường, và chỉnh lại kích thước font-size lại như KH vẫn sài. Sau đó thì phía tester/UI/UX đánh giá lại để khắc phục lỗi này bằng cách cho scroll để xem hết nội dung, còn nút skip và tiếp tục có thể để fixed ở phần bottom của màn hình để KH có thể nhấn được.

Nhưng đó cũng là một điểm mà các bạn BA/Tester/UI/UX nên chú ý để ứng dụng làm ra được ok hơn, tránh một số lỗi tương tự, làm mất thời gian build lại app, nâng version app, rồi KH lại tốn thời gian ra quầy hỗ trợ, gọi đủ bên để hỗ trợ việc này.

2. Đồng nhất UI và UX giữa mobile app và internet banking

Ở đây mình sẽ phân ra 2 loại:

  • Đồng bộ giao diện giữa Mobile Banking với Internet Banking (sau này 2 cái này các bank chuyển đổi theo hướng Omni Channel nên có nhiều bank đã đồng bộ cả về dữ liệu, hệ thống và giao diện)
  • Đồng bộ giao diện giữa 2 app mobile trên Android và iOS (và ứng dụng tên OS Mobile khác)

Hiện nay thì các Bank cũng có xu hướng chuyển sang xây dựng Omni (đồng nhất đa kênh) cho kênh MB và IB xưa kia, đồng nhất 2 kênh này lại cùng về 1 hệ thống, chỉ khác là mặt giao diện giao tiếp với KH phía trên, nên việc giao diện trên nền tảng mobile app và web đã được nhiều Bank phân tích thiết kế sao cho tương đối đồng nhất về UI, và nếu được thì cả phần UX.

Giao diện Mobile App và phiên bản trên Web của VCBDigibank KH cá nhân cũng tương đối đồng nhất.

Trước đây khi mình sài MB và IB riêng của 1 số Bank, mình tốn công phải nhớ 2 tài khoản khác nhau, với những mã user đăng nhập là mã Cif hoặc 1 mã gì đó do Bank đưa ra. Nay thì đã đỡ hơn nhiều khi các Bank chuyển sang Omni (hoặc xây dựng gần gần kiểu Omni) và chuyển đăng nhập bằng SĐT hoặc một kiểu user do người dùng có thể cài đặt.

Mô tả của ứng dụng BIDV phần Đồng nhất đa kênh trên CH Play do mình chụp lại

Về phần đồng nhất giữa các App trên Android và iOS thì cũng cần được chú trọng, đặc biệt là các luồng xử lý về mặt giao diện.

Mình cũng từng gặp vài trường hợp KH sài trên Android quen rồi, nhưng khi qua trên iOS thì luồng của ứng dụng lại có thay đổi, làm cho KH khi sử dụng chưa quen thì cảm thấy không thoải mái hoặc thậm chí làm sai luồng thao tác. Trường hợp này thì thường xảy ra khi 2 đội Dev iOS và Android là khác nhau (dev native app), mà việc kiểm tra lại luồng không được thực hiện kỹ. Với tính của mình thì mình cũng rất hay soi kỹ việc này nên né tránh được kha khá phàn nàn từ người dùng. Còn với trường hợp dev cross platform thì giao diện là giống nhau rồi, chỉ có vài điểm OS 2 bên không hỗ trợ thì có thể code để thay đổi tí tẹo.

Dĩ nhiên trường hợp Native App cũng vậy, cũng cần xem xét OS 2 bên có hỗ trợ để làm giống nhau không? Hay xem xét việc làm giống nhau mà tốn quá nhiều effort mà không quá ảnh hưởng gì đến việc người dùng sử dụng về UX thì cũng có thể bỏ qua.

3. Ưu tiên tùy chỉnh cá nhân hóa

Theo mình tìm hiểu thì đây là một xu hướng thiết kế mobile trong những năm nay khi ưu tiên việc cá nhân hóa người dùng lên hàng đầu, từ đó người dùng có thể tùy chỉnh vị trí các tính năng ngay trên ứng dụng.

Đặc biệt khi hiện nay trên một app tài chính/ngân hàng có quá nhiều tính năng, và khi KH chỉ sài có vài tính năng thường dùng, việc tùy chỉnh đưa lên đầu app là vô cùng quan trọng, làm cho việc trải nghiệm KH trên ứng dụng hoàn toàn đỉnh hơn rất nhiều.

Momo và VCB cũng hỗ trợ việc tùy chỉnh các chức năng thường dùng lên đầu.

Hoặc việc KH thay đổi màu giao diện App theo sở thích cá nhân, background bên trong ứng dụng cũng khiến KH thoải mái hơn khi sử dụng ứng dụng.

4. Giao diện theo thời điểm trong ngày/mùa

App của ABBANK thay đổi màu theo buổi sáng và buổi chiều/tối, App của BIDV hình như đổi nền trước đăng nhập theo buổi sáng, buổi trưa, buổi tối, rồi thay đổi câu chào theo từng buổi khác nhau.

Ý này mình đang nghiên cứu =)) ít hôm nữa tìm ra rồi thì mình viết bổ sung. Xưa làm thì có hỏi mấy bạn bên Bank vụ này vì sao có thì nhớ có trả lời mà mình giờ quên rồi. …

Hoặc bạn nào biết thì giúp mình trả lời ở phần comment nha.

5. Lưu ý cài đặt mặc định cho các nút toggle switch

Này mình cũng rất lưu tâm khi làm tài liệu nghiệp vụ, khi các nút tongle thể hiện việc YES hay NO cho việc bật một tính năng nào đó lên, nhưng đặt mặc định là gì cho phù hợp?

Việc này thì BA cần lưu ý, đặc biệt là các vấn đề liên quan đến bảo mật cần chú trọng.

Ví dụ trường hợp nút cho phép đăng nhập trên trên Web để thực hiện giao dịch thường bị hạn chế, thì cài đặt không cho phép đăng nhập trên web là mặc định, để mở chức năng đăng nhập thì cần thực hiện mở trên điện thoại, tránh kẻ gian nắm thông tin và thực hiện giao dịch trên ứng dụng web ngoài sự cho phép của chủ sở hữu tài khoản.

Nút toggle switch

6. Hiển thị phôi thẻ lên trên ứng dụng

Hiện nay việc sử dụng thẻ ghi nợ/tín dụng/trả trước không còn quá xa lạ với người dùng, và việc có nhiều thẻ thì cũng tương tự, nên việc hiển thị phôi thẻ trên ứng dụng điện thoại trong mục thẻ cũng giúp cho người dùng dễ phân biệt giữa các thẻ với nhau một cách nhanh chóng. Ngoài ra việc thanh toán thẻ trực tuyến bằng cách 1 chạm sẽ ngày càng phổ biến, nên hiện tại việc hiển thị phôi thẻ y như thật lên trên điện thoại là điều nên làm.

Lưu ý là phôi thẻ thì nên có một phôi mặc định, tránh trường hợp không lấy được thông tin của thẻ hoặc hình ảnh phôi thẻ thì cũng có một phôi mặc định hiển thị.

7. Thông tin thẻ/tài khoản nên được ẩn tránh lộ thông tin

Như ở mục số 6 mình có nêu ra, hiện nhiều Bank đã đưa hình phôi thẻ lên trên ứng dụng, nhưng nếu không cẩn thận thì thông tin của thẻ sẽ dễ bị lộ nếu không chú ý, đặc biệt là thông tin thẻ trên đường truyền đi từ Core/Trung tâm thẻ ra, nên được bảo mật và giải mã phía đầu client để hiển thị.

Hiển thị phôi thẻ trên ứng dụng ABBANK, và thông tin mặc định bị ẩn đi

Như nút hiển thông tin thẻ ở hình phía trên khi nhấn vào sẽ không có dữ liệu hiển thị ngay, mà phải gọi về trung tâm thẻ để lấy dữ liệu lên, và dữ liệu thẻ đã được mã hóa, đến Client được giải mã theo 1 key client nắm giữ.

Và cả việc chụp màn hình ở màn hình này cũng nên bị chặn, đặc biệt với thẻ credit thanh toán trực tuyến thông qua số thẻ, exp date, cvv.

8. Số dư tại màn hình thanh toán/chuyển khoản thành công

Việc bạn thực hiện xong một thanh toán, hay chuyển khoản và chụp màn hình lại gửi cho bạn bè/người cần nhận là bình thường đúng không?

Nhưng có bạn nào muốn họ thấy số dư tài khoản của bạn không nhỉ?

Ban đầu cách đây vài năm thì mình hay thấy chuyển khoản, hay thanh toán thì số dư hiện tại (của tài khoản) có thông tin hiển thị ra, rất bất tiện khi người nhận không nên biết về số dư đó, nên như mình xưa là phải cắt cái màn hình đó ra, chỉ để lại phần thông tin giao dịch gửi cho bạn/bè.

Giờ đây thì đa số các ngân hàng đã hiểu ra chuyện đó và bỏ đi dòng số dư hiện tại đi, kèm theo đó để thêm tính năng chia sẻ để gửi màn hình kết quả cho bạn bè nhanh hơn qua social.

Chuyển khoản hùi xưa, màn hình kết quả hiển thị số dư hiện tại
Chuyển khoản bây giờ – đã bỏ đi dòng số dư tại khoản, thêm nút chia sẻ tại màn hình kết quả thành công

Do bài viết cũng khá dài rồi, nên mình cắt ra làm 2 phần, phần 2 bạn đọc tại đây nhé: https://hoangphan.blog/15-diem-ui-ux-cho-mang-banking-hay-va-can-luu-y-phan-2/

Hi vọng bài viết này sẽ giúp bạn có thêm một số case study thực tế mình đã được thực hiện qua.

Categories Business Analyst Chia sẻ

Case study – Mua sim tại Viettel không dễ như bạn tưởng – BA

by hoangphan Posted on

Mấy hôm nay mình dự kiến mua 1 em SIM mới ở Viettel để dùng liên lạc với những người cực kỳ quan trọng như cha mẹ, anh chị em, con cháu, người yêu, bạn bè cực kỳ thân.

Lý do mua SIM mới

Và chuyển SIM hiện tại đang dùng sang 1 em điện thoại khác vì trước đó mình dùng số đó với nhiều mục đích từ cho người lạ số, đăng ký các tài khoản trên mạng, đăng ký tham gia nhiều chương trình, nên giờ nhiều anh cứ gọi mình kiểu: “Alo, bên mình đang có lô đất,…”, “Anh ơi, bên em đang có chương trình thẻ tín dụng,…”, “Em bên sàn chứng khoán, …”, “Bên công ty anh đang cần tuyển vị trí Dev iOS,…”. Do đó cũng hay khiến mình sao nhãn trong lúc làm việc hay tập trung làm 1 thứ gì đó. Nếu ai đó có tìm hiểu về trạng thái FLOW trong lúc làm việc thì sẽ hiểu, chỉ cần 1 cuộc gọi tới, thì bạn sẽ bị thoát ngay ra khỏi FLOW và phải tốn rất nhiều thời gian để quay lại, giờ mình làm việc thì cứ để điện thoại xa bản thân ra, nhưng nhiều lúc cũng cần sài tới nó cho 1 số việc. Nên mình mới quyết định mua 1 em SIM mới dành riêng cho những người cực kì quan trọng.

Ý tưởng này cũng nhờ nghe được bài PODCAST từ anh Hieu.tv

Anh ấy sài 5 chiếc điện thoại/5 SIM với các mục đích khác nhau, đối với bản thân mình thì mình nghĩ bản thân cần dùng 2 SIM/2 Điện thoại là đủ.

Mua SIM mới trực tuyến

Với ý tưởng đó, và cũng từng thấy Viettel bán SIM trên app My Viettel, nên mình đã dành vài tiếng để tìm 1 em sim số cũng gọi là tạm đẹp, và đặt – mua – thanh toán trực tuyến. Hẹn khung giờ 10h30 – 11h sáng để nhận SIM tại cửa hàng gần nhà.

Đơn hàng mình đặt

 

Nhận SIM – Vấn đề xảy ra tại đây

Đúng giờ mình chạy ra cửa hàng để nhận, thì cái đơn hàng của mình gặp 1 vấn đề là gói mình đặt mua “TRENDY” không còn phù hợp với độ tuổi của mình, vì mình đã 27 tuổi, còn gói cước chỉ dành cho 14-22 tuổi. Và bạn biết vì sao mình chọn gói TRENDY rồi đó, nhìn chi tiết gói cước – vì là gói dành cho KH trẻ (hay nói cách khác là lứa tuổi học sinh, sinh viên) nên giá cước sử dụng rẻ hơn các gói khác. Và trên ứng dụng cho phép mình chọn gói cước này để đăng ký mua SIM.

Các gói cước sẽ chọn khi mua

 

Chi tiết gói cước TRENDY – gói cước rẻ nhất

Chuyện sẽ không có gì nếu anh giao dịch viên tạo được thông tin SIM cho mình, và mình lấy SIM đi về với gói cước “TRENDY” hoặc không sử dụng được gói cước này, GDV có thể chuyển đổi gói cước sang gói “TOM690_12” phù hợp hơn, và tạo SIM thành công.

Nhưng phía GDV không được phép chuyển đổi thông tin giao dịch sang gói khác vì mình đã mua và thanh toán trực tuyến. Cũng dễ hiểu vì mình đã thanh toán rồi, nếu GDV thay đổi thì có thể xảy ra tình huống phải đóng tiền thêm, và xảy ra 1 số trường hợp gây khó khăn trong việc sai số liệu sau này.

Phía GDV không thể cập nhật, cũng như thay đổi gói, nên mình cũng đề xuất hủy đơn hàng và mình có thể thực hiện lại để mua SIM. Nhưng GDV cũng không thể hủy, và mình cũng GDV gọi thử lên tổng đài để hỗ trợ, gọi tổng đài A thì báo thử gọi qua tổng đài B để hỗ trợ, … và cả tổng đài A và B đều không hỗ trợ được vì đơn hàng mình đặt online và đã thanh toán, biện pháp duy nhất ở đây là đợi hết 48h để đơn hàng tự hủy – và đơn hàng sẽ không hoàn tiền tự động lại cho mình, do đó mình đã hỏi cách làm sao để được hoàn tiền từ tổng đài, họ có hướng dẫn cho anh GDV cách liên hệ vào 1 bên nào đó bên phòng kinh doanh và đợi 2 ngày để đơn tự hủy, sau đó anh GDV sẽ liên hệ mình để hỗ trợ việc hoàn tiền – thời điểm hiện tại mình cũng chưa biết có thực hiện việc hoàn tiền như này được không, nhưng không sao, anh GDV cũng đã cố gắng hỗ trợ mình rồi.

Việc tìm cách giải quyết làm mình tốn mất 1 tiếng 30 phút ngồi chờ đợi, cũng như gọi đến tổng đài, nên mình cũng chán chán, nhưng vì hiểu nên có thông cảm và kiên trì chờ đợi các anh tổng đài tìm hiểu cách giải quyết, và kết quả cuối cùng thì không bên nào có thể hủy đơn hàng hay thay đổi gói cước cho mình được.

Gợi ý giải pháp

Với mình là 1 người phân tích hệ thống, cũng như tự xây dựng cho các dự án cá nhân luồng process, cách thức hoạt động và cũng không ít lần gặp 1 vài trường hợp bất tiện tương tự, nên mình dễ cảm thông và chấp nhận chờ 48 tiếng để đơn hàng tự hủy.

Nhưng biết đâu đó ngoài kia, sẽ có những khách hàng khó tính – họ cảm thấy quá tốn thời gian cho việc mua SIM như này và họ có những trải nghiệm không tốt với dịch vụ.

Do đó dựa theo case-study này, bản thân mình cũng tự đưa ra một vài giải pháp vui – nhưng vì mình không biết phía sâu bên trong có những ẩn khuất ví dụ như các luồng kinh doanh sẽ bắt buộc xử lý luồng như vậy để đảm bảo việc quản lý tốt hơn, nên những giải pháp dưới đây với góc độ cá nhân mà chưa thông qua quy trình kinh doanh từ bên Viettel.

Phương án 1:

Ngăn chặn các trường hợp không thể xảy ra ngay từ đầu – Gói TRENDY chỉ dành cho lứa tuổi 14-22 tuổi, và ứng dụng đã nắm thông tin của KH có ngày tháng năm sinh, từ đó có thể tính toán được độ tuổi của KH, so sánh với điều kiện của các gói cước, từ đó chỉ hiển thị các gói phù hợp lên trên giao diện cho KH chọn, backend – logic xử lý phía dưới để trả kết quả về cho ứng dụng hiển thị không có gói TRENDY.

Đối với các gói khác thì có thể sử dụng những thông tin khác phù hợp để xử lý logic ngay dưới back-end.

Phương án 2:

Cho phép GDV thay đổi gói cước tại giao diện Client – dĩ nhiên sẽ có các gói cước với giá khác nhau.

Với các trường hợp khác nhau ta có thể xử lý:

  • Bằng tiền thì cho phép thay đổi – không phát sinh thêm giao dịch phụ, chỉ cập nhật thông tin giao dịch trước đó
  • Không bằng tiền có thể sinh ra 1 giao dịch bổ sung – có khóa ngoại gắn với giao dịch gốc (là giao dịch mình mua SIM), và việc thanh toán bổ sung/hoàn trả lại tiền cho KH ngay tại quầy giao dịch.
  • Hoặc xử lý trường hợp bằng tiền như giao dịch không bằng tiền, sinh ra giao dịch phụ với hóa đơn 0đ.

Và database đã ghi nhận thông tin giao dịch phụ, nên cũng dễ dàng hơn cho việc báo cáo giao dịch sau này.

Phương án này mình cũng đã từng áp dụng vào hệ thống book vé xe – mặc dù không có trường hợp nào gây lỗi nếu khách hàng thực hiện một luồng thông thường để mua vé, và hệ thống hoạt động trơn tru – nhưng biết đâu hệ thống xảy ra timeout, hoặc do việc cập nhật các phiên bản, thay đổi code mà dẫn đến API truyền sai tham số, từ đó dẫn đến việc dữ liệu không đồng bộ, hay xảy ra trường hợp hi hữu, từ đó với quyền của một admin/hoặc phân quyền phù hợp có thể tác động và cập nhật thông tin/trạng thái của đơn hàng sao cho phù hợp. Và dĩ nhiên các trường hợp cập nhật này hệ thống phải ghi lại log hoặc ghi vào db để đối soát nếu cần sau này.

Phương án 3:

Cho phép giao dịch viên hủy đơn hàng, và hệ thống thực hiện lệnh hoàn tiền trực tuyến. Với lệnh hoàn tiền sẽ sinh ra 1 giao dịch đảo ngược – gắn khóa ngoại là mã của giao dịch gốc (giao dịch mua SIM) – với những việc hủy đơn hàng như này, sẽ có đầy đủ thông báo để GDV nhấn xác nhận để thực hiện lệnh, tránh trường hợp nhấn nhầm.

Phương án 4:

Như các phương án 2 và 3, nhưng độ phân quyền được phép thay đổi giao dịch sẽ không được thực hiện tại GDV mà sẽ ở 1 cập độ nào đó lớn hơn để xử lý 1 vài trường hợp đặc biệt như xảy ra với mình, từ đó xử lý các tình huống dễ dàng hơn.

Phương án 5:

Phương án này mình thấy không nên áp dụng – nhưng cũng là 1 đề xuất thì mình cứ đề xuất thôi.

KH được thực hiện lệnh hủy đơn hàng khi chưa nhận SIM, cũng như đơn hàng nằm trong 1 trạng thái được phép hủy đơn hàng – giống như mua tiki hay shopee – shop chưa ghi nhận đơn hàng hoặc chưa gói hàng.

Lý do không nên áp dụng vì KH sẽ dễ dàng đặt đơn hàng và hủy đơn hàng thường xuyên, làm cho số lượng giao dịch tăng lên, nhiều người biết thì sẽ tấn công hệ thống để phá hoại, hay là các khái niệm như đặt thử,… rồi bùng.

Và các phương án trên có thể kết hợp lại để có thể xử lý để luồng business hoạt động một cách tuyệt vời hơn.

Kết luận

Với trường hợp mua SIM của mình, và cái tính thích suy luận kiểu IT BA – mình tự đưa ra 1 case-study thực tế để phân tích và viết blog, từ đó giúp bạn đọc dễ hình dung hơn việc đưa ra giải pháp phần mềm khi gặp các trường hợp tương tự.

 

Cập nhật tình hình là cái đơn hàng mình chưa được hoàn tiền (đang liên hệ để được hỗ trợ) + số điện thoại mình mất công tìm số đẹp mấy tiếng đồng hồ đã bị 1 người khác đặt mua :(( Toang

Categories Business Analyst

Cách mình đã thực hiện UAT khi làm Business Analyst

by hoangphan Posted on

Bài blog này mình muốn chia sẻ rằng mình đã thực hiện UAT như thế nào ở công ty mình đã làm việc.

1. Giới thiệu

Ý tưởng bài viết này cũng xuất phát từ câu nói “UAT không phải là kêu BA tới rồi test trong vòng 2h là xong.” trong bài: UAT (User Acceptance Testing). Và vì mình cũng từng UAT với chỉ 2h là xong, do đó ngồi nhìn nhận lại những gì mình đã làm với UAT.

Qua bài của mình các bạn có thể biết được mình đã làm UAT ra sao, những cái gì mình đã làm được, những cái gì mình chưa làm được. Và các bạn có thể tự áp dụng vô chính bản thân và cho mình đôi lời nhận xét xem mình đã làm UAT đúng chưa nhé.

2. Khái niệm

Theo như nhiều tài liệu mình đọc được thì UAT (User Acceptance Testing – Kiểm thử chấp nhận) là một loại kiểm thử được thực hiện để xác nhận rằng cái sản phẩm/tính năng mình làm ra có đáp ứng nhu cầu của người dùng hay không? Và nó được thực hiện trước khi sản phẩm được release.

3. Sai lầm của bản thân

Mình từng thực hiện UAT theo 1 khái niệm mà mình tự thấy là chính mình đã từng hiểu chưa tường tận. Đó là mình làm 1 cái checklist những tính năng cần phải đáp ứng từ những requirement và check nó trong vòng vài tiếng. Và nhận ra rằng mình đã thiếu sót trong việc thực hiện UAT.

Sau vài lần làm như thế thì đọc được nhiều tài liệu hơn về UAT, cũng như được hướng dẫn thì mình áp dụng 1 số phương pháp khác, mà tự đó nhận ra được bầu trời của UAT.

4. Những điều mình đã làm với UAT

4.1 Khảo sát, phân tích và thảo luận về tính năng sẽ làm thật kỹ

Trước khi làm tính năng/dự án, mình, team lead/PM hay thường đặt ra vấn đề là tính năng này sẽ làm như thế nào, có cần thiết cho end-user hay không?

Nếu câu trả là không? Thì hỏi lại khách hàng, cũng như trao đổi về sự cần thiết của tính năng với khách hàng để tránh lãng phí thời gian cũng như cost dự án.

Vậy đây mình nghĩ nó đã là bước đầu tiên của UAT rồi. Xác định nhu cầu của end-user về tính năng/dự án thật kỹ.

4.2 Verify theo checklist

Tự mình kiểm tra xem là sản phẩm làm ra đúng tính năng như khách hàng mong muốn từ ban đầu hay không, vì mình làm việc trực tiếp với khách hàng, lấy yêu cầu từ họ và từ đó phân tích đưa ra cái họ mong muốn, và với sự confirm the last requirement của khách hàng=> Mình cũng hiểu về sản phẩm và tự test lại sản phẩm theo checklist và coi đạt yêu cầu theo requirement để đưa cho khách hàng chưa? Này theo mình được biết nó gọi là: Contract Acceptance Testing

Mình sẽ chỉ đi những flow đảm bảo luồng chính (primary testcase) mà mang lại benefit cho End-user vì mình khá tin tưởng team QC của mình làm khá tốt với những case theo tech hay doc, vì mình luôn review test case của QC dự án (dự án gần nhất mình làm) sau khi họ hoàn thành bộ test case.

4.3 Nhờ nhân viên trong công ty support test

Gửi cho những member trong công ty để support test kiểu dùng như 1 end user và nhận feedback từ họ. Mình thấy 1 thiếu sót đó là không thể quan sát hết được họ đã sử dụng phần mềm như thế nào, có gặp trouble gì khi dùng sản phẩm/tính năng không? Nhưng mình tự nhận thực hiện UAT như thế nào cũng xem là chấp nhận được vì cũng lấy được feedback từ họ.

Vì mình biết có một số sản phẩm, tính năng trước khi được ra mắt thị trường thì họ sẽ mời end-user thật để tới văn phòng và cùng dùng sản phẩm. Kiểu như trong game Liên Minh Huyền Thoại, khi ra 1 tướng mới hoặc có chỉnh sửa, sẽ mời các game thủ tới chơi thử để đánh giá nhân vật trong game, quay video quan sát hành động của họ, từ đó phân tích ra là nhân vật đã ok chưa.

4.4 Gửi khách hàng verify bước cuối

Gửi cho khách hàng, và PM của mình share cho họ về tính năng được làm ra, nhưng không quá chi tiết. Sau đó họ sẽ dùng, và lấy feedback từ họ, xem có bug gì ở đó hay không? Vấn đề gì về tính năng, cũng như vấn đề UI/UX, nội dung của sản phẩm không? Từ đó team mình chỉnh sửa cho phù hợp.

4.5 Gửi bạn bè dùng thử

Thỉnh thoảng nếu project kiểu release rồi, nhưng mình vẫn muốn check lại để kiểm tra lại thực sự sản phẩm có tốt hay không? thì mình gửi cho bạn bè mình xem và đánh giá. Một điều đáng buồn là project hùi trước mình làm, luôn nhận kiểu than phiền là website truy cập load còn chậm. :(((( buồn quá buồn. Nhưng không sao, team vẫn đang cố gắng khắc phục vụ web chậm, phải làm từng bước để cho sản phầm ổn định dần chứ, bùm 1 cái đâu thể nói phát là web nhanh liền được đâu.

Cách này mặc dù sản phẩm/tính năng đã golive rồi, nhưng mình vẫn nghĩ nó là 1 phần nhỏ trong UAT

4.6 Thực hiện A/B testing

Ngoài ra để đánh giá về việc sản phẩm/tính năng làm ra có thu hút của người dùng hay không thì mình có áp dụng A/B testing vào. Và đặt tracking lên web để xem hành vi người dùng, xem họ click vào đâu nhiều,… từ đó rút ra được kết luận từ sản phẩm/tính năng nào phù hợp hơn với người dùng. Nhưng hơi buồn vì mình rời dự án trước khi được rằng A/B testing được gắn xong chưa (do dev gắn), và xem được số liệu từ phân tích :(( buồn như con chuồn chuồn.

Cách này cũng sau release sản phẩm, nhưng nó là cần thiết để xác định rằng sản phẩm có phù hợp với nhu cầu của end-user hoặc loại nào của tính năng thì phù hợp hơn. Như facebook vẫn thường thực hiện khi ra một tính năng mới.

5. Những điều mình chưa được thực hiện khi UAT

  • Chưa có nhiều kinh nghiệm làm việc với End-User, chỉ làm việc với bên khách hàng. Và cũng chỉ là làm những cái liên quan đến phân tích gắn js để kiểm tra độ tương tác của User thôi. Chưa tổ chức được nhóm user để xem hành vi sử dụng sản phẩm như thế nào, hay quay video lại để xem họ sử dụng như thế nào.
  • Những loại thực hiện UAT khác mà mình chưa biết tới.

Mình chỉ mong là mình sẽ có cơ hội làm những task như thế này ở cty mới.

6. Kết luận

Mình thực hiện UAT không phải chỉ ở giai đoạn trước khi release sản phẩm, mà đã bắt đầu thực hiện nó khi feature được đưa ra để làm. Và cả sau khi sản phẩm được lên thớt. Và có thể trả lời được là BA/PO có phải là người thực hiện UAT hay không? hay còn những roles khác cùng thực hiện nữa.

Hi vọng nhận feedback từ mọi người về bài viết cũng như kiến thức về UAT.

1 2 3