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 Blockchain Business Analyst

Khoá học nghiệp vụ Blockchain cho Business Analyst

by hoangphan Posted on
Khoá học nghiệp vụ Blockchain cho Business Analyst

Hi các bạn, lâu rồi mình không viết Blog, nay quanh lại với một khoá học về blockchain với hi vọng chia sẻ nhiều kiến thức hơn đến cho các bạn, và mình sẽ lại tiếp tục viết nhiều bài hơn về chủ đề nghiệp vụ ở mảng Blockchain.

Thông tin khoá học như sau:

Khoá học nghiệp vụ Blockchain cho Business Analyst

Thời gian học: 2 – 2,5 tháng

Ngày bắt đầu học: 26/02/2024

Chi tiết tại: https://blockchainba.hoangphan.blog/

Nhằm mục đích nâng cao nghiệp vụ, khám phá và chinh phục các dự án Blockchain chỉ sau 2 tháng.

 

Khoá học thiết kế dành riêng cho những bạn đang làm công việc phân tích nghiệp vụ, hoặc muốn làm về công việc phân tích nghiệp vụ như (BA, PO, PM, Product designer,…) muốn có cơ hội làm việc trong mảng Blockchain.

Nhưng vì các bạn đang lo sợ chưa đủ hiểu về nghiệp vụ blockchain hay chưa hình dung thị trường blockchain như thế nào.

Người hướng dẫn

Trong khoá này mình là người trực tiếp hướng dẫn

Người hướng dẫn khoá học Blockchain BA
Người hướng dẫn khoá học Blockchain BA

 

Tại sao nên học khoá học này?

Khoá này mình sẽ phối hợp nhiều phương pháp học (gọi là phương pháp học tập đa chiều), nơi mà mình áp dụng kết hợp giữa lý thuyết và thực hành, học qua video ghi hình sẵn, tài liệu đọc, và các buổi thảo luận trực tuyến, hỗ trợ trực tiếp.

Đặc biệt mình sẽ đưa các dự án thực tế vào để cùng nhau thảo luận và thực hành để giúp các bạn có thể áp dụng vào thực tiễn công việc.

Tại sao nên học khoá học này?
Tại sao nên học khoá học này?

 

Hình thức học
Hình thức học

Cùng với đó thì mình cung cấp lộ trình phù hợp với các bạn mới, dù chưa tiếp xúc với các dự án blockchain vẫn có thể tham gia học (nhưng vẫn yêu cầu học viên phải có kinh nghiệm đi làm trong mảng phần mềm ít nhất 2 năm – không yêu cầu biết code, để có thể bắt kịp bài học)

Anh em advisors xịn xò

Khoá học này với nội dung chất lượng, những khối nội dung này được đánh giá và góp ý bởi những người đi đầu trong ngành.

Khoá học được tư vấn bởi những chuyên gia đầu ngành hỗ trợ mình đánh giá về nội dung cũng như phương pháp giảng dạy
Khoá học được tư vấn bởi những chuyên gia đầu ngành hỗ trợ mình đánh giá về nội dung cũng như phương pháp giảng dạy

 

Nội dung bài học

Với lộ trình học tập được mình nghiên cứu và đánh giá kỹ.

Bước 1: Giới thiệu về khoá học, lộ trình học tập, phương pháp học để các bạn tham gia học có thể nắm rõ cách thức học tập cho phù hợp.

Bước 2: Lần đầu thực hành với blockchain, mình sẽ hướng dẫn các bạn thực hành với các public chain, từ đó sẽ hiểu rõ một blockchain có những hệ sinh thái gì xung quanh, từ đó dẫn đến các khái niệm cần tìm hiểu.

Bước 3: Giải thích các khái niệm, phần này tập trung vào học các khái niệm mới trong blockchain, hiểu nó như thế nào, và các tìm hiểu các khái niệm mới bởi chính bạn.

