Loading...
Tìm kiếm

Tag Archives: Case Study

Quản lý lịch cá nhân

Mở bài

Hi chào các bạn, lại là Hoàng đây. Nay cuối tuần, sáng mình có đi cf với anh Tony, chủ blog Blaoman. Anh em có bàn về nhiều kiến thức của dân IT BA chủ đề Fintech, Blockchain, cũng như thảo luận chia sẻ kiến thức mà anh em tự mần mò được để cùng nhau phát triển kỹ năng trong công việc.

Lý do có bài viết

Vô tình lại nhắc tới phần nhiều bạn đồng nghiệp hay book lịch họp lung tung, book tức thì hay sáng book → chiều họp mà không chắc cả nhóm có tham gia được hết không?

Hoặc thậm chí đôi lúc chính bản thân cá nhân cũng không biết mình có rãnh giờ nào để báo lại cho người khác là có tham gia họp được không? Và check lại lịch rất tốn thời gian. Hay cảnh phải hỏi từng người một để book lịch họp và đợi confirm từ từng người một khi người book không biết lịch rãnh của từng người.

Mình đã chia sẻ cách mình quản lý các lịch công việc của mình cho anh Tony. Cũng như cách mà mình báo lịch rãnh cho người khác. Do đó mình xin phép viết lại để chia sẻ “Cách mình quản lý lịch trình công việc dễ dàng hơn khi làm Business Analyst nhiều dự án, nhiều công ty qua calendar”

Các ứng dụng mình sử dụng để quản lý lịch làm việc

Hiện tại bản thân mình dùng 3 ứng dụng.

  • Google calendar
  • Calendar của Apple trên Macbook và Iphone.
  • Calendly.com

Cách mình kết hợp các ứng dụng lại để quản lý.

Hiện tại mình làm một lúc nhiều dự án cũng như nhiều công ty/đội nhóm, và cũng như meeting rất nhiều do đó lịch khá dày đặc và khó kiểm soát khi mỗi công ty lại sài một email khác nhau, ngoài ra mình còn có lịch cá nhân.

Dưới đây là cách mình thực hiện để quản lý lịch của mình.

Mình phân ra làm 2 nhóm:

  • Xem lịch và nắm thông tin lịch trình họp/làm việc:

    Kiểm tra lịch trình làm việc
    Apple calendar trên máy Macbook
    • Mình sẽ add tất cả các calendar khác nhau vào chung trong ứng dụng calendar trên MacOS và Iphone, là 2 thiết bị mình thường xuyên dùng để track lịch của mình.
    • Share quyền cho Calendar của Apple, để mình có thể reject/approve the calls từ các calendar khác. Do đó mình chỉ cần sài đúng 1 app để check và manage thay vì phải vào từng calendar để check cũng như reject/approve calls. Và cả tạo lịch họp ngay trên 1 ứng dụng này cho từng calendar riêng.
    • Tất cả các lịch như lịch bay, lịch ở hotel, lịch du lịch, hay reminder sẽ trao quyền add lịch vào 1 email cá nhân riêng (email để đăng ký các tài khoản trên internet)
    • Lịch cá nhân thì mình cũng sài email riêng để add khi cần (email cá nhân làm việc)
  • Đưa ra thông tin lịch rãnh của mình để những người khác book họp với mình nếu cần.

    Cách quản lý lịch của mình
    Cách quản lý lịch của mình
    • Mình sài Calendly.com để làm việc này
    • Add tất cả calendar & sync tất cả lịch của mình lên trên calendly để người khác thấy những lịch trống của mình để đặt.
    • Mình sài 2 calendly khác nhau, 1 cái là cho cá nhân, 1 cái là cho công ty mình có lịch họp nhiều nhất, riêng một số nhóm, cty ít họp thì mình có thể book trực tiếp, hoặc gửi link gg meet.
    • Mình chủ động add lịch bận của mình lên trên calendar ví dụ như có 1 call đột xuất chỉ gửi qua link google meet, thì mình cũng tự estimate khoảng thời gian mình bận họp và add lên trên calendar luôn.
    • Khi có ai muốn book mình họp, thì mình sẽ gửi link tương ứng để cho họ book họp với mình hoặc nhóm của mình.
    • Lịch được book sẽ được add đúng theo mình cài đặt, ví dụ lịch bạn mình đặt call với mình riêng thì mình sài link calendly cá nhân, trên đó đã cài đặt là có người đặt thì calendar tự động add lịch trên email cá nhân. Hoặc khi có ai book phỏng vấn thì sẽ add vào kênh của calendar A8 (calendly sẽ sync để lấy lịch rãnh chung của những người trong nhóm interviewers -> và người đặt lịch sẽ chỉ đặt lịch được những thời gian trống chung của tất cả mọi người trong nhóm.)
Calendly extension
Calendly extension

Kết bài

Đó là tất cả những gì mình đã áp dụng để quản lý công việc với nhiều công ty, đội nhóm khác nhau, cũng như lịch trình cá nhân. Hi vọng bài viết hữu ích và giúp bạn cũng quản lý được lịch trình của bạn dễ dàng hơn.

Blockchain Business Analyst

Thời gian rồi mình có tìm hiểu để xây dựng các dự án liên quan đến blockchain, và mình cũng đã chìm đắm gần hai năm trong nó rồi. Hôm nay lại rãnh rỗi chia sẻ một số kiến thức về những thứ mình làm đến anh em, cũng như giúp anh em có thêm kiếm thức về Blockchain Business Analyst.

