打破部门墙的沟通协议

第12章　打破部门墙的沟通协议

2002年5月的一个早晨，岩田聪站在任天堂本社大楼的电梯里，手里捏着一份经营企画部提交的GameCube软件发行计划。电梯在每一层停靠，有人进进出出，每个人都在鞠躬，每个人都叫他“社长”，但他们的眼神里有一种东西他太熟悉了——那种打量外来者的谨慎。他在HAL研究所经历过同样的眼神，那是1992年秋天，他作为新社长第一次走进那家濒临破产的公司时，员工们看他也是这样的。只不过这一次，审视他的不是几十个焦虑的程序员，而是一个拥有数千名员工、建立了复杂部门体系的百年企业。电梯门在三楼打开，一个穿着白色短袖衬衫的课长走进来，看到岩田聪，明显愣了一下，然后迅速鞠了一躬，转身面向电梯门站着，脖子后面渗出了细密的汗珠。岩田聪注意到他手里拿着的文件夹上贴着“硬件规格变更申请表”的标签。这种表格他见过太多次了——在HAL研究所跟任天堂合作开发游戏时，每次硬件团队修改了一个技术参数，第三方开发商都要重新填写一整套适配文件。

那是1990年代初期的事情，现在已经是2002年了，这张表格的格式几乎没变过。电梯到达顶楼，岩田聪走进经营企画部的办公室，把GameCube发行计划摊在桌上。他用红笔在上面画了一个圈，圈住的是“续作”两个字。这不是他第一次注意到这个问题。从2000年6月被招入任天堂本社担任经营企画部部长开始，他翻遍了公司过去三年的产品规划文件，发现了一个令人不安的模式：任天堂的游戏阵容越来越依赖既有IP的续作，新title的数量在逐年下降。这本身不是问题——《超级马里奥》和《塞尔达传说》的续作仍然是业界最高水准的作品——问题在于，这些续作的创意方向越来越保守，像是一个人在小心翼翼地走一条已经被证明安全的路，而不是在探索新的可能性。岩田聪把企画部的几个课长叫到会议室。他没有批评那份发行计划，而是问了几个问题。第一个问题是：“这些项目的立项讨论，硬件部门参与了哪几次？”课长们互相看了一眼，最后是资历最深的那位开了口：“硬件规格已经确定了，所以软件这边是按照规格来做规划的。”

“我没有问是不是按照规格，”岩田聪的语气很平静，“我问的是硬件部门有没有参与讨论。”

会议室里沉默了大概十秒钟。那十秒钟告诉岩田聪的信息，比之前看过的所有文件加在一起都多。任天堂本社的部门墙不是一道矮墙，而是一堵承重墙——它嵌入在公司的组织结构、汇报关系和日常习惯里，以至于人们已经意识不到它的存在。硬件部门设计主机，软件部门往上面做游戏，营销部门把做好的游戏卖出去。三个环节各自运转，彼此之间的信息传递主要靠正式的规格文档和审批流程，而不是靠人与人之间的对话。这不是某一个人的问题。这是任天堂在N64时代积累下来的组织惯性。当时公司从红白机和超级任天堂的巅峰期走过来，内部的职能分化越来越精细，每个部门都形成了自己的一套专业语言和工作节奏。这种专业化在产业快速扩张的1990年代曾经是优势——它让任天堂能够在短时间内同时推进多个大型项目——但到了2000年代初，当索尼PS2和微软Xbox开始用开放平台策略吸引第三方开发商时，这种部门壁垒开始变成致命的弱点。岩田聪没有在会议室里追究责任。

