一直说要把《微信背后的产品观》这本书看完，一直没顾得上，这次临时出差到厦门的路上带上了，动车上的时间把书看完了，去的时候看了一遍，回的时候看了一遍，看完，写下这篇文章。
这本与其说是书，不如说是演讲实录。书的内容来源自张小龙在 2012 年的那次著名的 8 小时演讲，2016 年被整理成书稿，在 2021 年决定出版。好的内容是经得起时间考验的，在 9 年之后出版，在 12 年后的今天来看也不过时，甚至部分观点会刷新我们的一些认知。
以下是我在读这本书的过程感受比较强烈的三个观点或建议。
这是从一个开发能力很强很全面的在朋友圈抱怨：「觉得微信的代码越来越复杂了，开始搞不定了」，张小龙在下面评论说：「如果一个问题的解决方案太复杂，一定是问题本身错了。事实上就是这样子的。」
一个好的问题不应该导致解决方案太复杂。
从研发的角度来看，引申出来有 3 点:
1. 如果解决方案非常复杂，一定是问题错了或者是需求有问题
很多时候，我们在面对一个问题时，容易陷入复杂的解决方案中或者限入为了解决问题而解决问题。但其实当一个解决方案变得非常复杂时，我们应该反思问题的提法是否正确，需求是否是真正的需求。一个好的问题应该能够用一个相对简洁优雅的方案去解决。
陷入困境时我们要学会换个角度或者跳出问题来思考问题。当感到解决方案过于复杂时，不妨退一步问问自己，是不是对需求或问题有误解，有没有更本质更简单的诉求。化繁为简，用简单的方法解决问题，是一种智慧。
2. 优秀的工程师其实可以帮助产品经理矫正需求
产品经理提出的需求，研发同学往往会无条件去满足。但优秀的工程师，应该具备产品思维，有能力去审视和质疑需求背后的逻辑，去引导产品经理矫正需求。
一味地满足需求，只会让产品变得复杂和庞大。优秀的工程师应该成为产品经理的思想伙伴，而不仅仅是执行者。在开发过程中提出合理化建议，做有价值的事，把控产品的定位和走向，这是更高境界的工程师素养。
3. 写代码只是其次，思考和讨论产品也是重要的工作
作为研发同学，不能把自己局限在写代码上。思考产品，了解用户，参与需求讨论，才能真正驱动产品的进步。
代码只是工具，而洞察需求，理解人性，思考产品形态，决定产品体验，这些应该是每一个研发同学的内功。要把自己的视野拓展到产品层面，主动去思考为什么做这个功能、用户会喜欢吗、还能怎么改进体验。唯有这样，才能成为真正优秀的工程师。
这个观点应该是大部分场景下面，研发同学都认同的。
当面对大量繁杂的需求时，与其逐一满足，不如试图提炼出其中的共性和本质，将之抽象为更少量、更高层次的需求。这个过程就是「抽象」。
以订阅内容为例，如果把各类内容提供方(如企业、个人、媒体等)的形形色色的诉求都一一满足，系统必然会变得非常复杂。但若能抽象出一个统一的账号体系和内容载体，就能用一套接口来服务各方，大大简化了系统。
抽象的层次越高，派生出的子需求就越多。比如将 100 个需求抽象、归纳为 10 个，甚至 1 个，则原本的 100 个需求都可以被这 10 个或 1 个「母需求」所覆盖。
要做好抽象，关键是要找准需求的共性、本质之处，即所谓的不变量，而非沉陷于各自差异化的细枝末节。唯有升维思考，才能在更高层次上对繁复的事物进行归纳和简化。
通过「以简御繁」「归一化」的抽象思路，可以大大降低系统复杂度，提升开发和管理效率。同时让产品对用户更加友好，使用更加简单统一。
这种化繁为简的抽象思维，是一种非常重要的思考方式和设计原则，对于管理大型复杂系统、满足多元需求有重要指导意义。不仅开发人员要掌握，其他非技术人员也很有必要学习这种思维方式。
在书中，改变旧世界的意愿是在气质篇的第一篇，从其定义上更多的是一些日常记录的点。
在「改变旧世界的意愿」这一点上，张小龙提到了自己：「对于对iPhone5的唯一期待是，像iPad（3G）一样，不支持电话功能。这样，我少了电话费，但你可以用kik跟我短信，用 googlevoice跟我通话，用 facetime 跟我视频。」
做一个产品，意愿是很重要的。我们有没有去一个改变旧世界的意愿
作为一个研发团队的管理者，改变旧世界的意愿是一个团队管理中的核心逻辑。上次和小帅聊天，也有聊到我们在团队管理岗上，我们始终应该改变点什么。
「改变旧世界」的意愿，本质上是一种创新驱动和价值追求。它意味着不满足于现状，主动去探索和尝试新的可能性，并以之来重塑既有的产品形态、技术架构乃至商业模式。这种意愿需要从管理者开始，成为团队的共识和愿景，并指引技术决策和项目实践的方向。
技术管理者需要与团队一起，去思考如何用技术的力量去创造更多的附加价值，解决用户和业务的痛点。要审视自己的产品定位和技术路线，看是否还有优化和颠覆的空间。同时要放眼行业前沿和未来趋势，去探索下一个风口和变革点。唯有确立了明确的变革方向和价值诉求，才能凝聚共识，激发动力。
事实上，很多时候阻碍我们「改变旧世界」的，恰恰是技术和架构层面的「旧世界」。长期累积下来的历史债务，割裂的系统，低效的架构，过时的技术栈，都成为了创新的桎梏。团队往往需要耗费大量时间和精力在修修补补和「打补丁」上，而无暇去思考和实现变革。
这就需要技术管理者下定决心，带领团队去正视和解决技术债务。要客观评估既有系统的健康度，识别出最急需重构和升级的部分。同时要重新思考整个技术架构，看如何通过解耦、重构、引入新技术等手段，来提升系统的灵活性、可扩展性和创新友好度。只有在架构层面打好基础，才能为变革扫清障碍。
除了对技术、架构、债务的改变，「改变旧世界」的意愿，还需要适配研发团队的现状和组织形态。如果团队长期处于产品需求的压力之下，缺乏思考和探索的时间；如果组织过于层级化和官僚化，创新的想法很难被听到和采纳；如果绩效考核过于短视和功利，大家不愿承担变革的风险，那么这种意愿就很难真正落地。
技术管理者需要为团队争取一定的自主权和探索空间。在项目排期和任务分配上，要预留出一定比例的「创新时间」或者技术时间，鼓励大家尝试新的 idea。同时要优化组织架构和流程，让信息和想法能够更顺畅地在团队中流动，减少决策链路，提升反应速度。绩效评估也要将创新和长期价值纳入考量，为「改变」提供合理的回报。
从技术管理者自身来说，站在产品和技术实现交汇的点上，对产品的认知和对实现细节的认知让研发管理可以更高效，更合理的决策技术方案和产品规划，从而更好地引领技术团队实现产品价值和商业目标。
作为管理者，要具备产品视角和技术视角的双重思维，一方面深入了解业务需求和用户痛点，另一方面洞悉技术方案的可行性和优劣。要善于在两个视角之间切换和权衡，找到既能满足需求，又能控制成本和风险的平衡点。也要能跳出具体实现，从更宏观的层面去思考技术战略和产品演进路径，看清下一步的发力点和布局方向。
在具体的实践过程中，技术管理者需要深入了解产品需求的来龙去脉。不能仅停留在需求文档上，而要主动与产品经理甚至客户沟通，理解需求背后的业务逻辑、用户痛点和产品价值。唯有对需求有了全面的认知，才能在技术选型、架构设计、任务拆分等环节做出正确的决策。
同时，技术管理者要对技术实现有足够的了解。这并不意味着要事无巨细地参与到每一行代码中，而是要对关键技术难点、潜在风险、优化方向等有把握。要与技术骨干保持频繁的讨论，时刻掌握开发进度和问题。只有将宏观的需求理解和微观的实现细节结合起来，才能站在全局的高度去调配资源、优化流程、控制质量。
管理者要营造产品和研发的良性互动。鼓励研发团队主动了解业务，引导产品经理关注技术价值，提倡双方同理共情、互相成就。打造一种「产品驱动研发，研发反哺产品」的良性循环，激发团队斗志，凝聚团队向心力。
以书中提到的微信 4.0.1 和 4.2 发布时的文案作为本篇文章的结尾：
很喜欢这句话：如你所知，微信不只是一个聊天工具；如你所见，微信，是一个生活方式。
你曾经在微博上虚掷光阴
如今又在微信里蹉跎岁月
你以为通过手机就连接了世界，
其实只是躲在屏幕后面获取了安全感。
是时候放下手机，和朋友面对面了!
如若不能，试试微信视频通话
少发微信，多和朋友见见面！