周一晚上好，我是蓝色蒜头
2023 年 12 月 18 号，欢迎收听短播客第 49 期
第 47 期的时候
我们在谈到游戏实现的过程里
曾经提到
把想象转化为实际产品
需要经验和技巧
几乎不可能以直觉来做到
今天从软件开发的角度
简单展开
讲讲这个地方的难度到底在哪里
我以前做过不少的与企业知识管理、知识库
相关的系统
多数这类系统里都会有内容检索、关键词搜索这样的功能
甲方用户在描述很多功能期望的时候
往往会从使用体验的角度来思考
倒不是说这个角度有什么问题
不让用户谈使用体验，那他也不好谈什么
只是这个过程里，经常会因为体验的简洁
而把开发也想象的过于简单，低估了实现的成本
像前面提到的这些检索功能
很多用户会这样描述
你做一个框，我可以打字上去
旁边放一个按钮
点一下就搜出来相关的东西
不用多复杂
然后可能还要补充下一句
「就像百度那样」
哈哈
用户做这些描述的时候
当然是从体验的角度出发
说的其实也没有错
问题在于，用户很容易把
体验描述中涉及到的事物
就当成开发的全部
在我过去的沟通里
真的有用户会觉得
上面的描述，对应的全部的开发工作量
就是做一个输入框，做一个按钮
做一个结果呈现列表
甚至当他说
「就像百度那样」的时候
他内心是很认真的
在很多思考比较粗糙的人那里
不管是百度，还是淘宝，还是抖音
开发上都是很简单的
只需要很少的开发人员就能复制
其实体验上越简洁的功能
其背后要考虑的因素
和开发的复杂程度
反而往往越高，而不 是越低
检索这件事情
都不需要深入到具体的实现原理层面
就从业务过程来稍微深入的想
仅谈体验，差的东西会很多
首先检索的范围是什么
是企业内部的所有文档
还是会包括互联网的内容
哪怕是局限于企业内部文档
什么层级的企业人员会有什么查看权限
查看权限是按照不同的文档库来横向分
还是按照文档本身的权限标识来纵向分
再进一步追问
目前企业里的文档是什么形式存在
word pdf 电子邮件 在线文档
有没有已经归纳的系统
还是说目前分散在各个办公电脑里来回传递
很多企业甚至在想要做检索的时候
根本没有意识到他现在并没有一个集中文档库
应该先建立这个集中文档库
再来谈检索
而他心目中模糊的开发预算
并不包含这一部分
这就是错估了成本
负责的有经验的乙方的需求梳理人员
对于甲方用户的描述不应该照单全收
应该在一些可能考虑不足
导致成本错估的地方
适当的提出疑问
而负责的有经验的甲方用户
应当能够解答这些疑问
或者自己事先就在业务过程方面考虑得稍微多一点
不太靠谱的用户
会以「你们开发者经验丰富，
一切交给你们考虑，我们信任你们」
这样的话来推脱
在我的职业经历里
类似这样的话在每个项目上都要听到一两次
但要是真正这样做了
做出来的东西，让人上手开始用了
问题和抱怨就一大堆了
为什么很多 TOB 的软件
就是企业软件
最后的成熟版本会卖得非常贵
其实就是在多年开发中踩过各种坑
软件能应对的情况非常多
以至于能避免掉非常多这样的低效沟通
做到：只要甲方出得起钱，就不用想太多
所以其实，不靠谱可能有时也没关系
只要出得起价钱
只是这个价钱是原本的 10 倍，100 倍，还是 1000 倍
就确实不好说
可以说，表面上，双方探讨的是需求理解的一致
功能定义的一致
但也许事实上，都是围绕着成本理解的一致
所谓的成本，归根到底都是时间和预算
回到检索功能上
我们克服了艰难
最后按照用户的描述
做出了符合描述的检索功能
用户刚试用就觉得不好用
就来投诉
原因是
「在搜索框里打完了字，按回车，什么反应都没有」
可是，前面他描述的时候
只说了「按按钮出结果」是吧
这听起来像个玩笑
其实也说明了单纯的体验描述
转化成实现的另一方面的困难
也就是一些体验角度的描述或想象
是包含所谓「默认常识」的
而默认常识这件事情
第一，不一定对所有人都默认，你的默认不等于我的默认
不是抬杠，而是我们的经历、经验确实都不同
第二，所有的要素，哪怕是「默认」的
在具体开发时都是要去好好实现的
想的时候的默认并不是说做的时候
就什么都不用做，它自动就会有
上面说的是一个软件领域里
非常浅显的小例子
来说明体验想象转化成实现要面临的难点
而电子游戏领域，是软件领域的一个子集
或者说更高度的集成
软件开发里我们会遇到的各种问题
都有机会在电子游戏开发时遇到
而电子游戏其实比上面举的这个简单例子
往往还要更加麻烦
从软件的大方向划分来说
电子游戏其实绝大多数要划分到 TOC 软件
也就是要直接面对非企业消费者
TOC 软件相比于 TOB
在需求转化上是更加缺乏直接 依据的
企业软件的需求来源是企业
甚至功能清单也是主要由企业来提出
本质上就是去专门打造或者配置一个
符合特定企业定制化要求的软件
所以这样的软件，单价会极其的昂贵
而电子游戏，目前好像还没有听说过
需求来源于玩家，玩法要素全部由玩家提出
开发团队抛掉自己的想法，只做定制实现这样的游戏
有朋友说这不就是外包吗
这还真不是外包
因为外包发包的人也是企业
这些外包最后是要集成起来对外销售的
而不是说做完了留下来自己玩
玩家提需求
开发团队做完了
玩家自己拿来玩
这样的事情，我不好说绝对没有
但应该很稀少
少到不足以作为一个现象去讨论
就算有这样的游戏开发形式
我觉得也会是天价
做出来也大概率不会让出钱的玩家满意
所以其实绝大部分的游戏开发
在面对实际的玩家想法时
像是面对迷雾一样
很难直接在产品还不存在的时候进行有效的沟通
多半还是以制作人自己的想象作为开发的起点
而当体验的想象和具体的实现
都要归纳到一个人或者说一个团队上的时候
前面 说的那种考虑不足，认知不足
导致的成本错估的问题
因为可能缺乏外部力量
就更加难以及时修正
导致很多游戏项目做到一半
发现想象不能转化成实现
如果强行做下去，成本是无底洞
所以只好转成肉鸽
或者就不做了，砍掉
及时止损
为什么有的很小的个位数人员的团队
甚至个人开发者
在不太长的时间里
就做出了风靡世界
甚至引发很多人模仿的游戏
而很多游戏游玩经验丰富
见识似乎不低
号召力也看来很强的人
去尝试做游戏
几年下来花了也不算太少的钱
还是没有什么成果
带来这种差别的
其中一个重要的原因
就是从体验想象到转化成实现的
成本估计错误
这一期我从非游戏的软件开发的角度
来引出这个话题
但是由于举的例子不在游戏方面
所以可能还是不够充分
我会再找另一期的时间
从具体的游戏场景的角度
来谈谈体验想象转化成实现的难度
但不是下一期
下一期聊其他内容
今天就先到这里
祝大家进步，祝 大家晚安
过好 2023 年最后的两个星期
再见！