Chủ đề hôm nay là “Token Launchpad có những tính năng gì?”, và tính năng nào quan trọng để từ đó anh em nào vô tình tìm thấy bài viết này có thể rút ngắn được thời gian nghiên cứu và có thể tham khảo để áp dụng cho dự án của các bạn.

Trên thị trường blockchain ngày nay có rất nhiều launchpad, mình tìm hiểu và có những ngày canh kèo để mua launchpad hi vọng có kèo ngon x10 x20 x100. Nên cũng tự hiểu được nỗi niềm của anh em người dùng, từ đó rút ra kinh nghiệm cũng như để build những sản phẩm tương tự.

Trước hết mình sẽ giải thích một số thuật ngữ để anh em biết về launchpad và blockchain nhé.

Các bạn xem bài về các thuật ngữ mình hay dùng khi xây dựng token launchpad ở link dưới nhé

Đọc thêm  Blockchain Business Analyst - Thuật ngữ thường dùng khi xây dựng Token Launchpad

Cơ chế của Token Launchpad (Ở đây là IDO Launchpad) như thế nào?

Cơ chế token launchpad - blockchain business analyst
Cơ chế token launchpad

Cơ chế mô tả ở đây chỉ là một cơ chế chung chung cho token launchpad (IDOs), tuỳ thuộc vào cách hoạt động, mô hình của mỗi dự án khác nhau mà có thể sẽ có sự thay đổi.

Bước Mô tả
Khởi tạo dự án Thường các đội ngũ phát triển dự án trên blockchain sẽ có ý tưởng, và xây dựng dự án trên blockchain. Tại thời điểm này họ sẽ xây dựng các Dapp/Business cho riêng họ. Và họ quyết định phát hành tokens.
Tạo token Bên dự án họ sẽ xây dựng và tạo ra tokens trên blockchain.

Bước tạo tokens có thể đội ngũ họ tự xây dựng smart contract riêng theo cơ chế của dự án, hoặc có thể sử dụng một số công cụ để tạo tokens với cơ chế có sẵn.

Liên hệ launchpad Bên dự án muốn thực hiện gọi vốn sẽ liên hệ các bên launchpad để được phép đăng bán/gọi vốn/public sale trên các kênh launchpad đó.
Bước này có thể thực hiện từ sớm trước khi tạo token
Tạo pool trên token launchpad Khi 2 bên đã thoả thuận, thì bên launchpad sẽ tạo pool, đặt các dữ liệu như thông tin dự án, thông tin vesting, hệ thống quản lý vesting, số lượng gọi vốn (softcap, hardcap), ngày xuất hiện trên trang chủ – trong danh sách pool, ngày chấp nhận whitelist, ngày thông báo kết quả whitelist, ngày cho phép swap, các giai đoạn swap, ngày kết thúc mua bán, điều kiện kết thúc mua, ngày được phép claim tokens về ví (theo vesting rule), danh sách đặc biệt, …. rất nhiều thông tin khác nhau tuỳ thuộc vào cơ chế hoạt động của dự án launchpad.
Chuyển tokens từ chủ sở hữu/đội ngũ dự án lên pool Vì là thường các dự án launchpad sẽ viết smart contract để thực hiện các lệnh mua token theo cơ chế đã đặt ra, và được audit nên pool trên smart contract khá an toàn, và cũng nhờ pool này mà người dùng có thể chủ động swap token và lệnh sẽ được thực hiện thông qua blockchain vô cùng minh bạch, do đó chuyển tokens lên pool giống như mình mang hàng của mình bày ra chợ bán, đợi tới ngày được phép bán thì người mua tới mua trên chợ một cách tự động.

Blockchain Business Analyst
Pool như một Sạp cá

Và tuỳ cơ chế mà có thể chính đội ngũ launchpad cũng không thể rút tokens về được.

Thực hiện luồng whitelist/social tasks Thường thì whitelist sẽ giúp cho một số lượng người chơi/nhà đầu tư được quyền mua tokens hoặc được quyền ưu tiên mua tokens, do đó sẽ có nhiều phương pháp để làm whitelist, ví dụ như:

  • Cho chia sẻ, like, follow bài viết trên các trang mạng xã hội.
  • Cho đi staking đạt được một số rules để có quyền whitelist
  • Tham gia các activity của dự án Whitelist có thể hiểu như một cái vé hoặc một danh sách đặt biệt được thêm vào trong rules của pool và từ đó pool sẽ tự động nhận dạng và cho phép người trong danh sách whitelist được thực hiện giao dịch hoặc có thể là discount.

Ngoài ra có thể tham gia dạng lottery nữa, sau khi có vé bạn cần phải bước qua bước lottery để được nằm trong số những người may mắn trở thành whitelist.