Bước 4: Giải thích và phân tích các dự án đang có mặt trong thị trường từ đó hiểu được hệ thống và luồng hoạt động của các dự án đó (Kiến trúc Blockchain, Kiến trúc của một Dapp, Dex, Farming, Launchpad, Bridge, SocialFi, …)

Thực hành cùng với 2 hệ thống mẫu là Launchpad và DexNgoài ra các bạn có thể gợi ý một vài hệ thống các bạn muốn mình hỗ trợ giải thíchBước 5: Cùng nghe các talk show mà mình quay sẵn cùng với những người trong ngành để nghe về nhận định thị trường, hiểu về cách họ tiếp cận với các dự án.

Bước 5: Trong xuyên suốt thời gian học, mình sẽ hỗ trợ học viên, cả về nhắn tin trả lời, video call hỗ trợ,…

Các topics cùng khách mời

Mình có mời ít nhất 4 khách mời để tham gia thảo luận

Khách mời tham gia thảo luận về chủ đề blockchain
Khách mời tham gia thảo luận về chủ đề blockchain

 

Kết bài

Hi vọng khoá học này sẽ giúp cho nhiều bạn đang chưa rõ về blockchain, sẽ hiểu rõ hơn về blockchain chỉ sau 2 tháng tham gia khoá học. Và sẽ tự tin tham gia làm việc tại các công ty blockchain, nhằm bổ sung nguồn nhân lực cho lĩnh vực mới này.

Categories Business Analyst

Phân biệt các môi trường phát triển phần mềm

by hoangphan Posted on
Các môi trường phát triển phần mềm

Mấy bữa trước ngồi chia sẻ cho một bạn BA mới vào làm mảng blockchain nắm thêm các môi trường phát triển phần mềm, nên sẵn có dịp viết lại để chia sẻ đến mọi người, có vẻ nó sẽ là kiến thức khá cũ với mọi người, nhưng đôi lúc bạn phân vân không biết được testing environment và staging environment khác nhau như thế nào, hay thỉnh thoảng lại bảo dev là “Deploy lên cho mình test với” thì dev hỏi lại “Deploy lên môi trường nào?”, hoặc thậm chí là bạn không biết khi nào gọi tên môi trường cho đúng và phù hợp, hi vọng dưới góc nhìn của một BA sẽ giúp bạn hiểu các môi trường này và áp dụng, triển khai nó một cách an toàn, hiệu quả.

Các môi trường trong phát triển phần mềm

Những môi trường mà mình nhắc đến trong bài viết hôm nay sẽ gồm có: Localhost (Development), Testing, Staging, Production, Sandbox, và một môi trường có thể hơi hơi lạ với một số người là Pilot, Devnet, Testnet.

Trước hết cho cái hình để bạn dễ hình dung hơn

Phân biệt các môi trường phát triển phần mềm
Phân biệt các môi trường phát triển phần mềm

Môi trường Development/Localhost:

  • Môi trường này là môi trường người Dev dựa theo tài liệu của BA và xây dựng tính năng trên máy của tính (local) của họ, người khác không thể truy cập server ngoài họ.
  • Database kết nối: Là database test, hoặc sandbox (tẹo mình sẽ giải thích sandbox là gì)
  • Người thực hiện test:
    • Người thực hiện test trên môi trường này chính là người Dev luôn, hoặc là một người Dev khác họ pull code về và chạy thử, test lại tính năng.
    • Đôi lúc team test nội bộ sẽ pull code của Dev xây dựng xong về test trên máy local của team test nội bộ luôn, nhưng mình nghĩ này có nhưng ít.
  • Vai trò của BA: Thường là hỗ trợ giải thích tính năng, nghiệp vụ, kiểm thử tính năng mới/hoặc bug fixed.

NOTE: BA cũng được xem như một phần của team test nội bộ

