Hoàng xuất phát là dân kỹ thuật phần mềm, tham gia mảng phát triển phần mềm từ 2017 đến nay. Mình muốn mang những trải nghiệm cá nhân chia sẻ đến anh em, từ đó anh em thấy gì hay thì có thể tham khảo sử dụng, mà dỡ thì anh em góp ý giúp nhé.
View all posts by hoangphan
Vào năm 2020 mình có xây dựng khóa học Vẽ wireframe với Balsamiq Mockup 3, nay mình xin phép chia sẻ lại khóa học với mọi người.
Tập 1 – Cài đặt và giới thiệu Balsamiq Mockup 3
+ Giới thiệu tổng quan về Balsamiq Mockup 3
+ Những thành phần có trên ứng dụng
+ Các chức năng riêng của từng thành phần
+ Thêm controls
Tập 2 – Chọn, di chuyển, sắp xếp các controls
Tập 3 – Thay đổi kích thước và group các control
+ Thay đổi kích thước của từng control
+ Group các controls lại thành từng nhóm
Tập 4 – Chỉnh sửa các controls
Chỉnh sửa màu, nội dung, các thuộc tính của các controls
+ Nhóm 1: Chỉ 1 dòng text
+ Nhóm 2: Không có text nào để edit cả
+ Nhóm 3: Mặc định không có text, nhưng có thể chèn 1 text vào
+ Nhóm 4: Nhiều hơn 1 text
+ Nhóm 5: Nhóm sử dụng shortcut style
+ Nhóm 6: Datagrid
Tập 5 – Mockup linking và presentation
Trong bài học đã tạo sẵn các wireframe màn hình: Login, Signup, Forgot Password, Homepage, Homepage with panel.
+ Link button từ màn hình login qua màn hình homepage, tương tự với các màn hình khác
+ Presentation: Trình bày luồng của wireframe cho các khách hàng, stakeholders
Tập 6 – Symbol/ Assets
Hướng dẫn về tính năng symbol/assets, giúp cho style của wireframes đồng bộ, cũng như chỉnh sửa 1 màn hình mà cập nhất cho các màn hình có vùng thông tin giống nhau.
Tập 7 – Thực hành vẽ wireframe
Bạn có bất kỳ câu hỏi nào thì email cho mình để mình giải đáp cho nhé – [email protected]
Sinh trắc học ở đây bao gồm: Vân tay, khuôn mặt, mống mắt, tĩnh mạch, …. hiện nay thì thường thấy ở các App là xác thực bằng vân tay và khuôn mặt.
Những ai hay quên mật khẩu hoặc ít nhớ mật khẩu thì đăng nhập và xác thực giao dịch (giá trị nhỏ) bằng sinh trắc học vô cùng hữu hiệu, giúp đỡ phải nghĩ mật khẩu của ứng dụng là gì, bấm nhiều ký tự, mất nhiều thời gian – từ đó sử dụng sinh trắc học thì nhanh, tiện lợi, bảo mật hơn, và mang đến một trải nghiệm công nghệ cho người dùng cực tốt.
Một cái tiện nữa là khi bạn đang ở 1 quầy giao dịch đông người, thực hiện giao dịch bằng faceID hay vân tay trên thiết bị, giúp cho việc thanh toán nhanh hơn, và những người xung quanh sẽ không thể nào dòm ngó được mật khẩu hay mã PIN của bạn, xưa kia mình chơi game nhập mật khẩu cũng bị dòm ngó và bay hết đồ trong game luôn :D, ước gì lúc đó game có đăng nhập bằng vân tay/faceID trên máy tính. :)))
Nhưng việc dùng sinh trắc học cũng là một điểm trừ khi nó làm bạn gần như quên luôn mật khẩu, khi cần dùng đến mật khẩu thì phải lục tìm lại. Chị sếp trực tiếp của mình chọn cách đăng nhập bằng mật khẩu luôn thay vì dùng vân tay :v để tránh quên mật khẩu =)).
Còn đối với mình thì mình sài 1password để lưu MK, và mình cứ sài sinh trắc học để đăng nhập ứng dụng cho lẹ, đỡ phải ấn ấn cho lâu.
Note: Phía trên mình có ghi bảo mật hơn, ý này mình có đọc nhiều bài nghiên cứu của các chuyên gia bảo mật nói rằng xác thực bằng sinh trắc học bảo mật hơn.
Những người tham gia khảo sát đều bình chọn sinh trắc học là một trong những hình thức xác thực an toàn nhất, với 97% cho rằng nhận diện vân tay là một phương thức bảo mật cao, theo sau là công nghệ nhận diện mống mắt với 94%, và nhận diện khuôn mặt với 92%. Những hình thức này được đánh giá an toàn hơn các phương thức như xác thực bằng mã PIN với 87% và mật khẩu với 84%.
Và cũng dĩ nhiên khi một BA đưa tính năng đăng nhập và xác thực giao dịch bằng sinh trắc học, cần lưu ý về các trường hợp thêm một vân tay mới, xóa bớt vân tay, hay xóa toàn bộ vân tay – từ đó xử lý các trường hợp sao cho phù hợp để đảm bảo bảo mật cho ứng dụng. Ví dụ trường hợp thêm một vân tay mới ở thiết bị, thì ứng dụng khi được mở lên sau khi cài mới một vân tay cần có thông báo để KH biết và có phương án xử lý như tắt đăng nhập, xác thực bằng vân tay hoàn toàn hay là vẫn đồng ý sử dụng vân tay, từ đó chặn được rủi ro bảo mật sớm.
10. Đánh giá app
Hiện nay khi mình làm App mình thấy có nhiều chỗ đánh giá ứng dụng, nhưng mình thường chú ý tới đánh giá trên AppStore/CHPlay và đánh giá trên App và thu kết quả đánh giá về DB dự án dùng phân tích/đánh giá để cải thiện ứng dụng.
Cách đây một tháng, mình cũng ngồi cà phê với bạn chí cốt của mình làm product về book bác sĩ online, team phát triển của bạn đã họp nhiều lần và đánh giá rằng việc sử dụng đánh giá trên App trực tiếp sẽ giúp cho việc thu thập thông tin đánh giá nhanh và user real đánh giá ứng dụng thật. Ngoài ra nếu App có không được tốt quá thì rating trên AppStore/CHPlay cũng không bị quá thấp, vì KH đã đánh giá trên App – team sẽ khắc phục nhanh.
Nhưng cũng đừng lạm dụng việc đánh giá trên App quá, trước đây khi mình làm với 1 Bank, họ cũng đề xuất thêm rất nhiều chỗ để đánh giá App, nhưng mình chưa kịp phân tích xong chỗ nào cần đặt đánh giá/chỗ nào không cần thì đã nghỉ công ty mất tiu :D, chứ không giờ có thêm 1 mớ kinh nghiệm chia sẻ về phần này ở đây rồi (đùa thôi).
Dưới đây là một ví dụ mình thấy trên cộng đồng UI/UX Designers có chia sẻ về việc biểu mẫu đánh giá xuất hiện chưa đúng chỗ, mọi người xem tham khảo để tránh những trường hợp tương tự nhé, bài đăng lên thả haha quá trời luôn (hơn 60% thả haha)
11. Nhắc nhở thanh toán hóa đơn/đơn hàng
Về tính năng này thì mới xuất hiện vài năm gần đầy thôi, khi mà các ứng dụng về thanh toán xuất hiện hàng loạt, nhưng giờ tính năng cũng nằm khắp các ứng dụng từ momo, zalopay, viettelpay, vnpay, app ngân hàng.
Thường thì các hóa đơn điện, nước, internet, phí chung cư, thanh toán thẻ tín dụng … là lặp lại tại một ngày nào đó hằng tháng, nhưng khách hàng lại hay quên bén đi ngày đóng, do đó việc thêm tính năng nhắc nhở sẽ giúp cho khách hàng không quên thanh toán hóa đơn, cũng như giúp KH truy cập App nhiều hơn, dùng app của doanh nghiệp bạn để thanh toán – từ đó có lợi nhuận thêm cho doanh nghiệp – một yếu tố hàng đầu trong việc kinh doanh.
Việc nhắc nhở có thể thực hiện bằng cách hiển thị nổi bật, nhắc nhở trong tin nhắn, push notification, gửi tin nhắn về sđt cho KH,… hoặc kết hợp vài phương án lại, miễn sao thực hiện đúng mục đích và chi phí thấp nhất.
12. Hiển thị loại bàn phím phù hợp
Trong thời điểm làm việc với các App của ngân hàng, đây là một trong những điểm làm mình lâu lâu phải đọc lại tài liệu và chỉnh sửa nó.
Ban đầu thì chỉ cho nhập số, nhưng sau đó thay đổi yêu cầu cho nhập chữ, đôi lúc thì chỉ cho nhập chữ tiếng Việt không dấu, rồi bỏ dấu đi, nên khi thay đổi yêu cầu từ phía Bank, đầu nghiệp vụ và Dev, tester cũng phải cập nhật theo.
Nhưng đó là khi yêu cầu rõ ràng, và chủ động từ phía Bank. Đôi lúc đầu Bank chưa chủ động về việc nói ra chỗ đó cho phép nhập loại ký tự gì, thì đầu BA cũng cần có chút kinh nghiệm để hỏi rõ chi tiết, chi tiết nên kỹ đến mức là cho phép nhập ký tự đặt biệt thì cho phép những ký tự đặt biệt nào, có những trường hợp chỉ cho nhập vài loại ký tự đặt biệt thôi, từ đó hiển thị bàn phím phù hợp và kèm theo chặn trên đầu Client (App) để KH không nhập được. Nhất là trong trường hợp dữ liệu đẩy về CoreBanking – dữ liệu ký tự cần chuẩn hóa sao cho phù hợp với Core để không gây ra lỗi.
Việc kỹ từng ký tự và hiển thị bàn phím phù hợp sẽ giúp giải quyết được nhiều trường hợp lỗi bất ngờ và giúp trải nghiệm người dùng tốt hơn rất nhiều.
Một ví dụ cụ thể hơn đó là thanh toán hóa đơn – đóng học phí cho trường ABCXYZ.
Nếu BA thăm dò được rằng trường ABCXYZ thanh toán thông qua mã số sinh viên – và mã này chỉ có 10 ký tự số, thì bàn phím hiển thị loại bàn phím số, và cho nhập tối đa 10 ký tự, Client (đầu App) kiểm tra không cho phép paste ký tự chữ vào ô đó hoặc thậm chí là chặn paste vào trường mã số sinh viên luôn cũng được. Khi nhấn tiếp tục để kiểm tra thông tin sinh viên thì Client kiểm tra sẵn trường đã đủ 10 ý tự số chưa, nếu chưa đủ thì báo lỗi để SV nhập lại, còn đủ rồi thì mới truyền cho Server kiểm tra và gọi vào các đầu Core xử lý.
Sẵn tiện ở mục này, mình có 1 điểm hay cần chia sẻ luôn, thứ tự của các trường dữ liệu nhập vào – chọn từ danh sách cũng nên được phân tích để sắp xếp cho phù hợp, và tại đầu Client và Server kiểm tra thông tin hợp lệ cũng nên được xem xét để đầu Dev biết thứ tự kiểm tra phù hợp và thông báo cũng theo thứ tự lỗi luôn. Điều này giúp cho Dev develop dễ hơn, tester viết testcase cũng theo thứ tự và biết lỗi nào trước lỗi nào sau, một phần giúp cho 2 đầu App (iOS/Android) đồng bộ về báo lỗi – nhiều TH KH bị 2, 3 lỗi, nhưng thử ở các OS khác nhau lại hiển thị lỗi khác nhau hoặc thứ tự lỗi bị đổi cũng làm KH hoang mang – đội Dev ngồi tìm lỗi cũng mệt nhọc hơn sau này.
13. Tự động chọn loại chuyển tiền liên ngân hàng
Gần đây mình sử dụng một số ứng dụng thì thấy đã triển khai việc chuyển tiền thường và chuyển tiền qua Napas về chung 1 tụ.
Trước đây mình mới vào công ty, đa số ngân hàng đều phân ra chuyển tiền thường (có người tác động lên thì lệnh mới thực hiện được – thường là vài phút – vài tiếng hoặc 2 ngày nếu là cuối tuần thì lệnh mới được các bạn GDV thực thi) và chuyển tiền qua Napas/nhanh (thông qua hệ thống Napas, tiền chuyển đi trong vài chục giây, phút nếu hệ thống chạy trơn tru) – Nhưng KH thì đâu biết thường và Napas khác nhau thế nào đâu. Thậm chí trước khi mình làm mảng BA cho Finance/Banking thì chưa phân biệt được, và dùng còn nhầm, và người yêu mình cũng là một trong những người bị vướng phải khi cần chuyển tiền gấp cho người quen, và phải đợi tận 2 ngày tiền mới tới – nên phải chuyển thêm lần nữa qua Napas để tới liền, rồi đợi hoàn tiền từ người quen sau 2 ngày tiền kia tới.
Nên việc đưa về 1 tụ cho 2 ông chuyển khoản liên ngân hàng này là rất cần thiết, hoặc thậm chí là chuyển trong cùng ngân hàng (3 tụ về 1). Nhiều KH họ chỉ biết là chuyển cho STK nào, chủ tài khoản là ai và ngân hàng nào thôi, chứ họ không quan tâm chuyển qua kênh Napas hay thường, và cũng không phân biệt được chuyển đó là trong cùng ngân hàng hay khác ngân hàng.
Và trong việc chung về 1 tụ như thế này thì đầu Server sẽ detect xem rơi vào trường hợp chuyển tiền nào và từ đó gọi API về CoreBanking thực hiện cho đúng, với trường hợp chuyển tiền liên ngân hàng qua Napas bị lỗi thì App đề xuất KH thực hiện chuyển tiền thường (nếu muốn – và app có thông báo phí, thời gian thực hiện rõ ràng cho KH biết).
ps: Chú ý thêm vấn đề phí chuyển khoản, hạn mức, số lần được chuyển khoản trong ngày/tháng ở đây nhé – khi đi sâu vào vấn đề này thì cần phân tích kỹ hơn để đầu server chạy cho đúng từng trường hợp.
14. Nội dung chuyển tiền mặc định
Nội dung chuyển tiền nên được hiển thị mặc định, đôi lúc KH chỉ chuyển tiền giữa các tài khoản của mình nhưng khác ngân hàng, hay đơn giản là bạn bè cho mượn tiền thanh toán, và chuyển tiền ngay để trả thì nội dung cũng ít cần thiết tại thời điểm lúc đó.
Thay vì KH tốn thời gian nhập nội dung chuyển tiền thì App để mặc định nội dung với tên KH, ví dụ “Nguyen Van A ck” là một phương án vô cùng hợp lý, và KH có thể thay đổi nội dung chuyển tiền cho phù hợp nếu thật sự cần điền nội dung chuyển tiền. Hiển nhiên với các trường hợp Chuyển tiền cần nội dung chi tiết, thì KH luôn được nhắc nhở, hoặc thông tin chuyển tiền thường đã đề cập nội dung chuyển tiền ⇒ VD như chuyển tiền cho PhiEnglish học tiếng Anh (dự án trung tâm tiếng Anh của mình) thì trong email gửi cho KH mình luôn đề cập kỹ đến nội dung chuyển tiền và tô đậm lên cho KH biết.
15. Tìm kiếm ngân hàng thụ hưởng
Khi chọn ngân hàng thụ hưởng, bạn sẽ tìm kiếm ngân hàng đó như thế nào?
VD như ngân hàng VCB thì 1 số KH lại nhớ ký hiệu VCB thôi, có KH thì lại nhớ Vietcombank, hoặc ngân hàng ngoại thương (thường tên đầy đủ ngta lại ít nhớ hơn, nào là ngoại thương, kỹ thương, công thương, thương tín…)
VCB – Vietcombank – Ngân hàng ngoại thương – Ngân hàng thương mại cổ phần Ngoại thương Việt Nam.
Nên việc tìm kiếm tên ngân hàng thụ hưởng cũng cần được thể hiện ở nhiều loại tên khác nhau, hoặc có thể viết gọn (hiển thị trên App), nhưng vẫn cho phép tìm kiếm với đầy đủ thể loại.
Với lại nên sài tiếng Việt có dấu đầy đủ cho KH dễ đọc ở mục hiển thị trên App, thay vì sài tiếng Việt không dấu trả từ CoreBanking ra – làm cho việc đọc tên ngân hàng bị khó đi.
Nên tránh hiển thị thêm các mã ngân hàng trong tên, chỉ làm KH loạn thêm – vì họ chẳng biết mã đó là mã gì mà còn làm họ suy nghĩ có khi nào mình chọn sai ngân hàng không, hay nó là số gì đó ảnh hưởng không phải người nhận đúng chỗ.
Với ví dụ trên, thì khi KH tìm kiếm ngân hàng Vietcombank có thể xảy ra các trường hợp nhập như sau:
Vietcombank
VCB
vietcombank
ngoai thuong
ngoại thương
Thì việc hiển thị ra được thông tin ngân hàng đúng là một điều rất tuyệt vời và cải thiện trải nghiệm người dùng rất nhiều. Và tên hiển thị ra có thể chỉ là “VCB – Ngân hàng ngoại thương” (nếu kèm logo được thì tốt) một cách gọn ghẻ trên màn hình mobile, nhưng tìm với nhiều loại keyword bao gồm cả Vietcombank thì vẫn tìm ra được đúng ngân hàng đích.
Bổ sung thêm là ds này lên load lúc màn hình khởi tạo để việc tìm kiếm tên là có ngay, thay vì KH phải đợi để load từ corebank hay từ confign lên – mất một thời gian phải chờ đợi.
Kết luận
15 điểm UI/UX được trình bày phía trên là một trong những trải nghiệm riêng của bản thân khi làm việc mảng BA cho Banking, hi vọng bài viết sẽ giúp đỡ bạn đọc hiểu thêm/cách nhìn thêm về 1 khía cạnh làm việc của vị trí Business Analyst cũng có liên quan đến một phần UI/UX.
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
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.
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.
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.
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.
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ị.
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.
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à.
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.
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
Hi các bạn, mình là Hoàng đây. Đây có vẻ là blog đầu tiên mình viết trên hoangphan.blog.
Mình muốn kể các bạn nghe về quá trình mình xóa dốt tiếng Anh bằng cách đi học tiếng Anh tại Philippines của mình, và mình xây dựng nên Trung tâm tiếng Anh online như thế nào để tại thời điểm mình exist Trung tâm tiếng Anh đó đã giúp được khoảng 75 học viên giao tiếp tốt và tự tin hơn – với gần 100 khóa học, 2000 buổi học từ 14 giáo viên người Philippines.
Và gần đây mình đã xây dựng lại một trung tâm tiếng Anh mới, đã vận hành từ tết âm lịch 2024, tính tới thời điểm hiện tại (14 Nov 2024) đã có 80 học viên, hơn 14 giáo viên.
*** KỂ VỀ QUYẾT ĐỊNH ĐI HỌC BÊN PHILIPPINES ***
Thời điểm giữa năm 2019, khi mình đọc được bài chia sẻ về khóa học tiếng Anh tại Philippines từ Tony Buổi Sáng, mình bắt đầu kiểm tra xem về chi phí, sự an toàn khi học tại Philippines. Thêm vào đó mình có quen biết 1 đứa em cũng đi học tại Philippines cách đó 1 năm, nhờ bé chia sẻ thông tin, cũng như cảm nhận khi đi học, chưa kể là bé tăng kỹ năng tiếng Anh lên rất nhanh, thế là mình quyết định gọi điện về cho ba đi học tiếng Anh ngay – với mục đích xóa dốt tiếng Anh giao tiếp cho bản thân – một trong những yếu tố giúp mình thăng tiến trong sự nghiệp tốt hơn đặc biệt là với ngành IT Business Analyst.
Đối với ba mình thì cứ học thì ba mình tìm mọi cách để chi cho mình đi học ngay, miễn là mình chịu học. Cũng may là tại thời điểm đó ba vừa nhận được tiền hỗ trợ đất khi nhà nước thu đất cho Hòa Phát xây dựng nhà máy, miếng đất của ba được 200 triệu, ba cho mình 100 triệu để đi học, chứ không thì cũng không có tiền mà đi học =)) khi mà lương lúc đó mình chỉ đủ sống mà chưa có khoảng dư quá nhiều để cho 1 cuộc đầu tư như thế này.
Với cơ bản mình cũng ý thức được rằng đầu tư cho bản thân/công việc là một trong những thứ đầu tư không thể nào lỗ được, mình có thể kiếm được số tiền 100 triệu đó để trả lại cho ba mình sớm thôi khi có vốn tiếng Anh tốt hơn.
*** ĐĂNG KÝ ĐI HỌC ***
Ngày đó mình liên hệ với chị Trang – là chị của bé Nhã (đã đi học ở Philippines trước đó) để giúp mình đăng ký, vì chị ý cũng tự mở dịch vụ đi học tiếng Anh bên Philippines với cái tên là theo thể loại Gap Year… với khi đăng ký qua chị Trang thì chi phí rẻ hơn nhiều so với những bạn đăng ký qua trung tâm khác. Điều này mình biết được khi qua bên trường học và hỏi các bạn đi cùng giá cả, mình rẻ hơn gần 15%. Chắc rẻ là nhờ mối quan hệ quá :))))
Đầu tháng 7 mình bắt đầu book khóa học, đặt vé máy bay, book ký túc xá đồ các kiểu, gần như mình chọn cái tiết kiệm nhất. Đến 03/08/2019 là mình bay đến Manila, sau đó từ Manila tiếp tục bay đến Bacolod, lần đầu được đi nước ngoài, và cũng là lần đầu được bay – Khóa mình đăng ký học là khóa ESL (English as Second Language)
Chị Trang giúp mình book vé máy bay, rồi đăng ký tất cả mọi thứ, còn gửi mình 1 list các vật dụng cần phải mang theo, thành ra mình mang gần đủ mọi thứ mà không cần qua bên đó mua gì thêm, ngoài Mì Tôm :(( – cái mà mình được dặn rất kỹ rằng phải mang vì qua đó thèm mì tôm VN lắm, và mình thì là người rất hiếm khi ăn mì tôm nên chỉ mang theo có 5 gói, thế là qua đó thèm thiệt, đói mì tôm chỏng queo luôn, đi xin ăn ké bạn mới qua hoài.
*** QUÁ TRÌNH HỌC TẠI BACOLOD ***
Học tiếng Anh tại LSLC (Trường ở Bacolod City) thì mình sẽ học 1 tuần 5 ngày, và 1 ngày khoảng 6 tiếng (bắt buộc), 3 tiếng tự chọn, 4 lớp luyện 4 kỹ năng là giáo viên 1 kèm 1 (gọi là Man-to-man class), 1 lớp học chung với các bạn khác – lớp 6 bạn (gọi là Group class). Cuối tuần thì mình thường dành thời gian enjoy cùng bạn bè để khám phá văn hóa cũng như đi khám phá phong cảnh các khu vực gần thành phố.
Nói chứ mình học tại đây 12 tuần, thì mình đã dành 10 cái cuối tuần để đi du lịch, trong tuần thì cố gắng cày cuốc, thứ 7 và Chủ Nhật thì cứ bắt kèo với các bạn người Nhật, Hàn, Đài, Trung và bạn bè người Việt đi leo núi, đèo, rồi qua vài hòn đảo khác để khám phá.
Tự bản thân mình đánh giá thì thời điểm mình bắt đầu học thì phản xạ mình rất yếu, điểm yếu mình nằm ở phần nghe, do đó khi học với giáo viên mình cực kì tập trung kỹ năng nghe để tăng phản xạ, tự luyện thêm sách mỗi tối, còn kỹ năng nói thì gần như lớp nào cũng dùng rồi, ở bên đó thì làm gì cũng phải sài tiếng Anh, như đi mua đồ ăn, nói chuyện với bạn bè, giáo viên, tiếp viên hàng không, tài xế xe Jeepney hay đi du lịch, book phòng, book xe.
Tự đặt bản thân mình vô thế phải dùng tiếng Anh, thì tự nhiên khả năng phản xạ của mình tăng rất nhanh, kèm với việc ôn luyện kỹ năng nghe mỗi tối nên xong khóa tiếng Anh của mình tăng 1 bật, có thể tự nhiên giao tiếp với người nước ngoài bằng tiếng Anh, nhưng để thực tế áp dụng vào công việc, trao đổi trực tiếp với Khách hàng bằng tiếng Anh thì mình thấy chưa đủ, do đó khi học xong tại Philippines, mình về HCM làm việc và vẫn tiếp tục liên hệ giáo viên bên Bacolod để học trực tuyến, và từ đó là tiền đề của việc xây dựng nên dự án trung tâm tiếng Anh trực tuyến đầu tiên (đã tặng cho bạn vận hành), và một dự án mình mở lại năm 2024 là EnrichEnglish.net
Giá học mới đã cập nhật, giá chỉ từ 138K/buổi (50 phút học)
Học ở môi trường với nhiều học viên từ các nước khác nhau, giúp mình hiểu được 1 phần về con người, văn hóa và cách các bạn nước khác học thông qua việc kết bạn, trò chuyện, cũng như nhờ họ chia sẻ về việc học tập, những vấn đề xã hội tại quốc gia họ. Sau 3 tháng học mình kết bạn được với nhiều bạn từ Nhật, Hàn, Đài, … và dĩ nhiên là những người bạn tại thành phố Bacolod nữa.
Giữ contact với giáo viên đã dạy mình, và những giáo viên không dạy nhưng mình tự bắt chuyện làm quen, đặc biệt là những giáo viên trẻ tuổi – họ thích nói chuyện cũng như thỉnh thoảng giúp mình sửa lỗi tiếng Anh. 2 tuần mà mình không đi du lịch, khám phá chính là thời gian mà mình đi cà phê với những giáo viên này, những cuộc nói chuyện thông thường giúp mình cải thiện thêm khả năng phản xạ khi học tại đây. Và khi về Việt Nam họ đôi lúc còn giúp mình sửa ngữ pháp cho những bài viết CV tìm việc.
Tóm lại quá trình học Tiếng Anh, mình dành 70% công lực cho việc học, 30% công lực cho việc du lịch và khám phá, kết quả thu về thì ngoài vốn tiếng Anh, sự tự tin và khám phá về con người sống tại Philippines. Cả việc kết bạn với những người bạn đến từ Nhật Bản, Hàn Quốc, Đài Loan, Trung Quốc, … những mối quan hệ mà đến giờ mình vẫn còn giữ liên lạc, đôi lúc thì gọi để trò chuyện, từ đó giúp mình có những động lực phát triển bản thân hơn ở những mặt khác.
Công cụ lao động không chỉ là những vật dụng, những dụng cụ hiện hữu giúp bạn làm việc tốt hơn. Mà trong thời đại ngày nay, đối với mình thì có một loại công cụ lao động không thể thay thế cho nguồn lao động chất lượng cao. Nếu không có nó, nguồn lao động này không còn là chính nó nữa. Đó chính là “Tri thức”.
2. Khái niệm
Theo như mình nhớ, lịch sử lớp 10 từng có dạy về khái niệm công cụ lao động, mình xin trích một phần định nghĩa từ wiki vào như sau:
3. Các thời kỳ của công cụ lao động
Xưa công cụ lao động được sắp xếp theo các kỷ nguyên từ thời kỳ đồ đá -> Đồ đồng -> Đồ sắt -> vậy thời nay, là thời kỳ đồ gì???? Theo mình nghĩ giờ là kỷ nguyên của nền tri thức.
Để mình giải thích cho các bạn vì sao mình nghĩ vậy nhé.
4. Kỷ nguyên nền tri thức
4.1 Việc không thiếu, thiếu là do thiếu tri thức
Gần đây mình có đọc được cuốn sách “Tôi tương lai và Thế giới” của tác giả Nguyễn Phi Vân. Cuốn sách có đề cập rất nhiều về vấn đề Robot đang dần thay thế con người trong công việc. Nhiều người trở nên thất nghiệp, vậy vấn đề có phải do robot đang dần chiếm lấy công việc của người lao động. Theo ý kiến cá nhân của mình thì không phải. Thỉnh thoảng mình lướt facebook, có rất nhiều tin tuyển dụng, HR hằng ngày đăng status than rằng không tìm được ứng viên phù hợp, không có CV nộp cho họ.
Vấn đề ở chỗ việc thì không thiếu, mà người than không có việc cũng không thiếu nốt. Trước ở trọ, nghe anh phòng kế bên than không có việc, tìm hoài không ra việc. Vậy sao người thiếu việc, việc thiếu người không chạm được với nhau. Đó có phải là do nguồn lao động chưa đủ kỹ năng, kiến thức để làm những công việc đó (bỏ qua một phần từ sự phù hợp nhé).
Kỹ năng và kiến thức có phải là trí thức không?
Câu chuyện xảy ra là robot đang thay thế dần những công việc tay chân, những công việc có thể lập trình cho nó tự hoạt động được. Còn rất nhiều khối công việc cần nguồn nhân lực tri thức, như ví dụ ở trên.
Để làm được những công việc khó hơn, những công việc mà robot hay cả những người lao động khác khó có thể thay thế. Thì việc nâng cao trí thức (một công cụ lao động) là điều không thể thiếu.
4.2 Học là chuyện suốt đời
Đừng nghĩ rằng việc nạp kiến thức chỉ thực hiện khi từ 5 tuổi đến hết 22 tuổi, rồi sau đó tập trung sáng đi làm, tối về nằm xem youtube, facebook, titok đến suốt hết cuộc đời. Mình thật sự thấy nhiều bạn thực sự phí tuổi trẻ của chính họ trong khi đó họ có thể nạp thêm kiến thức để trở thành một phiên bản tốt hơn của bản thân.
Để phát triển thêm, tồn tại dễ hơn trong thời đại hội nhập, công dân toàn cầu này thì mỗi người chúng ta cần phải học tập liên tục và không ngừng nghỉ. Như thế thì “tri thức” mới nâng cao được, công cụ lao động được rèn dũa tốt hơn, xịn xò hơn. Từ đó mà thăng tiến trong sự nghiệp và trở thành một nguồn lao động chất lượng cao, cực cao và rất rất cao cả khi bạn đi làm thuê, làm cho chính mình hay làm ông chủ.
4.3 Ngoại ngữ là thành phần không thể thiếu
Thêm vào đó để hội nhập tốt hơn, dễ dàng trở thành công dân toàn cầu thì ngoại ngữ là một trong những yếu tố quan trọng. Bạn có biết rằng 3 ngôn ngữ được dùng phổ biến nhất (tính theo số lượng người dùng, số quốc gia dùng và được sử dụng trên internet) là: Tiếng Anh, Tiếng Trung và Tiếng Tây Ban Nha (số liệu 2018).
Và Tiếng Anh là một ngôn ngữ được sử dụng phổ biến trong công việc ở Việt Nam và nhiều nước trên thế giới, do đó việc nâng cao trình độ Tiếng Anh là một điều thực sự nên làm của người trẻ Việt Nam.
Và mình cũng đang cung cấp dịch vụ kết nối việc học tiếng Anh giữa học viên ở Việt Nam và giáo viên Filipino, để giúp học viên trở nên tự tin và nói lưu loát hơn với các khóa học Giao tiếp, tiếng Anh trong công việc (học 1-1). Liên hệ mình để biết được thông tin nhé, giá từ 129K/60p học.
4.4 Ngẫm nghĩ thêm
Ngoài ra gần đây mình cũng nghe được 1 chia sẻ từ anh Viruss, nó thực sự thấm với mình nên cũng muốn chia sẻ lại cho các bạn.
Theo luật vận động của vũ trụ, nếu bạn không trao dồi kiến thức, bạn không trao đồi bản thân về mặt kiến thức. Thì bạn sẽ luôn luôn bị chững lại hoặc bị lún, phải trao đồi liên tục, vì cá nhân của chính bạn. Càng làm việc, thì càng ra nhiều thứ, và cách nhìn về cuộc sống sẽ đa dạng và theo nhiều chiều hướng khác nhau.
Mình chỉ để đây để bạn đọc và mình cùng suy ngẫm.
5. Tóm tắt
Tóm tắt lại bài viết, mình muốn truyền tải với các bạn:
Công cụ lao động thời nay chính là “tri thức”.
Nâng cao trình độ giúp bạn không bị thay thế bởi robot và những người khác.
Nạp kiến thức không chỉ từ 5->22 tuổi, mà nó nên đi theo suốt cuộc đời bạn.
Tiếng Anh là 1 trong 3 ngôn ngữ phổ biết nhất thế giới, học tiếng Anh giúp bạn dễ dàng hơn trong việc trở thành công dân toàn cầu.
Hãy luôn trao dồi kiến thức vì cứ qua mỗi giây thì kiến thực lại bị cũ đi 1 ít.
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.
Mình cũng vừa tiếp cận với vị trí BA trong thời gian cũng không quá lâu, khoảng hơn 7 tháng làm công ty và 2 tháng freelancer với vị trí front-end kết hợp BA.
Mình muốn chia sẻ những công cụ mà giúp ích mình trong công việc (BA), hi vọng qua bài này có thể giúp bạn đọc tìm hiểu thêm được 1 số công cụ mới, phù hợp với chính bạn.
Và đa số những tool này đều là free, nên rất dễ dàng cho các bạn sử dụng mà không tốn phí.
1. Tool quản lý task/document
1.1 Jira/Confluece:
Chắc cũng rất rất nhiều bạn đã biết về phương pháp phát triển phần mềm, framework Scrum hay là Agile rồi nhỉ? Thì Jira là một trong những công cụ không còn quá xa lạ, nó là ứng dụng theo dõi, quản lý lỗi/vấn đề trong dự án, theo mình thấy trong Jira hay gọi chung là Issue.
Mình khi vừa bắt đầu đi làm công ty đầu tiên, đã tiếp cận ngay với anh Jira này rồi, và cực kì thích cách hoạt động của ảnh.
Thứ nhất, ảnh bám sát theo mô hình scrum, agile mà ra cái tool này, mà xu hướng hiện giờ đa số các công ty IT đều theo framework này, do đó mà được nhiều công ty ưa dùng, mình cũng ưa nữa =)). Ưa cả framework Scrum lẫn Jira.
Thứ high: Ảnh có support thay đổi workflow theo từng project, quá tuyệt vời luôn. Tùy thuộc vào team/dự án, mà workflow nó khác nhau. Do đó nhờ vào việc có thể dễ dàng thay đổi workflow mà mình custom cho mỗi dự án. Tuyệt vời ông mặt trời.
Thứ bar: Công cụ tìm kiếm cũng rất tốt, chỉ cần search theo bất kì từ nào nhớ về task, có thể tìm nó ra ngay lập tức luôn. Quên mất title của task => Search bằng description cũng ra nữa.
Đi kèm với anh Jira, thì có anh Confluece, mình hay gọi ảnh là công cụ lưu trữ document, nhưng các chỗ khác thì gọi là tích hợp nội dung đa phương tiện. Anh này mình thấy tiện nhất đó là tích hợp với anh Jira phía trên. Khi mình gắn task Jira lên Confluece, thì từ Confluece, với 1 cú click là ảnh nhảy qua anh task Jira liền, và ngược lại cũng vậy.
Mình dùng công cụ này để tạo các trang trao đổi Q/A, document, guideline, ghi lại ticket đã làm trong tháng, một số lưu ý, các kiểu con đà điểu.
Nhưng hai anh Jira và Confluence muốn dùng phải trả phí nhá, có 2 phiên bản On Cloud và Hosted on your server. Muốn dùng hàng ngon thì phải trả phí thôi.
Anh Trello này mình hay dùng thời sinh viên, thời còn làm cho Hội sinh viên trường với làm ở Đội Công tác Xã hội. Ban đầu dùng nó để chủ yếu quản lý công việc, phân công, và mọi thứ lưu hết trên trello này, rất dễ sử dụng. Và đặc biệt là FREE.
Trello là một công cụ để quản lý công việc một cách hiệu quả, giúp cho ta có thể dễ dàng nhìn vô là biết mình cần làm gì, ai đang làm, cái nào đã được hoàn thành. Có thể gọi ngắn gọn là một bản Kanban cũng được.
Cái mình thích ở Trello đó là có thể một công việc có rất nhiều cái công việc con trong đó. Giả sử đi chợ mua đồ, mình có thể list hết những thứ cần mua: Gạo, cá, rau muống, quần s, … khi mua xong nào thì check vô.
Ngoài ra còn thích cái pẹt pẹt của nó nữa. Cái pẹt pẹt này là khi xong task, hoặc cần kéo task đi đâu, thì kéo pẹt 1 phát, nó qua list khác liền.
Mình mới biết đến Asana khi làm ở công ty Kyanon.digital thôi, mới vô công ty có tờ checklist, được add vô Asana của team, thế là mình biết Asana :)).
Cũng như trello, thì Asana là một trong những công cụ quản lý dự án khá là tốt, thiên về quản lý tiến trình.
Asana là gì??
Mình thấy cái hay của Asana đó là rất dễ dàng để tạo task, tự mình tạo hoặc tạo cho đồng đội cũng được luôn, quản lý công việc theo bảng, hoặc theo dạng như danh sách, có thể dùng tag để đính kèm thể hiện cho status của task. Và một cái rất rất hay đó là 1 task có thể gắn với nhiều project liên quan.
Asana cung cấp 1 phiên bản free với số lượng user không quá 15 người. Mình nghĩ số lượng này rất phù hợp cho 1 team. Còn nếu team nhiều người quá thì phải bỏ tiền ra mua để dùng thôi. 😀
1.4 Bộ công cụ của MS: Excel/Word/PP và bộ online của nó
Nhắc tới 3 cụ cậu này, thì đa số điều biết hết nhỉ.
Mình thì thường dùng Excel như một bộ quản lý issue, checklist khi thực hiện UAT, hay dùng xây dựng test-case. Thỉnh thoảng dùng như một bộ matrix để đánh giá, đặt question, đánh giá mức độ các kiểu….
Word viết document, release note, demo script,…
Còn anh PP thì note bug trên này luôn cũng khá tiện, làm slide trình bày, hoặc vẽ vời.
1.5 Công cụ quản lý khác
Ngoài những công cụ phía trên, thì mình cũng đã từng sử dụng 1 số tool khác như: TFS (ở công ty cũ), MindMeister (tự tìm hiểu), Ms Project, Bitrix. Các bạn có thể kham khảo thêm để sử dụng nhé.
2. Tools vẽ
2.1 Balsamiq Mockups
Đây là một công cụ mình cực kì hay dùng trong các dự án mình làm BA. Tên của phần mềm có chữ mockup, nhưng mình dùng chính vẫn là để vẽ wireframe. Còn để biết sự khác nhau giữa sketch, wireframe, mockup, prototype thì xem qua bài viết này nhé.
Dưới đây là một demo mình vẽ wireframe các version khác nhau cho tính năng share một bài viết qua email….
Để tìm hiểu thêm về phần mềm này, liên hệ mình cho key dùng vài năm nè 😀
2.2 Adobe XD
Thường sau khi đã có phiên bản wireframe, mình lười nên hay bỏ qua bước vẽ mockup lắm, vọt luôn qua bên anh Adobe XD để vẽ luôn prototype mode.
Đây là một công cụ hoàn toàn free (trước kia phải mua), và nếu ai đã dùng qua các công cụ khác của Adobe, thì sử dụng công cụ XD cực kì đơn giản.
Trước mình hay vọc photoshop, AI, lightroom nên khi qua XD cũng không cần phải học gì để sử dụng cả. Vọc 1 buổi là biết dùng ngay.
Ngoài ra còn hỗ trợ rất nhiều bộ UI Kit khá là ngon để tạo một prototype một cách nhanh chóng. Ảnh có luôn phần điều hướng khá dễ sử dụng (gần giống như của Xcode), khi Dev xem qua prototype có thể biết được từng nút sẽ hoạt động như thế nào, click vô thì cái gì sẽ được xuất hiện. Còn nếu anh Dev không cài XD thì có thể mình record lại cách hoạt động (Workflow) của sản phẩm mình đang làm, và gửi video cho anh dev là được rồi.
Đây là 1 video lúc mình học năm 3, lúc đó còn code nên cũng vẽ prototype lấy loeeeeeeee.
Video demo cho ứng dụng hẹn hò – code bằng React Native, build bằng Xcode
Nhưng thực tế thì cái này mình chỉ dùng khi trước kia làm tự do, hoặc làm đồ án gì thôi. Chứ hiện tại team mình có 1 anh Designer, do đó mình chỉ vẽ wireframe, còn chuyển về prototype hay mockup thì ảnh cân tất. Ảnh dùng sketch trên MacOS với https://Invisionapp.com để mọi người trong team có thể xem được design trên cloud, cũng như workflow giữa các design.
Tìm hiểu và download XD tại đây nhé: https://www.adobe.com/products/xd.html
Ngoài ra các bạn có thể tìm hiểu thêm một số tool mình từng dùng liên quan đến vẽ như: Photoshop, AI, Sketch, Photoshop online khi vào đúng máy quên chưa cài pts.
2.3 Draw.io
Xong phần về design thì mình sẽ tém lại, và nhảy qua phần vẽ liên quan đến workflow, diagram, gọi chung là các sơ đồ. Phần các sơ đồ, thì mình sẽ viết một bài khác nhé.
Hầu như các sơ đồ liên quan đến BA mình hay vẽ, đều dùng tool này.
Trước kia thì có dùng StarUML khi còn là sinh viên năm 2, với các môn học phân tích thiết kế hệ thống thông tin, phương pháp mô hình hóa, đặc tả hình thức các kiểu.
Và cũng từng dùng qua MS Visio, nhưng khi biết đến anh Draw.io, thì mình quên luôn 2 công cụ kia.
Rất mạnh mẽ, hỗ trợ nhiều hình khối, kéo thả cũng rất lẹ.
Chạy online, không cần cài đặt j hết. Cứ mở draw.io trên browser và sử dụng thôi.
Hoàn toàn miễn phí
Có thể lưu xuống local để lúc khác sử dụng tiếp, hỗ trợ export dưới dạng xml, html, và image
Có thể vẽ đủ thể loại các sơ đồ thiết kế hệ thống, template cực kì phong phú.
Đây là 1 workflow mình vẽ chơi.
2.4 Bizagi
Phần mềm này là một phần mềm thiên về vẽ các mô hình, tài liệu BPMN.
Khá là dễ sử dụng, cảm giác nó rất giống với các phần mềm office. Hỗ trợ xuất sang các tài liệu như word, PDF, Visio, và tool này được sử dụng free nha
Tìm hiểu thêm về BizAgi tại: https://www.bizagi.com/
2.5 Microsoft Visio
Ứng dụng này thì đến 2019 khi làm việc tại VNPAY mình mới sử dụng, và sài ẻm suốt 2 năm làm việc tại đây.
Đây là một ứng dụng giúp bạn xây dựng nên những bản vẽ vô cùng trực quan cùng với những bộ template có sẵn, do đó bạn sẽ không tốn quá nhiều thời gian để xây dựng nên những bảng vẽ Activity, Diagram, …
2.6 Giấy A4 và bút
Một trong những công cụ mình không thể thiếu để vẽ đó là Giấy A4 và bút, mình hay chôm giấy A4 từ máy in của công ty, sau đó dùng để phân tích, vẽ phát họa các idea, các sketch cơ bản, hoặc đơn giản là ghi ra những ý trong bộ checklist.
Mình nghĩ khi là 1 BA, thì đây là một công cụ cực kì cần thiết, bởi vì khi sử dụng giấy và bút, mình nghĩ gì là viết, vẽ ra liền… để có thêm thời gian nghĩ về những ý khác.
3. Tool ghi idea/brainstorm
3.1 Gloomaps.com
Tool này mình mới lượm nhặt được cách đây 3-4 tháng, thực sự rất thích tool này vì nó thuộc dạng tool vẽ sitemaps cơ bản, chỉ cần ghi vài từ trên các thẻ card, xong nhấn Save thì sẽ xuất ra 1 URL, có thể share bất kì ai xem. Không cần tạo tài khoản, không cần đăng nhập, và hoàn toàn free. Và cực kì dễ dàng export ra pdf, png, xml
Mình hay dùng công cụ này dưới dạng là ghi các idea, các đại ý mà mình đang tập trung chú ý phân tích, từ đó dựa theo kiểu cây thư mục, phát triển thêm ý.
Và dễ dàng drag & drop các thẻ card sang vị trí khác.
Tìm hiểu tool tại: https://www.gloomaps.com
Ngoài tool này thì trước kia mình cũng có sử dụng các tool mindmap, nhưng vì phải tốn công đăng nhập, bị giới hạn như export file các kiểu thì mình từ bỏ, và chuyển sang sử dụng luôn gloomaps. Thấy tool nào tiện với bản thân thì sử dụng thôi. 😀
3.2 Giấy, bút:
Cũng là một trong những công cụ mình cực kì hay dùng để ghi các đại ý, idea để phân tích các tính năng trong phần mềm.
3.3 Google.com
Thỉnh thoảng bí ý tưởng, hay phân tích bị bí, hoặc gặp domain mới thì mình hay dùng anh Gu Gồ để tìm giải pháp.
3.4 Công cụ Sticky Note
Không cần phải cài đặt gì hết khi bạn đang dùng Windows 10, nhanh chóng để mở lên và ghi note thật nhanh vào, hoặc có thể ghi liền một thông tin gì được nghe. Hoàn toàn miễn phí, dễ sử dụng, linh hoạt với nhiều màu sắc khác nhau.
4. Tool capture/record
4.1 FSCapture
Trước kia khi còn dùng MacOS thì mình hay dùng ScreenFlow, nhưng khi chuyển sang windows lại thì mình dùng FSCapture.
Cái mình thích ở tool này đó là công cụ hỗ trợ quay screen rất lẹ, có hỗ trợ tổ hợp phím để bật lên quay lẹ, và tool hoàn toàn free, có thể quay màn hình, thu âm từ Micro, hoặc thu âm từ trong desktop.
Và thường mình dùng công cụ này để ghi lại những bug xảy ra mà chỉ có quay lại màn hình mới thấy, chứ screenshot thì không thấy, do đó nhu cầu của mình chỉ quay và lưu lại thôi, nên tool này không có công cụ chỉnh sửa cũng là không có quá thiếu với mình.
Thực tế tool này cũng có hỗ trợ phần screenshot, nhưng mình có dùng 1 tool khác đã quen nên mình dùng đúng tính năng screen recorder của FScapture thôi.
4.2 Greenshot
Greenshot là công cụ tình cờ search trên google, và download về dùng thử. Nhưng mình cực kì ưa thích tool này.
Có thể tùy chỉnh bộ tổ hợp phím tắt để mở tính năng screenshot rất nhanh, từ đó khi gặp bug hay cần ghi lại 1 hình ảnh trên desktop, mình chỉ cần nhấn Alt + 3 là có thể kéo và ghi lại khu vực cần ghi.
Ngoài ra có những action ví dụ như hover vô button thì button đổi màu, thì kha khá nhiều tool screenshot khó có thể ghi lại được khoảnh khắc này, vì khi bật tool lên thì hiệu ứng hover bị mất. Nhưng tool này thì lại không bị mất, hoàn toàn có thể ghi lại nhanh chóng.
Ngoài ra các tính năng khác như vẽ hình ảnh tròn, chữ nhật, mũi tên, line, text cũng giống như những tool edit image khác.
Nhưng có hỗ trợ phần đánh số thứ tự rất nhanh, đặc biệt mình hay dùng để đánh thứ tự từng bước trong một hình ảnh khi xây dựng guideline hoặc demo script.
Tool này hoàn toàn free, có thể download tại đây: https://getgreenshot.org/
5. Tool testing
Thật ra để kể về tool testing thì khá là nhiều, tùy thuộc vào từng loại test mà dùng tool khác nhau, nhưng dưới đây là một số tool mình hay dùng và mình nghĩ là 1 BA cũng có thể dùng để hỗ trợ cho việc phân tích.
5.1 Email
Thường mình test các trang web mình sẽ không dùng email thật để test, mà sử dụng mailinator.com như là một nơi để nhận email.
Cái lợi của mailinator đó là không cần phải đăng ký tài khoản hay đăng nhập gì hết, mà còn free nữa chứ.
Chỉ đơn giản 3 bước. Truy cập mailinator.com, gõ phần mail muốn dùng, enter và check mail. Không cần đăng nhập, có thể dùng với hàng trăm/hằng ngàn email khác nhau mà không phải tốn phí.
Email ở mailinator sẽ bị xóa sau vài giờ, do đó ta không cần tốn công phải xóa những email đã được gửi đến để test.
Nhưng mailinator có thể sẽ bị 1 số nhà cung cấp lớn chặn, ví dụ như facebook, google,… do đó ta sẽ chuyển qua dùng email 10 phút. (search mail 10 phút trên gg là ra đầy)
Hoặc bị chặn luôn, thì mình lại dùng email với domain cá nhân và đăng ký thông qua zoho… ví dụ như email: [email protected] với phần đuôi phía sau là domain mình mua riêng. Hoặc mua mấy domain free 1 năm rồi tạo mail cá nhân bằng zoho cũng free nốt.
Tương tự đó, bạn cũng có thể sài sdt trên mạng free nếu cần nhận OTP qua sddt như cách sài email 10 phút nhé…
5.2 Audit của DevTool google chrome
Audit hay được gọi là tool Lighthouse, có sẵn trong chrome browser. Dùng để phân tích một trang web với performance, accessibility, SEO, PWA, Best Practices. Nhằm để biết được trang web mình đang phân tích như thế nào, từ đó lên được biện pháp, cũng như phân tích thêm về trang web để giúp cho chất lượng trang web tốt hơn.
Chỉ cần bật devtool lên (Inspect) => xong chọn tab audit => Chọn type cần analyst => click button analyst => là xem được kết quả.
5.3 Wappalyzer
Đây là một extension của google chrome, tool này là một công cụ có thể giúp mình biết được website mình đang xem thuộc nền tảng nào.
5.4 Chuyển file nhanh từ device này sang device khác.
Công cụ mình hay dùng đó là dropbox, mình cài app dropbox trên device, và khi có gì cần chuyển, mình đẩy lên thư mục ở dropbox, và tải xuống ở một nơi khác.
Mình thấy nhiều bạn hay dùng zalo, facebook để chuyển hình screenshot từ điện thoại qua desktop, nhưng hình ảnh dễ bị mất chất lượng.
Nhưng lưu ý khi dùng dropbox, tránh để chế độ tự động sync nha, không khéo hình nóng của bạn up lên dropbox chung của công ty hay sao đó thì lại cháy hết mắt của mọi người. 😀
Hoặc mình cũng hay up lên drive, và share bằng URL để cho người khác có thể xem file của mình.
6. Call/trao đổi công việc
Phần này chủ yếu là để share một số tool mình hay dùng, vì tool để trao đổi là một trong những công cụ buộc BA phải biết, tùy thuộc vào team, dự án, khách hàng mà sử dụng khác nhau.
Dưới đây là những tool mình hay dùng:
Zoom: Hỗ trợ call meeting, với tính năng share màn hình mạnh mẽ, hỗ trợ đa nền tảng.
Skype: Call meeting theo nhóm hoặc 1/1 khá tốt, share màn hình.
GG Meet
Facebook/workchat
Zalo: Chủ yếu là nhắn tin, call video 1/1
Slack: Chat trong công việc là nhiều, hỗ trợ tạo nhiều kênh nhỏ để trao đổi công việc lẹ.
Lời cảm ơn
Cảm ơn các bạn đã theo dõi hết bài viết của mình nhé. Có gì để lại comment để mình biết lời bình luận của các bạn với nhé.
Thời gian vừa rồi mình có tìm hiểu cách để nội dung của một trang web có thể tiếp cận với các đối tượng người dùng khuyết tật như bị khiếm thị, khiếm thính, suy giảm vận động…
Và chuyên mục này mình sẽ chia sẻ những kiến thức mình đã tìm hiểu được, làm sao người khuyết tật tiếp cận được với sản phẩm của bạn, cách bạn đưa trang web tiếp cận với các đối tượng khuyết tật.
TỔNG CHUNG CHUYÊN MỤC NÀY MÌNH SẼ CÓ 3 PHẦN
+ Phần 1: Hiểu về WCAG
+ Phần 2: Cách người khuyết tật tiếp cận với website của bạn
+ Phần 3: Lộ trình đưa website đến với người khuyết tật
PHẦN 1: HIỂU VỀ WCAG
1. WCAG là gì?
Để tìm hiểu về cách người khuyết tật tiếp cận với website, thì ta hãy tìm hiểu về bộ tiêu chuẩn WCAG để biết nó giúp gì cho việc tiếp cận nhé.
WCAG là một bộ tiêu chuẩn trong xây dựng website, được tổ chức W3C đưa ra nhằm xác định cách làm cho nội dung Web dễ tiếp cận hơn với người khuyết tật.
Tài liệu chính gốc của WCAG tại đây nha: https://www.w3.org/TR/WCAG21/
2. 4 Nguyên tắc
Nó có 4 nguyên tắc chính đó là: perceivable, operable, understandable, và robust.
1. Perceivable
Các thành phần thông tin và User Interface phải được trình bày sao cho người dùng không chỉ là đọc mà có thể thông qua các thiết bị khác, người khuyết tật có thể cảm nhận được nội dung của thông tin.
2. Operable
Các thành phần về giao diện và navigation có thể hoạt động tốt. Web của bạn phải làm sao đó để thông qua các thiết bị như keyboard, nút ấn, … mà vẫn điều khiển được web của bạn 1 cách dễ dàng. Như cách thay đổi focus, cấu trúc của page, thời gian đọc và sử dụng nội dung, di chuyển từ module này sang module khác trên cùng 1 page mà người dùng có thể cảm nhận rằng họ đang ở vị trí đó của trang web của bạn.
3. Understandable
Các thông tin và operation của UI phải dễ hiểu, thiên về nội dung của trang web phải dễ đọc, dễ hiểu, điều hướng nhất quán, dễ đoán được hướng của điều hướng, giúp tránh lỗi hoặc có lỗi với các thông báo lỗi rõ ràng, …
4. Robust
Các nội dung cung cấp phải đủ mạnh để diễn tả từng thành phần một cách đầy tin cậy đến với user agents và các công nghệ hỗ trợ. Thông qua parsing, cách đặt name, role, và value cho các thẻ html, cách truyền tải status message .
3. Đánh giá qua 3 cấp độ
Và WCAG nó đánh giá các tiêu chuẩn (gọi là tiêu chí thành công) dựa vào 3 cấp độ (A-AA-AAA). Vì các tiêu chí thành công được tổ chức dựa trên tác động của chúng đối với thiết kế, cấp độ càng cao, thiết kế càng trở nên gò bó.
Cấp độ A – một số tác động đến thiết kế.
Cấp độ AA – tác động trung bình đến thiết kế
Cấp độ AAA – tác động cao đến thiết kế
Với 3 mức độ này, thì có thể cùng 1 thể loại tiêu chí, nhưng nó có 3 mức. Khi bạn vượt qua được cấp độ AA, nghĩa là cấp độ A của tiêu chí đã được đáp ứng. Và theo những tài liệu mình tìm hiểu được, thì khuyến nghị nên đạt đến level AA.
Để rõ hơn, thì xem thử ví dụ này nhé, trong Guideline 1.4 Distinguishable.
Tiêu chí thành công 1.4.1 – Use of Color – level A. Mục đích của Tiêu chí Thành công này là đảm bảo rằng tất cả người dùng có thể truy cập thông tin được truyền tải bởi sự khác biệt về màu sắc, nghĩa là bằng cách sử dụng màu sắc trong đó mỗi màu có một ý nghĩa được gán cho nó.
Tiêu chí thành công 1.4.3 – Contrast (Minimum) – level AA. Trình bày trực quan của văn bản và hình ảnh của văn bản có tỉ lệ tương phản ít nhất 4,5: 1
Tiêu chí thành công 1.4.6 – Contrast (Enhanced) – level AAA. Trình bày trực quan văn bản và hình ảnh của văn bản có tỷ lệ tương phản ít nhất là 7: 1
Như ví dụ trên ta thấy chỉ đạt được level A, thì khi xem trang web này trên 1 device ở 1 môi trường quá sáng, thì có thể sẽ không đọc được chữ do tỉ lệ contrast quá thấp, hoặc những người bị khiếm thị hoặc thiên về bị bệnh về màu cũng khó mà đọc được những text #FFFFFF trên nền #65A6BF trong môi trường bình thường. Còn khi thay đổi đến level AAA sẽ ít còn bị các vấn đề về contrast, nhưng có thể thay đổi nguyên bộ thiết kế, cũng như bộ màu trên trang web.
Từ đó ta có thể thấy là level càng cao thì càng khó đáp ứng, và sẽ vượt qua được level cao hơn, thì level thấp sẽ được đáp ứng.
4. Vì sao áp dụng WCAG lại quan trọng?
Bình đẳng không gian mạng cho tất cả mọi người
Người khuyết tật dễ dàng sử dụng
Tạo ra sự khác biệt lớn cho người dùng của bạn và có thể giúp ngăn chặn các vấn đề hoàn toàn có thể tránh được.
Thu hút một lượng người đọc/tham gia khá lớn.
Giúp đáp ứng các nhu cầu và đảm bảo khách truy cập trang web có trải nghiệm tốt nhất có thể khi truy cập.
Khảo sát về người khuyết tật Canada báo cáo rằng hơn 80% người khuyết tật sử dụng ít nhất một thiết bị hỗ trợ. Do đó để các thiết bị hỗ trợ đọc được nội dung website của bạn, thì nên đảm bảo được các tiêu chí thành công của WCAG.
Cảm ơn bạn đã đọc hết phần này của mình, cùng đón xem 2 phần tiếp theo nhé.
Bài blog này được viết thời điểm mình gặp Khoa và Linh tại 1 quán CF ở quận 9 vào đầu tháng 4/2019. Được Niviki.com (Khoa) phỏng vấn và chia sẻ đến mọi người, nay mình đăng lại trên blog mình để mọi người cùng đọc nhé.
1. Giới thiệu
Hoàng Phan là bạn đại học của mình, hiện tại Hoàng đang là Business Analyst tại Kyanon Digital (2018-2019). Thực ra gọi là phỏng vấn nhưng đây cũng như buổi nói chuyện bình thường giữa mình với Hoàng thôi. Trong buổi nói chuyện còn có Linh Nguyễn nữa.
2. Nội dung
Khoa: Hoàng có thể giới thiệu bản thân với bạn đọc trên NIVIKI.COM được không?
Hoàng: Chào mọi người, mình là Hoàng hiện tại mình đang làm ở vị trí BA trong khoảng thời gian 6 tháng. Hết rồi 😀
Khoa: BA là công việc đầu tiên của Hoàng hay là trước đó Hoàng có làm gì không?
Hoàng: Trước đó mình có làm ở vị trí Quality Control (QC) khoảng 8 tháng, và có một thời gian mình làm freelance ở mảng frontend.
Khoa: Được biết Hoàng là Đội Trưởng đội Công tác Xã hội UIT có đúng không? Vậy thì kinh nghiệm làm Đội Trưởng đội Công tác Xã hội UIT có giúp ích gì cho công việc QC không?
Hoàng: Mình thấy rằng việc rèn luyện kỹ năng mềm, tham gia các tổ chức sự kiện thì nó giúp cho mình tự tin, trình bày nội dung rõ ràng và dễ hiểu hơn. Trước đó mình nói thì nó hơi bị vòng vòng. Sau khi mình tham gia các hoạt động dự án tình nguyện thì mình làm quen với việc trình bày nội dung của các buổi tình nguyện đến cho Tình Nguyện viên, chính quyền địa phương và từ đó dẫn đến khi đi làm mình cũng làm tốt làm việc ở QC và cả BA. Khi gặp khách hàng, dễ nói chuyện hơn, mình trao đổi với các thành viên trong team của mình như là dev, designer cũng sẽ tốt hơn.
Khoa: Hoàng có thể mô tả sơ sơ QC là làm gì không?
Hoàng: QC là đảm bảo cái mà dev làm ra chạy đúng requirement của khách hàng. Đảm bảo cho phần mềm chạy tốt hơn không có quá nhiều lỗi (phần mềm nào chẳng có lỗi :D).
Khoa: Phần mềm phải làm xong rồi mới kiểm tra lại hay là?
Hoàng: Thực ra thì dựa vào requirement, mình xây dựng ra những bộ test case
Khoa: Là viết test case trước khi dev làm
Hoàng: Không, cùng lúc với dev làm.
Khoa: Công việc đó (QC) Hoàng làm khoảng 8 tháng xong rồi nghỉ thì tại sao lại không tiếp tục công việc đó?
Hoàng: Thứ nhất là công ty quá xa vị trí mình ở. Thứ hai là ở trường mình có nhiều bài tập đồ án tốn khá nhiều thời gian cho nên mình không đảm bảo được thời gian để đi làm. Mình cũng đang muốn công việc của mình nó thiên về giao tiếp với khách hàng nhiều hơn nên mình quyết định nghỉ một thời gian để tìm hiểu về vị trí BA
Khoa: Vậy là QC sẽ không có nói chuyện gì với khách hàng đúng không?
Hoàng: Cũng có nhưng mà nó ít so với BA
Khoa: Ủa, vậy sẽ nói chuyện gì với khách hàng
Hoàng: Thường khách hàng sẽ hỏi là quy trình kiểm thử như thế nào? Sử dụng tool gì để test. Khách hàng có thể track bug ở đâu, trao đổi về Report Testing.
Khoa: Có khi nào khách hàng tự báo bug luôn không?
Hoàng: Có. Tất nhiên là sẽ không có phần mềm nào hoàn chỉnh 100%, sẽ luôn có bug. Thì khi khách hàng gặp Bug có thể đăng bug lên, QC có thể cùng trao đổi khách hàng: bug đó thỉnh thoảng bị hay là hay là luôn luôn xảy ra. Hay là do yếu tố bên khách hàng như mạng internet, thiết bị.
Khoa: Vậy là QC sẽ là người tìm ra nguyên nhân lỗi chứ không phải dev hả?
Hoàng: QC sẽ vào cái bug đó và làm lại xem có gặp bug đó hay không, gọi là reproduce Bug. Sau đó, QC sẽ liên hệ với dev để coi thử là bug đó có có thực sự là do dev hay là do vấn đề nào khác.
Khoa: Còn trường hợp cái bug đó không được không làm lại được?
Hoàng: Ừ thì mình cũng có một trải nghiệm như sau. Có một cái lỗi mà 7 người trong team mình đều không reproduce lại được. Thì mình có trao đổi với khách hàng là cứ để cái bug đó ở trong backlog. Một thời gian thì sau khoảng 2, 3 sprint thì cũng không gặp lại nó.
Khoa: Hoàng có nói là Hoàng thích làm BA vì được nói chuyện nhiều với khách hàng thì từ đâu mà mày có suy nghĩ như vậy. Tức là Hoàng tìm hiểu công việc BA ở đâu để quyết định chuyển công việc như thế?
Hoàng: Đầu tiên mình được bạn Khoa giới thiệu, sao không thử mảng BA đi. Vì Khoa biết mình làm Công tác Xã hội thì đi Khoa nghĩ là BA cũng hợp với mình.
Thực chất thì lúc đó cũng không biết 100% là hợp hay không nhưng mà mình đã quyết định bỏ thời gian ra tìm hiểu về vị trí này khoảng 3 tháng: Mình bắt đầu tìm hiểu là vị trí này công ty nào tuyển, tuyển có nhiều hay không, range lương như thế nào.
Rồi mình đọc các job description thì mình mới coi là mình thiếu cái kỹ năng gì từ đó thì mình đi học những cái mình thiếu
Khoa: Vậy cái thiếu đó là gì?
Hoàng: Thứ nhất là UI/UX, nhưng mình lợi cái là có tham gia Công tác Xã hội, biết được design, một ít về UI/UX và từng tìm hiểu rồi.
Khoa: Design đó có kỹ không, hay cái mức độ như thế nào?
Hoàng: Như là vẽ wireframe thôi, thấy design nó hợp lý, thân thiện với người dùng, hợp lý về UX, còn không nhất thiết phải quá đẹp hay gì đó. Thường thì muốn đẹp thì vẽ wireframe, đề xuất xong designer sẽ thực hiện bản hoàn chỉnh hơn.
Khoa: Còn kỹ năng nào nữa không?
Hoàng: Thứ hai đó là kỹ năng sử dụng các tool vẽ use case như draw.io. Nó online free và tiện lợi, có thể export ra PNG, lưu xuống máy dạng XML rất tiện.
Cái này mình hay dùng để vẽ các User Case, biểu đồ khi làm đồ án ở Đại học. Ngoài ra mình còn biết thêm những tool khác như Visio của Microsoft, Lucidchart.
Kỹ năng nữa cũng rất quan trọng đó là kỹ năng giao tiếp. Mình giao tiếp tiếng Việt cũng ổn, thì mình sẽ làm việc tốt với các bên ở Internal team (Việt Nam Team). Nhưng khách hàng đa số là người nước ngoài nên mình cần phải improve thêm về Tiếng Anh. Hiện tại mình chat với khách cũng tốt, nhưng về phần giao tiếp (nói chuyện trực tiếp) tiếng Anh còn hơi kém.
Kỹ năng quản lý thì mình tham khảo thêm về cách sử dụng các tools như Jira, TFS, đọc nhiều tài liệu về quản lý dự án, quản lý task để có sẵn lý thuyết, khi đi làm mình áp dụng luôn, đỡ tốn thời gian tìm hiểu khi đi làm.
Và tham gia các group trên facebook, cộng đồng BA để đọc những bài viết, những kinh nghiệm những anh chị đi trước đã trải qua, và chia sẻ lại để improve khả năng phân tích và giải quyết vấn đề.
Khoa: Hoàng thấy kỹ năng nào của QC giúp ích được cho BA
Hoàng: Thứ nhất là trong BA có QC. Cái mà mình thấy hay dùng nhất của QC là UAT (User Acceptance Testing – Kiểm thử chấp nhận). Và có thêm các kỹ năng về document, tức là mình đã làm quen với việc đọc document, requirement và xây dựng các test case tỉ mĩ từ khi làm QC, nên qua áp dụng cho BA cũng tốt hơn.
Khoa: Ủa vậy Hoàng có thể nói kỹ hơn sự khác nhau giữa test casse và UAT
Hoàng: Test case là mình test chi tiết từng trường hợp hơn. Còn UAT là kiểm thử chấp nhận. Tức là mình kiểm tra những cái case người dùng sẽ hay dùng nhất, phần mềm có đáp ứng cho tiêu chí chấp nhận và có sẵn sàng cho sử dụng không. Mình thường thực hiện nó thông qua một check list, có những tính năng mà cần người dùng UAT nhiều, thì nhờ các anh chị trong công ty vô thử, và chạy thử với mỗi người 1 trường hợp khác nhau, và xin feedback từ họ. Trước UAT là QC đã đảm bảo phần mềm chạy tốt rồi và UAT mình test lại để cho một user dùng những tính năng hay dùng nó chấp nhận được là ổn.
Khoa: Tức là UAT mình có thể đưa cho khách hàng coi và họ hiểu được, đúng không?
Hoàng: Ừm, đúng rồi. Họ xem và hiểu thông qua checklist mình xây dựng.
Khoa: Còn test case nó thiên về kỹ thuật hơn?
Hoàng: Đúng rồi, test case đôi khi kiểm tra những trường hợp rất là lắc léo luôn.
Khoa: Thì công việc mới của Hoàng thì Hoàng apply như thế nào
Hoàng: Lúc mình đi làm thì đã có 8 tháng kinh nghiệm QC, nhưng mình chấp nhận apply vị trí intern 2 tháng.
Ban đầu mình làm ở BA dạng pre-sale. Đầu tiên mình tham gia phân tích các tool như CRM, HRM các tool về quản lý nhân sự, khách hàng. Sau đó dựa vào tuỳ yêu cầu của khách hàng để đề xuất giải các tool phù hợp hoặc xây dựng thêm tính năng theo mong muốn của khách hàng.
Sau đó mình đề xuất với sếp của mình xin chuyển sang IT BA và được sếp đồng ý chuyển sang dự án mới với vai trò IT BA sau 2 tháng intern.
Khoa: Thì dự án mới đó là dự án đã có sẵn?
Hoàng: Dự án đó đã có từ trước nhưng chạy chưa tốt, khách hàng muốn nâng cấp. Khách hang của dự án này bên Sing.
Linh: Khi join vào một dự án có sẵn như vậy thì việc học cái domain knowledge có khó không?
Hoàng: Thật ra thì may mắn là dự án này cũng liên quan đến tình nguyện xã hội luôn, mà mình đã có 3 năm sinh hoạt ở Đội Công tác Xã hội nên cũng có khá nhiều kinh nghiệm về thể loại, nên mình rất nhanh hiểu về domain này. Còn những tính năng thì cũng chưa quá phức tạp, nó dạng như blog, và chạy các chiến dịch liên quan đến việc truyền thông điệp.
Linh: Theo Hoàng thì làm việc với khách nước ngoài vậy có khó khăn gì không?
Hoàng: Theo mình nghĩ là tiếng Anh là điểm yếu nhất của mình. Đôi khi khách hiểm lầm ý mình, và cần phải vẽ sơ đồ để giải thích. Thứ hai là làm việc online với khách nên việc chờ đợi làm mình trĩ hoàn nhiều việc khác.
Khoa: Khó khăn với khách hàng là vậy, còn khó khăn với team dev, designer như thế nào?
Hoàng: Designer là bên team Singapore luôn, nên được coi như là trao đổi với khách hàng. Còn team Dev, QC thì hiện tại mình thấy chưa có khó khăn với bản thân trong dự án này, vì mình cũng có thời gian làm Dev và cả QC nữa, nên khi truyền đạt về requirement thì mình share theo hướng của Dev và QC luôn.
Khoa: Quy trình cho 1 tính năng mới thì như thế nào?
Quy trình hiện tại: Khách hàng sẽ đăng user story mô tả tính năng họ muốn làm ở đơn giản nhất. Và mình sẽ phân tích và đưa ra đề xuất, khi đã confirm tất cả thì mình document lại thành requirement và truyền đạt đến Dev + QC.
Khoa: Khi khách hàng đăng user story vậy, Hoàng có thường say no không?
Hoàng: Có chứ. Ví dụ mình làm một cái popup, có rất nhiều cách để tắt popup. Thì mình có thể để xuất cho khách vì sao nên dùng dấu chéo (x) để tắt. Popup to quá thì mình giải thích có thể gây khó chịu cho user, mình nên làm sao để thân thiện với user hơn.
Ví dụ khách có nghĩ ra một tính năng nhưng khi trao đổi với team dev mà tính năng đó quá phức tạp thì mình có thể deal lại với khách để cân nhắc độ ưu tiên và mức độ xây dựng của tính năng này.
Khoa: Tức là mình có thể thảo luận với team dev, desinger về tính năng, nhưng BA vẫn là người quyết định cuối cùng và chốt với khách hàng.
Hoàng: Đúng rồi. Đa số các tính năng mình sẽ được tự chốt với khách hàng.
Khoa: Khi dev làm xong thì BA là người làm UAT?
Hoàng: Đúng rồi, nhưng trước đó là có team QC kiểm tra thật kỹ luôn. Và mình cũng trao đổi phần kiểm thử với QC.
Khoa: Vậy là khi khách hàng pass cái UAT thì có 2 trường hợp: có thể khách hài lòng hoặc không. Vậy có trường hợp nào sau UAT mà khách muốn chỉnh sửa không?
Hoàng: Có chứ. Vì mình còn non kinh nghiệm nên thỉnh thoảng cũng có một số trường hợp. Cũng cái ví dụ popup, mình có trao đổi với anh frond-end là làm sao cho show popup nó mượt đúng ý khách hàng. Nhưng bên khách cũng chưa hình dung được. Nên mình cứ discuss là cứ làm đi, khách họ sẽ có feedback sau.
Khoa: À, tức là nếu có chỉnh sửa cũng những thứ lặt vặt thôi, vì hầu như đã trao đổi với khách lúc đầu rồi.
Hoàng: Um, vì dự án lần này khách khá quan trọng về UI/UX nhưng mà design họ gửi chỉ có mobile & desktop thôi. Có thể ipad nó chưa tốt nên BA có thể linh động để trao đổi phần này với khách hàng. Có thể làm trước luôn rồi đưa khách hàng nhận xét vì mình biết là những cái này sửa tốn rất ít thời gian so với tổng thời gian xây dựng tính năng.
Khoa: À, thà là deal trước với khách hàng những cái core feature chính, còn mấy cái lặt vặt cứ làm rồi show lên cho khách nhận xét
Hoàng: Um, đúng rồi.
Khoa: Ngoài team phát triển sản phẩm, BA có giao tiếp với những team khác như sale, marketing gì không?
Hoàng: Những công ty và team khác mình không biết. Nhưng hiện tại dự án này team mình không có giao tiếp với team sale, marketing nữa. Có thể mấy anh Sếp ở trên lo rồi. hehee
Khoa: Vậy sắp tới Hoàng có dự định học gì để cải thiện kỹ năng BA của mình không.
Hoàng: Thứ nhất là tiếng Anh giao tiếp để tự tin với khách hàng nước ngoài rồi. Ngoài ra mình dự định học một khoá về BA để biết rõ chuẩn quy trình BA là như thế nào.
Khoa: Hoàng có lời khuyên gì cho những bạn muốn làm BA không? Có nên theo con đường của Hoàng là làm QC rồi chuyển qua BA, hay intern thẳng BA luôn?
Hoàng: Mình phân làm 2 đối tượng. Đối tượng thứ nhất là chưa tìm hiểu gì về BA thì nên apply QC để hiểu về quy trình, cách làm việc trong team, một số kỹ năng về document sau đó mình làm BA tốt hơn.
Còn những bạn có khả năng tự học, kỹ năng mềm tốt, giao tiếp tốt thì nên appy luôn vị trí intern BA tốt hơn.
Khoa: Một số bạn sẽ nói là những kỹ năng mềm khi tham gia những câu lạc bộ, Công tác Xã hội hay Đoàn-Hội gì đó thì tốn thời gian không có ích gì thì Hoàng có lời khuyên gì cho những bạn đó không?
Hoàng: Thực ra thì không nhất thiết phải tham gia. Các bạn còn nhiều cách khác như là đi làm thêm như làm trợ giảng ở các trung tâm tiếng Anh. Tham gia những công việc như là dẫn khách du lịch, đi tour. Vừa biết cách nói chuyện với khách hàng vừa tăng khả năng tiếng Anh của bản thân.
Công việc đơn giản hơn là các bạn có thể làm ở những quán cà phê với vị trí bộ phận tiếp tân, phục vụ để hiểu cách làm hài lòng khách hàng, cách nói chuyện với khách hàng.
Bởi vì khi làm BA sẽ có nhiều trường hợp mình rất là khó chịu với khách hàng thì mình phải học cách kiềm chế bản thân.
Nhưng mà tham gia rõ câu lạc bộ trường học là một trải nghiệm rất là tốt. Mình thấy là nó cho mình rất nhiều thứ luôn á. Ví dụ như mình là Đội trưởng Đội Công tác Xã hội nên mình sẽ có những cơ hội đến gặp trực tiếp địa phương, làm việc với chính quyền địa phương để trao đổi về lịch trình của các chương trình tình nguyện.
Mình cũng là người quyết định lịch trình của các hoạt động này và mình biết cách làm các quy trình riêng cho từng địa phương tại vì mỗi địa phương sẽ có cái cách làm việc khác nhau
Khoa: Tức là nó cũng na ná giống như BA về cái quy trình giống như là mình làm việc với khách hàng là là nói chuyện với chính quyền địa phương còn làm việc với team phát triển sản phẩm là quay về trường xin giấy tờ.
Hoàng: Đúng rồi đó.
Khoa: Cảm ơn Hoàng về buổi nói chuyện, với những bạn muốn trao đổi thêm với Hoàng thì có thể liên hệ qua kênh nào nhỉ? đã update mới: [email protected] (email mình nhé)
3. Kết
Qua buổi phỏng vấn trên, mình nghĩ bạn cũng có cái nhìn tổng quan về công việc của QC và BA rồi. Một số kỹ năng không thể thiếu của BA: Giao tiếp, phân tích, xử lý vấn đề, quản lý.
Ngoài ra khi chuyển sang một vị trí mới mà chưa có kinh nghiệm gì ở vị trí mới đó thì thử intern cũng là lựa chọn không tồi.
Thứ ba là nhiều khi nghề chọn người cũng đúng bạn à. Lúc trước thấy mình code dạo iOS, Hoàng cũng apply thử vị trí iOS nhưng… rớt rồi chuyển sang làm QC, sau đó mới sang BA. Nếu không có lần rớt đó, chắc giờ Hoàng nó cũng làm iOS dev rồi chăng?