Nếu users được quyền swap token Nếu pool đó có whitelist thì xét điều kiện whitelist để users/investors được mua
Nếu pool có yêu cầu KYC thì cũng xét thêm điều kiện KYC
Nếu pool không yêu cầu whitelist thì có thể bán dạng public không qua whitelist
Nếu pool có discount hoặc điều kiện đặc biệt như nắm giữ token để có quyền mua thì cũng xét để users được phép swap
Claim tokens Thường sau khi swap tokens, tokens không được chuyển ngay tới ví của users/investors mà sẽ đợi đến thời gian claim, user có thể vào và nhấn nút để nhận tokens.
Và giờ đa số các dự án uy tín luôn có cơ chế vesting, thì tuỳ thuộc vào đó mà launchpad cũng có thể có cơ chế vesting và áp dụng cho pool, và phân phát lượng tokens đã swap thành từng đợt claim khác nhau
List DEX Tuỳ thuộc vào dự án launchpad khác nhau mà cơ chế này tự động hoặc làm tay.
Nhưng mình thấy mấy dự án launchpad xịn xịn hay tự động lắm, xét giờ sau khi xong bước swap là cho tự động list lên DEX luôn.
Rút tiền về túi chủ dự án Sau khi launchpad xong, có thể chỉ cần xong bước swap thôi, là chủ dự án có thể rút tiền về túi để có tiền phục vụ cho các công đoạn phát triển dự án như marketing, trả lương nhân viên, shill, duy trì dự án, ….
Tiền add vào LP trong DEX (hoặc nếu có cơ chế list DEX tự động) thì tiền LP sẽ tự động trừ ra và chủ dự án không thể rút về, mà hệ thống sẽ tự động add LP sau khi lệnh được kích hoạt.
Tiền sẽ được rút từ pool contract address về ví của nhà đầu tư hoặc ví tạo pool, tuỳ cơ chế được định nghĩa.
Cancel Các pool không phải cứ tạo ra là lúc nào cũng thành công, mà sẽ có những trường hợp pool bị cancel. Do đó sẽ có các rule hỗ trợ việc cancel pool, và cho phép chủ dự án rút tiền về, cũng như hoàn tiền về cho nhà đầu tư nếu nhà đầu tư đã swap tokens (thường bước cancel sẽ nằm trước bước claim tokens, hoặc có thì phải thực hiện tay sau đó vì không biết tokens về tay investors thì sẽ di chuyển đi đâu rồi)

  • ví dụ pool không đạt được soft-cap (cancel tự động)
  • dự án thay đổi kế hoạch
  • pool cài đặt sai (thường có một số thông tin cấu hình mà sai, khi đã đưa vào pool có thể không thay đổi được)

Model overview

Blockchain Business Analyst
Token launchpad Model Overview

 

Thành phần Mô tả
Interface/UI Là giao diện hiển thị (thường là trên Dapp), giúp cho người dùng giao tiếp/kết nối với hệ thống như đăng nhập, kết nối ví, đăng ký tham gia launchpad, xem thông tin dự án, swap tokens, claim tokens, …
Server Là layer logic, giúp tiếp nhận thông tin từ interface, xử lý logic, kết nối với tầng database offchain, smart contract, và các bên thứ 3 khác.
Phần logic của app sẽ nằm tại đây.
Database (off chain) Là nơi lưu trữ dữ liệu offchain của dự án.
Khi bạn tham gia các dự án blockchain và đủ hiểu thì bạn sẽ quen với việc dữ liệu nào nên nằm ở database offchain và dữ liệu nào nên trên on-chain.
Smart contract Smart contract cũng tương tự như Server, nhưng tầng này bộ giao thức xử lý các điều khoản trên on-chain
Đôi lúc chúng ta có thể chỉ cần gọi lệnh trên smart contract trực tiếp (thông qua explorer như bnbscan, solscan, etherscan,…) mà không cần thông qua server để thực hiện các bước như tham gia pool, swap tokens, claim tokens,…
Blockchain Tầng lưu trữ dữ liệu on-chain, tranx.
Admin system Admin system là một hệ thống gồm Interface và server riêng
Nhằm mục đích quản trị hệ thống, tạo pool, chỉnh sửa thông tin pool (nếu có), cài đặt các cấu hình trên dự án, quản trị về profit, tiền đầu vào – ra, ….
Cấu hình này có thể vừa cấu hình dữ liệu on-chain và off-chain.
Wallet provider/user account system Có thể gọi đây là một tài khoản ngân hàng và user dùng nó đăng nhập hay kết nối vào hệ thống. Khi thực hiện giao dịch, hệ thống sẽ gọi đến và yêu cầu xác nhận như bình thường mọi người xác nhận giao dịch trên momo hay các ví điện tử.
Xác nhận ở đây là kiểu bạn trao quyền để thực hiện một lệnh gì đó, và việc bạn trao quyền như này sẽ được dữ liệu blockchain lưu trữ lại.
Ngoài việc xác nhận giao dịch (có tiền) thì còn xác nhận dạng những giao dịch không có tiền kiểu như xác nhận bạn đồng ý làm một việc gì đó.
Social task system Ở đây có thể là một hệ thống bên thứ 3 hoặc tự xây dùng để hỗ trợ việc làm tasks của người dùng.
Ví dụ như 1 tài khoản họ follow twitter, thả tym, tweet, đọc bài facebook, …. và được hệ thống social này ghi lại đã hoàn thành những công việc này, trả dữ liệu về cho hệ thống Launchpad để ghi nhận, từ đó có thể có những điều kiện phù hợp để xét whitelist.
Ngoài ra có thể thiết kế whitelist manual để làm riêng biệt hỗ trợ cho việc truyền thông hay activity trong cộng đồng của dự án. Và thêm danh sách này trước thời điểm cho phép swap tokens.
Staking system Staking system là một hệ thống hoạt động để user có thể stake token của dự án vào, và từ những dữ liệu stake đó + mechanism → Chọn ra người được whitelist.
Nói chung chỗ này tuỳ thuộc vào mechanism của từng launchpad riêng, có thể dựa vào dữ liệu staking, hay phải hold token trong ví, hay là có volume giao dịch hay 1 số điều kiện khác, tuỳ mà điều chỉnh theo mong muốn từ chủ launchpad. |

