一直说要把《微信背后的产品观》这本书看完，一直没顾得上，这次临时出差到厦门的路上带上了，动车上的时间把书看完了，去的时候看了一遍，回的时候看了一遍，看完，写下这篇文章。

这本与其说是书，不如说是演讲实录。书的内容来源自张小龙在 2012 年的那次著名的 8 小时演讲，2016 年被整理成书稿，在 2021 年决定出版。好的内容是经得起时间考验的，在 9 年之后出版，在 12 年后的今天来看也不过时，甚至部分观点会刷新我们的一些认知。

以下是我在读这本书的过程感受比较强烈的三个观点或建议。

1 如果解决方案非常复杂，一定是问题错了。

这是从一个开发能力很强很全面的在朋友圈抱怨：「觉得微信的代码越来越复杂了，开始搞不定了」，张小龙在下面评论说：「如果一个问题的解决方案太复杂，一定是问题本身错了。事实上就是这样子的。」

一个好的问题不应该导致解决方案太复杂。

从研发的角度来看，引申出来有 3 点:

1. 如果解决方案非常复杂，一定是问题错了或者是需求有问题

很多时候，我们在面对一个问题时，容易陷入复杂的解决方案中或者限入为了解决问题而解决问题。但其实当一个解决方案变得非常复杂时，我们应该反思问题的提法是否正确，需求是否是真正的需求。一个好的问题应该能够用一个相对简洁优雅的方案去解决。

陷入困境时我们要学会换个角度或者跳出问题来思考问题。当感到解决方案过于复杂时，不妨退一步问问自己，是不是对需求或问题有误解，有没有更本质更简单的诉求。化繁为简，用简单的方法解决问题，是一种智慧。

2. 优秀的工程师其实可以帮助产品经理矫正需求

产品经理提出的需求，研发同学往往会无条件去满足。但优秀的工程师，应该具备产品思维，有能力去审视和质疑需求背后的逻辑，去引导产品经理矫正需求。

一味地满足需求，只会让产品变得复杂和庞大。优秀的工程师应该成为产品经理的思想伙伴，而不仅仅是执行者。在开发过程中提出合理化建议，做有价值的事，把控产品的定位和走向，这是更高境界的工程师素养。

3. 写代码只是其次，思考和讨论产品也是重要的工作

作为研发同学，不能把自己局限在写代码上。思考产品，了解用户，参与需求讨论，才能真正驱动产品的进步。

代码只是工具，而洞察需求，理解人性，思考产品形态，决定产品体验，这些应该是每一个研发同学的内功。要把自己的视野拓展到产品层面，主动去思考为什么做这个功能、用户会喜欢吗、还能怎么改进体验。唯有这样，才能成为真正优秀的工程师。

2 抽象方能化繁为简

这个观点应该是大部分场景下面，研发同学都认同的。

当面对大量繁杂的需求时，与其逐一满足，不如试图提炼出其中的共性和本质，将之抽象为更少量、更高层次的需求。这个过程就是「抽象」。

以订阅内容为例，如果把各类内容提供方(如企业、个人、媒体等)的形形色色的诉求都一一满足，系统必然会变得非常复杂。但若能抽象出一个统一的账号体系和内容载体，就能用一套接口来服务各方，大大简化了系统。

抽象的层次越高，派生出的子需求就越多。比如将 100 个需求抽象、归纳为 10 个，甚至 1 个，则原本的 100 个需求都可以被这 10 个或 1 个「母需求」所覆盖。

要做好抽象，关键是要找准需求的共性、本质之处，即所谓的不变量，而非沉陷于各自差异化的细枝末节。唯有升维思考，才能在更高层次上对繁复的事物进行归纳和简化。

通过「以简御繁」「归一化」的抽象思路，可以大大降低系统复杂度，提升开发和管理效率。同时让产品对用户更加友好，使用更加简单统一。

这种化繁为简的抽象思维，是一种非常重要的思考方式和设计原则，对于管理大型复杂系统、满足多元需求有重要指导意义。不仅开发人员要掌握，其他非技术人员也很有必要学习这种思维方式。

3 改变旧世界的意愿

在书中，改变旧世界的意愿是在气质篇的第一篇，从其定义上更多的是一些日常记录的点。

在「改变旧世界的意愿」这一点上，张小龙提到了自己：「对于对iPhone5的唯一期待是，像iPad（3G）一样，不支持电话功能。这样，我少了电话费，但你可以用kik跟我短信，用 googlevoice跟我通话，用 facetime 跟我视频。」