他知道追究没有用——那些课长们不是不愿意跨部门沟通，而是整个组织结构没有给他们这样做的空间和激励。他用了另一种方法。从2001年初开始，岩田聪在经营企画部推行了一项被他私下称为“接口调试”的试验。他要求每一个新项目的立项文件必须附带一份“跨部门沟通记录”，列出在立项阶段跟硬件、软件和营销三个部门分别进行过的讨论内容。记录不要求很长，但要求具体：讨论的日期、参与人员、涉及的技术或市场问题、达成的共识或明确的分歧。这份文件没有标准模板，没有审批流程，只有一个要求——它必须是真实的讨论记录，而不是事后补写的走过场文书。这个要求看起来温和，执行起来却遇到了巨大的阻力。最先提出异议的不是基层员工，而是中层管理者。一位在硬件部门工作了二十年的部长私下找到岩田聪，礼貌但明确地表达了不满：“岩田部长，我们每周都有跨部门的进度同步会议，会议纪要也会抄送各相关部门。现在再加上这个沟通记录，不是在重复劳动吗？”

岩田聪认真听完了他的意见，然后问了一句话：“那些进度同步会议，上一次有人提出反对意见是什么时候？”

那位部长没有立即回答。这不是一个反问，而是一个诊断问题。岩田聪参加过那些跨部门会议——他坐在角落里旁听，不发言，只是观察。他看到的是一个个精心准备的汇报演示，每个部门的发言人都在展示自己团队的工作成果，但几乎没有人会在会议上说“我们遇到了一个问题，需要其他部门帮忙”。不是因为问题不存在，而是因为在这种正式场合暴露问题，会被视为自己部门的失职。岩田聪对那位部长说：“进度同步会议解决的是‘告知’问题——让各部门知道彼此在做什么。但我需要解决的，是‘理解’问题——让不同专业背景的人真正理解彼此的工作逻辑和约束条件。”

为了说明这一点，他举了一个例子。在HAL研究所开发《星之卡比》初代时，程序员发现Game Boy的硬件性能不足以同时处理卡比的移动、敌人的AI和场景的动态效果。按照常规做法，程序团队应该接受这个限制，砍掉一些特效。但他们没有。他们找到了硬件团队，花了整整一天时间讨论Game Boy的图形处理机制，最终发现了一个被文档忽略的技术特性：可以通过调整渲染优先级来节省性能开销。这个发现的前提是程序员愿意花时间去理解硬件工程师的工作，而硬件工程师愿意耐心解释那些在他们看来“理所当然”的技术细节。“任天堂现在的问题，”岩田聪说，“不是缺乏这种能力，而是缺乏让这种能力发挥出来的环境。”

他决定从最棘手的地方开始动手。2001年春天，GameCube的硬件团队和软件团队之间爆发了一次严重的分歧。起因是GameCube的光碟读取速度达不到某些类型游戏的需求——特别是那些需要频繁加载场景的RPG和开放世界游戏。硬件团队认为这是软件团队对光碟格式理解不足导致的，因为程序员习惯了卡带时代的即时读取，没有针对光碟的特性优化代码。软件团队则认为硬件规格在设计阶段就应该考虑到游戏的多样性需求，而不是让所有开发者去适应一个狭窄的技术窗口。这个争论在部门之间来回拉扯了将近两个月，双方都写了长篇的技术分析报告，抄送给各自的部长和岩田聪的办公室。岩田聪读完了每一份报告。他发现一个核心问题：硬件团队的报告用的是电路工程师的语言——寻道时间、数据传输率、纠错算法的冗余度；软件团队的报告用的是游戏设计师的语言——场景切换的节奏感、玩家等待时间的心理阈值、不同游戏类型对加载频率的敏感度差异。

两份报告都在各自的语言体系里完全正确，但彼此之间几乎没有交集。岩田聪做了一件在他之前没有人做过的事。他把硬件团队的三名核心工程师和软件团队的三名技术总监叫到一间会议室，在白板上画了一张GameCube光碟读取机制的简化原理图。然后他对硬件工程师说：“从现在开始，我不会让你们用任何我不懂的术语。如果你们说了一个我不理解的概念，我会打断你们，要求你们用另一种方式解释，直到我能听懂为止。”他转向软件团队的人，“你们也一样。有不懂的，当场提问。不要怕显得无知——在这个房间里，无知的唯一表现是不提问。”