Tính năng thường gặp

Dựa theo model overview, cơ chế cơ bản của Token Launchpad, mình có thể đưa ra một số tính năng thường gặp như sau.

Trên trang admin

Tính năng Giải thích/vì sao cần?
Đăng nhập/Đăng xuất Đăng nhập vào hệ thống/ đăng xuất hệ thống
Thường các dự án mình làm là đăng nhập bằng wallet luôn thay vì đăng nhập bằng user name/password – vì thường các pool muốn được thay đổi hay tạo cần một wallet xác nhận, confirm cũng như được quyền thao tác.
Mức độ quan trọng: Cao
Phân quyền Phân quyền theo cơ chế dự án, thường phân ra super admin và các managers để quản lý từng nhóm project owners/pools.
Cần thì phát triển phân quyền lớn hơn cho các team kế toán, vận hành, phân tích dữ liệu, …
Mức độ quan trọng: Trung bình (này có thể set cứng cũng được)
Danh sách pool Hiển thị các pools
Mức độ quan trọng: Cao
Tạo/chỉnh sửa/Cancel pool Tạo pool và cài đặt thông số pool
Chỉnh sửa pool – thường bị hạn chế vì dữ liệu của pool thường là on-chain và được hoạt động bởi smart contract
Cancel pool nhằm huỷ pool đang hoạt động, và để làm tính năng này nên chú ý cơ chế roll back để trả tiền về lại cho nhà đầu tư (nếu đã swap) và ai trả phí/ multiple sender.
Mức độ quan trọng: Cao
Whitelist/whitelist manual Công cụ hỗ trợ quản lý whitelist/manual whitelist
Mức độ quan trọng: TB Cao (giờ đa số đều áp dụng whitelist cho launchpad hết rồi, nên cơ chế này khá quan trọng)
Withdraw Cơ chế rút tiền từ pool về sau khi thực hiện xong giai đoạn launchpad của một pool. Hoặc rút tiền ngang về khi pool bị cancel. Có thể kết hợp cơ chế commission, fee giữa chủ Launchpad và project owner.
Thường sẽ cấu hình ai sẽ là chủ pool và ai là project owner để việc rút tiền được thực hiện đúng người. Và dữ liệu này khó thay đổi vì đã đẩy vào pool config.
Mức độ quan trọng: Cao
Profit report Bảng report để xem lợi nhuận, chi phí các kiểu…
Mức độ quan trọng: Trung bình/Thấp

Trên trang user interface

Tính năng Giải thích/vì sao cần?
Đăng nhập/connect wallet Giúp user có thể đăng nhập hoặc connect wallet vào dự án để khi thực hiện lệnh hay tham gia pool thì sẽ lấy tài khoản/wallet đó join pool/tham gia pool
Mức độ quan trọng: Cao
Thông báo/notification Giúp user nhận thông tin về dự án, quản bá dự án
Mức độ quan trọng: Trung bình
Pool Danh sách pool detail, cơ chế sort/filter và có thể xem chi tiết từng pool
Mỗi pool thì có cơ chế có thể khác nhau nhưng cần có bước swap và claim tokens – do đó thường trong pool detail nêu rõ thông tin ngày giờ swap, claim, tỉ lệ swap,…
Mức độ quan trọng: Cao
Active pool Active thì pool mới hiển thị và user có thể swap được – nhằm mục đích tránh tạo pool bị lỗi cũng như trong thời gian chờ để launch thì chưa active ra – kiểu giống giống như draft/ chưa publish post
Mức độ quan trọng: Cao/trung bình
Cancel pool Pool đang hoạt động, có sự cố có thể huỷ pool ngay lập tức hoặc là gọi vốn không đủ Có thể phát triển tính năng hide pool để hide tạm thời để điều chỉnh cho phù hợp và hiển thị trở lại.
Mức độ quan trọng: Cao
Max buy Hạn chế user buy trong FCFS ⇒ Mua nhiều thì nắm tỉ lệ token cao ⇒ dễ điều phối dự án.
Mức độ quan trọng: Cao
Joined pool Danh sách các pool đã tham gia, history các kiểu – tại đây user có thể track lại đã tham gia cái nào, và từng bước ra sao, đã chi bao nhiêu tiền, lời lỗ trên dự án đó như thế nào
Mức độ quan trọng: Trung bình
Lottery Cơ chế đăng ký tham gia (có thể có điều kiện) và từ đó chạy raffle để chọn ra những bạn được whitelist
Mức độ quan trọng: Tuỳ dự án – trung bình
Whitelist manual Cơ chế nạp một danh sách đặc biệt vào pool một cách manual để trở thành whitelist
Thường là dự án muốn một số thành viên trong dự án/đối tác/hỗ trợ việc marketing thì sẽ có một danh sách đặc biệt
Mức độ quan trọng: Tuỳ dự án – Trung bình cao
Guarantee Whitelist Cơ chế những người được whitelist sẽ có chắc chắn một slot để swap token trong một khoản thời gian nhất định, người khác mua trước thì mình vẫn có phần.
Mức độ quan trọng: Tuỳ dự án – caoThường Guarantee whitelist sẽ có đi kèm với FCFS – để tránh trường hợp những người trong guarantee họ không mua hết → vẫn còn cho người khác mua
Hoặc kết hợp với FCFS whitelist tuỳ theo cơ chế nhất định do chủ sản phẩm đưa ra.Guarantee cũng có 2 loại:
– Một là chỉ đảm bảo slot trước, user có tiền mua hay không, hoặc mua bao nhiêu đó thì tuỳ
– Một là user phải bị lock một số tiền trước (kiểu như trả trước/hoặc bị tạm giữ trước) để user đó tới giờ mua sẽ swap đúng số slot đã đặt ⇒ Lúc này thì sẽ không có dư token sau vòng guarantee sale.
FCFS Whitelist Cơ chế những người được whitelist sẽ được quyền mua trong một khoảng thời gian nhất định, nhưng không cam kết sẽ còn phần để mua – ai trong danh sách whitelist tới mua/swap trước thì được trước, ai tới sau mất phần thì chịu.
Mức độ quan trọng: Tuỳ dự án – cao
FCFS Cơ chế bất kỳ ai (nhưng cũng có thể có điều kiện như phải KYC hoặc có nắm giữ một đồng token nào đó) tham gia swap token – ai tới trước thì có phần trước, ai tới sau mất phần ráng chịu.
Mức độ quan trọng: Tuỳ dự án – cao
Vesting Như mô tả ở cách hiểu vesting ở phần định nghĩa trên, thường sẽ hiển thị chi tiết kế hoạch vesting của những người swap token, và cơ chế giúp user claim token theo từng giai đoạn đó – có thể tự động gửi tới user, hoặc user phải vô claim, hoặc chủ dự án gửi tay

