Về cuộc thảo luận về hạ tầng blockchain, thường xuyên quanh quẩn ở cấp cao — chúng ta bàn về ý tưởng, kiến trúc, ưu thế công nghệ, khả năng chống đối. Tất cả đều rất quan trọng. Nhưng khi những ý tưởng này thực sự đi vào thực tế, rơi vào phòng họp của một protocol, hoặc đến tay người ra quyết định phải phê duyệt, phong cách sẽ thay đổi hoàn toàn.
Các vấn đề thực tế bắt đầu nổi lên: Tôi có nên dùng không? Tôi có dám dùng không? Tôi có thể tích hợp nó vào quy trình kinh doanh chính không?
Lúc này, người phụ trách không chỉ đối mặt với một báo cáo phân tích kỹ thuật. Họ phải cân nhắc toàn bộ hệ sinh thái — đội ngũ kỹ thuật, đối tác, tổ chức kiểm toán, nhà đầu tư, cộng đồng, thậm chí còn bao gồm cả các cơ quan quản lý trong một số trường hợp. Thêm vào đó là áp lực thực tế nội bộ: Nếu chọn sai thì sao? Nếu dự án gặp sự cố thì ai chịu trách nhiệm? Nếu quỹ bị thiệt hại thì phải giải thích thế nào? Cuối cùng, tất cả những trách nhiệm đó đều đổ lên người ra quyết định.
Vì vậy, khi lựa chọn hạ tầng, điều đầu tiên người phụ trách nghĩ đến thường không phải là điểm số kỹ thuật, mà là **chi phí giải thích**.
Chi phí giải thích là gì? Chính là khả năng bạn có thể trình bày rõ ràng quyết định này. Giải thích rõ tại sao chọn nó. Trình bày rõ các bằng chứng dựa vào. Nêu rõ giới hạn và rủi ro của nó. Giải thích cách xử lý khi có tranh cãi xảy ra. Trình bày rõ chuỗi trách nhiệm và phân công. Quan trọng nhất, là phải rõ ràng rằng bạn không phải là quyết định theo cảm tính.
Nhiều方案 mới đúng ra lại gặp phải bước này. Không phải vì chúng không tốt về mặt kỹ thuật, mà vì quá khó để những người không phải kỹ thuật hiểu, khó để được các bên lợi ích khác nhau đồng thuận.
Bạn sẽ nhận thấy, người phụ trách một protocol không chỉ cần thuyết phục các kỹ sư, mà còn phải thuyết phục nhiều người không viết mã. Những người này không quan tâm đến chi tiết kỹ thuật, chỉ quan tâm đến một điều: Nếu xảy ra vấn đề, có thể giải thích được không? Có thể chứng minh rằng tôi đã không hành động vội vàng không? Có thể chứng minh quá trình ra quyết định của tôi đủ cẩn trọng không?
Đây chính là lý do thực sự khiến nhiều方案 kỹ thuật vượt trội bị gác lại.
Xem bản gốc
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
8 thích
Phần thưởng
8
4
Đăng lại
Retweed
Bình luận
0/400
CantAffordPancake
· 01-07 00:18
Nói rõ ra thì chính là vấn đề chính trị. Dù công nghệ có xuất sắc đến đâu cũng phải vượt qua được vấn đề nhân sự, vấn đề là phần lớn các nhà quyết định hoàn toàn không hiểu về công nghệ, chỉ biết đổ lỗi.
Xem bản gốcTrả lời0
GasWaster69
· 01-04 19:49
Haha, đó chính là lý do tại sao những thứ tốt đẹp thường nằm trong giấy suốt nhiều năm
Nói một cách đơn giản, đó là trò chơi đổ lỗi rủi ro, công nghệ tối ưu lại càng nguy hiểm hơn
Xem bản gốcTrả lời0
digital_archaeologist
· 01-04 19:42
Nói một cách dễ hiểu thì đó là vấn đề chính trị, không phải vấn đề kỹ thuật. Giải pháp xuất sắc nhất đã chết trên bản trình bày PPT.
Xem bản gốcTrả lời0
ChainSauceMaster
· 01-04 19:37
Thật lòng mà nói, bài viết này đã chạm đúng điểm, một số thứ kỹ thuật vượt trội thật sự chết ở bước "làm thế nào để giải thích với ông chủ lớn" ... Việc người phụ trách phải chịu trách nhiệm đã quyết định anh ta không chọn phương án tốt nhất, mà là phương án dễ dàng nhất để thuyết phục.
Về cuộc thảo luận về hạ tầng blockchain, thường xuyên quanh quẩn ở cấp cao — chúng ta bàn về ý tưởng, kiến trúc, ưu thế công nghệ, khả năng chống đối. Tất cả đều rất quan trọng. Nhưng khi những ý tưởng này thực sự đi vào thực tế, rơi vào phòng họp của một protocol, hoặc đến tay người ra quyết định phải phê duyệt, phong cách sẽ thay đổi hoàn toàn.
Các vấn đề thực tế bắt đầu nổi lên: Tôi có nên dùng không? Tôi có dám dùng không? Tôi có thể tích hợp nó vào quy trình kinh doanh chính không?
Lúc này, người phụ trách không chỉ đối mặt với một báo cáo phân tích kỹ thuật. Họ phải cân nhắc toàn bộ hệ sinh thái — đội ngũ kỹ thuật, đối tác, tổ chức kiểm toán, nhà đầu tư, cộng đồng, thậm chí còn bao gồm cả các cơ quan quản lý trong một số trường hợp. Thêm vào đó là áp lực thực tế nội bộ: Nếu chọn sai thì sao? Nếu dự án gặp sự cố thì ai chịu trách nhiệm? Nếu quỹ bị thiệt hại thì phải giải thích thế nào? Cuối cùng, tất cả những trách nhiệm đó đều đổ lên người ra quyết định.
Vì vậy, khi lựa chọn hạ tầng, điều đầu tiên người phụ trách nghĩ đến thường không phải là điểm số kỹ thuật, mà là **chi phí giải thích**.
Chi phí giải thích là gì? Chính là khả năng bạn có thể trình bày rõ ràng quyết định này. Giải thích rõ tại sao chọn nó. Trình bày rõ các bằng chứng dựa vào. Nêu rõ giới hạn và rủi ro của nó. Giải thích cách xử lý khi có tranh cãi xảy ra. Trình bày rõ chuỗi trách nhiệm và phân công. Quan trọng nhất, là phải rõ ràng rằng bạn không phải là quyết định theo cảm tính.
Nhiều方案 mới đúng ra lại gặp phải bước này. Không phải vì chúng không tốt về mặt kỹ thuật, mà vì quá khó để những người không phải kỹ thuật hiểu, khó để được các bên lợi ích khác nhau đồng thuận.
Bạn sẽ nhận thấy, người phụ trách một protocol không chỉ cần thuyết phục các kỹ sư, mà còn phải thuyết phục nhiều người không viết mã. Những người này không quan tâm đến chi tiết kỹ thuật, chỉ quan tâm đến một điều: Nếu xảy ra vấn đề, có thể giải thích được không? Có thể chứng minh rằng tôi đã không hành động vội vàng không? Có thể chứng minh quá trình ra quyết định của tôi đủ cẩn trọng không?
Đây chính là lý do thực sự khiến nhiều方案 kỹ thuật vượt trội bị gác lại.