做一个产品，意愿是很重要的。我们有没有去一个改变旧世界的意愿

作为一个研发团队的管理者，改变旧世界的意愿是一个团队管理中的核心逻辑。上次和小帅聊天，也有聊到我们在团队管理岗上，我们始终应该改变点什么。

「改变旧世界」的意愿，本质上是一种创新驱动和价值追求。它意味着不满足于现状，主动去探索和尝试新的可能性，并以之来重塑既有的产品形态、技术架构乃至商业模式。这种意愿需要从管理者开始，成为团队的共识和愿景，并指引技术决策和项目实践的方向。

技术管理者需要与团队一起，去思考如何用技术的力量去创造更多的附加价值，解决用户和业务的痛点。要审视自己的产品定位和技术路线，看是否还有优化和颠覆的空间。同时要放眼行业前沿和未来趋势，去探索下一个风口和变革点。唯有确立了明确的变革方向和价值诉求，才能凝聚共识，激发动力。

事实上，很多时候阻碍我们「改变旧世界」的，恰恰是技术和架构层面的「旧世界」。长期累积下来的历史债务，割裂的系统，低效的架构，过时的技术栈，都成为了创新的桎梏。团队往往需要耗费大量时间和精力在修修补补和「打补丁」上，而无暇去思考和实现变革。

这就需要技术管理者下定决心，带领团队去正视和解决技术债务。要客观评估既有系统的健康度，识别出最急需重构和升级的部分。同时要重新思考整个技术架构，看如何通过解耦、重构、引入新技术等手段，来提升系统的灵活性、可扩展性和创新友好度。只有在架构层面打好基础，才能为变革扫清障碍。

除了对技术、架构、债务的改变，「改变旧世界」的意愿，还需要适配研发团队的现状和组织形态。如果团队长期处于产品需求的压力之下，缺乏思考和探索的时间；如果组织过于层级化和官僚化，创新的想法很难被听到和采纳；如果绩效考核过于短视和功利，大家不愿承担变革的风险，那么这种意愿就很难真正落地。

技术管理者需要为团队争取一定的自主权和探索空间。在项目排期和任务分配上，要预留出一定比例的「创新时间」或者技术时间，鼓励大家尝试新的 idea。同时要优化组织架构和流程，让信息和想法能够更顺畅地在团队中流动，减少决策链路，提升反应速度。绩效评估也要将创新和长期价值纳入考量，为「改变」提供合理的回报。

从技术管理者自身来说，站在产品和技术实现交汇的点上，对产品的认知和对实现细节的认知让研发管理可以更高效，更合理的决策技术方案和产品规划，从而更好地引领技术团队实现产品价值和商业目标。

作为管理者，要具备产品视角和技术视角的双重思维，一方面深入了解业务需求和用户痛点，另一方面洞悉技术方案的可行性和优劣。要善于在两个视角之间切换和权衡，找到既能满足需求，又能控制成本和风险的平衡点。也要能跳出具体实现，从更宏观的层面去思考技术战略和产品演进路径，看清下一步的发力点和布局方向。

在具体的实践过程中，技术管理者需要深入了解产品需求的来龙去脉。不能仅停留在需求文档上，而要主动与产品经理甚至客户沟通，理解需求背后的业务逻辑、用户痛点和产品价值。唯有对需求有了全面的认知，才能在技术选型、架构设计、任务拆分等环节做出正确的决策。

同时，技术管理者要对技术实现有足够的了解。这并不意味着要事无巨细地参与到每一行代码中，而是要对关键技术难点、潜在风险、优化方向等有把握。要与技术骨干保持频繁的讨论，时刻掌握开发进度和问题。只有将宏观的需求理解和微观的实现细节结合起来，才能站在全局的高度去调配资源、优化流程、控制质量。

管理者要营造产品和研发的良性互动。鼓励研发团队主动了解业务，引导产品经理关注技术价值，提倡双方同理共情、互相成就。打造一种「产品驱动研发，研发反哺产品」的良性循环，激发团队斗志，凝聚团队向心力。

小结

以书中提到的微信 4.0.1 和 4.2 发布时的文案作为本篇文章的结尾：

很喜欢这句话：如你所知，微信不只是一个聊天工具；如你所见，微信，是一个生活方式。

你曾经在微博上虚掷光阴
如今又在微信里蹉跎岁月
你以为通过手机就连接了世界，
其实只是躲在屏幕后面获取了安全感。
是时候放下手机，和朋友面对面了!
如若不能，试试微信视频通话
少发微信，多和朋友见见面！

