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
Lúc mình làm BA tại công ty, có rất nhiều bạn Business Analyst mới dùng Balsamiq hay hỏi mình tải ở đâu, rồi cách crack công cụ này :D, sẵn dịp mới mở lại vụ viết blog, nên chia sẻ anh em Balsamiq Mockup miễn phí (key) nha.
Nhưng trước hết mình phải biết được Balsamiq Mockup là công cụ gì cho anh em nào chưa biết nhé.
Balsamiq wireframe là gì?
Đây là một công cụ mà giúp xây dựng nên những giao diện web/app dưới dạng wireframe bằng cách kéo thả những widget đã được tạo sẵn. Giao diện thì bao dễ sài, dùng vài lần là sài dễ như ăn chơi. Anh em có thể tìm thêm khóa học của mình về Balsamiq để học nhé, hướng dẫn chi tiết từ A tới Z luôn.
Trước kia khi mình dùng và hay kiểm tra trang web của Balsamiq thì tên của công cụ này là Balsamiq Mockup, nhưng hiện nay đã đổi qua tên mới là Balsamiq Wireframe.
Để hiểu hơn về Wireframe, mockup, sketch, prototype thì anh em đọc thêm bài này nhé:
Balsamiq có 2 phiên bản, phiên bản desktop và cloud – và 2 phiên bản đều có trả phí. Nhưng trên các diễn đàn chia sẻ cách crack rất nhiều, riêng mình thì tìm được một số key từ một số diễn đàn và dùng thử, mình thấy rất tốt nên chia sẻ lại cho anh em sài phiên bản Desktop – Version Balsamiq Mockup 3.
Cảm ơn anh em đã đọc bài viết của mình nhé, hi vọng bài viết này sẽ giúp cho anh em sài được Balsamiq miễn phí nha. Nếu yêu thích bài viết của mình thì lâu lâu ghé thăm blog của mình nhé. Cảm ơn ae 😀
Đọc thêm về cách chia sẻ wireframe/mockup đến khách hàng khi làm Business Analyst nhé
Mình là một user của Adobe XD, phải nói là cực kỳ thích sài ẻm. Bắt đầu sử dụng từ phiên bản Beta đầu tiên tên ”Adobe Experience Design CC” vào tháng 03/2016, và còn sài đến hiện tại với tên chính thức là Adobe XD.
Mình sài Adobe XD từ việc làm đồ án thời sinh viên, đến khi đi làm thì sài ẻm trong công việc hằng ngày, đặc biệt là với công việc Business Analyst. Và ngay cả những lúc làm freelancer với anh em cũng mang XD ra để thiết kế dạng product design cho các dự án của team. Và cái hay của Adobe XD là được sử dụng miễn phí với phiên bản Starter Plan.
Nên khi đi làm việc mình sử dụng quen và thích sài XD là một chuyện thường tình. Trong lúc làm dự án với anh em trong công ty, mọi người thì sài Axure, mình thì sài XD nên không đồng bộ được, nên mình lên chị google tìm cách đồng bộ các source từ 2 bên với nhau – chưa kịp tìm được cách đồng bộ source, thì vô tình mình lượm được mẹo review wireframe/mockup dễ hơn khi kết nối XD và Axure Cloud.
Lưu ý là bài viết này dành cho những bạn thích sài XD (miễn phí) và muốn sử dụng thêm mẹo này, thay vì sài những công cụ có sẵn như Figma (miễn phí và trả phí), Axure (trả phí),…hoặc chính bản gốc Axure XD Share (bị giới hạn cho phiên bản Starter)
Tình huống review wireframe/mockup mà Business Analyst thường dùng.
Dưới đây là những tình huống review wireframe/mockup hay gặp:
Gặp khách hàng/đồng nghiệp (KH/ĐN) trực tiếp, mở file lên để review
Gửi nguyên file source cho KH/ĐN để họ mở trên phần mềm của họ và xem (điều không được hay đó là có thể khách hàng có thể không sài chung phần mềm với mình, do đó họ không mở được luôn, nên sẽ có trường hợp sài cách thứ 3 và thứ 4 dưới đây)
Export file hình ảnh/pdf và gửi cho khách hàng để họ xem và đánh giá trên hình ảnh, có thể là note comment ngay trên hình ảnh luôn.
Copy hình bỏ vô file word offline hoặc docs online cho khách hàng xem và review với tính năng comment trên word/docs (hoặc tool công cụ như excel,…).
Export ảnh ra và copy ảnh lên phần mềm cho phép review online (Ví dụ như Axure, Invision,…)
Sử dụng tính năng sharing and reviewing của công cụ đó (Ví dụ như Adobe XD Share designs and collaborate, Balsamiq sharing and collaborating) – nhưng công cụ này sài nhiều có trả phí.
Đối với bản thân mình thì từng sử dụng tất cả các cách trên, và mình dần dần chuyển đổi dần qua cách mới tốt hơn. Và mẹo mình chia sẻ ở bài viết này chính là cái mình thấy tiện và dễ sử dụng nhất, do đó chia sẻ cho anh em để dùng thử, biết đâu lại thích như mình.
Note: Bạn đọc nào chưa sài 1 trong 6 cách trên thì comment ở dưới, mình viết hướng dẫn cụ thể cho nhé.
Mẹo mà Hoàng hay sài
Đây là một tính năng trên Axure Cloud – gọi là Publishing Artboard Projects, tính năng này giúp user publish source từ các phần mềm khác: Sketch, Adobe XD, Figma, lên Axure Cloud và chia sẻ cho những thành viên khác, và có cả chia sẻ public – được comment không cần tài khoản Axure Cloud (Đây là điểm khác so với Figma).
Đặc điểm:
Hoàn toàn miễn phí (adobe XD starter + Axure Cloud)
Được sài XD theo mong muốn của bạn (giống mình, thay vì sài các tool tương tự)
Bước 5: Trong XD, chọn artboard muốn chia sẻ để publish lên Axure Cloud.
Bước 6: Trên top menu, chọn Plugins > Axure > Export Selection to Axure Cloud. (Lưu ý là phải mở app Axure Cloud trước nha, không mở nhiều khi lỗi không hoạt động được)
Bước 7: Trong Axure Cloud App, bạn chọn workspace và artboard project mà muốn publish lên. Nếu chưa có sẵn thì bạn tạo mới “Create New Project” và đặt tên dự án “Project Name” – và lưu ý bạn chọn Project size cho phù hợp nhé, ví dụ thiết kế ở size Iphone 12 thì chọn iPhone 12 (390 x 844)
Bước 8: Nhấn Upload, sau đó chia sẻ cho KH/ĐN để comment – và ở đây bạn cũng có thể chia sẻ với mật khẩu (Access Code) hoặc dạng private cho tài khoản cụ thể.
Bước 3: Chấm 1 điểm bằng click chuột trái vào vị trí muốn comment
Bước 4: Add comment
Bước 5: Nhấn Post
Bước 6: Bạn có thể comment bởi đăng nhập hoặc a guest (điền email bất kỳ)
Bước 7: Team review tất cả, sau đó BA hoặc các bên khác có thể update lại wireframe/mockup
Bước 8: Mark Resolved các comment nào đã được giải quyết, hoặc delete comment.
Áp dụng cho chia sẻ Wireframe từ Balsamiq.
Cơ bản thì mình copy image từ Basamiq qua XD, rồi share lên Axshare để mọi người có thể thảo luận và comment trên đó. Các bước mình thường thực hiện như sau:
Bước 1: Chọn vùng cần copy trên balsamiq
Bước 2: Nhấn Command + C (trên MacOS) để copy vùng chọn. (Đọc thêm phần hướng dẫn export/copy image ở hướng dẫn ở balsamiq để biết thao tác trên Windows nhé, xưa mình nhớ phím tắt nó phải 3 nút lận mới copy được)
Bước 3: Nhấn Command + V (trên MacOS) để paste hình ảnh lên XD
Mình trình bày ở XD như sau:
Bước 4: Share lên Axure Cloud như hướng dẫn ở trên (Project Size thì chọn Auto Web), sau đó copy link gửi cho KH/ĐN
Phía trên là mẹo sử dụng Axure Cloud để chia sẻ wireframe/mockup đến ĐN/KH để dễ dàng review và comment cho một Business Analyst. Giảm thiểu chi phí cho cá nhân người sử dụng khi được sử dụng miễn phí cả Adobe XD Starter và Axure Cloud, khi mà công ty các bạn không/chưa hỗ trợ trả phí cho việc sử dụng phần mềm trả phí.
Dĩ nhiên có nhiều công cụ, tính năng tương tự nhưng đây là mẹo dành riêng cho Adobe XD Starter, đặc biệt là đối với các bạn thích dùng Adobe XD Starter giống mình.
Mấy nay mình hay đi cà phê gặp bạn bè này kia, xong nghe bạn bè đồn lương Business Analyst cao quá trời, mà còn nghe các bạn kể về những bạn trái ngành nghe lương cao bèn tìm cách chuyển qua làm BA, rồi đâu nghe mấy bạn đó mới qua làm fresher mà lương 1000$ rồi, nên mình cũng tá hỏa, chết xưa mình đi làm hố hả ta :v sao công ty trả mình fresher lương đủ sống thôi vậy.
Thế là Hoàng lên mạng đọc thử mấy bài về lương BA, đặc biệt là lương BA ở Việt Nam mình – nhưng mình thấy chưa đã, làm gì làm cũng tự tay khảo sát thì mình mới thấy đã. Nên mình quyết định tự đi collect data tay từ các bài tuyển dụng mà có để sẵn mức lương, và từ đó tính ra mức lương hiện tại BA ở VN mình như nào.
Cũng như là một thước đo mà để anh em biết được hiện tại lương Business Analyst trên thị trường như nào, mình có được trả cao hay thấp quá không? Mà từ đó đưa ra những quyết định phù hợp (dĩ nhiên còn xem ở công ty mình có những benefit khác không nữa nhé, ví dụ như ở công ty học được nhiêu thứ, thì có thể vẫn từ từ xem xét đến lương) – Vì mình biết rằng nhiều anh em cũng hay nhảy việc để được mức lương phù hợp với năng lực của mình lắm.
Lưu ý rằng số liệu này dựa trên tin tuyển dụng, sau khi bài này Hoàng cũng sẽ khảo sát thêm tối thiểu 100 anh/chị/bạn làm mảng BA về mức lương hiện tại để từ đó đưa ra số liệu nó chính xác hơn một tíu, và mình sẽ viết một bài khác để anh chị em đọc nhé. Form khảo sát nằm ở cuối bài nhé.
Collect Data – 112 tin tuyển dụng
Đây là bảng data mình collect của 112 tin tuyển dụng BA còn hiệu lực tại ngày 10/03/2022 từ các trang như: ITviec, TopCV, Careerbuilder.vn, Timviec365, Topdev, Vietnamworks. Ở đây mình có phân ra công ty nào, là cty product hay outsourcing, việc làm ở đâu, số năm kinh nghiệm yêu cầu, level yêu cầu, mức lương tối thiểu, mức lương tối đa, các kỹ năng cần có hoặc sẽ áp dụng để làm việc và các benefit thêm ngoài lương.
Bảng dữ liệu mình collect được.
Mình cũng có viết một bài về các kỹ năng khi làm BA theo tin tuyển dụng, bạn đọc xem khi làm một Business Analyst thì cần những kỹ năng gì nhé.
[…Link sẽ cập nhật sau..]
Kết quả lọc dữ liệu lương BA
Dưới đây là kết quả mình lọc được.
Tất cả kinh nghiệm/khu vực:
Mức lương thấp nhất: 7,000,000 VND
Mức lương cao nhất: 92,000,000 VND (level Senior)
Mức lương min trung bình: 20,641,237 VND
Mức lương max trung bình: 36,401,786 VND
Mức lương trung bình: 28,521,511 VND (khoảng 1240$)
Có 88/112 tin tuyển dụng cho vị trí BA làm ở công ty Product
Có 34/112 tin tuyển dụng cho vị trí BA làm ở công ty Outsourcing
Có 5/112 tin tuyển dụng vừa để bạn làm vị trí BA cho product/outsourcing
Đa số công việc được tuyển sẽ làm tại Hà Nội (46) và TP. Hồ Chí Minh (70), số lượng công việc remote rất ít – chỉ 2/112 tin tuyển, một số nơi khác HN và HCM vẫn tuyển BA như Cần Thơ, Đà Nẵng.
Nhìn chung thì số liệu này chỉ để thấy mức chung chung thôi, chưa thể hiện được nhiều, ta cần xem chi tiết hơn theo nhóm kinh nghiệm, thì con số nó sẽ chi tiết hơn nha.
Lương theo kinh nghiệm và khu vực
Khu vực (số lượng tin tuyển dụng)
Yêu cầu kinh nghiệm
Mức lương thấp nhất (VND)
Mức lương cao nhất (VND)
Mức lương min trung bình (VND)
Mức lương max trung bình (VND)
Mức lương trung bình [(avg min + avg max)/2] (VND)
Hồ Chí Minh (17)
Ít hơn 1 năm kinh nghiệm, khoảng 1 – 2 năm kinh nghiệm
7,000,000
46,000,000 (2000$)
15,882,353
31,011,765
23,447,059
Hồ Chí Minh (30)
Yêu cầu tối thiểu 2 năm KN
10,000,000
57,500,000 (2500$)
23,546,429
36,660,000
30,103,215
Hồ Chí Minh (13)
Tối thiểu 3 năm KN
14,000,000
69,000,000 (3000$)
27,160,000
45,892,308
36,626,154
Hồ Chí Minh (6)
Yêu cầu tối thiểu 4-5 năm KN
25,000,000
92,000,000 (4000$)
37,875,000
58,166,667
48,020,833
Hà Nội (20)
Ít hơn 1 năm kinh nghiệm, khoảng 1 – 2 năm kinh nghiệm
8,000,000
40,000,000
13,964,706
26,210,000
20,087,353
Hà Nội (13)
Yêu cầu tối thiểu 2 năm KN
11,500,000
57,500,000 (2500$)
19,030,000
37,307,692
28,168,846
Hà Nội (8)
Tối thiểu 3 năm KN
9,200,000
57,500,000 (2500$)
21,183,333
36,712,500
28,947,916
Hà Nội (2)
Yêu cầu tối thiểu 4-5 năm KN
23,000,000
69,000,000 (3000$)
34,500,000
66,700,000
50,600,000
Tất cả (34)
Ít hơn 1 năm kinh nghiệm, khoảng 1 – 2 năm kinh nghiệm
7,000,000
46,000,000
14,968,065
27,850,000
21,409,032
Tất cả (42)
Yêu cầu tối thiểu 2 năm KN
10,000,000
57,500,000 (2500$)
22,216,216
36,473,810
29,345,013
Tất cả (21)
Tối thiểu 3 năm KN
9,200,000
69,000,000 (3000$)
24,918,750
42,395,238
33,656,994
Tất cả (8)
Yêu cầu tối thiểu 4-5 năm KN
23,000,000
92,000,000 (4000$)
36,750,000
60,300,000
48,525,000
Bảng dữ liệu Hoàng tổng hợp được từ các tin tuyển dụng đã collect
Visualize nó lên xem thử nhé.
Trung bình của 0-2 năm kinh nghiệm rơi vào hơn 20 triệu/1 tháng, một mức thu nhập khá cao so với tưởng tưởng của mình khi làm report này. Không biết là do tin tuyển dụng họ đưa ra một con số cao cao để thu hút ứng viên ứng tuyển không? Hay thực tế là như vậy nhỉ? Có vẻ report sắp tới khi mà mình collect được từ những bạn đang làm BA, thì sẽ rõ hơn nhé.
Về mức tối thiểu 2 năm KN, thì về bản thân mình thấy con số này khá chuẩn, có vài đứa bạn mình rủ mình qua làm bên các công ty mà các bạn đang làm, cũng báo mình mức tương tự.
Con số tối thiểu 3 năm kinh nghiệm và 4-5 năm kinh nghiệm, khi mình so sánh với các report khác thì thấy con số cũng tương đương (từ bài viết của blaoman)
Lương theo kinh nghiệm và loại công ty
Giờ đi chi tiết thêm vào phần lương dựa theo số năm kinh nghiệm, và loại công ty product/outsourcing nhé
Loại công ty
Yêu cầu kinh nghiệm
Mức lương thấp nhất (VND)
Mức lương cao nhất (VND)
Mức lương min trung bình (VND)
Mức lương max trung bình (VND)
Mức lương trung bình [(avg min + avg max)/2] (VND)
Product (26)
Ít hơn 1 năm kinh nghiệm, khoảng 1 – 2 năm kinh nghiệm
9,000,000
46,000,000
15,513,478
27,123,077
21,318,277
Product (31)
Yêu cầu tối thiểu 2 năm KN
10,000,000
57,500,000
21,640,741
34,883,871
28,262,306
Product (20)
Tối thiểu 3 năm KN
9,200,000
57,500,000
24,918,750
41,065,000
43,630,803
Product (7)
Yêu cầu tối thiểu 4-5 năm KN
23,000,000
92,000,000 (4000$)
36,750,000
62,342,857
49,456,428
Outsourcing (8)
Ít hơn 1 năm kinh nghiệm, khoảng 1 – 2 năm kinh nghiệm
7,000,000
46,000,000
13,400,000
30,212,500
21,806,250
Outsourcing (13)
Yêu cầu tối thiểu 2 năm KN
10,000,000
57,500,000
22,400,000
40,146,154
31,273,077
Outsourcing (2)
Tối thiểu 3 năm KN
34,500,000
69,000,000
34,500,000
57,500,000
46,000,000
Outsourcing (3)
Yêu cầu tối thiểu 4-5 năm KN
46,000,000
92,000,000
51,750,000
69,000,000
60,375,000
Theo biểu đồ thì mức offer của các tin tuyển dụng của công ty outsourcing đưa ra mức offer tốt hơn các công ty product khi mà các cột màu cam cao hơn so với cột xanh lam, nhưng mức chênh lệch không nhiều.
Mình nghĩ việc này có thể do một phần các tin tuyển dụng mình đọc, nhiều công ty product tuyển dụng đầu vào vốn tiếng Anh không bắt buộc nhiều như các công ty Outsourcing, nên cũng là một yếu tố làm cho mức Outsourcing cao hơn.
Kết luận
Qua 2 ngày đọc job descriptions của hơn 112 tin tuyển dụng Business Analyst, mình cũng đã visualize được mức lương tuyển dụng của ngành Business Analyst, từ đó có thể là bước đệm để anh em có thể tham khảo và nắm được mức lương thị trường hiện nay ra sao.
Tiếp theo đây mình cũng đang chuẩn bị bài viết liên quan đến BA sẽ làm gì, cần kỹ năng gì tại các công ty dựa theo các tin tuyển dụng, sẽ tranh thủ đăng sớm nhất cho anh em đọc nhé.
Mình là một người học môn Văn lúc xưa chỉ được 4/10 điểm, được cô giáo văn thấy đẹp trai, hiền lành mà nâng điểm lên 5 cho được học sinh Khá :v, nên ngồi nghĩ hoài cái mở bài sao cho hợp lý mà chưa ra.
Tóm gọn là bài này mình muốn chia sẻ trải nghiệm cá nhân khi áp dụng kiến thức đọc/viết API cơ bản vào trong công việc Business Analyst như thế nào. Đặc biệt là các bạn từ mảng non-IT chuyển qua làm BA, thì đôi lúc để học hiểu sâu vào API thì sẽ tốn khá nhiều thời gian, và đôi lúc thấy khó mà từ bỏ. Nên mình sẽ chia sẻ dưới dạng những trải nghiệm mình đã gặp để các bạn có thể hình dung một cách dễ hơn nhé.
API là gì?
Trước hết cũng nên hiểu 1 chút về API là gì nha.
API là viết tắt của Application Programming Interface – dịch nôm na là Giao diện lập trình ứng dụng. Nó là một giao diện (interface) giữa hệ thống/ứng dụng này với hệ thống/ứng dụng khác – dữ liệu được trao đổi qua lại giữa những hệ thống/ứng dụng này.
Profile mình về API
Thực tế là ở đại học, mình học chuyên ngành Kỹ thuật phần mềm, nên từ năm 2 cũng đã bắt đầu nhảy vào code lung ta lung tung, rồi tập kết nối API giữa App và firebase các kiểu, rồi chuyển qua học Swift, lấy data từ API để đẩy vào trong tableview, nên cũng hiểu sơ sơ về cách API hoạt động. Cũng có một thời gian mình tham gia test web có kết nối API và cần dùng postman để check dữ liệu hoạt động có đúng hông. Nhưng mãi sau này khi đi làm BA, mình không còn code nữa, nhưng kiến thức còn ở đó cũng dùng được ở một mức đọc/hiểu để từ đó tham gia được các dự án có liên quan API. Còn kết nối Postman thì mình quên rồi – nếu mò lại thì đc, code cũng chẳng viết được mấy dòng :(( – khóc á.
Tính đến nay thì từ lúc mình chuyển qua làm vị trí BA đến giờ, hầu như tất cả dự án mình tham gia đều có dính tới API, và dưới đây là đại diện các cases mình có đụng chạm nó trong các dự án quá khứ nhé.
Case 1: Kết nối thanh toán/donation thông qua các cổng thanh toán như Paypal, Stripe, …
Case 2: Tách hệ thống web hiện tại từ kết nối GUI trực tiếp với CMS trong 1 thể thống nhất thành một cổng web API và các interface khác nhau để lấy dữ liệu hiển thị.
Case 3: Luồng các tính năng trong thanh toán/chuyển khoản – hoạt động có đi qua 1 hay nhiều cổng trung gian nối API giữa các hệ thống với nhau – này mình thấy giờ đa số các phần mềm lớn lớn đều áp dụng.
Case 4: Kết nối bên thứ 3 vào để run business riêng cho – ví dụ kết nối 1 luồng đặt vé xe cho chuỗi booking (hotel, xe, tour du lịch)
Các tình huống khác mà mình chưa đặt ra tên, nên đại diện 4 tình huống trên thôi nhé.
Đa số các dự án mình làm thuộc dạng API kết nối về để xử lý nội bộ, và chưa thử phân tích phần API trỏ ra cho các khách hàng/dự án bên ngoài, nên sẽ không bàn luận phần analysis để tối ưu lợi nhuận đồ các kiểu nhé – vì mình cũng chưa có kinh nghiệm, không dám bàn phần này. Và các loại API khác mình không đề cập thì xem như mình bỏ qua, chỉ tập trung vào phần API mình đề cập trong bài viết nha, vì mình có tìm hiểu trên gg thì còn nhiều loại API mà mình chưa đụng tới bao giờ.
Lợi thế khi biết đọc/hiểu về API
Mình tự tin là nhờ vào biết đọc/hiểu sơ về API, làm cho mình xây dựng cũng như hiểu dự án nhanh hơn rất nhiều. Dưới đây là những lợi thế của 1 BA khi biết đọc/hiểu về API
Viết tài liệu chuẩn, chính xác hơn khi biết được dữ liệu gọi đi đâu, gọi như thế nào, dữ liệu truyền đi và truyền về có những thông tin ra sao.
Đỡ phải hỏi developer quá nhiều câu hỏi về tài liệu API khách hàng gửi cho bạn, nhiều khi dev không có rãnh để ngồi với bạn để giúp bạn hiểu hoặc trả lời cho bạn, vì họ cũng có phần việc của họ và họ cũng bận lắm.
Kiểm tra được API của KH cung cấp có phù hợp với tính năng đang xây dựng hay không? Thiếu hay đủ, từ đó có thể đưa ra phương án giải quyết phù hợp từ bước phân tích. Này là trước kia mình có làm dự án, vì tính năng lên rất là gấp, nên 2 bên sẽ chạy song song phần việc, đầu mình thì lên tài liệu, đầu KH thì lên API để kết nối – và mọi thứ chỉ dựa trên trao đổi tổng quan qua cuộc họp mà chưa có 1 tài liệu nào chi tiết cả, nên khi đó nếu BA biết API, thì có thể trực tiếp trao đổi sớm phần dữ liệu ra vô giữa hệ thống 2 bên và cập nhật tài liệu/API cho phù hợp, đảm bảo tiến độ.
Đưa dữ liệu phù hợp để hiển thị lên màn hình giao diện (client), cũng như lỗi tương ứng. Này dễ dàng nhận thấy trong dự án case 4 của mình, mình biết được dữ liệu nào API có thể cung cấp ra được, từ đó vẽ màn hình có những thông tin hợp lý được đưa lên, tránh vẽ lên màn hình, lên design UI/UX các kiểu thì mới hớ ra là API không trả dữ liệu được… mà nếu API từ bên thứ 3 – chỉ có 2 cách, 1 là bên mình bỏ và sửa lại UI, 2 là bảo bên thứ 3 bổ sung trường trong API … và việc cập nhật lại ảnh hưởng tới những đối tác khác của bên thứ 3 đó @@. Lợi thế đó 😀 …
Biết được luồng nghiệp vụ cơ bản của đầu KH dựa theo API của KH cung cấp – cũng trong case 4 luôn, ví dụ mình lên tài liệu build app tích hợp việc đặt vé du thuyền – thì biết được để đặt vé du thuyền bước 1 phải xác thực được KH đó là ai, chưa có tài khoản thì phải đk tài khoản về phía App mình và truyền thông tin để tạo tài khoản về bên Core đặt du thuyền, rồi tìm kiếm khu vực đặt thuyền, …. rồi nguyên 1 luồng từ đầu tới khi thanh toán xong, vé xuất ra sao, các trường hợp lỗi hay hoàn tiền thì sẽ chạy như thế nào. Do đó đỡ bớt một phần lớn đọc rất nhiều tài liệu dài thòng để hiểu luồng nghiệp vụ cơ bản.
Và cả những lợi ích khác mình chưa nghĩ ra… chắc cũng có thôi mà chưa có từ trong đầu mình để mô tả ra :((
Sau phần này, thì mình sẽ chỉ bạn cách viết và đọc tài liệu API cơ bản nhé
Cách viết tài liệu có liên quan đến API
Bản thân mình khi viết tài liệu, thì mình không đi sâu hay tập trung quá vào các trường kiểu bắt buộc 2 bên hệ thống phải có (ví dụ như mấy trường checksum, key, header, signature, ….), mà các trường này mình sẽ để 2 đầu dev làm việc và build tài liệu API riêng. Nên trong tài liệu BA mình sẽ bỏ những trường như này ra.
Các dòng màu đỏ mình không quan tâm tới, và để dev trực tiếp trao đổi với nhau
Theo cá nhân mình hiểu thì API luôn có:
Request: Yêu cầu gì, dữ liệu truyền vào để yêu cầu gồm những trường nào
Response: Kết quả trả ra là gì dựa theo yêu cầu và dữ liệu truyền vào từ request
Do đó trong tài liệu (nếu có viết mục API vào) của mình có:
Bảng là request – yêu cầu request là gì, dữ liệu truyền vô là những trường nào, định nghĩa dữ liệu từng trường
Bảng response – kết quả hợp lệ trả ra là gì, định nghĩa dữ liệu từng trường
Bảng các trạng thái/lỗi có thể xảy ra – đối với bảng này mình không ghi mã lỗi vào, mà chỉ ghi là sẽ có các trường hợp nào xảy ra tại đây, còn mã lỗi sẽ được định nghĩa trong đầu tài liệu API giữa các dev.
Dưới đây là một ví dụ cụ thể, trường hợp truy vấn thông tin khách hàng
Thì khi phân tích ra ta thấy:
request: Yêu cầu truy vấn thông tin khách hàng, với thông tin đầu vào là mã định danh khách hàng
response: chi tiết thông tin khách hàng (vd: họ và tên, ngày tháng năm sinh, ngày tạo tài khoản)
trạng thái/lỗi: có thành công, không tìm thấy khách hàng, lỗi timeout
Nên trong tài liệu nếu viết có mục API sẽ như sau:
Name: Truy vấn thông tin khách hàng
Request:
Data field
Type
Required
Sample
Description
customerId
string(8)
Yes
CUS04829
Mã khách hàng
Response
Data field
Type
Required
Sample
Description
fullName
string(50)
Yes
Nguyen Van A
Tên đầy đủ của khách hàng
birthDay
DateTime
No
18/07/1992
Ngày tháng năm sinh KH dd/mm/yyyy
createdDate
DateTime
Yes
16/02/2022
Ngày tạo tài khoản
Code
Status
Description
success
Tìm thấy khách hàng
not found
Không tìm thấy khách hàng
timeout
Lỗi timeout
Ở code này thì tùy vào dự án, có dự án mà bên kết nối có sẵn API thì họ sẽ có mã code để mình điền sẵn vào, còn nếu build mới thì lúc làm tài liệu mình không có mã code để điền 😀 nên sẽ ghi tên lỗi/trạng thái ra thôi.
Cách đọc tài liệu API
Dưới đây là một ví dụ nhỏ về cách mình đọc API để thể hiện nó lên trên màn hình. Nhưng thường trước khi mình vào chi tiết, mình sẽ xem tổng quan các hàm API đang được cung cấp, từ đó có thể suy luận luồng API chạy ra sao theo một mô hình tổng quan trước, rồi đi chi tiết. Về cách nhìn tổng quan thì mình cũng không biết chia sẻ sao cho bạn đọc, nên mình ở đây xin chỉ mô tả chi tiết bên trong nha.
Trường hợp mô tả trong 1 table
Giả sử trong tài liệu API KH mô tả trong table như đoạn trên mình có mô tả demo, thì ta cũng có thể hiển thị dữ liệu tương ứng trên màn hình giao diện sao cho phù hợp với dữ liệu trả về, tránh trường hợp hiển thị dư trường mà API không trả dữ liệu ra
Trường hợp họ gửi link mô tả API và có result example dưới dạng json
Ví dụ đây là 1 API gọi để lấy thông tin của employee có mã là 719, và kết quả trả ra nếu thành công sẽ có:
Tên employee
Lương
Tuổi
Hình đại diện.
Ở hình trên thì ta có thể thể hiện các thông tin từ API trả ra, giả sử BA muốn hiển thị ngày tháng năm sinh và không đọc tài liệu API thì có thể hiển thị sai, và sau này phải chỉnh sửa lại tài liệu/cập nhật code,….
Trường hợp họ gửi file mô tả API dạng XML
Tương tự với trường hợp tài liệu API mô tả theo kiểu XML thì cũng sẽ đọc và chắc lọc thông tin nào sẽ được trả ra từ API – để có thể hiển thị lên màn hình.
LƯU Ý: Không phải dữ liệu nào trả ra cũng hiển thị lên màn hình nhé, và cũng có những trường dữ liệu đã có trước đó, dù API không trả ra nhưng vẫn có dữ liệu để hiển thị lên.
Còn các dạng tài liệu API khác cũng tương tự, các bạn tự tìm hiểu thêm nhé.
Tổng kết
Biết đọc API giúp mình rất nhiều trong khi làm những công việc của một Business Analyst – hiểu nghiệp vụ nhanh hơn, và trao đổi cũng nhanh hơn với các bên liên quan, mô tả tài liệu một cách chính xác hơn.
Không cần thiết phải hiểu quá sâu về kiến thức API, đôi lúc chỉ cần biết tới đọc hiểu cũng sẽ giúp BA rất nhiều – đặc biệt là các bạn non-IT tiếp cận với kiến thức API.
Mọi thông tin trên là những trải nghiệm và kiến thức cá nhân mình, nếu có sai sót gì mọi người cứ góp ý dưới comment nha :D.
Bắt đầu bởi lời nói không suy nghĩ của mình, đề xuất join dự án về các sản phẩm chăm sóc da chiết xuất từ thiên nhiên với Giang – một người bạn gặp nhau 6 năm trước trong lớp học thêm tiếng Anh. Biết Giang yêu thích công việc này đã lâu, cũng như là các sản phẩm bạn làm ra tặng cho bạn gái mình dùng rất chất lượng, và cũng biết thêm là bạn đang bán các sản phẩm như dầu gội, kem ủ tóc, chăm sóc da mặt, xà phòng tắm, toner,…
Khả năng bản thân
Nhưng sau lời đề nghị đó vài ngày, mình cũng có suy nghĩ về bản thân mình – thật sự muốn đầu tư chung với Giang hay không, mình giúp được gì cho Giang để cùng phát triển? Sau khi phân tích điểm mạnh và điểm yếu bản thân – thì mình không hề biết gì về mảng này, mình chỉ biết về các mảng liên quan đến IT – SEO, 1 ít về quản lý chi tiêu ra vào theo kiểu kinh doanh nhỏ, tính toán chi phí, tỉ lệ phần trăm sao cho hợp lý để mang lợi nhuận phù hợp. Nên đã trao đổi lại với Giang theo hướng tư vấn cho bạn để bạn tận dụng thế mạnh để tự phát triển trước.
Cuộc hẹn CF
Thế là cuộc hẹn CF với bạn Giang diễn ra tại Gò Vấp, HCM để nghe thêm thông tin chi tiết dự án của bạn, bạn đã đầu tư bao nhiêu, thời gian bạn dành cho dự án như thế nào, các phương án tính toán và mong muốn của bạn với dự án ra sao để phát triển dự án sau này.
Tính toán chi phí và tỉ lệ lợi nhuận
Mình cũng không nghĩ Giang dành rất nhiều thời gian cho dự án khi gần như ngày nào cũng dành 4 tiếng cho dự án ngoài công việc nghiên cứu – và sản xuất mỹ phẩm cho công ty bạn đang theo làm, và chi ra cũng hơn 100 triệu để mua máy móc thiết bị về để tự làm phòng thí nghiệm tại nhà, và làm sản phẩm để bán trong suốt gần 2 năm qua.
Tính chi phí sơ lược cho 100 sản phẩm dầu gội, bạn sẽ lời được 7% (1 triệu 8) – chưa kể phần lương nhân công chuyên viên nghiên cứu đang tính với chi phí giá rẻ theo giá thị trường ngành của bạn đang làm.
Với các số liệu của bạn, cộng hưởng cùng kinh nghiệm của mình trước đó để tính toán cho các dự án cá nhân của mình, thì mình tính ra các chi phí để sản xuất 100 rồi tới 1,000 sản phẩm theo các phương pháp khác nhau như tự sản xuất tại phòng lab, thuê gia công bên ngoài với công thức từ bạn, thì lợi nhuận của bạn cũng rất thấp so với công sức bạn bỏ ra và chưa tính số tiền đầu tư – đây là một trong những bài học mình đã mắc phải khi phát triển dự án PhiEnglish.com của mình, từ đó giúp Giang nhận ra bài toán này sớm. (Mình sẽ chia sẻ về dự án của mình riêng, vì với dự án của mình thì cách tính và lợi nhuận tốt hơn của Giang, và nhiều lý do để mình chuyển dự án cho một người tâm huyết hơn.)
Nó chỉ lời theo dạng bỏ công làm lời – chứ không ra hẳn thu lợi phù hợp với công sức đầu tư và nghiên cứu.
Dĩ nhiên ai cũng biết rằng để tăng doanh thu thì phải tăng số lượng hàng bán ra, giảm chi phí sản xuất hoặc tăng giá sản phẩm.
Số lượng hàng bán ra để tăng được lên mức 1,000 sản phẩm 1 tháng thì cũng mất khoảng hơn 1 năm nữa – chưa kể mất rất nhiều khó khăn để đặt được, nhưng mức lợi nhuận cũng quá thấp.
Giảm chi phí sản xuất – khó, vì công thức của bạn phải đạt được chất lượng cao như mong muốn của bạn – giá cả của nguyên liệu không giảm được vì gần như tất cả nguyên liệu bạn đều mua loại 1, loại 2. Rồi chi phí cố định là có khi sau này phải tăng vì sắm thêm máy móc, còn nhân công thì cũng đã là chi phí hợp lý để có người hỗ trợ đưa sản phẩm ra thị trường, quản lý chi tiêu, nghiên cứu và sản xuất. Cả việc thuê một gói gia công bên công ty mỹ phẩm thì chi phí cũng đã tối ưu không thể giảm với yêu cầu chất lượng cho sản phẩm như bạn.
Tăng giá sản phẩm – hiện tại giá gần như đạt ngang với các sản phẩm của hãng nổi tiếng – nên việc nâng giá thành sẽ khó khăn cho việc cạnh tranh – bán hàng, và giá cả này đã nằm trong vùng giá phù hợp để đưa ra thị trường.
Với 3 yếu tố trên nên để tăng lợi nhuận theo mong muốn của bạn là rất khó, dù có 2 hay phát triển thêm vài năm nước, với việc bán sản phẩm ra thị trường nhiều khoảng 1,000 – 2,000 sản phẩm – VẪN LỜI KHÔNG ĐẠT MONG ĐỢI. – và để lời được mong đợi chỉ còn cách giảm chất lượng sản phẩm xuống 1 tẹo để vẫn đảm bảo chất lượng kiểm định, và dĩ nhiên là bạn Giang sẽ không làm vậy rồi.
Chưa kể nếu muốn phát triển được thì phải có người đồng hành, thì việc lời lại chia ra cho các co-founders, nên khá khó khả thi.
Thế là mình lại vạch ra thêm một kế hoạch khác cho bạn ấy với khả năng và sự cống hiện của bạn hiện tại – một phần cũng là phần việc bạn đang làm – nhưng nó free.
Nghề coaching 1-1 chăm sóc da
Hiện tại về sức khỏe – chắc ai cũng biết về nghề PT (personal trainer) trong luyện tập Gym hay một số môn thể dục thể thao, với việc từng tìm hiểu giá cả và thuê Gym thì mình cũng biết được giá cả khi mức thấp khoảng tầm 250K/h-500K/h và mức cao thì có thể 1 triệu đến vài triệu.
Như mình thuê thời điểm sau giãn cách vừa rồi với chương trình khuyến mãi thì chia ra đã 250K/h.
Và mình cũng quen 1 anh dưới Bến Tre làm PT, giá hữu nghị cũng được 400K/h.
Giá thuê PT trên mạng
Và PT thì dễ tiếp cận hơn rất nhiều (thị trường có nhiều PT và KH cũng dễ dàng lựa chọn) so với việc coaching 1-1 chăm sóc da (theo như tìm hiểu trên gg qua keyword thì chưa có nhiều người làm mảng này) – nên cũng là một cơ hội lớn.
Qua tìm hiểu nhiều keyword gg thì chưa có quá nhiều người làm mảng coaching chăm sóc da mặt 1-1. Và cần phân tích thêm để có thể tham gia thị trường này.
Và ngành nghề coaching cũng đang khá mới ở thị trường Việt Nam, và lại hay tập trung vào build doanh nghiệp, kỹ năng về tài chính là nhiều.
Nên để phát triển được thì trước hết hãy để người khác công nhận thực lực thì bản thân Giang thì cũng cần thêm nhiều yếu tố như bằng cấp – chứng chỉ – chứng nhận – thiết bị (vd: máy soi da)- những khóa học bổ sung – những group chia sẻ trên facebook, website.
Do đó cũng cần đặt mục tiêu về chia sẻ kiến thức, làm blog, gắn analyst và tự PR bản thân. Kèm theo đó là vẫn tiếp tục công việc tư vấn chăm sóc da 1 kèm 1 với chi phí rẻ trước, có thể lấy giá 100K/h và sau đó nâng mục tiêu lên 400K/h-600K/h với đối tượng khách hàng phù hợp hơn ở lứa tuổi phụ nữ đã đi làm và có thu nhập tốt để có thể chi trả phù hợp. Cả về kế hoạch bán các gói tư vấn chăm sóc 1-12 tháng, gặp online, offline, nhắn tin,…
Một ví dụ về coaching build business – có thể build coaching chăm sóc da 1 – 1 tương tự với giá theo năng lực cá nhân
Dĩ nhiên là mình cũng có tư vấn private với bạn về chiến lược này, và hỗ trợ thêm cho bạn sau này về việc build website, SEO, analyst user truy cập – tiếp cận… – mình sẽ chưa chia sẻ được ngay trong bài blog này.
Và với các công thức tính toán về chi phí, lợi nhuận thì việc kết hợp tư vấn 1-1 (lợi nhuận ổn hơn – nằm trong khoảng an toàn) và phát triển sản phẩm chăm sóc da chiết xuất từ thiên nhiên chất lượng cao (lợi nhuận thấp) thì là một lựa chọn rất phù hợp với Giang – cũng như giúp Giang suy nghĩ để tính toán phương án build cho bản thân một dự án cá nhân và có thể sau này ra riêng phát triển sự nghiệp được với đam mê của chính bạn ấy.
Kết luận
Với khả năng phân tích từ ngành Business Analyst cũng như kinh nghiệm cá nhân, mình đã có cuộc gặp nói chuyện và giúp đỡ Giang nhận ra được con số lợi nhuận chưa phù hợp với business cá nhân – và từ đó tư vấn cho bạn định hướng có thể phù hợp với bạn trong một mức thu nhập phù hợp với khả năng cống hiến cá nhân Giang.
Bạn nào cũng có những câu chuyện tương tự – nhắn tin mình để cùng trò chuyện, biết đâu mình giúp đỡ được bạn nhé, liên hệ email: [email protected]
Và bạn nào muốn liên hệ Giang để tìm hiểu và ủng hộ sản phẩm từ Giang, truy cập: https://www.facebook.com/GiCornerMadefromheart, bạn ấy có nhiều bài chia sẻ rất hay (cả bài viết + video)
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.
Sử dụng đăng nhập bằng vân tay trên ứng dụng Mobile Banking
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.
Ví dụ về thông báo tránh rủi ro thêm vân tay mới trên thiết bị
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)
Đăng xuất cũng bắt đánh giá, phiền kinh dị :((
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.
Nhắc thanh toán hóa đơn/thông tin hóa đơn đã lưu trên Momo
Nhắc thanh toán hóa đơn trên ZaloPay
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.
Bàn phím trên điện thoạ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.
Chuyển khoản đến số tài khoản (liên ngân hàng, chuyển trong ngân hàng qua số tài khoản) gộp 3 trong 1 trên ứng dụng VPBank NEO.
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 đó.
Nội dung chuyển tiền được điền mặc định, KH có thể thay đổi nội dung được – App VCBDigiBank.
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
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
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
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.
*** 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.
Bán đất đi học :v (ảnh vui thôi)
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á.
Philippines travel
Học tại LSLC group class
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
Tiếng Anh giao tiếp 1 kèm 1 Enrich English Center
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.
Teacher help me for writing skill
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.