这场会议从下午两点一直持续到晚上七点。起初的气氛是僵硬的。一个硬件工程师在解释光碟寻道机制时，习惯性地用了一个缩略词，岩田聪打断了他：“请你把这个词翻译成‘光碟上的激光头需要多少时间从一个位置移动到另一个位置’。”那个工程师愣了一下，重新组织语言讲了一遍。讲到第三遍的时候，软件团队的一个技术总监突然插话：“等等，你说的‘寻道时间在读取小文件时影响微乎其微’——这个‘小文件’具体是多小？我们场景里用的纹理文件，大小范围是多少？”

这个问题让硬件工程师打开了笔记本电脑，翻出了之前没有给软件团队看过的技术测试数据。数据显示，当单个文件小于64KB时，光碟的寻道时间几乎可以被忽略；当文件超过512KB时，寻道时间会开始显著影响读取速度。软件团队的技术总监盯着那组数据看了几分钟，然后说了一句让所有人都沉默的话：“我们之前完全没有拿到过这组数据。我们一直以为光碟的读取性能瓶颈是稳定的，所以把所有纹理文件都打包成了统一大小的数据块。”

岩田聪在白板上写下了两个字：“假设。”然后他圈起来，在旁边加了一个箭头，指向“格式错误”四个字。“硬件团队假设软件团队会针对光碟特性优化文件结构，”他说，“软件团队假设光碟读取性能在任意文件大小下都是一致的。这两个假设都没有错——在各自的专业领域内，它们都是合理的。但当这两个假设撞在一起的时候，就产生了格式错误。”

这场会议的直接成果是硬件团队向软件团队开放了之前被视为“内部技术文档”的光碟性能测试数据，软件团队则根据这些数据重新设计了纹理文件的打包策略。修改后的加载效率提升了大约百分之二十，足以支撑原本被认为“在GameCube上做不了”的几款游戏的场景设计需求。但岩田聪真正想要的不是一个技术解决方案。他想要的是一个组织记忆——让参与过这场会议的人记住：当他们愿意花时间去理解另一个部门的工作逻辑时，他们能找到被“专业壁垒”遮住的解决方案。这种跨部门“翻译会议”在2001年变成了任天堂内部的一个半制度化实践。岩田聪不强制所有项目都这样做——他知道强制会导致形式主义——而是选择那些部门分歧最严重、延期风险最高的项目作为试点。每场会议他都会参加，不是作为决策者，而是作为“翻译者”：不断要求发言者用其他部门能听懂的语言重新表述自己的立场，不断纠正那些隐含了专业预设的概念误用。效果是渐进的，但方向是明确的。

到2001年底，GameCube的第一方软件开发周期平均缩短了大约十五个百分点。缩短的关键不在于加班或增加人手，而在于减少了开发后期的返工——当硬件和软件团队在项目启动阶段就充分沟通了彼此的约束条件后，那些在后期需要推倒重来的技术方案大大减少了。但这套机制在管到营销部门时遇到了新的障碍。任天堂的营销部门在公司内部一直是一个相对独立的王国。它的工作逻辑跟硬件和软件部门完全不同——硬件部门关心的是技术参数，软件部门关心的是交互体验，而营销部门关心的是消费者认知和市场定位。在N64时代，营销部门的策略基本是延续超级任天堂的成功模式：强调任天堂第一方游戏的高品质，针对核心玩家群体进行精准投放。GameCube发售初期也基本沿用了这套策略。岩田聪发现的问题在于，营销部门的市场数据很少回流到产品开发环节。

营销人员会定期做消费者调研、分析竞争对手的销售数据、追踪不同区域的渠道反馈，但这些信息大部分被用于制定促销方案，很少被系统地传递给硬件和软件团队。有一个例子让岩田聪印象深刻：2001年北美市场的数据显示，GameCube在家庭用户中的购买决策很大程度上受到“家中年龄最小的孩子”的影响——通常是八到十二岁的孩子向父母提出购买请求。但这个洞察从来没有被传递给软件团队，后者仍然在用“核心玩家”的假设来设计游戏的难度曲线和新手引导。岩田聪把营销部门的部长请到自己的办公室，不是要批评他，而是提出一个具体的问题：“如果我在软件团队，我现在最需要从你们这里知道什么？”