向上沟通是什么

从定义上来看，向上沟通，是指中层管理者向上级领导传递信息、反映情况、争取支持的一种垂直沟通方式。作为连接高层决策和一线执行的纽带，中层管理者通过向上沟通，架起了组织内部上下贯通的「信息桥梁」。

说得更详细一点，向上沟通主要包含四重内容:

1. 工作汇报，即向领导报告部门的运行情况、阶段性成果等。作为中层管理者，我们有责任定期向上汇报部门的运行状况、阶段性成果、面临的问题等，让领导及时、全面地了解一线工作的进展。这种常态化的信息传递，是保证管理决策准确性的前提。
2. 资源争取，即向领导说明团队面临的资源缺口和需求，以争取必要的人力、财力支持。企业资源向来有限，中层管理者需要通过向上沟通，合理说明团队的资源需求，努力争取上级的支持。这种资源可以是人力、财力，也可以是决策权限、发展机会等。通过有理有据的阐述，我们可以让领导认识到满足需求的必要性和紧迫性。
3. 问题反馈，即及时向领导反映工作推进中遇到的困难和挑战，揭示问题的症结所在。我们有必要通过向上沟通，及时向上反映问题，揭示困难的症结所在。这不是简单的「甩锅」，而是为寻求解决方案创造机会。只有领导意识到问题的严重性，才会给予更多指导和支持。
4. 方案建议，即围绕某些决策、措施，向领导提出自己的见解和意见，为领导的判断提供参考。中层管理者扮演着参谋的角色。通过向上沟通，我们可以就某些决策、措施向领导提出自己的见解和建议，为领导的判断提供参考。这种建议要基于扎实的一线实践，要有数据支撑，要考虑决策的可行性和影响。只有让建议「接地气」，才能获得领导的采纳。

就形式而言，向上沟通并不局限于面对面的口头陈述，书面表达如周报、月报、分析报告等，同样是常用的沟通方式。

就对象而言，向上沟通既要面向直接上级，也要根据事项的重要性，与更高层级的隔级领导保持必要沟通。

就时机而言，既包括常态化的日常工作汇报或固化的 1v1 沟通，也包括应对突发事件、重大问题决策的非常态沟通。

向上沟通对于中层管理者和组织发展都具有重要意义。通过高效的向上沟通，中层管理者可以帮助领导及时掌握一线工作动态，为科学决策提供支撑；可以为团队争取更多资源支持，保障运转顺畅；可以将问题「第一时间」反映给领导，推动矛盾化解；可以让领导听到基层声音，优化决策方案。由此可见，向上沟通是中层管理者履行岗位职责、提升领导力、实现个人价值的关键所在。

向上沟通不仅仅是单向的「信息上传」，更是一种双向互动、循环反馈的过程。作为「夹心层」，中层管理者需要通过主动、积极、有效的向上沟通，在组织中发挥「承上启下」的独特价值，架起最坚实的「同心桥」，推动组织目标的达成和使命的实现。这既是岗位所赋予的重任，更是实现自我价值的途径。唯有不断提升向上沟通的意识和技能，才能在组织中赢得认可和发展，走向卓越管理之路。

那么在这个向上沟通的过程中，上级对于我们来说意识着什么？

上级是什么

对于技术管理者而言，上级领导扮演着多重角色，对其个人成长和团队发展都有着至关重要的影响。上级不仅是技术管理者的「领路人」，更是他们的「靠山」、「学习榜样」、「引路人」和「合作伙伴」。

首先，上级是技术管理者的「领路人」。大多数技术管理者起初都是从一线技术岗位成长起来的，对于公司的业务、文化、运作方式等还相对陌生。这时，直接上级就成为引导他们快速适应从技术到管理角色转换的「领路人」。一位优秀的领导会给下属适时的指点和反馈，帮助其尽快熟悉企业管理的方方面面。

其次，上级还是技术管理者坚实的「靠山」。作为中层技术管理者，我们难免会遇到一些难以独力解决的问题，如资源争取、跨部门协调等。这就需要直接上级从更高的层面给予协调和支持。当下属遇到困难时，上级挺身而出，提供必要的资源和支持，让技术管理者备感安心，更有信心去攻坚克难。

再次，优秀的上级是技术管理者学习的「榜样」。领导丰富的管理经验、敏锐的行业洞察，以及游刃有余的领导艺术，都是技术管理者成长的「富矿」。通过观察上级的决策思路、沟通技巧、领导风格，技术管理者可以潜移默化地吸收管理的精髓，少走弯路，将个人影响力发挥到极致。

