Những hành động người dùng nào nên được hỗ trợ trước tiên trong bản build Web3 của bạn?
Một bản build Web3 nên bắt đầu bằng những gì một người cần làm, chứ không phải bằng danh sách công nghệ. Lựa chọn đó giúp đội ngũ của bạn quyết định phần nào nên đặt trên chuỗi, phần nào nên nằm trong giao diện và phần nào có thể chờ đợi sau.
Ví dụ, một dự án token có thể cần hành vi token được xác định và hỗ trợ triển khai. Một sản phẩm có các hành động kết nối wallet có thể cần một dApp cho phép mọi người xem thông tin hoặc gửi giao dịch. Một trải nghiệm cộng đồng có thể phù hợp với Telegram mini app. Chúng tôi biến những hành động người dùng đó thành các phần mềm cụ thể và ghi chú các dịch vụ hoặc quyền truy cập mà mỗi phần cần.
Bạn có thể bắt đầu bằng cách hỏi: người dùng mới thấy gì, họ có thể làm gì và điều gì sẽ xảy ra tiếp theo? Sau đó mô tả hành vi mong đợi bằng ngôn ngữ đơn giản. Chúng tôi có thể ánh xạ việc tạo và triển khai token vào phát triển token. Hoặc xem xét các quy tắc đằng sau một tương tác thông qua phát triển hợp đồng thông minh. Đối với hành trình hướng đến người dùng, phát triển dApp có thể là phần phù hợp trong kế hoạch.
Điều này giúp cuộc trò chuyện đầu tiên trở nên thực tế. Chúng tôi xác định riêng các tính năng ra mắt thiết yếu, các phụ thuộc và ý tưởng sau này, để đội ngũ của bạn có thể xem xét các lựa chọn trước khi phát triển bắt đầu.
Cập nhật lộ trình dễ dàng hơn với ranh giới build rõ ràng
Một ranh giới rõ ràng giúp đội ngũ của bạn giải thích những gì đang được xây dựng và những gì vẫn cần quyết định. Nó cũng cung cấp cho những người đánh giá công việc một thứ cụ thể để kiểm tra.
Hãy tưởng tượng một trưởng nhóm chương trình đại sứ khi sắp có bản cập nhật lộ trình. Đội ngũ muốn đề cập đến một tính năng token và một trải nghiệm Telegram, nhưng hành trình người dùng chính xác vẫn đang được định hình. Chúng tôi sẽ hỏi một đại sứ nên làm được những gì, mạng lưới nào sản phẩm cần và những dịch vụ hiện có nào phải kết nối. Sau đó, chúng tôi sẽ tách các tính năng đã xác nhận khỏi các câu hỏi mở, để bản cập nhật mô tả một kế hoạch chứ không phải một giả định.
Đối với một sản phẩm có nhiều phần, chúng tôi ghi lại cách các phần đó kết nối với nhau. Một hợp đồng có thể cung cấp hành vi được chỉ định, trong khi giao diện cho người dùng cách tương tác với nó. Một Telegram mini app có thể xử lý một hành trình riêng. Nếu đội ngũ cũng cần một trang web sản phẩm công khai, chúng tôi có thể kết nối kế hoạch với phát triển trang web Web3. Khi hành vi wallet là trung tâm, phát triển wallet crypto có thể cần các quyết định và đánh giá riêng.
Loại trao đổi sớm đó có thể tiết kiệm thời gian qua lại sau này. Lộ trình của bạn luôn hữu ích và bản build bắt đầu với những kỳ vọng chung.
Những gì đội ngũ của bạn có thể mong đợi nhận được
Bạn nhận được các phần mềm đã thống nhất cho dự án, cùng với thông tin mà đội ngũ của bạn cần để đánh giá và tiếp tục công việc. Chúng tôi làm rõ nội dung trước khi phát triển bắt đầu, thay vì coi danh sách tính năng là một kế hoạch hoàn chỉnh.
Tùy thuộc vào brief của bạn, công việc có thể bao gồm:
- Mã nguồn cho các thành phần hợp đồng, ứng dụng hoặc mini app đã thống nhất.
- Hướng dẫn triển khai hoặc cấu hình cho môi trường đã chọn.
- Các trường hợp kiểm thử và ghi chú cho thấy những hành vi mong đợi nào đã được kiểm tra.
- Chi tiết tích hợp, giả định và ghi chú bàn giao thực tế.
- Một buổi hướng dẫn cuối cùng với những người sẽ tiếp tục công việc.
Chúng tôi sử dụng danh sách kiểm tra khởi động để thu thập các tính năng, quyền truy cập, phụ thuộc và tiêu chí chấp nhận. Chúng tôi thống nhất 2 điểm đánh giá. Điểm đầu tiên là trước khi triển khai, để xác nhận kế hoạch. Điểm thứ hai là trước khi bàn giao, để kiểm tra kết quả so với các tiêu chí đã thống nhất. Bạn có thể nêu ra sự không khớp trong khi công việc đang tiến hành. Bằng cách đó, bạn sẽ không chỉ phát hiện ra nó vào cuối cùng.
Giả sử đội ngũ của bạn đã có một dApp nhưng muốn có một quy trình AI song song. Chúng tôi có thể thảo luận điều đó như một phần riêng thông qua phát triển AI agent, để sản phẩm hướng đến người dùng và quy trình tự động có các kỳ vọng riêng biệt.
Bốn quyết định giúp quá trình build tiến triển
Một kế hoạch phát triển Web3 hữu ích trả lời bốn câu hỏi thực tế trước khi mã được coi là sẵn sàng để xây dựng. Câu trả lời rõ ràng giúp việc đánh giá dễ dàng hơn cho cả đội ngũ sản phẩm của bạn và chúng tôi.
| Quyết định | Những gì cần ghi lại |
|---|---|
| Mạng lưới | Chuỗi mục tiêu và mọi địa chỉ hợp đồng hoặc ứng dụng hiện có. |
| Hành trình người dùng | Các hành động mà mỗi vai trò người dùng nên thực hiện được. |
| Kết nối | Các wallet, API và dịch vụ khác cần thiết, cùng với ai có thể cung cấp quyền truy cập. |
| Chấp nhận | Những gì đội ngũ của bạn sẽ kiểm tra trước khi phê duyệt từng tính năng đã thống nhất. |
Chúng tôi xem xét các chi tiết này với đội ngũ của bạn và ghi lại bất kỳ mục nào chưa được trả lời. Nếu có hai hướng kỹ thuật hợp lý, chúng tôi giải thích các đánh đổi bằng ngôn ngữ hàng ngày. Sau đó, chúng tôi ghi lại hướng bạn chọn. Chúng tôi cũng kiểm tra xem môi trường kiểm thử, tệp thiết kế hoặc kho lưu trữ hiện có hay không.
Trong tuần đầu tiên, mục tiêu hữu ích là sự hiểu biết chung về các tính năng và điểm đánh giá. Nó không phải là một danh sách lời hứa vội vàng. Nếu quyền truy cập hoặc quy tắc sản phẩm bị thiếu, chúng tôi đánh dấu nó là một quyết định mở. Điều đó cho đội ngũ của bạn một hành động tiếp theo rõ ràng và giữ cho việc triển khai dựa trên các lựa chọn mà bạn thực sự đã đưa ra.
Giữ các phụ thuộc bên ngoài hiện rõ khi sản phẩm hình thành
Một bản build tốt làm cho hành vi đã thống nhất có thể kiểm tra được và để lại cho đội ngũ của bạn một bàn giao có thể sử dụng được. Những điều chính cần giải quyết sớm là quy tắc sản phẩm, quyền truy cập tích hợp và ai sẽ đánh giá từng tính năng.
Công cụ chuỗi, hành vi wallet, quyết định đánh giá Telegram và tính khả dụng của dịch vụ bên thứ ba nằm ngoài tầm kiểm soát của chúng tôi. Chúng tôi không thể hứa hẹn sự phê duyệt hoặc hoạt động không bị gián đoạn của chúng. Chúng tôi có thể cam kết thực hiện việc triển khai, kiểm tra và bàn giao mà chúng tôi cùng thống nhất. Chúng tôi cũng xác định các phụ thuộc trước khi chúng trở thành các giả định ẩn.
Để bắt đầu, hãy gửi cho Brand Community một bản brief sản phẩm ngắn với hành trình người dùng và chuỗi mục tiêu. Bao gồm các tính năng được yêu cầu và mọi kho lưu trữ hoặc tham chiếu thiết kế hiện có. Ba chi tiết khởi đầu hữu ích là người dùng nên làm gì, dịch vụ hiện có nào phải kết nối và đội ngũ của bạn sẽ sử dụng gì để đánh giá công việc. Nếu một câu trả lời vẫn còn mở, hãy bao gồm nó luôn.
Chúng tôi sẽ xem xét những gì bạn chia sẻ và làm rõ các điểm chưa được trả lời. Sau đó, chúng tôi sẽ đưa ra các tính năng đề xuất, thời điểm đánh giá và bàn giao. Bạn sẽ có một kế hoạch cụ thể để xem xét trước khi quyết định xây dựng gì trước.
Câu hỏi thường gặp
Tôi nên gửi gì trước khi chúng ta thảo luận về một bản build Web3?
Hãy gửi một mô tả sản phẩm ngắn, những người sẽ sử dụng nó và các hành động họ cần thực hiện. Bao gồm chuỗi mục tiêu, mọi mã hoặc hợp đồng hiện có, tham chiếu thiết kế và các dịch vụ bạn đã sử dụng. Ví dụ, nếu cần kết nối wallet, hãy ghi chú hành động người dùng nào nên sử dụng nó. Các câu hỏi mở cũng hữu ích; chúng tôi có thể giúp xác định những gì cần quyết định.
Bạn có thể xây dựng một token và sản phẩm xung quanh nó không?
Có, chúng tôi có thể lên kế hoạch tạo và triển khai token cùng với dApp hoặc giao diện liên quan. Hãy cho chúng tôi biết hành vi token dự kiến, chuỗi mục tiêu và các hành động người dùng mà ứng dụng phải hỗ trợ. Chúng tôi sẽ liệt kê riêng các phần trên chuỗi và giao diện, để đội ngũ của bạn có thể đánh giá từng phần. Một địa chỉ hợp đồng hoặc ứng dụng hiện có rất hữu ích, nhưng bạn cũng có thể nói khi không có sẵn.
Bạn có thể thêm Telegram mini app vào một sản phẩm chúng tôi đã có không?
Có. Hãy chia sẻ hành trình người dùng hiện tại, các tính năng bạn muốn có trong Telegram và các dịch vụ mà mini app cần kết nối. Chúng tôi sẽ làm rõ những gì mini app xử lý và những gì vẫn nằm trong sản phẩm hiện có của bạn. Một ví dụ đơn giản là hành trình có màn hình bắt đầu, một hành động người dùng và một bước tiếp theo rõ ràng.
Phát triển Web3 thường mất bao lâu?
Chúng tôi đặt thời gian sau khi xem xét danh sách tính năng, chuỗi mục tiêu, quyền truy cập tích hợp và nhu cầu đánh giá. Một thành phần tập trung với tiêu chí chấp nhận rõ ràng dễ lên lịch hơn một sản phẩm có các quy tắc chưa được giải quyết. Chúng tôi sẽ phác thảo trình tự đề xuất và các điểm đánh giá khi chúng tôi hiểu những chi tiết đó. Điều này giúp đội ngũ của bạn lên kế hoạch dựa trên các quyết định thực tế thay vì một dòng thời gian phỏng đoán.
Bạn có thể hứa rằng hợp đồng thông minh sẽ vượt qua audit độc lập không?
Không. Người đánh giá audit quyết định liệu hợp đồng có vượt qua hay không, dựa trên hợp đồng được gửi và đánh giá của họ. Chúng tôi có thể triển khai hành vi đã thống nhất, cung cấp ghi chú kiểm thử liên quan và xử lý các phát hiện là một phần của công việc đã thống nhất. Ví dụ, bạn có thể chia sẻ sớm các yêu cầu của người đánh giá để chúng tôi có thể thảo luận những gì cần bao gồm.
Chúng tôi có nhận được mã nguồn và ghi chú khi bàn giao không?
Việc bàn giao có thể bao gồm mã nguồn cho các thành phần đã thống nhất, ghi chú triển khai, bằng chứng kiểm thử và một buổi hướng dẫn với đội ngũ của bạn. Chúng tôi xác nhận các mục chính xác và thỏa thuận truy cập trước khi công việc bắt đầu. Nếu đội ngũ của bạn cần một kho lưu trữ hoặc môi trường kiểm thử cụ thể, hãy đề cập trong brief để chúng tôi có thể tính đến ngay từ đầu.
Kể cho chúng tôi về dự án của bạn
Trả lời bốn câu hỏi nhanh và quản lý sẽ gửi kế hoạch, thời gian và mức giá trong vòng một giờ. Mọi thứ được bảo mật.
Đang tải biểu mẫu…