Thường kết hợp với cơ chế locktoken
Mức độ quan trọng: Tuỳ dự án – cao

CCY Hỗ trợ nhiều tiền tệ trên cùng một chain, đôi lúc là hỗ trợ multi chain/multi CCYs
Ví dụ: Trên chain BNB – Thường được raise với BNB và BUSD, hoặc support cả USDT.
Mức độ quan trọng: Tuỳ dự án – cao
KYC Định danh khách hàng
– Người tham gia swap/investor
– Chủ dự ánTính năng này cũng tuỳ định nghĩa mỗi dự án launchpad khác nhau mà thiết kế cho phù hợp. Mình thấy KYC này hay sài của một bên thứ 3 nào đó thay vì bên Launchpad tự thiết kế riêng.
Mức độ quan trọng: Trung bình
Tự động listing DEX Sau khi xong vòng swap, thì có thể chủ động list lên một sàn DEX nào đó theo công thức đã định sẵn và thời gian định sẵn.
Mức độ quan trọng: Thấp (Có thể làm tay)
Cơ chế thu phí user User swap phải trả phí hoặc làm một việc gì đó phải trả phí cho launchpad – cơ chế này rất rộng tuỳ thuộc vào đội ngũ BD rất nhiều, từ đó tích hợp tương ứng với hệ thống Launchpad
Mức độ quan trọng: Tuỳ dự án – trung bình/thấp
Cơ chế thu phí dự án Dự án phải trả một lượng phí cho launchpad và phí này có thể được tích hợp vào hệ thống hoặc làm manual và quản lý bên ngoài hệ thống cũng được.
Mức độ quan trọng: Tuỳ dự án – trung bình/thấp
Leaderboard Tuỳ dự án mà định nghĩa các bảng top khác nhau như top pool bán nhanh nhất, top pool thành công nhất, hoặc top user tham gia nhiều nhất, volume nhiều nhất….
Mức độ quan trọng: Thấp
Discount mechanism Tính năng giúp cho việc bán giá thấp hơn/giảm giá cho một số lượng user nhất định trong một khoản thời gian nhất định
Mức độ quan trọng: Trung bình thấp
Anti-bot Cơ chế giúp cho việc né bot mua tokens hay chiếm lĩnh thị phần =))
Này cũng tuỳ dự án – thường nếu tích hợp KYC vào thì sẽ né dễ hơn
Mức độ quan trọng: Trung bình thấp

Hệ thống đi kèm

Các hệ thống hay tính năng đi kèm theo cho một Token Launchpad

  • Staking – giúp user stake token
  • DEX – hỗ trợ việc listing
  • Bounty/Quest – Tặng quà, vật phẩm khi đạt được một số yêu cầu hoặc chạm được volume từ Token Launchpad, hoặc ngược lại nhận được quyền whitelist cho một số dự án từ bounty /quest system
  • Máy tạo token (Token Machine) – hệ thống tạo token tự động theo một cơ chế nhất định, hoặc có thể cho phép người dùng tự đặt logic cho cơ chế của token – mình hay gọi là studio.
  • User Identity, profile – Hệ thống quản lý user hoặc định danh user ngoài ra còn hiển thị profile user, achievement về tham gia Token Launchpad, tham gia Defi, Degen.
  • KYC – Hệ thống hỗ trợ việc định danh khách hàng/project owner, giúp cho dự án an toàn hơn, không bị thao tám dự án dễ dàng.
  • Safu – công cụ đo dự an toàn của dự án
  • Research page – Trang phân tích chi tiết về dự án, chia sẻ thông tin kiến thức hay nhận định về dự án – giúp những tay mơ hay những kẻ đã hiểu biết – biết thêm về dự án
  • Vesting – hệ thống có thể hỗ trợ việc vesting
  • Multisig wallet – Dạng đa chữ ký – hiện nay có nhiều đội ngũ với các thành viên được kết hợp ngẫu nhiên/gặp nhau trực tuyến làm cho việc trust nhau không cao, thậm chí là anh em làm việc lâu năm cùng xây một dự án. Tránh việc một thành viên trong dự án tự quyết định hay bán token của họ, làm ảnh hưởng tới dự án – nên công cụ giúp việc xử lý việc ký đồng thuận để xử lý một việc gì đó, đơn giản như việc bán token thì cần 3/4 người/hoặc thiết bị cùng ký thì mới thực hiện được. Này có thể tích hợp vào Token Launchpad để việc đảm bảo team dự án có thành viên tự chủ động bán tháo.