同时，上级还是技术管理者职业发展道路上的「引路人」。在很大程度上，技术管理者的职业发展空间取决于上级的栽培和引荐。一位善于发掘下属潜力，给予成长机会的领导，会成为下属的「伯乐」，为其铺就一条通往卓越的康庄大道。上级的信任和赏识，无疑是激励下属不断进取、挑战自我的力量源泉。

最后，从更高远的视角来看，上级与下属是并肩作战、齐头并进的「合作伙伴」。组织的目标达成，使命的实现，离不开上下级的通力协作。单打独斗已不适应当今高度复杂的商业生态，只有协同作战，才能制胜未来。上下级要跳出简单的管理与被管理的思维定式，用「命运共同体」的意识去对待彼此，携手共进，打造「比翼双飞」的领导关系。

总的来说，对技术管理者而言，直接上级意味着良师、益友、伙伴等多重角色。这种关系绝非简单的上下级，而是需要双方用心经营、用行动培育的。

如何做好向上沟通

作为中层技术管理者，向上沟通是一门必修课。高效的向上沟通，可以让我们在组织中发挥「承上启下」的独特价值。以下我们将从沟通准备、沟通策略、沟通技巧三个维度，聊一些如何做好向上沟通的心得体会。

第一，在沟通准备上要「三问三思」：沟通什么、为什么沟通、怎样沟通。

沟通前，我们要明确此次沟通的主题和目的，是单纯汇报工作，还是反映问题、争取资源，或是提出建议。唯有「心中有数」，才能准确表达。

同时，还要思考为什么要进行这次沟通，沟通的必要性何在，不同角度的利弊权衡如何，以增强论证的说服力。

最后，还要考虑如何开展沟通，口头还是书面，正式还是非正式，选择对上级而言最容易接受的方式。

唯有「磨刀不误砍柴功」，未雨绸缪，准备工作做扎实了，才能在沟通中做到游刃有余。

第二，在沟通策略上要做到「四个有度」:简洁有度、客观有度、积极有度、灵活有度。

• 简洁有度：向上沟通时，我们要把控内容的详略，该详时详，该略时略，避免冗长，「听者藐」。
• 客观有度：沟通要客观理性，持事实说话，用数据佐证，不夸大成绩，不隐瞒问题，让领导听到一手的「真话」。
• 积极有度：沟通还要积极正面，多提建设性意见，少讲「不可能」，让领导感受到我们解决问题的诚意和信心。
• 灵活有度：沟通还要因「听」而变，根据领导的反应和需求，灵活调整沟通节奏和内容，避免「自说自话」。

这「四个有度」是上级欣赏的沟通品质，也是高情商沟通的重要体现。简单来说就是：说话简洁点，持事实多反馈，少埋怨多建议，看领导脸色行事。这样沟通，领导爱听，你也不费劲。

第三，在沟通技巧上要把握「三个贴近」:贴近实际、贴近需求、贴近语言。

沟通时，我们要立足一线实际，用鲜活的案例阐述观点，让沟通”接地气”；要顺应领导的关注重点，抓住痛点难点，让沟通「有的放矢」；要学会用上级惯用、喜欢的语言表达，让沟通「入情入理」。

比如，如果上级是「数字控」，就多从数据角度论证；如果上级偏好形象化表达，就要在言辞上多些比喻和生动描述。总之，向上沟通要因「领」而异，用对方喜闻乐见的方式传递信息，才能事半功倍。

这里我想强调的是，向上沟通不是「作秀」，更不是「拍马屁」，而是一种技能，一种智慧。它需要我们在日常工作中持续打磨，在领悟中不断精进。每一次向上沟通，都是展现个人思考力、表达力、影响力的绝佳舞台。

每一次向上沟通不仅仅是你个人在沟通，更是你代表整个团队在和上级沟通。

向上沟通没有捷径可走，只有在勤学善思、用心领会中，才能悟出其中真谛。作为中层技术管理者，我们要立足岗位，练就过硬本领，在组织中当好上传下达的「中枢」，发挥「齿轮」作用，以高效的向上沟通推动组织的前行。

这既是管理者的必备修养，更是走向卓越的核心竞争力。让我们从现在做起，从点滴做起，用智慧和汗水打造沟通的「金字招牌」，在管理的道路上行稳致远。