Môi trường Testing:

  • Môi trường này thường là môi trường được đội ngũ team test nội bộ chạy kịch bản kiểm thử đã được thiết kế trước, giúp tìm lỗi và sự cố trong phần mềm, đảm bảo chất lượng phần mềm trước khi lên những môi trường tiệm cận production, hoặc production.
  • Còn về phần dev thì xem thử mấy tính năng họ code có tích hợp được với code có sẵn hay code của người khác chạy được trơn tru hay không?
  • Database kết nối: Là database test hoặc sandbox
  • Người thực hiện test:
    • Người thực hiện chính là nhóm kiểm thử nội bộ
    • Dev đôi lúc sẽ vào test để kiểm tra lỗi có bị như nhóm kiểm thử nội bộ đã report hay không.
  • Vai trò của BA: Thường là hỗ trợ kiểm thử, review bugs, đứng ra làm việc giữ tester và dev để xác nhận bug là bug thật hay có thể bỏ qua, giải quyết tranh cãi giữa họ, có thể dùng môi trường này để UAT (một số trường hợp).

Môi trường Staging:

  • Cũng là môi trường test nhưng tập trung vào phần tương thích và ổn định của phần mềm trước khi triển khai, môi trường này gần như sát với môi trường production.
  • Database kết nối: Là database test hoặc sandbox, đôi lúc có thể cắm trên database production hoặc là lấy database production clone ra và đổi hay dấu đi những thông tin nhạy cảm như email, số điện thoại, id nhận notification,…
    • Tại vì khúc này môi trường cần gần giống với production để khi go live tránh xảy ra lỗi hoặc sự cố không đáng xảy ra nên cần phải có configuration/phần cứng, service tương tự với production.
    • Có những cái khi mà dev chạy trên local/testing env thì thấy ngon nghẻ, nhưng đẩy lên production cái sinh ra lỗi => Cũng là một lý do để có môi trường staging để tạo cơ hội cho dev tìm lỗi liên quan đến configuration, tính tương thích với phần cứng.
  • Người thực hiện test:
    • Người thực hiện chính là khách hàng hoặc nhóm kiểm thử nội bộ
    • Dev kiểm tra lỗi do KH hoặc tester report.
    • Đôi lúc vẫn có thể cho một số nhóm user đặc biệt test cùng (kiểu như sài thử và đưa ra feedback)
  • Vai trò của BA: UAT, follow nắm thông tin từ khách hàng khi họ test, trao đổi nghiệp vụ nếu cần, review lại bugs, confirm một số bugs có tranh cãi.

Môi trường Production:

  • Là môi trường chạy thật với người dùng và dữ liệu thật
  • Database kết nối: Là database thật.
  • Người thực hiện test:
    • Tester thực hiện test khi release sản phẩm
    • Dev kiểm tra lỗi do người dùng cuối report
    • BA follow hoặc kiểm tra lỗi do người khác report.
    • Người dùng cuối sử dụng
  • Vai trò của BA: Tương tác với người dùng cuối hoặc nhận thông tin từ bên khác liên quan đến lỗi, giải quyết vấn đề phát sinh, hỗ trợ người dùng, hoặc phân tích dữ liệu/ux để tìm ra những giải pháp tốt hơn cho phần mềm.

Môi trường Pilot:

  • Môi trường này mình mới biết từ năm 2019 khi làm các dự án liên quan đến banking.
  • Là môi trường chạy thật với một nhóm người dùng đặc biệt và dữ liệu thật, nhóm này sẽ đưa ra các nhận xét góp ý cho ứng dụng.
  • Thường thì Pilot sẽ nằm sau giai đoạn UAT và trước khi lên production
  • Test trên thời gian thực để tìm ra lỗi.
  • Không phải dự án nào cũng có môi trường này
  • Database kết nối: Là database thật.
  • Người thực hiện test:
    • Nhóm người dùng cuối đặc biệt được lựa chọn sẵn để sử dụng trước sản phẩm.
    • Nhóm kiểm thử team nội bộ và khách hàng.
  • Vai trò của BA: Tương tác với nhóm người dùng đặc biệt để thu thập phản hồi, ý kiến góp ý, từ đó giải quyết các vấn đề phát sinh.
  • Đây cũng là một môi trường xác minh tính sẵn sàng của dự án, nên mọi thứ giống y chang production, chỉ khác là cho một nhóm người sài, những người dùng cuối khác chưa được sài.

