Bạn nên xây dựng gì trước trong Web3: token, hợp đồng thông minh, dApp hay mini app?

Phát triển Web3 bao gồm những gì

Kiểm tra nhanh: Viết bản dựng thành 3 hành động người dùng. Nếu cần nhiều hơn 3, hãy chọn bản phát hành đầu tiên nhỏ hơn.

Dịch vụ phát triển Web3 biến yêu cầu sản phẩm thành một kế hoạch kỹ thuật và bàn giao cụ thể. Chúng có thể bao gồm tạo và triển khai token, hợp đồng thông minh, ứng dụng phi tập trung và Telegram mini app, với kế hoạch chính xác được định hình dựa trên những gì sản phẩm cần làm.

Một brief khởi đầu hữu ích giải thích người dùng, nhiệm vụ chính họ cần hoàn thành và điều sẽ xảy ra sau nhiệm vụ đó. Ví dụ, một dự án token có thể cần một hợp đồng sẵn sàng triển khai và bàn giao rõ ràng; một dApp có thể cần kết nối wallet và tương tác hợp đồng; một sản phẩm cộng đồng có thể cần một Telegram mini app với hành trình người dùng đơn giản.

MarketingExtra phối hợp công việc xoay quanh các yêu cầu đó thay vì xử lý mọi yêu cầu như cùng một package. Tùy thuộc vào brief, bản dựng có thể kết nối với tạo và triển khai token, phát triển hợp đồng thông minh, phát triển dApp hoặc phát triển Telegram mini app.

Trước khi yêu cầu đề xuất, hãy chuẩn bị mọi ghi chú sản phẩm hiện có, tài liệu tham khảo thiết kế, chuỗi ưa thích và dịch vụ bên thứ ba đã biết. Nếu một số quyết định vẫn còn mở, hãy xác định chúng là câu hỏi thay vì phỏng đoán; giải quyết chúng sớm làm cho kế hoạch hữu ích hơn.

Bản dựng nào nên đến trước?

Bắt đầu với hành động sản phẩm phải hoạt động đáng tin cậy, sau đó lên kế hoạch chỉ các thành phần cần thiết để hỗ trợ nó. Token, hợp đồng thông minh và ứng dụng giải quyết các vấn đề khác nhau, vì vậy quyết định hữu ích đầu tiên là người dùng nên có thể làm gì.

Một trang web hoặc landing page Web3 có thể cần thiết để giải thích sản phẩm và hướng người dùng đến ứng dụng. Nếu sản phẩm cần người dùng lưu trữ hoặc quản lý tài sản, hãy thảo luận xem crypto wallet có nằm trong kế hoạch hay ứng dụng nên kết nối với wallet hiện có.

Yêu cầu mỗi tính năng được đề xuất gắn với một nhiệm vụ người dùng và một kết quả có thể kiểm tra. Điều này giúp dễ dàng tách biệt công việc quan trọng cho ra mắt khỏi các cải tiến sau và thấy được thành phần nào phụ thuộc vào thành phần nào. Kế hoạch cũng nên nêu rõ thông tin hoặc quyền truy cập mà khách hàng phải cung cấp trước khi triển khai có thể tiến hành.

Bàn giao phát triển nên bao gồm những gì

Một bàn giao phát triển Web3 hữu ích giải thích những gì đã được xây dựng, cách kiểm tra các chức năng đã thống nhất và những gì nhóm khách hàng cần để vận hành hoặc mở rộng nó. Xác nhận các kết quả đầu ra đó trong khi kế hoạch đang được thống nhất, thay vì chờ đến cuối quá trình triển khai.

Tùy thuộc vào dự án, những gì bạn nhận được có thể bao gồm:

• Một kế hoạch tính năng và tích hợp bằng văn bản, với các quyết định mở được nêu rõ.
• Triển khai token, hợp đồng thông minh, dApp hoặc Telegram mini app đã thống nhất.
• Một danh sách kiểm tra các chức năng đã được xem xét so với yêu cầu đã phê duyệt.
• Ghi chú triển khai hoặc cấu hình cho môi trường đã thống nhất.
• Một bàn giao bao gồm quyền truy cập, phụ thuộc đã biết và các nhiệm vụ tiếp theo được đề xuất.

MarketingExtra sử dụng một đánh giá kế hoạch bằng văn bản để kiểm tra rằng mỗi tính năng có chủ sở hữu, hành vi mong đợi rõ ràng và cách để xác nhận nó. Đối với hợp đồng thông minh, hãy mô tả các hành động và quyền cần xem xét; đối với ứng dụng, hãy đi qua hành trình người dùng và các tích hợp mà nó dựa vào. Giữ các yêu cầu và phê duyệt trong một hồ sơ chia sẻ duy nhất để các thay đổi không biến mất vào các luồng chat.

Nếu bạn đã có tệp thiết kế, thông số kỹ thuật hợp đồng hoặc tài liệu kỹ thuật, hãy chia sẻ các phiên bản hiện tại và xác định phiên bản nào là cuối cùng. Điều đó cung cấp cho nhóm bàn giao một tài liệu tham khảo đáng tin cậy và giúp bàn giao cuối cùng khớp với sản phẩm mà nhóm của bạn dự định vận hành.

Từ brief đến bàn giao