这个问题让那位在营销领域工作了二十多年的部长想了很久。最后他承认，他从来没有被问过这个问题。“以前的做法是，”他说，“软件那边做出什么产品，我们负责把它卖出去。产品好不好卖，是营销的问题；产品做得好不好，是开发的问题。”

岩田聪给他讲了一个故事。在HAL研究所开发《星之卡比：梦之泉物语》时，程序员们最初打算把游戏设计成一个硬核的平台跳跃游戏，难度曲线从第四关开始急剧上升。但当时负责市场调研的一位同事找到了开发团队，给他们看了一组数据：购买初代《星之卡比》的用户中，有将近三分之一是不到十岁的孩子，而且这个比例在欧美市场更高。开发团队根据这组数据调整了难度曲线——不是降低，而是让挑战变得更有层次：前三关提供完整的新手引导，中间几关逐步引入新机制，最后两关才释放全部难度。这个调整后来被认为是《星之卡比》系列能够在全球市场取得成功的核心设计策略之一。“如果那位市场调研的同事没有敲开我们办公室的门，”岩田聪说，“我们可能会做出一款只有硬核玩家喜欢的游戏。《星之卡比》也就不会成为后来那个能跨年龄层传播的IP。”

这个故事在营销部门内部引起了一些反响。不是因为它的道理有多深刻——这些道理营销部门的人都懂——而是因为它来自社长的亲身经历。岩田聪不是在用一个管理学理论教育他们，而是在分享一个程序员如何被市场数据改变判断的过程。到了2002年初，岩田聪在任天堂内部推行的跨部门沟通实践有了一个更具体的承载形式。他开始定期组织“社长问答”会议，每次邀请来自不同部门、不同层级的员工参加，回答他们提出的任何问题。这些问题事先不需要经过部门主管的审批，问答的记录会在公司内部公开。最开始的几场问答会上，问题都很温和，但岩田聪等的是有人敢第一个问出尖锐的问题。第四次问答会上，一个来自软件部门的年轻程序员举手了。“社长，我觉得我们公司有一个问题，”他说，“每次项目延期，最后压力都落在基层程序员和美术身上。但延期明明是因为前期沟通没做好、中间反复改规格造成的。我们加班是应该的，可是如果加班的根源不解决，每次都是我们扛，大家真的很累。”

会场的声音消失了。岩田聪没有用“我理解你的感受”这种套话来回应。他沉默了几秒钟，然后说：“你说得对。延期的根源在流程的开头，不在结尾。我们今天在座的有硬件部门的同事，也有营销部门的同事——我想请你也听听他们的角度。硬件那边，有没有被临时改规格折腾过的经历？”

一个坐在后排的硬件工程师犹豫了一下，举了手。“有。GameCube开发初期，软件部门提了一个对模拟摇杆精度的新需求，那时候我们的电路板布局已经确定，改一个组件意味着整个板子重新设计。但那个需求确实合理——是《路易吉洋楼》团队提出来的，他们需要更精确的吸尘器指向操作。我们最后改了，但交货期延了两个月，我们部门的工程师也在工厂里盯生产线盯了两个月。”

软件部门的另一个声音接上了：“那为什么不早点让我们知道那个精度是可以调的？如果我们知道有技术空间，我们一开始就会提出需求。”

“因为你们从来没问过，”硬件工程师说，“你们只看了规格文档，然后觉得‘这就是既定的，不能动了’。”

这句话像一把钥匙。会议室里开始出现此起彼伏的对话，不同部门的人第一次在一个安全的环境里，听到了彼此视角下的同一个问题。岩田聪大多数时候在听，偶尔插一句话把讨论拉回到具体的技术或流程细节。他没有试图在当场得出解决方案，他要的是让这个对话本身发生。这场问答会的记录后来被整理成一份内部文件，标题是《关于延期问题各部门视角的实录》。它没有任何管理层给出的结论或指示，只是客观记录了每个人说的话。但正是这份文件在任天堂内部产生了意想不到的影响。那些以前只在私下抱怨“延期都是因为其他部门不靠谱”的员工，第一次看到了整个延迟链条的完整图景：营销部门的模糊需求导致软件团队的设计方向反复调整，设计方向的反复导致硬件规格被临时修改，硬件规格的修改导致测试周期被压缩，测试周期的压缩导致基层开发人员在发售前连续加班。这不是任何一个部门的错，是整个信息传递链条的系统性断裂。岩田聪把这种断裂比喻为“组织版本的依赖冲突”。