Môi trường Sandbox:

  • Sau khi xem xét thì thấy Sandbox không nên xếp vào nhóm của Localhost, testing, staging, pilot, production, mà nó là 1 kiểu thể loại khác.
  • Có thể hiểu nó là môi trường thật dùng thử, thường được sài cho những hệ thống liên quan đến tiền bạc, tài chính, payment
  • Vì là dùng thử nên nó là database thử (test) chứ không phải database thật, hoặc là clone từ thật ra, chỉ cần thay đổi endpoint (api) thì sẽ có thể giúp phần mềm hoạt động trên môi trường real.
  • Nếu không có sandbox thì khi test có thể khó cover nỗi những tính năng liên quan đến tiền thật.
  • Mình thấy nó khi làm blockchain, hoặc banking, billing, AAS, payment gateway.
  • Một số tên khác
    • Testnet/Devnet: Môi trường test/sandbox của một blockchain
    • Goerli, Sepolia: Môi trường testnet/sandbox của Ethereum.

Lưu ý khi làm việc trên các môi trường khác nhau.

  • Không nên để khách hàng vào môi trường testing, sau khi mình làm với rất nhiều khách hàng cho thấy để KH vào môi trường test họ sẽ thấy những cái không hay, hoặc có khi họ không hiểu mình đang làm gì và tưởng là mình đang làm sai yêu cầu, hoặc gây ảnh hưởng đến quá trình test của team nội bộ khi KH vào và thay đổi một số cấu hình.
  • Ở môi trường local host -> Có những trường hợp cần chạy cronjob liên tục hay sửa database sướng hơn trên môi trường testing (dù trên testing env vẫn thực hiện được nhưng đôi lúc gặp khó khăn)
  • Chia thành nhiều môi trường testing hoặc kế hoạch release trên testing env theo từng giai đoạn để tránh bug nó bị lộn xộn, ví dụ như báo bug xong dev fix và đẩy ngay lên testing mà không báo, hoặc 2-3 testers nhảy vào test chung 1 môi trường nhưng lại thay đổi DB có ảnh hưởng lẫn nhau, làm cho kết quả test bị rối hoặc bị sai.
  • Điều quan trọng là phải có môi trường Testing độc lập để không ảnh hưởng đến các môi trường khác và giúp dev tập trung vào việc tìm lỗi và sửa chúng, chứ đụng lỗi cái báo và fix liền, xong deploy lên test liền thì không hay.
  • Môi trường Staging, Pilot đôi lúc không cần thiết phải có mà có thể gộp lại thành môi trường testing thôi, lý do chính là khá tốn chi phí, tài nguyên khi phải cần gần giống với môi trường production.
  • Khi test ở Pilot hoặc Staging, BA cần kiểm tra lại với các thành viên khác vì có dính tới database thật, có thể sẽ gửi những kết quả test đến cho người dùng thật, do đó nên phân nhóm người dùng được nhận hoặc thay đổi email/phone thật thành những dữ liệu test.
  • Đối với môi trường Pilot, luôn phải có một kế hoạch liên quan đến việc Rollback release để khi có trường hợp xấu sẽ xử lý được.

Kết bài.

Với những chia sẻ của mình hi vọng các bạn hiểu được từng môi trường phát triển phần mềm, cũng như nhiệm vụ và trách nhiệm một BA làm việc trong từng môi trường, sẽ có những thay đổi trong tên gọi của môi trường, hay trách nhiệm của người làm BA trong từng dự án, công ty khác nhau.

Categories Business Analyst

Phân biệt Sketch, Wireframe, Mockup, Prototype

by hoangphan Posted on

Khi mình làm việc với nhiều anh em Business Analyst, mình thấy nhiều bạn dùng các từ Sketch, Wireframe, Mockup và Prototype đôi lúc sai ngữ cảnh, ý nghĩa. Nên mình viết lại bài này, hi vọng sẽ giúp bạn hiểu hơn về các khái niệm, dùng khi nào và cách dùng cho hợp lý nhé.

