我在做区块链产品设计这个方面, 已经有五年的年头了。我最害怕的事情, 其实并不是去编写那些技术文档。我最害怕的, 是需求阶段里面, 那道叫做“思考题”的题目究竟是什么样子。
这道题目就是: 你真正要解决的问题到底是什么这个问题。因为太多的这种团队, 在开始的时候, 一上来就画出了功能图。然后, 它们把链上还有链下, 搅和成了一锅粥。最后的结果就是, 产品上线以后, 根本没有人会使用它。

区块链产品设计难在哪
困难的地方并不在共识算法这块, 难在信任边界究竟要划到什么地方。我们可以举供应链金融这个例子来说明一下, 面对五个体量完全不一样的企业, 你必须得去判断清楚, 究竟是哪些企业愿意把核心的数据放到链上去存储, 是哪一些企业只接受开放接口这种形式, 又是哪一些企业干脆连API这个东西都不愿意给你使用。
文档上写得非常漂亮, 写着是全链透明, 等到了落地执行环节, 实际上的状况却变成了部分节点选择性披露, 这个存在差距的地方, 才是真正花费设计工作量的地方。
我看过的一个农业溯源项目, 产品负责人非要把全链路不可篡改这个要求给死死守住, 后来他去种植基地实地考察了一下, 发现那个环节连智能手机都配备不齐不足, 这怎么可能让他进行扫码操作并且数据上链呢, 经过深思熟虑后发现正确答案永远只存在于现场实际情况之中, 绝对不会出现在那些制作精美的PPT演示文稿里面。
区块链产品设计咋落地
落地的核心意思非常明确, 也就是需要先把那些“如果不进行链上处理就不行”的关键环节给找出来, 而其他的部分就可以直接扔到传统数据库里面去吧。
记得在去年搭建过一个数字藏品平台的时候,因为确权的操作必须要上链进行处理, 所以积分、签到以及社区互动这些功能全部被放到了中心化的服务中去承担这样的任务, 最终让系统的每秒查询率翻了一十倍, 用户也感觉不到任何不同。
千万不要被“全链”这种执迷不悟的想法给捆住了手脚。这道思考题考查的根本就不是你有多么擅长去调整那份合约, 它真正考验的是你敢不敢胆量十足地在你的方案之中写下这句话, 也就是“这里的环节完全没有必要去上链”, 或者更直白一点是说“此处无需借助于任何形式的区块链链接”。
我桌子上的那张思考题, 修改到第三个版本之后, 我才有胆子发给客户。大约从事设计工作就是这样子的事情, 不存在所谓的标准答案, 只有让自己把问题再追问一遍又一遍, 确认那是否真的是自己想要的样子。
转载请注明出处:枣强文明网,如有疑问,请联系()。
本文地址:https://www.zqwxw.com/imqb/9810.html
