流水的代码，铁打的案子

开发游戏那几年，办公室里不太平。

干系人有三方：策划，美术，程序，标准的搭台唱戏配置，有《三国志》珠玉在前，这里就不再展开诸如“勇如关张例会互喷，多智近妖公厕串联”的两马错蹬，单说一下程序和策划沟通的一个切面：代码和策划案。

无法填满的口子

当时开发管理模式正从scrum向白板转型。核心在于快出最小可用原型，批判也好称赞也罢，快速迭代出下一个版本才是终极追求。一般的流程是：策划结合市面流行与未来趋势，赶出一版策划案；程序拿过来一看，虽然麻烦好在没什么难点，开始整吧。

程序开发完，策划一看：这是啥啊？我案子说得这么明白，你给我一个半成品都算不上的？大清药丸啊！于是拿给了主管产品的boss：“这怎么玩啊？加班重做！”程序也闹嘀咕：不是说最小原型吗，就一个礼拜时间，让我按像素细抠，一个月也不行啊！而且，流程主逻辑不是跑通了吗？

很明显，冲突是由于两边的期望不同造成的：策划希望程序能将自己的vision/idea或者脑海中的游戏画面，转化成屏幕上实际可以操作的应用；而程序在硬性截止日期的压力下，认为把最基本的逻辑实现完毕就可以，反正可以继续迭代。策划和程序对目标的不同认识，导致了南辕北辙，互相不能接受。

而且，树状的逻辑流程，开发实现到“主支完备”和“所有分支完备”，按照树叉分层多少，工作量相差3到无穷倍。页游这种简单点普遍逻辑不超过3层的，大概是6倍左右......

脑补和deadline

案子一出，除非写成像当年IBM PC使用手册那样的好几块砖头似的大部头——其实只说了怎么开关电脑、访问文件——否则对细节的描述肯定是稀疏的，细节都在策划的脑海里。而程序实现极其依赖细节，如果缺失，比如“购买体力对话框，在没充值的时候和充值的时候，点‘取消’是同一个逻辑吗？”等等数以百计这种问题，实在没法一一沟通，只好脑补了。

文字，限于写作和阅读水平，沟通效果很可能要乘以两个1/2；而在有固定开发截止日期的情况下，指望程序员脑补出策划的要求，只能是美好的想像......

硅谷有的产品经理到项目上，先做个超级简单的功能，来磨合团队，增进感情并没有达成一些基本的共识，能有效减少在一个组织里因为期望目标没有达成产生的恐惧感和反应过度。获得了大家的充分信任之后再挑战高难度，可能是一个好方法，然而我们当时采用了——

不是办法的办法

深度交流

策划案的作者和开发者坐在一起，结对编程。策划一旦发现程序想偷工减料，就会指正；而程序也可以免除脑补之勉为其难，随时向策划发问。终于，两边都能接受的产品，逐渐成型了。代价是策划和程序都至少增加了一倍的工作时间，比如策划在程序凝神思考时，只能发呆；而程序的沉思也经常被策划打断。——没有万能钥匙啊！

最好的办法

《炉石传说》，开发人员都是全才，案子我出，代码也是我写——只要画画草图，大段冗余而又容易引起误会的描述都可以省了！恳谈会我自己和自己开就行，产品还倍儿帮！

有歌云“假如人人都献出一点爱，世界将变成美好的人间”，可惜，爱是解决一切问题的终极方案，同时，也是终极的稀缺物。不管铁打的还是流水的，终将雨打风吹去。除了汗水和灵感，什么也不需要。