当你成为一个技术团队的管理者时，就会经常会被老板问到，研发的价值在哪里？如何让研发的价值更大？现在的研发团队和行业内相比效率/能力/水平怎么样？如此种种……

每个公司每个技术团队的管理者都有自己的逻辑来回答这个问题，因为这是带团队的核心逻辑之一，且各有缘法。

今天这篇文章不是想准确的回答这个问题，也不是标准答案，只是这些问题最近引发的一些个人思考。

先抛两个公式：

公式一：研发的价值 = (业务价值 + 技术价值) – 非正常成本 – 正常成本

公式二：研发的价值 = 单位有效时间内产出的价值 × 有效时间 – 非正常成本 – 正常成本

这是简化的研发的价值模型，可以作为理解研发价值创造的基础框架。实际应用中可能还需要进一步的细化和调整，因为价值的计算可能远比这两个公式复杂。

总体来看，让价值更大在于攻守，如何攻，如何守，攻就是提高产出价值，守就是减少成本。

在攻的方面，提高产出价值包括提高业务价值和技术价值。我们都知道业务需求是做不完的，如何在做不完的业务需求里面产出更大的价值， 关键点在于业务需求本身的价值和业务价值生效的时间，将具有更大价值的业务需求更快的上线是提高研发侧业务价值的主体逻辑。当然，需求上线后可能还有 bug 之类的，这个我们作为守的那部分来聊。

提高业务价值

提高业务价值的主体逻辑包括两层意思，一个是更大价值的业务需求，另一个是更快的上线。

更大价值的业务需求我理解为做重要的事情，实际上是我们对于事项的一个优先级排序。对于重要的事情分两个阶段，一个是确定事项前的判断，一个是事项确定后的判断，确定前的判断有以下要点：

• 战略和期望：这是一个前期非常重要的判断项，公司层面的战略、技术长期规划，老板对这个组织的期望等等
• 业务影响和目标价值：直白的说，看这些事项对业务目标的达成情况的影响，对收入增长的影响，对于 NPS 这些的影响等等
• 第三方约束和风险：比如已经签了合同的，有截止时间要求的，比如一些严格的技术风险，或者稳定性的问题等等

基于以上这些我们有了一个对事情的判断，但是当这些事情过滤后对于一个管理者来说，还需要做的一个重要性的判断是资源。

资源是最后一个项，是一个相对后期的项，看我们在人力、时间，财务资源上投入多少，这个是过程态中我们要持续看的，根据这些来看我们个人和团队的精力如何分配等。资源需求较大的事项，即使重要性较高，也可能因为资源的限制而需要降低优先级。

在明确了事项的优先级后，下一步就是更快的上线了，更快的上线从研发管理的角度可以分为三个层面，研发流程、工程系统、团队协作和沟通。

1. 研发流程：

   • 精简流程：优化开发到上线的流程，减少不必要的步骤，以加快从需求到部署的时间。可以有一个系统来看每个流程阶段的时间花费，如果没有系统用表格顶一下也行。具体落地指标可以看平均需求交付周期、每流程交付时间等
   • 敏捷实践：采用敏捷方法论，如 Scrum 或 Kanban，以小批量、快速迭代的方式推进项目。在实际落地过程中可以以需求吞吐量、平均需求交付周期、每需求人力成本等。

2. 工程系统：

   • 系统工程化建设：投资于自动化测试、持续集成（CI）、持续部署（CD）等工程系统，以提高开发和部署效率。
   • 技术架构优化：根据业务需求，对技术架构进行持续优化，确保其支持快速增长和变化，并降低长期维护成本。

3. 团队协作和沟通：

   • 跨部门协作：促进开发、运维、产品和其他相关部门之间的沟通，确保需求的快速流转和问题的及时解决。
   • 沟通机制：建立高效的沟通机制，包括定期会议、即时通讯工具和项目管理软件，确保信息流通畅通。
   • 团队授权：赋予团队更大的决策权，使得团队能够快速作出决策，而不必每一项都上报等待批准。

以上是业务价值，将具有更大价值的业务需求更快的上线是核心逻辑。

提高技术价值

对于技术价值而言，逻辑略有不同，技术价值在将更大价值的技术更快的上线的基础上， 需要坚定不移的持续投入和有规划的稳步建设。

持续投入是指在资源方面，特别是人力资源方面，需要在业务需求紧张的情况下保障技术需求的投入资源占比。

有规划的稳定建设是指在保障系统稳定的前提下，有规划的对技术架构进行优化，明确技术发展路线图，按照既定的规划逐步实施技术改造和优化，确保每一步都有明确的目标和时间表。

