2017年12月28日摄于日本高知。
“IT行业问题很多”，这是众所周知的事实。“IT行业很年轻”，这也是众所周知的事实。那么，要解决IT行业的很多问题，应当向其它不那么年轻的、更有经验的行业借鉴经验——这一点，似乎也没有异议。
可是，到底应当向哪些行业，借鉴哪些经验呢？
在我看来，其实各行各业都有值得借鉴的经验。之前我写过 《丰田生产方式的启发》，是借鉴制造业、精益生产的经验。今天，我想谈谈如何从演艺界借鉴经验。
谈起演艺界，IT行业的许多朋友大概是不屑一顾的，觉得太浮躁、太虚华、太夸张。没错，演艺界确实给人这样的印象。但是浮躁、虚华、夸张并不是全部，如果我们沉下心来，IT行业确实可以从演艺界找到不少值得借鉴之处。下面，简单谈谈我的看法。
首先值得借鉴的，是写剧本的态度。
我不知道这篇文章的读者里，有多少人清楚小说和剧本的区别。至少我是看了很多年小说之后，才真正了解小说和剧本的差别。在我看来，二者最重要的差别是，小说写起来可以天马行空，自由挥洒，而剧本写起来必须受很多限制，更像“戴着镣铐跳舞”。
具体来说，写小说更像“一个人的事情”，只要你喜欢，想怎么写就怎么写，基本不受其他人意志的强制——当然，写了之后是不是卖得掉，读者是不是买账，创作时并不需要关心。写剧本则是另一回事，它不但要受到导演、制片方的限制，而且还要有具体的影像思维，有精确的长度、节奏、成本控制的意识。一句话，写剧本更像对若干个变量的综合博弈、权衡取舍。许多好的小说之所以没法拍出来，原因就在这里。
写小说和写剧本的差别，很值得IT行业的产品设计借鉴。
我见过一些产品经理，完全是用“写小说”的态度来设计产品，一味追求设计的畅快和产品的炫酷，既不考虑内在逻辑，也不考虑工期、人力的约束，更不用说背后的数据支持了，完全靠“我有一个天才的想法”来支撑。结果不但开发过程变成了痛苦的煎熬，最终产品开发出来也收不到预想的效果。借用小说和剧本的差别也很容易明白其中的道理——天马行空的小说，未必适合拍成影视作品。
相反，合格的产品经理，或者说合格的产品设计，一定会明白“戴着镣铐跳舞”的事实，像写剧本那样，考虑到各种客观的限制因素，认真权衡取舍。这样做出来的设计，或许没有那么炫酷，成功率却是有保障的。
其次值得借鉴的，是剧本繁复但准确的描写。
下面这段文字写在小说里，应当没有任何读者感觉意外：
密林深处有一所“森林客舍”。这天早晨，远处有个人边唱边走近来。
我们知道，一万个读者就有一万个汉姆雷特。所以对于这段文字，其实人人都可以有自己的想象。对于小说而言，这样没有问题。但是作为剧本则万万不可，因为它太“抽象”了，缺乏具体的画面感，如果要演绎出来，一万个参与的人可能有一万种理解。因此如果写成剧本，大概会是这样：
舞台为中轴对称布局，左右两侧都是茂密的树林，右侧有一座小木屋，门上悬挂一面木牌，牌子上书“森林客舍”。布光是柔和的黄色，外面远处逐渐传来鸟叫声、风吹过树林的声音、脚步声。角色甲从舞台右边，一遍唱歌一边慢步登场……
剧本的描写虽然繁复，但是更具体也就更准确。从某种程度上说，可以保证“一万个读者只有一个汉姆雷特”。
实话说，我在看一些产品文档的时候时常有捶胸顿足的感觉，因为这些文档写得太抽象太写意了，许多具体的细节是空白，十个人看了起码会有九种理解。真正要开发的时候，就会发现苦难重重（还拿上面小说和剧本的差异举例子）：“森林客舍”到底是木头的还是水泥的？是在舞台左边还是右边？木牌子是挂在门上的还是立在门外？……
这类问题往往会在开发过程中反复出现，沟通不好就导致嫌隙丛生。每到这种时候，产品和设计人员往往会埋怨开发人员死脑筋，没有想象力，而开发人员会埋怨产品和设计人员文档不够详细具体…… 虽然我认为，好的团队里各种角色应当通力合作，迅速澄清误解、对齐认识。但我同时认为，好的设计也应当追求“一万个读者只有一个汉姆雷特”。最起码，可以对着剧本学学嘛。
除了剧本本身，演艺界值得IT借鉴的还有角色的设计。
许多不懂文艺的人认为，文艺作品中的角色是被作者操纵的木偶，作者想怎么安排他们的命运就怎么安排。但是现实显然不是这样。好的作品里的角色必须要可信，所以必须符合观众的某类想象，而不能恣意妄为。
比如“长接短送”是北方某些地方的风俗，但一定不是全国人民的习惯，如果某个南方角色给人接风吃面条，送人离去吃饺子，就会显得很突兀，很出戏，作品就不容易为观众所欢迎。所以创作者千万不要以为自己是全知全能的大神，一切都可以随意摆布。实际上，也有越来越多的创作者发现，角色本身有内在的逻辑性和规范性，在创作时必须要遵守，甚至是“虽然我想那么写，但这个角色只能这么安排”，这样创作看似受限，其实角色真实可信许多。
在IT行业的产品设计中，对用户“想当然”的做法也相当普遍。我曾见过一些产品，聚集了优异的资源，详细描述了用户的行为，设计了用户的行为轨迹。结果开发出来投入到市场上，与真正用户见面时，才发现真实的用户行为和偏好和自己想象的完全不一样。换句话说，从“用户应该懂这个图标、这个文案”到“用户此时应该点这个按钮”再到“用户接下来应该这么办”，完全是一厢情愿，完全没有真正站在用户的角度来思考。
第四点值得借鉴的，是拍戏的调度安排。
对于影视作品，我们往往是从前向后线性观看的。但是，作品拍摄时的顺序却和放映时的大不相同。简单说，拍摄是把整部作品切成一个又一个的镜头，根据每个镜头所需的资源来合理安排。
比如一部作品描写某个人从家里出发去远方，然后再回家，因为“出发之前”和“回家之后”的布景基本相同，所以多半是集中拍摄完再剪辑开放到整部片子的首尾，而不能分开拍摄。再比如作品中出现了多处零散的战争戏，一般都会集中拍完再剪辑开，而不会零散拍摄，否则道具的利用率就太低了。真实的拍摄过程还要复杂，因为还涉及到场地租期、明星的档期等等很多资源，这些资源往往代价不菲，而且有严格的限制。
看到这里，我常常会想起IT行业的项目管理。老实说，很多时候我觉得项目管理确实很难，但也做得确实很糟糕。没错，IT行业本身要求创意，不能管得太死太严格，但有时候资源管理也确实太简陋了，粒度太粗，也没有识别关键资源，做到合理运用。
亏得主要技术人员往往不像演艺明星那样四处拍戏，“档期安排”不算必须慎重考虑的因素。无论如何，开发的成本其实是有不少水分可以挤的。有志于此的项目经理，不妨去了解一番影视作品的拍摄调度，相信一定会受到启发。
以前看过卡尔·波普尔的一句话，我印象很深：学科的划分只是基于知识的需要，问题本身是不分学科的。所以我经常在想，IT行业的某些问题，是不是为这个行业所独有，是不是可以从其它行业得到一些借鉴和启发。
这些年来我越来越确信，其实许多问题并不是IT“独有”的，其它行业的许多经验确实可以启发我们举一反三。今天我谈了值得从演艺界借鉴的几点，如果你有不同意见，或者你觉得其它行业也有值得借鉴的地方，欢迎给我留言。