1. Sketch

  • Là bản phác thảo một cái gì đó trên giấy hoặc trên bản vẽ ở máy tính.
  • Nó cung cấp cho mình những thông tin cơ bản.

Sketch
Sketch

DÙNG KHI NÀO?

  • Thường là giai đoạn đầu của việc phân tích, mình hình thành ra ý tưởng, luồng, màn hình cơ bản.
  • Mình hay vẽ đại ra trên giấy để có cái nhìn vô một cách trực quan để dễ hình dung và phân tích.

CÁCH DÙNG:

Vẽ đơn giản, dễ hình dung,  tiết kiệm thời gian, vẽ miễn sao dễ hiểu và nhanh, dễ truyền đạt ý tưởng chứ không cần vẽ cho đẹp.

Dùng giấy, hoặc phần mềm Excalidraw, Balsamiq, Figma

 

2. Wireframe

  • Là kiểu thiết kế có các thông tin cơ bản, giao diện cơ bản đủ thành phần (ví dụ phải đủ các trường, dữ liệu, nút button…)
  • Và bản thiết kế này thì không cần màu mè gì nhiều, không cần quá đẹp, nhìn vô là hiểu trên màn hình sẽ có nội dung ra sao, nút đặt chỗ nào, …

Wireframe
Wireframe

Đọc thêm  Công cụ vẽ wireframe và diagram tuyệt vời mình tìm được cho Business Analyst.

DÙNG KHI NÀO?

  • Trong khi phân tích chi tiết, viết tài liệu nghiệp vụ, business rule, trước khi làm UI, khi làm các bước về luồng màn hình.
  • Giúp cho thấy được sự luân chuyển giữa các màn hình (điều hướng), cách các màn hình làm việc với nhau.

CÁCH DÙNG:

  • Vẽ đơn giản, đầy đủ thông tin trên màn hình,  dễ hình dung,  tiết kiệm thời gian.
  • Đừng thêm màu mè quá nhiều, chỉ dùng các màu đơn giản để đánh dấu tạo điểm nhấn, nút quan trọng,…
  • Thông tin trên màn hình nên đầy đủ về trường, nút, …
  • Đi kèm với mô tả Business Rule hoặc viết tài liệu hoặc comment/chú thích.
  • Vẽ đường mũi tên để chỉ sự điều hướng giữa các màn hình, hoặc đôi lúc gắn nút điều hướng trên ứng dụng design để có thể thể hiện sự tương tác giữa các màn hình => giúp cho việc trình bày với KH, stakeholders khác dễ hình dung hơn.
  • Mình hay dùng Balsamiq, Figma, Excalidraw, Adobe XD, Giấy, hoặc Ipad (với bút) để tạo wireframe.

3. Mockup (UI)

  • Là kiểu thiết kế trực quan, khá giống với phiên bản thực tế khi xây dựng web/ứng dụng. Có màu đầy đủ, có mấy yếu tố như đổ bóng, viền, animation kèm theo,…
  •  Vẽ kỹ tới mức mà Front-end designer có thể nhấn vào và xem kích thước chính xác, có các thành phần CSS, responsive.
  • Mình làm công ty thì thấy mọi người hay gọi là UI, Bảng design

Mockup
Mockup

Đọc thêm  Figma Professional miễn phí: Công Cụ Đắc Lực Cho Business Analyst

DÙNG KHI NÀO?

  • Thường thì BA chả đụng gì trong phần thiết kế UI mà chỉ làm phần review luồng, nút có đủ chưa, phù hợp với tính năng nghiệp vụ đang làm hay không?
  • Thường được làm sau bước đã xong tài liệu nghiệp vụ/hoặc làm song song dạng cuốn chiếu với tài liệu nghiệp vụ.
  • Được dùng khi thiết kế trực quan, cụ thể để từ đó dựng nên giao diện web/ứng dụng.
  • Khi mà cần đánh giá yếu tố màu, phong cách, thương hiện, phối giữa các đối tượng giao diện, hình ảnh, sự chuyển động.