他在HAL研究所当程序员时，最怕的bug不是代码写错了，而是依赖库的版本不一致——A模块调用的是3.0版本的函数，B模块调用的是2.0版本的同一个函数，每个模块单独运行都没问题，但放在一起就崩溃。任天堂现在的情况是一样的：每个部门在自己的版本里都是正确的，但这些版本之间没有对齐。2002年5月，山内溥正式宣布退休，岩田聪接任第四任社长。这个消息在任天堂内部引起的震动，远远超过外部媒体的预料。山内溥执掌这家公司五十二年，它的组织架构、决策流程和企业文化几乎都是他一手塑造的。现在他把这一切交给了一个四十二岁的程序员——一个在任天堂本社只待了两年、没有山内家族血统、没有在京都总部从基层一步步爬上来的外来者。在交接仪式上，山内溥对在场的高管们说了一句话：“我选岩田，不是因为他跟我一样，而是因为他能做我做不了的事。”

这句话的含义，在场的人要花好几年才能真正理解。岩田聪接任社长后的第一个月，没有做出任何重大的人事调整。他没有撤换任何一个部长，没有推翻任何一项已经上马的开发计划，甚至连办公室都没有换——他继续待在三楼经营企画部那间跟其他课长差不多大的房间里，窗外对着另一栋楼的灰色墙壁。他的理由很简单，也完全符合他的程序员思维：如果系统正在运行，不要随便修改核心模块；先观察，先收集数据，先理解每一个组件之间的调用关系。但他的确做了一件事。他把任天堂本社的所有部长召集到会议室，没有拿讲稿，没有放PPT，只是在白板上画了一个简化的组织结构图。他在每个部门旁边标注了它们输出的“数据类型”：硬件部门输出的是“性能参数”（整数），软件部门输出的是“用户体验”（字符串），营销部门输出的是“市场反馈”（浮点数）。然后他在三条箭头的交汇处画了一个红色的叉。“这里，”他用笔尖点了点那个叉，“是我们的bug所在。不是任何一个部门出了问题——每个部门的输出在自己的类型定义下都是正确的。但当这些输出传递给另一个期望不同类型输入的部门时，就会产生错误。”

“过去我们解决这个错误的方式，是让山内社长做最终裁决。他是一个天才的仲裁者，能够同时理解硬件、软件和市场的语言。但现在他不在了。我们不能指望再来一个山内社长——我们需要重新设计整个系统的接口协议。”

他停顿了一下。会议室里一片安静，几位年长的部长脸上带着克制的表情，但没有人打断他。“未来两年，我最重要的工作不是决定我们要做什么产品，而是让硬件团队、软件团队和营销团队能够真正听懂彼此在说什么。”

这场会议后，岩田聪开始系统地扩展他在经营企画部部长任上启动的跨部门沟通实验。他要求每一个部门的周报中增加一项内容：“本周与其他部门沟通中发现的一个认知差异。”这个要求不高——每个部门只需要写一件事，不需要长篇大论的分析，只需要描述“我们原来以为对方是这样想的，沟通过后发现对方其实是那样想的”。最初几个月，这些记录都是走过场的敷衍——“没有显著差异”是最常见的回答。岩田聪没有批评任何人，只是在一次管理层例会上读了其中几条写得比较认真的记录，然后说了一句：“这六个字节省不了时间，但可能会让我们在下个项目中多加班两个月。”

敷衍慢慢地减少了。不是因为部长们被说服了，而是因为他们的下属开始主动参与岩田聪组织的跨部门讨论会，那些讨论会上产生的信息和解决方案让项目周期实实在在地缩短了。当一个课长发现自己的团队因为参加了技术翻译会议而少熬了两个通宵，他就不再需要上级的命令去配合这套机制了——他自己会主动问：“下个项目启动前，能不能安排一次跟硬件的对齐会？”

