Loading...
Tìm kiếm

Author Archives: hoangphan

Hoang Phan

Author: hoangphan

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

Categories Business Analyst

Thực tập IT Business Analyst cần những kỹ năng gì?

by hoangphan Posted on
Thực tập sinh IT BA cần những kỹ năng gì?

Hi lại là Hoàng đây!

Chắc có lẽ nhiều bạn đang còn ngồi trên ghế nhà trường, hoặc đang đi làm có ý định thực tập vị trí IT Business Analyst quan tâm rằng

“Cần những kỹ năng gì để có thể được nhận làm vị trí thực tập sinh IT Business Analyst.”

Dưới đây là góc nhìn của mình, một người từng tuyển dụng nhiều vị trí BA chia sẻ về các kỹ năng mình cần tìm ở một bạn ứng viên thực tập sinh IT Business Analyst.

Ba kỹ năng chính mình tìm ở Thực tập sinh.

  • Kỹ năng về logic và hiểu về hệ thống
  • Kỹ năng về giao tiếp
  • Kỹ năng về documentation.

Vậy chi tiết từng kỹ năng mình yêu cầu như thế nào?

Kỹ năng đầu tiên: Logic và hiểu về hệ thống

Theo quan điểm của mình thì người IT BA phải là người có thể suy luận logic và đưa ra những giải pháp hợp lý cho dự án phần mềm, mà để làm được điều này thì bản thân người làm cũng phải hiểu về tư duy hệ thống, đối với level thực tập, fresher thì tư duy hệ thống cơ bản là bắt buộc, ví dụ như tư duy Ba tầng của phần mềm gồm có tầng giao diện (UI), tầng xử lý nghiệp vụ – logic và tầng kết nối lưu trữ dữ liệu. Cách hệ thống hoạt động cho luồng đăng nhập, thì user phải nhập thông tin đăng nhập tại giao diện (UI) và gửi yêu cầu đến xử lý ở tầng nghiệp vụ – logic, và từ tầng này sẽ truy xuất và so sánh kiểm tra với dữ liệu trong hệ thống để biết được thông tin đăng nhập có khớp không?

Ba tầng xử lý trong IT BA
Ba tầng trong ứng dụng phần mềm.

Hay là cách phần mềm hoạt động như thế nào, có thể tư duy ra được các trường hợp có thể xảy ra, giống như chuyện suy luận “nếu hôm nay mình quên học bài” thì sẽ có những trường hợp nào xảy ra như “không thuộc bài”, “bị cô giáo phạt”, “bị lên sổ đầu bài”, “mẹ biết bố mẹ buồn”,… thì khi áp dụng vô phần mềm, ví dụ đăng nhập thì phải tư duy được người dùng có thể dùng phương thức nào để đăng nhập như “email/pass”, “số điện thoại/pass”, …. và trong email/pass lại có những trường hợp nào có thể xảy ra  như “email không hợp lệ”, “email không tồn tại”, “mật khẩu bị sai”, … hoặc đăng nhập xong thì phải có tư duy suy luận là hiển thị màn hình gì? màn hình hiển thị cần những thông tin gì? những thông tin đó ở đâu, các trường hợp có thể xảy ra khi đăng nhập thành công.

Do đó khi phỏng vấn thực tập sinh hay fresher, thường câu hỏi của mình sẽ hỏi đến các câu hỏi thực tiễn để xem các bạn có tư duy logic suy luận như thế nào? và hiểu cách hệ thống chạy ra sao? mình sẽ chưa quan tâm đến trong cuộc phỏng vấn thì ứng viên có trả lời hoàn hảo hay không, mà sẽ quan tâm đến cách ứng viên đi tìm ra câu trả lời sao cho phù hợp và đưa ra “giải pháp” phù hợp theo tư duy logic của ứng viên.

Đọc thêm  Khoá học nghiệp vụ Blockchain cho Business Analyst

Kỹ năng thứ hai: Giao tiếp

Tiếng Anh là một lợi thế cực lớn cho các bạn làm IT BA, với nỗi đau trước đó của mình, khi bắt đầu làm BA thì tiếng Anh của mình ở đâu đó 500-600 TOEIC, mà còn giao tiếp (nghe/nói) cực yếu nữa, khi làm dự án Âu Mỹ hay Sin thì mình bị ngợp, cũng như mình tìm thông tin chưa quá tốt và tốn nhiều thời gian khi phải gần như là sài Translate rất nhiều, gặp khách hàng trực tiếp thì lúc nào cũng cần có một bạn làm công việc như PM đi cùng để giúp mình, rất là bất tiện.