CÁCH DÙNG:

  • Thường BA ít/không làm phần này, mà là Designer sẽ lo, do đó BA có thể đi sâu vào mục review đánh giá, góp ý cũng như bổ sung thêm các thông tin còn thiếu trên giao diện, hay sự tương tác giữa các màn hình sao cho khớp với yêu cầu nghiệp vụ.
  • Nếu bạn có kỹ năng về phần giao diện này thì bạn có thể góp ý cũng như đưa ý kiến cá nhân nếu thấy sản phẩm mockup chưa được phù hợp.
Đọc thêm  Khoá học nghiệp vụ Blockchain cho Business Analyst

Prototype

  • Là một bản như Mockup mà nó có thể hoạt động được khi mình gắn sự liên kết giữa các màn hình và user có thể thao tác được. Mục tiêu chính là để mô phỏng sự tương tác giữa người dùng và giao diện.

DÙNG KHI NÀO?

  • Phần này thường bên BA dùng để đi trình bày với khách hàng, stakeholders, mô phỏng ứng dụng thực tế 
  • Hoặc có thể xem và đánh giá trước khi code để chắc chắn rằng bản giao diện phù hợp, luồng tính năng hợp lý, hoặc làm cả việc nhờ người dùng đánh giá,…

CÁCH DÙNG:

  • Cũng là phần Design lo là chính, BA thường phụ phần gắn tương tác giữa các màn hình.
  • Lưu ý khi bật prototype thì chọn màn hình cho phù hợp, mà mở ở mức 100% để cảm nhận nó giống thật, không bị phóng to, hay thu nhỏ mà đánh giá sai về giao diện.
  • Với mình thì mình đánh giá cả độ tương phản, rồi test WCAG.
  • Ngoài ra Prototype còn hay được dùng cho các ứng dụng xây tạm thời, mô phỏng giao diện và build ra app/web để đưa ra cho người dùng thấy (có thể viết một vài tính năng cơ bản mà chưa xây dựng đủ, dùng dữ liệu giả,…)

Kết bài.

Cảm ơn bạn đã đọc bài viết của mình, nếu có gì sai sót hoặc chưa đúng thì để lại comment cho mình nhé.

Categories Blockchain Business Analyst Chia sẻ

Giải nhất 10,000$ từ Solana Coding Camp với vai trò Business Analyst

by hoangphan Posted on

Team mình đã dành giải nhất 10K$ trong cuộc thi SOLANA CODING CAMP VIỆT NAM và

6 bước mình thực hiện trong quá trình Business Analysis với vai trò lại một BA như thế nào?

1. Tiếp cận dự án & trao đổi business & idea (Elicit)

  • Anh em ngồi lại thảo luận ý tưởng và chọn 1 ý tưởng thấy phù hợp để tham gia Coding camp. Các ý tưởng là tự bộ những tính năng team mình dự kiến build cho công ty để xây dựng sản phẩm hoàn hảo.
  • Thảo luận về ý nghĩa thực sự của tính năng, giúp cho user làm gì? Tương lai phát triển tính năng ra sao (Ở đây là thảo luận để thực hiểu về Business, cách business vận hành, problem và solutions)

2. Phân tích & nghiên cứu giải pháp

  • Mình dùng các kỹ thuật khơi gợi (trong chính mình) để phân tích các tính năng, vẽ ra user flow, các trường hợp có thể xảy ra.
  • Vẽ sketch, mình dùng phần mềm excalidraw để vẽ ra những trường hợp xảy ra, lên phát hoạ ý tưởng, hình dung tính năng nó như thế nào, sẽ có những nút nào, những màn hình như thế nào,… chọn lọc và đưa ra những phân tích sơ khởi để đi đến bước tiếp theo…
Đọc thêm  Công cụ vẽ wireframe và diagram tuyệt vời mình tìm được cho Business Analyst.