这就是岩田聪的变革逻辑：不靠权力强制推行，而是让信息流动的好处先显现在一部分愿意尝试的人身上，然后让这些成功案例去拉动整个组织的惯性转向。但这套逻辑的推进速度，赶不上市场变化的速度。2002年第四季度，GameCube的全球销量数据摆在了岩田聪的办公桌上。累计销量不到PS2的三分之一，在北美甚至被新入局的微软Xbox超过。第三方开发商的信心在动摇——已经有至少四家中型发行商私下通知任天堂，他们在下一财年不会为GameCube开发独占游戏。零售商也在调整货架分配，一些连锁渠道已经把GameCube从主推位置移到了次推区。岩田聪在投资者说明会上面对的是一个比公司内部元老派更难应付的群体：金融市场分析师。他们对任天堂内部正在进行的那场静悄悄的组织变革毫无兴趣——不，不是毫无兴趣，是根本不认为那些东西跟业绩有关系。他们问的是硬件销量、软件附着率、第三方的独占协议数量。只有一个指标能让他们满意：数字在上季度之上的上季度之上再上升。

岩田聪没有回避这些压力。他在2002年第四季度的投资者说明会上承认了GameCube的市场表现未达预期，但他拒绝了一个反复被提起的建议——退出硬件市场，像世嘉那样转型为纯粹的软件发行商。他的回应是：“任天堂创造价值的核心方式，是让硬件和软件由同一群人设计。当我们失去这种整合能力时，我们就失去了在市场上的唯一性。”

这句话背后的逻辑，正是他过去两年里一直在建立的那套跨部门沟通机制。任天堂在硬件赛道上永远不可能跑赢索尼——这是资源决定的，不是技术决定的。但任天堂可以做出其他平台无法复制的产品，前提是软硬件团队真的在共同创造，而不是各自完成然后拼接。这套逻辑在公司内部正在被越来越多的人接受，但在公司外部——在投资者、分析师、第三方开发商、零售商和数以百万计的游戏玩家面前——它还没有被证明。2003年1月，一个寒冷的冬日早晨，岩田聪比平时早了一个小时走进办公室。他在空无一人的走廊里站了一会儿，看着墙上那些花札时代的老照片和N64时期的纪念海报。然后他走进自己的房间，从抽屉里拿出一本没用过的笔记本，在第一页上画了一个大大的问号。在那页纸上，他一笔一划地写了三道题：一、如果任天堂继续按照索尼和微软定义的规则竞争，胜算有多大？二、如果不按照他们的规则，我们的规则应该是什么？三、要落实这个新规则，组织内部需要什么样的能力？他坐在那儿看了这三道题很久。

窗外，京都的冬天在慢慢转灰。但他的手始终没有抖动——他清楚地知道，任天堂如果要走出困境，需要的不是更激进的权力重组或更快的产品节奏，而是一个更根本的战略转向：不追赶对手的强度，而改变竞争的维度。这种转变的前提，是他已经植入到组织内部的那套沟通机制——当硬件、软件和营销部门能够真正相互理解时，他们就有可能共同创造出一种不在现有军备竞赛赛道上的产品。但那只是前提，不是答案。手机在桌上震动了一下。是宫本茂发来的信息：“那件事，什么时候聊？”

岩田聪回复了两个字：“今天。”

他放下手机，在那三道题下面又写了一行字。这次写的不再是问题，而是一个指令。它指向的不是GameCube的补救方案，也不是下一代主机的性能参数，而是一个将在此后两年里彻底改变电子游戏产业竞争格局的战略方向。但此刻，它只是笔记本上的几行字——一个程序员在京都冬日的办公室里，独自得出的一个结论。窗外，这个冬天最后的一场冷雨开始落下来。整座大楼的暖气管道发出低沉的嗡嗡声，像一台正在编译的程序，正在把几行代码翻译成足以驱动庞大系统运转的底层指令。