Một số lưu ý khi làm Token Launchpad

Các bạn đọc thêm bài về lưu ý khi làm Token Launchpad ở đây nhé

Đọc thêm  Blockchain Business Analyst - Một số lưu ý khi làm Token Launchpad

Kết bài:

  • Xây dựng một Token Launchpad, phải có một số hiểu biết về thị trường, trải nghiệm và từ đó rút ra những bài học hay ho để áp dụng vào dự án của bản thân.
  • Cơ chế hoạt động của Token Launchpad thật ra dễ hơn rất nhiều hệ thống ở thị trường web2, do đó khi nắm chắc kiến thức hệ thống và phân tích thì trở thành một Blockchain Business Analyst khá là dễ
  • On-chain thực tế cũng là một bộ server và database
  • Các kiến thức ở trên có phần nào sẽ giúp các bạn hiểu rõ thêm một ứng dụng Dapps hoạt động như nào, và các thành phần của nó.
  • Một hệ thống thường kết hợp với nhiều hệ thống bên thứ 3 để hoạt động được đầy đủ.
  • Mình cũng hơi bận nên viết bài đôi lúc lủng củng về câu cú, cách viết nên các bạn thông cảm nhé. Khi có thời gian rãnh mình sẽ viết thêm. Hi vọng qua bài viết trên sẽ giúp cho các bạn hiểu biết thêm về lĩnh vực Blockchain BA.
Blockchain Business Analyst

Dưới đây là một số thuật ngữ mà mình hay sài cũng như nói chuyện với các bên khi xây dựng một token launchpad.

Launchpad

Thường được đi kèm với hình ảnh tên lửa được phóng lên bầu trời, với ý nghĩa là một nơi bệ phóng Token giúp cho các dự án dễ tiếp cận với nhà đầu tư, hay còn gọi là gọi vốn đầu tư dựa theo lượng users của công cụ launchpad đó hoặc ngược lại.

Vì là bệ phóng nên Launchpad có nhiều loại như ICO – Initial Coin Offering (Lần đầu phát hành token/coin), IDO – Initial Dex Offering – (Lần đầu phát hành token trên sàn DEX), IEO – Initial Exchange Offering (Lần đầu chào bán token trên sàn giao dịch crypto), IGO – Initial Gaming Offering (Lần đầu chào bán/phát hành NFTs/Mystery Boxes/Token liên quan đến GameFi), INO – Initial NFT Offering (Lần đầu phát hành NFT)

Token & Coin

Bạn tham khảo thêm nhiều bài viết để hiểu rõ hơn nhé. Để tránh mình mô tả ngắn gây hiểu sai lệch về 2 khái niệm này. Các từ khoá liên quan: Tiền điện tử, Crypto, Tiền mã hoá, …

White paper

Là một tài liệu để trình bày ý tưởng, kế hoạch phát triển dự án, kiến trúc hệ thống, phân chia token, dự báo tăng trưởng, … Nhằm mục đích chia sẻ minh bạch thông tin về dự án đến nhà đầu tư.

DYOR

Do your own research – bạn tự nghiên cứu về dự án để biết rằng dự án đó tốt không? Những người đi shill dự án chỉ là chia sẻ thông tin – họ không chịu trách nhiệm gì về việc đầu tư của bạn

ROI

Return On Investment – tỷ suất hoàn vốn, là chỉ số đo lường những khoản thu được so với chi phí bỏ ra (thường ở đây là tiền và thời gian).

Ví dụ bạn đầu tư 100$ và sau 1 năm bạn bán ra 500$ ⇒ ROI = ((500$-100$)/100$)*100% = 400%

KYC

Know your customer = quy trình xác minh danh tính của người dùng hoặc chủ dự án. Nhằm biết được người chủ dự án hoặc người tham gia là người thật.

Staking

Staking được hiểu là việc mang một lượng coins/tokens nhất định khoá lại để nhận được một lượng phần thưởng nhất định.

Ngoài ra bạn có thể tìm hiểu thêm Proof of Stake để rõ thêm nhé.

Smart Contract

Là bộ giao thức tự động thực hiện những điều khoản/thoả thuận giữa các bên dựa trên công nghệ blockchain.

Thường là smart contract sẽ được viết code và xử lý các logic mà được ví như những điều khoản trong hợp đồng.

Nhưng vì hợp đồng thường cũng có lỗ hỗng → có thể điều chỉnh hợp đồng cho phù hợp, nên smart contract cũng có upgradable.

Blockchain

Blockchain thì đóng vai trò như một bộ database phi tập trung, lưu trữ thông tin theo từng khối (block) và được liên kết với nhau bằng mã hoá, cứ theo thời gian thì các block này càng dài tạo thành một chuỗi (chain)

Vì là phi tập trung nên dữ liệu được nằm phân tán ở nhiều máy tính khác nhau, và các thông tin được liên kết với nhau và không thể phá vỡ nên thông tin cũng không thể bị thay đổi dưới bất cứ hình thức nào.