Sketch
Sketch

  • Vẽ wireframe, mình cũng tiếp tục dùng excalidraw để vẽ wireframe, nhưng vẽ lộn xộn từ luồng màn hình, các thành phần trên  màn hình, vị trí tính năng, một số diagram, vẽ tất cả những gì mà sản phẩm có thể xây dựng được.
  • Ở bước này vì khơi gợi và chưa chốt cụ thể tính năng nào sẽ build, scope ra sao nên mình ghi ra tất cả những gì mình phân tích và các trường hợp/ tính năng có thể build

Wireframe
Wireframe

3. Trình bày giải pháp

  • Call với anh em trong đội ngũ phát triển dự án để trao đổi về giải pháp, thảo luận và chọn ra những tính năng cần xây dựng trong thời gian ngắn là 5 tuần.
  • Chốt scope và chốt giải pháp từ nghiệp vụ đến technical.
  • Phân chia công việc
Đọc thêm  Khoá học nghiệp vụ Blockchain cho Business Analyst

4. UI & Business rule

  • Scope wireframe về Figma & vẽ rõ luồng hơn để nhiều người nhìn vô dễ hiểu, sẽ khác với wireframe ở mục 2, phần wireframe này sẽ gọn gàng, ngăn nắp, vẽ các mũi tên điều hướng chỉ sự tương tác giữa các màn hình rõ ràng hơn để anh em phát triển dự án theo dõi dễ hơn.

Arranged Wireframe
Arranged Wireframe

  • UI vẽ cuốn chiếu, vẽ màn hình nào thì sẽ review và chỉnh sửa đến đó, cùng thời điểm đó Dev FE cũng sẽ theo dõi và làm dần.
  • Mình viết Business Rule & review UI/flow/cases xảy ra(không viết tài liệu cụ thể)

Business Rule
Business Rule

  • Tester viết checklist (vì thời gian quá ngắn)

5. Dev & Test

  • BE/Smart Contract Dev viết code theo Wireframe & Business Rule mình đã định nghĩa ở mục Wireframe đã chốt scope (ở mục 4)
  • FE dev theo UI, và code cuốn chiếu cùng lúc với thời điểm vẽ và review UI.
  • Review checklist & test UI cùng với tester để tìm ra lỗi UI, từ đó kịp thời sửa chữa lỗi ngay thời điểm làm UI.
  • Lắp ráp FE & BE, SC để thấy sự tương tác giữa các tính năng, giữa BE và FE, cả về Smart Contract.
  • Test functional để tìm ra lỗi hoạt động của tính năng, cũng như tích hợp tính năng.
  • Luôn cập nhật Business rule & Review UI cùng với anh em để có thông tin mới, chính xác nhất.

6. UAT

  • Test sau khi sản phẩm hoàn thiện xem có đáp ứng yêu cầu không, nếu chưa đáp ứng thì feedback và chỉnh sửa bổ sung cho phù hợp, còn nếu đã hoạt động ok rồi thì anh em mang đi nộp bài và nhận giải thôi.

 

Kết bài.

Từ 6 bước của mình, bạn có thể áp dụng cho các dự án mà các bạn đang thực hiện, đây cũng là quy trình mà mình thực hiện khi tham gia các dự án thông thường khác, chỉ khác là mình thực hiện chi tiết, cẩn thận và viết tài liệu đầy đủ hơn.
Hi vọng bài viết sẽ giúp ích cho quá trình làm Business Analysis của các bạn.

 

Bạn có thể tìm đọc bài viết về giải ở đây:

https://nhipcaudautu.vn/cong-nghe/solana-vietnam-coding-camp-mua-2-cong-bo-doi-doat-giai-3349752/

https://vnreview.vn/thread/cuoc-thi-lap-trinh-solana-vietnam-coding-camp-mua-2-da-tim-ra-nhung-team-danh-chien-thang-trao-thuong-gan-2-4-ty-dong.492581209480721

 

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í.
1 2 3 4 5