Nên thường mình cũng sẽ khá quan tâm đến kỹ năng tiếng Anh của ứng viên, dĩ nhiên ở mức giao tiếp cơ bản đủ sài. Hoặc giống như lúc mình xuất phát với vị trí BA, thì đọc hiểu cơ bản là mình chấp nhận nhưng luôn dặn ứng viên là cần phát triển thêm về Giao tiếp.

Tiếng Anh thì tuỳ thuộc công ty và dự án, nếu dự án ít dùng hay không dùng thì tiếng Anh không quá bắt buộc, nhưng có tiếng Anh là một lợi thế cho BA. Ngoài liên quan đến làm việc giữa anh em dự án, khách hàng, thì còn ảnh hưởng đến việc tìm kiếm thông tin hay học hỏi thêm kỹ năng BA từ nơi khác, đặc biệt là các nguồn tài liệu tiếng Anh.

Giao tiếp và trao đổi tốt là một điều rất cần của một BA, khi mà BA là nơi cầu nối giữa Khách hàng và Đội ngũ phát triển dự án, thì việc giao tiếp là bắt buộc. Giao tiếp ở đây là khái niệm khá chung chung, nó bao gồm cả việc nói chuyện với khách hàng, khơi gợi khách hàng để họ chia sẻ ra những cái NEED (dịch tạm là yêu cầu/cần) của họ, trao đổi trong lúc làm việc, kết nối anh em đội ngũ, hay trình bày ý tưởng, chia sẻ quan điểm cá nhân, thuyết phục mọi người.

Communication Kỹ năng giao tiếp
Kỹ năng giao tiếp

Do đó với phần giao tiếp này mình thường hay hỏi về tính cách, rồi công việc, các hoạt động từng tham gia ở sinh viên hay cách ứng viên trả lời phỏng vấn.

 

Kỹ năng thứ ba: Documentation

Kỹ năng này là kỹ năng cuối cùng mà mình thường tìm ở ứng viên, nhưng độ quan trọng nó sẽ không cao bằng 2 yêu cầu phía trên, vì bản chất người làm công việc BA là người có tư duy và đưa ra giải pháp, cách trao đổi nói chuyện với mọi người để giải quyết vấn đề trong phát triển phần mềm, phải có tư duy thì mới có giải pháp được, còn việc viết lại tài liệu là một kỹ năng theo sau bổ trợ cho tư duy và giải pháp để giúp làm rõ giải pháp cũng như truyền tải giải pháp ra một cách dễ dàng hơn.

Nhưng ứng viên cũng cần PHẢI biết để thể hiện rằng ứng viên biết về BA sẽ làm những loại việc gì? có tìm hiểu và tìm cách học các kỹ năng về documentation, wireframing.

Kỹ năng sketch
Kỹ năng sketch

Đa phần bây giờ khi tìm trên google sẽ ra ngay là documentation thì cần học cách viết BRD, URD, SRS, User Story, … rồi vẽ sketch, wireframe,… học về UML, BPMN.

Đọc thêm  Balsamiq Wireframe miễn phí - công cụ cho Business Analyst

 

Đọc thêm  Thực tập IT Business Analyst cần những kỹ năng gì?
Review wireframe/mockup dễ hơn với tool Axure Cloud.”]

 

Nên thường ở đoạn kỹ năng này mình sẽ hỏi các câu hỏi liên quan đến việc các bạn ấy biết là BA cần làm gì ở phần viết tài liệu, tài liệu nào sẽ được dùng trong trường hợp nào, đã học được công cụ gì rồi, diagram A thì khi nào sài, diagram B khi nào sài, …

 

Kết bài

Với kinh nghiệm từng tìm vị trí thực tập, rồi đến giai đoạn mình tìm ứng viên là thực tập sinh, fresher rồi các bạn làm công việc BA ở các level cao hơn, phỏng vấn vài chục bạn BA để tuyển dụng. Khi tuyển dụng thực tập sinh ba kỹ năng quan trọng mà mình cần tìm ở thực tập sinh IT Business Analyst là Tư duy logic, hiểu về hệ thống, kỹ năng về giao tiếp và trình bày trên tài liệu, biết các công cụ cơ bản để trình bày.

Hi vọng bài viết trên sẽ giúp các bạn trả lời phần nào thắc mắc “Thực tập sinh IT Business Analyst cần những kỹ năng gì?”, giúp các bạn sớm chuẩn bị đầy đủ những kỹ năng phù hợp để ứng tuyển vị trí BA.

Categories Chia sẻ

Cách mình quản lý lịch trình làm việc?

by hoangphan Posted on
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.

Categories Blockchain Business Analyst

Blockchain Business Analyst – Token Launchpad có những tính năng gì?