Chain

Từ này mình hay sài để chỉ các công nghệ blockchain/nền tảng khác nhau.

Ví dụ như Binance Chain, Etherium Chain, Solana Chain ⇒ Multi chain là đa chuỗi/đa nền tảng khác nhau.

Off-chain

Là các giao dịch xử lý và lưu trữ nằm ngoài blockchain

On-chain

Là các giao dịch xử lý và lưu trữ nằm trên blockchain

Audit

Là hành động kiểm tra code trên smart contract xem đã code tốt/có đảm bảo được bảo mật hay chưa? Nếu có lỗ hỗng bảo mật thì báo lại đội ngũ phát triển dự án điều chỉnh để tránh rủi ro về lỗi và hackers.

Một cái hay nữa là thường Audit giúp cho dự án uy tín hơn nhiều, và thu hút thêm nhà đầu tư.

Thường các dự án blockchain liên quan khá nhiều tới tài sản (coin/token) nên cần được audit cẩn thận bởi những đội ngũ có trình độ cao.

Nhưng không phải dự án nào audit rồi cũng an toàn 100% nha 😀

Pool

Mình định nghĩa từ này trong các launchpad mình tham gia, cũng như build.

Pool ở đây nghĩa là một nơi/một cái hồ/một contract address được sinh ra để chưa tokens/coins/NFTs/… từ đó dựa vào cơ chế xây dựng trên smart contract mà phân phối tokens sao cho phù hợp theo logic đã được định nghĩa.

Đôi lúc lại hiểu nó như một dự án launchpad.

Social task

Là các nhiệm vụ nhà đầu tư phải làm như chia sẻ lên facebook, theo dõi một bài viết, nhấn like, bình luận một bài viết, truy cập trang web,…

Mục đích tuỳ thuộc vào cơ chế hoạt động của dự án, có thể là để có quyền được tham gia launchpad của pool, hoặc có cơ hội, hoặc được quyền nhận miễn phí tokens,…

Whitelist

Kiểu như một danh sách các wallet hoặc một định danh nào đó đã được chọn lọc để có quyền tham gia một chương trình đặc biệt nào đó. Cụ thể ở đây là được quyền tham gia pool.

Tokenomics

= Token + economics: Thường là mô tả về cách token hoạt động trong nền kinh tế như: Tổng số lượng tung ra là bao nhiêu? vốn hoá như thế nào? phân bổ tokens ra sao? Các tiện ích gồm những gì?

FCFS

First Come First Served – ai đến trước thì được tham gia trước, thường là dành cho các pool được tham gia rộng rãi tới mọi người, và ai nhanh tay thì được tham gia trước.

Allocation

Sự phân bổ tokens, nhưng còn được hiểu là phần tokens được dành riêng cho một nhà đầu tư, một tổ chức đầu tư.

Ví dụ như cái bánh 10 phần chia cho 5 người, mỗi người 2 phần.

Thì 2 phần này là allocation của 1 người nào đó được chia.

Raffle

Là kiểu xổ số – quay ngẫu nhiên để chọn những người chiến thắng.

Vesting

Một nhà đầu tư nào đó tham gia để mua tokens, nhưng mà không phải được lấy toàn bộ token và ưng bán đi lúc nào thì bán. Mà phải được dự án giữ lại hoặc khoá lượng tokens đó lại, và chỉ được mở ra theo lộ trình nhất định. Quá trình này gọi là vesting → Nhằm tránh nhà đầu tư xả hàng hàng loạt hoặc thao túng thị trường → giúp cho dự án an toàn hơn, có thời gian để phát triển dự án.

DEX

Decentralized Exchange – là loại sàn giao dịch crypto phi tập trung. Thường mấy IDO Launchpad pool xong sẽ list trên DEX.

Lưu ý

Sẽ có những khái niệm trong blockchain mà bài viết này không thể mô tả hết được, bạn vui lòng tìm kiếm thêm trên google nhé.

Blockchain Business Analyst

Đây là một bài kèm theo của bài viết

Đọc thêm  Blockchain Business Analyst - Token Launchpad có những tính năng gì?

Một số lưu ý khi làm Token Launchpad

  • Upgradeable Smart Contract: Thường thì khi phát triển sẽ có đôi lúc cần update lại smart contract để cho phù hợp với nhu cầu BD, nên việc để smart contract ở upgradeable giúp cho việc thay đổi sau này, dĩ nhiên là thay đổi sẽ nên audit lại Mình bị dính một vụ để Smart Contract không thay đổi được – từ đó bó thay để chỉnh sửa khi mong muốn cập nhật.
  • Audit kỹ: Audit giúp cho smart contract an toàn, tránh bị hack – do đó nếu có chi phí/budget thì hãy đầu tư cho audit thật kỹ. Nhiều dự án đã bị hack rồi 😀
    Chưa kể cơ chế launchpad là pool nắm giữ token và tiền investors đã swap – nên tránh hack/đảm bảo security là yếu tố quan trọng hàng đầu.
    Một số bên Audit được biết đến trong thị trường Crypto:

Chi phí trung bình/thấp:

    1. ContractChecker
    2. InterFi
    3. AnalytixAudit
    4. SpyWolf
    5. FreshCoins
    6. SafuAudit
    7. Audit Rate Tech
    8. BlockSAFU
    9. Tech Audit
    10. DAudit
    11. CFG Ninja
    12. Coinsult
    13. Cyberscope
    14. Kishield
    15. SolidProof
    16. Rug Free Coins
    17. Cracken
    18. TechRate – mình đã sử dụng
    19. Solidity Finance
    20. Asfalia

