提升开发效率的黄金法则：如何避免认知、沟通和非正常成本的陷阱

在前面的文章中我们聊了技术成本的精细化运营；聊了要识别出成本要素，找出每个要素的关键成本点，将成本定义为顾客付出的代价，根据成本的基本特性对其分类包括生产性成本、支持性成本、监察成本和浪费成本；聊了成本的核算以及成本和业务以及公司商业化策略的关系等等。

今天我们从一个技术团队的负责人角度来聊一下软件研发过程中的成本。

研发过程中成本主要包括研发过程的成本和对业务产生的影响而带来的「非正常成本」。而其中软件研发成本的核心是认知成本和沟通成本。

认知成本

认知成本是一个相对宽泛的概念，它涉及到所有获取、理解、处理信息以及进行决策的努力和资源。在一般情况下，认知成本可以分为以下几个部分：

1. 学习成本：这是指为了掌握新的知识、技能或工具所需要的时间和精力。如一个开发同学需要学习一种新的编程语言，那么这就会产生学习成本。

2. 理解成本：这是指为了理解新的信息或知识所需要的时间和精力。如阅读和理解一份复杂的技术方案文档就会产生理解成本。

3. 处理成本：这是指为了处理信息，比如进行分析、整理或应用，所需要的时间和精力。如分析一份用户行为数据报告就会产生处理成本。

4. 决策成本：这是指为了做出决策，比如评估选项、权衡利弊、制定策略，所需要的时间和精力。如选择一个软件开发框架或选择一个市场策略就会产生决策成本。

在实际应用中，降低认知成本通常是提高效率和效果的重要目标。例如，良好的用户界面设计可以降低用户的认知成本，提高用户体验；有效的信息管理和知识共享可以降低团队的认知成本，提高团队效率。

研发过程中的认知成本，其差异点在于对于事情的了解。从认知神经科学的角度来看认知成本又分为认知载入（ Cognitive load ）和认知投入（ Cognitive effort ）。

• 认知载入是一个信息处理的心理过程，是装载、把…的信息加载到工作记忆的过程。
• 认知投入是指在知识加工过程中付出的脑力及努力程度。

对于开发过程来说，认知投入往往相对平稳，成本的主要差异点在于认知载入，而认知载入和人的记忆相关。

记忆分为中短时记忆和长时记忆，中短时记忆一般只维持数十秒或数分钟，长时记忆可以存储很多年并可以被回忆，短时记忆中的内容如果不被刻意记录，可能会完全丢失。

工作记忆（Working Memory）是对短时记忆模型的一种扩展，代表一种容量有限的、在短时间内保存维持信息，并对这些信息进行心理处理操作的过程。工作记忆的内容可以源于感觉记忆的感觉输入，也可以从长时记忆中提取获得，并且后者是一个重要的来源。

据此，我们可以得出造成开发同学需要付出的认知成本的差异的关键原因在于：

• 载入工作记忆中的代码内容来源：如果是自己编写的代码，它将唤起长时记忆中的回忆，更快地加载对代码内容的理解；如果是别人编写的代码，所有的内容需要经感觉记忆输入，它将变得较难理解，并需要更多的时间与长时记忆中的内容建立关联，或写入长时记忆；
• 代码中的模式与长时记忆的关联性：如果代码遵循了一致的规范（包括命名、缩进、结构、接口标准等），大多数开发者都共享了这一规范（存于长时记忆），将能够更快地加载理解过程，从而提升处理速度；
• 代码中的领域知识与长时记忆的关联性：与编写规范一样，领域知识是另一种可共享的长时记忆内容，它也能够加速理解的过程。

基于此，我们可以从认知过程的改进，论证得出减少认知成本，或者说在平时积累认知的方法：

• 选拔正确的人： 以选拔/面试的方式，找到满足认知成本的人；
• 经常性的交叉评审代码：如果代码规模庞大，相比传统的代码走读方式通常为从核心模块开始，更推荐从活跃代码开始（如 30 天内的活跃修改范围），以更快地熟悉近期的工作；
• 共享且强制执行的标准和规范：代码规范，数据库规范，文档规范……；
• 共享的领域知识：包括系统顶层结构、如何开始工作和必须的业务知识，构建团队的知识库。

沟通成本

有同学说「白天在开会，晚上才能写代码」

有同学说「不是在沟通就是在去沟通的路上」

软件研发是高度协作的工作，沟通成本非常高。

沟通成本是指为了达成共识，传递和理解信息，以及协调团队成员间或者团队与团队之间的工作所需花费的时间和精力。在软件研发中，沟通成本包括以下三个方面：

1. 信息交流成本：包括团队成员之间进行面对面交流、写邮件、开会等方式的沟通所需的时间和精力。

2. 知识转移成本：当需要将知识或信息从一个团队成员传递给另一个团队成员时，可能需要进行培训、编写文档等，这都会产生一定的成本。

3. 协调成本：在团队成员之间协调工作，比如确定任务分配、同步项目状态、解决冲突等，都需要投入时间和精力。