Nguyên tắc chung: Thông số kỹ thuật trước, mã nguồn sau, kiểm tra thứ ba. Bỏ qua bước đầu tiên tốn kém nhất.

Một hợp đồng phát triển Web3 di chuyển từ brief đã thống nhất đến bản dựng đã lên kế hoạch, xem xét các chức năng đã thống nhất và bàn giao thực tế. Trình tự làm cho quyền sở hữu hiện rõ và cho khách hàng cơ hội giải quyết các lựa chọn quan trọng trước khi chúng trở thành thay đổi triển khai.

Đầu tiên, chia sẻ mục tiêu sản phẩm, người dùng dự định, chức năng yêu cầu, chuỗi hoặc nền tảng ưa thích và bất kỳ tài liệu hiện có nào. Tiếp theo, cùng xem xét kế hoạch được đề xuất: xác nhận những gì được bao gồm, những gì phụ thuộc vào dịch vụ khác, ai cung cấp quyền truy cập hoặc nội dung và cách kiểm tra chấp nhận sẽ được thực hiện. Công việc sau đó có thể được phối hợp dựa trên hồ sơ đó, với các câu hỏi và yêu cầu thay đổi được nêu ra khi chúng phát sinh.

Thời gian được đặt sau khi đánh giá này vì triển khai token, hợp đồng thông minh với nhiều tích hợp và mini app với hành trình người dùng rộng hơn là các kế hoạch khác nhau. Tín hiệu lập kế hoạch hữu ích không phải là thời lượng xây dựng chung chung; đó là liệu các yêu cầu, phụ thuộc và người ra quyết định đã sẵn sàng hay chưa.

Trong quá trình bàn giao, giữ phản hồi tập trung vào các hành vi đã thống nhất và ghi lại bất kỳ chức năng mới được yêu cầu một cách riêng biệt. Khi bàn giao, nhóm của bạn nên biết những gì đã được bàn giao, những gì đã được kiểm tra, cấu hình nào nó cần và những nhiệm vụ tiếp theo nào còn lại. Để thảo luận về một dự án, hãy gửi brief và bất kỳ tài liệu kỹ thuật hoặc thiết kế hiện tại nào qua liên hệ.

Danh sách kiểm tra brief xây dựng 6 điểm của bạn

Điền 6 dòng này trước khi yêu cầu bất kỳ báo giá nào. Người xây dựng chỉ có thể định giá những gì được viết ra và nhóm của bạn chỉ có thể xem xét dựa trên một tiêu chuẩn bằng văn bản. Nếu một dòng khó đánh dấu, đó là tin hữu ích: nó cho thấy những gì cần giải quyết trước khi bất kỳ tiền bạc hoặc thời gian nào được chi tiêu.

• Mô tả sản phẩm trong 1 câu.
• Liệt kê 3 hành động người dùng chính.
• Nêu tên chuỗi và wallet cần hỗ trợ.
• Liệt kê tích hợp và nguồn dữ liệu.
• Quyết định ai xem xét và ai phê duyệt.
• Thống nhất các hạng mục bàn giao: mã nguồn, ghi chú và các bước kiểm tra.

Thuật ngữ trong một dòng

Bàn giao (nói đơn giản: bàn giao mã nguồn, ghi chú và quyền truy cập để nhóm của bạn có thể chạy bản dựng).

Môi trường triển khai có nghĩa là nơi bản dựng chạy, chẳng hạn như mạng thử nghiệm hoặc mạng chính.

Điều gì có thể ảnh hưởng đến bản dựng sau khi bàn giao

Kế hoạch dự án có thể xác định bản dựng và các kiểm tra của nó, nhưng nó không thể quyết định cách một nền tảng độc lập xem xét hoặc trình bày sản phẩm. Một hợp đồng token hoặc mini app đã bàn giao không thể buộc chuỗi bên thứ ba, wallet, Telegram review hoặc thư mục ứng dụng chấp nhận hoặc hiển thị dự án; những quyết định đó nằm ngoài kế hoạch xây dựng. Chúng tôi xác minh chức năng đã thống nhất và cung cấp bàn giao, trong khi việc xem xét bên ngoài, khả năng hiển thị hoặc thay đổi chính sách vẫn thuộc về nền tảng liên quan.

Để có một đánh giá chấp nhận rõ ràng, hãy thống nhất trước về các hành vi mà nhóm có thể kiểm tra: các hành động hợp đồng được chỉ định, màn hình và luồng ứng dụng, và bất kỳ tích hợp được đặt tên nào là một phần của công việc. Giữ phê duyệt bên ngoài và yêu cầu tài khoản nền tảng như các nhiệm vụ ra mắt riêng biệt, với chủ sở hữu được chỉ định về phía bạn.

Phát triển cũng phù hợp với một kế hoạch sản phẩm lớn hơn. Một bản dựng token có thể kết nối với phát triển hợp đồng thông minh; một giao diện có thể được lên kế hoạch với phát triển dApp; và luồng người dùng Telegram có thể được xem xét cùng với phát triển Telegram mini app. Các kế hoạch liên quan này giúp làm cho hành trình sản phẩm mạch lạc mà không gộp công việc không liên quan theo mặc định.

Gửi 3 thứ: một brief sản phẩm ngắn, môi trường triển khai ưa thích của bạn và các quyết định vẫn còn mở.