by hoangphan Posted on
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.

Đọc thêm  Khoá học nghiệp vụ Blockchain cho Business Analyst
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.
Categories Blockchain Business Analyst

Blockchain Business Analyst – Thuật ngữ thường dùng khi xây dựng Token Launchpad

by hoangphan Posted on
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.

Đọc thêm  Khoá học nghiệp vụ Blockchain cho Business Analyst

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

Categories Blockchain Business Analyst

Blockchain Business Analyst – Một số lưu ý khi làm Token Launchpad

by hoangphan Posted on
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:
Đọc thêm  Khoá học nghiệp vụ Blockchain cho Business Analyst

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í.
Categories Business Analyst Chia sẻ

Balsamiq Wireframe miễn phí – công cụ cho Business Analyst

by hoangphan Posted on

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.

Đọc thêm  Khóa học làm quen với Balsamiq Mockup 3 - Miễn phí

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

Đây là giao diện của em Balsamiq

 

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.

Tải và cài đặt

Để sử dụng thì bạn tải balsamiq mockup 3 tại đây: https://balsamiq.com/wireframes/mockups3fordesktop/

 

 

Sau khi tải và cài đặt, bạn nhập key sau nhé:

1) Name: Flash
Serial: eNrzzU/OLi0odswsqnHLSSzOqDGoca7JKCkpsNLXLy8v1ytJTczVLUotKNFLzs8FAJHYETc=

2) Name: SoftVnn
eJzzzU/OLi0odswsqgnOTysJy8ursUQCNc41hjV+7q5+AClADYE=

3) Name: tuan.cse06 – SoftVnn
eJzzzU/OLi0odswsqikpTczTSy5ONTBT0FUIzk8rCc..q7FEAjXONYY1f u6ufgD21RF1

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é

Đọc thêm  Balsamiq Wireframe miễn phí - công cụ cho Business Analyst
Review wireframe/mockup dễ hơn với tool Axure Cloud.”]

Categories Business Analyst

[Mẹo Adobe XD Free] Review wireframe/mockup dễ hơn với tool Axure Cloud.

by hoangphan Posted on

Giới thiệu

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ự)
  • Chia sẻ wireframe/mockup dễ dàng, dễ review/comment trực tuyến
  • Không bắt buộc đăng nhập để comment
  • Dễ quản lý source (vì gửi qua gửi lại, nhiều khi lộn giữa các file source)
  • Không bị giới hạn sharing của Adobe XD Starter- Share Links: 1 active shared link

Cách cài đặt và sử dụng:

  • Bước 1: Cài đặt Adobe XD phiên bản Starter (miễn phí) – tải tại đây
  • Bước 2: Cài Axure Cloud Desktop (miễn phí) – tải tại đây
  • Bước 3: Đăng nhập XD và Axure Cloud (chưa có tài khoản thì tự tạo nhé)
  • Bước 4: Tải plugin the Axure plugin for XD
  • 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ạn có thể test project mình share ở đây: https://nnsbdq.axshare.com/start.html – mật khẩu là “hoangphan”

Cách comment

Làm theo như hình:

Bước 1: Nhấn vào icon comment

Bước 2: Nhấn Add comment

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

Tham khảo mình share project demo từ Balsamiq lên Axshare: https://50wmtz.axshare.com/start.html#g=14

Đọc thêm về sử dụng Balsamiq Mockup 3 miễn phí (dùng key – không cần crack)

Đọc thêm  Balsamiq Wireframe miễn phí - công cụ cho Business Analyst

Kết luậ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.

Alternative app:

  • Adobe XD – sharing (9.99$/mo)
  • Figma (Free or 12$/mo)
  • Axure (25$/mo)
  • Sketch (9$/mo)
  • Invisionapp (Free or 7.95$/mo)
  • Balsamiq Mockup
Categories Business Analyst Chia sẻ

Lương Business Analyst ở Việt Nam năm 2022 là bao nhiêu?

by hoangphan Posted on

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.

Đọc thêm  Khoá học nghiệp vụ Blockchain cho Business Analyst

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

Học tiếng Anh online

Tư vấn học tiếng Anh (159K/h)

1 kèm 1 trực tuyến cùng giáo viên Philippines

Đăng ký ngay

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.

Categories Business Analyst

Business Analyst biết đọc API

by hoangphan Posted on
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 á.

Đọc thêm  Khoá học nghiệp vụ Blockchain cho Business Analyst

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ả

 

 

Categories Business Analyst Chia sẻ

BA phân tích và tư vấn định hướng nghề nghiệp

by hoangphan Posted on

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

1 2 3 4 5