不管是哪种成本，从沟通的角度，本质是一样的，都是一个信息传输的过程。

沟通过程中主体是发送者、接收者和渠道，主要操作是编码、传输和解码。

• 发送者：沟通的发起者，本次信息传输的主导者；
• 编码：整理信息，以自己的理解和技能把信息、思想与情感等内容用相应的语言、文字、图形或其他非语言形式表达出来的过程；
• 渠道：信息传输的载体，常见的渠道包括：语言、电话、文档、传真、电子邮件、各种 IM 工具等；
• 解码：接收者对所获取的信息的理解过程；
• 接收者：信息接收者、信息达到的客体，可能是一个人也可能是一群人，也可能没有人。

如我们想给比较多人的讲一个事情，一种性价比比较高的方式就是写文档或电子邮件发给这些人看，这个写文档/邮件，发给接收者阅读并理解整个文档的过程就是一次信息传输的过程，也就是一次沟通的过程。

在信息传输过程中，有较多的噪声会影响整个传输的效果，比如我们刚才说的写文档，编码的过程就是我们将想法、思想和逻辑转化成文档的过程，而每个人写文档的能力，对于问题的理解不一样，从而写出来的文档参差不齐，这里的差异就是我们编码中的一种噪声。

在语言沟通过程中，除了讲，还要听，做彼此的倾听者，沟通过程中随时调整沟通的方式和方向，以求达到沟而相通的目的。

从信息传输的模型来看，这里的倾听其实就是为了更好的解码，更好的接收传递过来的信息，而调整沟通的方式和方向是为了优化编码的方式，以适配对方的解码逻辑。

汉字其实很形象地表述了听的逻辑，听的繁体字写法是「聴」，拆开来看，它要求我们听的时候要用耳朵、眼睛和心来聆听，这样你才能准确地理解他人的意思。而简体字的「听」拆开是「口」和「斤」，这仿佛在告诉我们现代人听不再用耳朵, 而用的是「口」， 而且是根据对方的「斤」两来决定到底听还是不听。

从沟通的本质出发，降低沟通成本的策略可能包括：优化沟通方式和流程，提高沟通技巧，使用有效的工具支持沟通，以及建立明确的角色和责任，以减少不必要的沟通。

另外，从整体研发效率来说，可以设置不沟通的时间，如设置研发静默时间，专注于写代码。

非正常成本

非正常成本则相对难以预计和控制。它们可能源自多种因素，如项目延期、需求变更、技术难题、产品缺陷等。当这些问题出现时，团队可能需要付出额外的时间和努力来解决，这就产生了非正常成本。例如，如果因为技术难题导致项目延期，那么团队可能需要加班，甚至可能需要聘请外部的专家或顾问来帮助解决问题，这些都会增加非正常成本。

最为常见的非正常成本一定有过度设计和技术债务。

过度设计是指在开发过程中投入的工作远超过解决问题所需的程度，这通常体现在过于复杂的系统设计、不必要的功能，或过早优化的代码上。涉及到开发、维护和产品质量三方面，这种过度设计会导致更多的开发和测试时间，更复杂的维护工作，以及可能降低的产品质量。

技术债务是指由于短期内的快速开发和决策，而在长期内需要支付的额外工作。例如，为了赶项目进度，团队可能会选择快速但不完美的解决方案，而不是花费更多时间来寻找更好的解决方案。为了解决技术债务，可能需要进行代码重构或重新设计系统，这将带来额外的开发和测试时间。此外，技术债务可能会降低开发团队的生产力，例如，如果代码质量低，团队可能需要花费更多的时间来理解代码、修复错误和添加新功能。

比较特殊的一种非正常成本是线上事故，线上事故对于任何技术团队来说都是一种非常严重的非正常成本。这类事故可能会对用户产生直接的影响，包括用户体验降低、数据丢失、服务中断等。这不仅可能导致用户对产品或服务的信心降低，甚至可能导致用户流失。此外，严重的时候，线上事故还会导致公司的资产损失。

小结

在提升软件研发效率的过程中，技术团队需要有效地管理和控制「隐形」的认知成本、沟通成本和非正常成本。认知成本，包括获取和处理信息以及决策的代价，可以通过选拔合适的人才和制定共享标准来优化。沟通成本，主要涉及达成共识和协调团队工作所需的资源，可以通过优化沟通方式和明确角色责任等来降低。非正常成本，源自如项目延期、技术难题和线上故事等因素，其控制需要避免过度设计和及时偿还技术债务。

此外，团队需要有明确的计划，有效的项目管理和质量控制流程，并与业务部门和市场部门紧密合作。同时控制和防范线上事故也至关重要，技术团队需要在系统设计和开发过程中考虑安全性和稳定性，建立有效的监控和预警系统，并制定实施恢复和应急计划。

因此，掌握这些研发成本的管理和控制，以及有效的项目管理和防范措施，构成了提升软件研发效率的黄金法则。