Chi phí cao:

  1. Certik – mình đã sử dụng
  2. Inspex – mình đã sử dụng
  3. SolidGroup
  4. HashEx
  5. Chainsulting
  6. QuillAudits
  7. FairyProof
  • Cơ chế nên định nghĩa đầy đủ từ ban đầu – định nghĩa rõ cơ chế ban đầu giúp cho tiết kiệm khá nhiều thời gian, chi phí để phát triển dự án. Thay đổi càng nhiều thì ảnh hưởng tới tiến độ và chi phí.
  • Có cơ chế Cancel pool – cơ chế này mình thấy cực kì quan trọng vì phía dự án đôi lúc sẽ có 1 bất trắc gì đó hoặc lỡ gọi vốn không đủ mình có thể thực hiện cancel pool ngay. Cơ chế này có thể làm manual hoặc tự động cancel và hoàn tiền cho user theo điều kiện.
  • Nên có tính năng whitelist manual – vì có một số trường hợp đặc biệt sẽ được mua token mà không cần thông qua các bước như user bình thường như partner, anh em trong dự án,…
  • Quan tâm đến cơ chế realtime database – việc cập nhật dữ liệu real time rất quan trọng, đôi lúc cập nhật chậm làm cho việc thực hiện swap token không suôn sẻ hoặc đang thấp được phép mua, nhấn vào thì mua không được…. nên cần suy nghĩ về cơ chế này để dữ liệu cập nhật được sớm nhất trên client/interface.
  • Hiển thị thông tin cơ bản chung chung ra ngoài – Việc tìm/săn dự án trên launchpad là chuyện của nhiều Degen hay làm, do đó nếu interface hỗ trợ show một số thông tin cơ bản nhưng mà quan trọng cho những tay săn, họ có thể xem từ vòng danh sách thay vì phải nhảy vào từng pool đọc chi tiết → Tay săn có thể lựa từ bên ngoài và xem chi tiết dự án nào đó nếu cần.
  • Cơ chế vesting nên hiển thị rõ ràng – Nhà đầu tư rất quan trọng việc vesting khi tham gia Launchpad, nên hiển thị thông tin Vesting càng rõ ràng càng tốt.
  • Dự án KYC phải đánh rõ để tăng độ trust ⇒ Do đó tích hợp tính năng KYC là một điều nên làm.
  • Hiển thị warning rõ ràng để người dùng biết tiền đi đâu rồi, khi nào tiền, token về, trao quyền cho ai/hệ thống nào, làm việc gì ? Vì hiện tại trên crypto khá nhạy cảm về tiền bạc, và cũng như sự thiếu hiểu biết của người sử dụng → Do đó càng rõ ràng chi tiết thì càng tốt. Dĩ nhiên là cần kết hợp các thông tin/dữ liệu này sao cho hợp lý tránh complex UX.
  • Decimals – là số dư đằng sau dấu phẩy, thường nó lại dính tới Decimals của tokens nữa, nên cần chú ý về điểm này khi làm tròn số.
  • Money flow: Dòng tiền trong dự án – khá liên quan đến cơ chế business – và suy nghĩ kỹ để thiết kế tiền chạy từ túi user sang túi của project owners/launchpad owners như thế nào cho phù hợp. Mình bị mắc phải lỗi này khi bị phụ thuộc vào một 3rd system quá nhiều – từ đó làm cho money flow bị lệch, khó quản lý – nên phải làm tiếp 1 ver để nâng cấp, làm tốn nhiều chi phí.

Giới thiệu

Hello các bạn, lại là mình Hoàng Phan đây.

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.

Lương theo khu vực

Khu vực Mức lương thấp nhất Mức lương cao nhất Mức lương min trung bình Mức lương max trung bình Mức lương trung bình [(avg min + avg max)/2]
Hồ Chí Minh 7,000,000 VND 92,000,000 VND 22,269,841 VND 38,558,571 VND 30,414,206 VND
Hà Nội 8,000,000 VND 69,000,000 VND 17,647,368 VND 33,376,087 VND 25,511,727 VND

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é.

Cảm ơn anh em đã đọc bài viết của mình.

 

Dưới đây là form khảo sát lương hiện tại của anh chị, Hoàng sẽ visualize kết quả response (từ 100 response) và cập nhật trong bài viết này nhé.

Business Analyst biết đọc API

Mở bài

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 huống áp dụng kiến thức về API

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
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
  • Status/error code: Danh sách các mã trạng thái/lỗi response trả ra.

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.

Comment góp ý từ các anh chị độc giả

 

 

15 điểm UI/UX hay cho mảng Banking App

Tiếp theo đây là phần 2 của 15 điểm UI/UX cho mảng banking mà mình rút ra được

Nếu bạn chưa đọc phần 1 thì tìm đọc tại đây nhé: https://hoangphan.blog/15-diem-ui-ux-cho-mang-banking-hay-va-can-luu-y-phan-1/

9. Đăng nhập và xác thực bằng sinh trắc học

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ị
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ị :((
Đă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/thông tin hóa đơn đã lưu trên Momo

 

Nhắc thanh toán hóa đơn trên ZaloPay
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
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.
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.
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.

Giới thiệu profile

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Nút toggle switch

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.