提高有效时间内的价值

从公式二：单位有效时间内产出的价值 × 有效时间 来看，要提高研发价值，需要提高单位有效时间内产出的价值以及提升有效时间。那么如何提高单位有效时间内产出的价值？

一个是从业务层面，将具有更大价值的业务需求更快的上线，另一个从人的层面，提高单兵能力，因为研发最终是要落在人身上，强化单兵能力，对于提升整个团队的有效时间内的产出有极大地促进作用，单兵能力的高低能决定团队总体效能的高低。

至于提升有效时间，从研发管理角度来看一个是以机制形式保障研发的开发投入时间，如研发静默时间，在静默时间不允许插入非写代码相关的事项；

另一方面是以目标为导向，推动团队集中精力专注于某个目标的达成，如小黑屋之类的，当然，其本质上是延长工作时间，也就在一定程度上提升了有效时间，此法慎用，除非文化本来如此，能留下来的是能接受这种文化的人。

以上是攻的角度，也就是提高产出价值来思考，从守的角度来看，更多提就是减少成本，这里主要是减少非正常成本。

减少非正常成本

非正常成本是指在生产和运营过程中由于管理不善、技术失败、人为疏忽或外部因素导致的超出正常开支的成本。这些成本通常不是生产或提供服务的必需开支，而是由于各种非计划事件造成的损失，可以以某种方式减少或规避。

这里的非正常成本我的理解包括以下的部分：

1. 项目延期和需求变更

项目延期和需求变更会导致增加额外的人力成本，延迟了需求的上线时间，可能导致业务损失或风险发生。我们一般可以通过更精细的项目管理来减少延期，通过正式的变更控制流程，评估变更的必要性和影响，以控制变更带来的成本。

2. 技术难题

当在项目过程中遇到了预料之外的技术挑战和难题，可能会导致项目停滞，以至研发团队无法按时完成项目，需要额外的研发投入或影响产品需求计划等。

我们一般在项目开始前对技术难题进行充分调研和风险评估，如果是在项目中遇到了，快速协调资源解决，甚至是请外部的专家来解决，从内部来看，提升现有团队人才梯队，提升团队成员能力，让成为技术难题的项越来越少是更优的解决方案。

3. 产品缺陷

产品缺陷我们通常称之为线上 BUG，当一个线上 BUG 出现后就会有一个流程串起一批人来解决，这个成本比在更前置的开发阶段或测试阶段发现并解决的成本更高，甚至会影响到用户的使用和口碑。

我们一般是通过代码审核、自动化测试、生死用例、showcase 等各种流程和机制来保障和提升产品的质量，同时对于已经出现的问题，使用缺陷管理系统，确保所有缺陷被记录、跟踪并及时处理。

4. 过度设计

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

在设计时尽量遵循  KISS（Keep It Simple, Stupid） 原则 ，避免不必要的复杂性。

5. 历史债务

技术债务是指由于短期内的快速开发和决策，而在长期内需要支付的额外工作。例如，为了赶项目进度，团队可能会选择快速但不完美的解决方案，而不是花费更多时间来寻找更好的解决方案。

为了解决技术债务，可能需要进行代码重构或重新设计系统，这将带来额外的开发和测试时间。此外，技术债务可能会降低开发团队的生产力，例如，如果代码质量低，团队可能需要花费更多的时间来理解代码、修复错误和添加新功能。

我们一般是要将历史债务管理起来，识别和记录技术债务，并制定计划逐步解决，同时在新项目中避免产生新的技术债务。

6. 线上故障

线上事故对于任何技术团队来说都是一种非常严重的非正常成本。

这类事故可能会对用户产生直接的影响，包括用户体验降低、数据丢失、服务中断等。这不仅可能导致用户对产品或服务的信心降低，甚至可能导致用户流失。此外，严重的时候，线上事故还会导致公司的资产损失。

为此，我们需要建立全面的监控系统，及时发现并响应线上故障，同时制定灾备计划和故障恢复策略，以减少故障影响，并对每次故障进行事后分析，总结教训并采取预防措施避免未来的重复。

在我们的研发过程中，持续的减少以上的非正常成本是提升整体研发价值的守的逻辑。

除此之外，我们还需要考虑整体系统的复杂度，用持续优化对抗世界的不确定性。

康康说：老板要的无非是「人少活好效率高」

换句话说是成本低质量高产出多，而质量高也是为了成本低，只不过和人少的成本相比是不一样的成本。

老板看的还是 ROI