在软件开发领域，架构师常被视为技术的领航者和项目的灵魂人物。他们不仅仅是技术专家，更是系统的规划者、团队的协调者和问题的解决者。

随着技术的不断演进和项目复杂性的提升，架构师的角色也在不断扩展和深化。

要成为一名优秀的架构师，掌握以下七大核心能力至关重要。这些能力不仅奠定了架构师的技术基础，还支撑了他们在项目中的领导力和决策力。

1. 系统设计与建模能力

系统设计与建模是架构师的看家本领，是将业务需求转化为可落地执行的技术蓝图的关键一环。这需要架构师具备深厚的技术功底和丰富的实践经验。

架构师首先要具备的就是将业务需求转化为系统设计的能力。这个过程并不仅仅是技术上的实现，而是需要架构师深入理解业务目标和背景，并将这些抽象的需求转化为切实可行的技术方案。

架构师需要与产品经理、业务分析师等角色密切合作，理解用户的需求、业务流程和核心目标，准确提炼和细化需求，明确系统的目标定位、功能边界、非功能需求等关键要素。要能透过表象看本质，抓住需求的核心要义。

在需求分析的基础上，架构师要进行深入的领域建模。这需要运用领域驱动设计( DDD )等方法，对业务实体及其之间的关系进行抽象和建模。通过统一语言、限界上下文等工具，厘清业务概念，消除分歧，形成领域模型。领域模型是架构设计的基石，需要投入大量时间精雕细琢。

有了清晰的需求和领域模型，架构师就可以进行技术架构设计了。这个阶段是将业务架构映射为技术架构的关键环节。架构师需要在头脑中构建出系统的技术蓝图，包括系统的层次划分、模块职责、接口约定、数据流动、部署模式等。要合理运用分层、分治、解耦、高内聚低耦合等原则，设计出清晰、灵活、可扩展的技术架构。

架构设计需要权衡各方。比如系统的性能与可维护性，往往是一对矛盾。追求极致的性能，可能会导致代码的高度耦合和复杂度上升。架构师需要权衡利弊，找到平衡点，在满足性能目标的同时，尽量保持架构的简洁和可维护性。

架构师还需要基于技术架构，设计系统的物理部署方案。要根据系统的可用性、弹性、扩展性等非功能需求，合理规划服务器数量、配置和分布。对系统的存储、缓存、负载均衡、限流、降级等方案也要细致设计。部署架构要尽量实现自动化，提高运维效能。

架构师还要对系统进行详细建模，形成架构文档。这包括但不限于：总体架构图、时序图、流程图、状态图、ER 图、类图等。这些架构模型要力求简洁明了，用最精炼的表达来呈现系统的核心设计思想。要让团队成员能一目了然地读懂架构，减少沟通成本。

架构师在建模时，要识别系统在演进过程中的变化点和不变点。变化点要通过依赖反转、开闭原则等方式封装，最小化其对周边模块的影响。而不变的核心逻辑，则要稳定地抽象为系统的骨架。要为架构的持续演进预留空间和可能性。

除了结构建模，架构师还要进行系统的行为建模。通过制定架构原则、API 规范、编码规范等，对系统各组成部分的行为进行约束，以保障体系风格的一致性。架构原则要体现技术价值观，引导架构的演进方向和决策过程。

架构师要善于运用架构模式，如 MVC、MVP、MVVM、SOA、微服务等。要深入理解每种模式背后的设计哲学，对其使用场景、优缺点、实践要点等了然于胸。同时也要跳出模式的局限性，审时度势，根据系统的独特个性，对模式加以裁剪和改进，甚至探索新的模式。

总结上面的内容，整体过程包括以下几个关键词：需求理解、领域建模、技术架构、部署架构、详细建模、行为建模、架构模式等。

需求分析是一切的起点，领域建模是架构设计的基石，基于需求和领域模型，架构师要进行系统的架构设计和仔细权衡。

系统设计与建模能力需要日积月累地锤炼。优秀的架构师往往能对系统的方方面面了如指掌，头脑中有一个清晰的技术地图。系统设计与建模贯穿软件生命周期的始终，是一项需要持之以恒修炼的核心能力。

2. 技术能力

技术能力是架构师的安身立命的根本，这里要着重聊的是技术的广度与深度

一个优秀的架构师不仅需要在某些技术领域拥有深厚的技术积累，还需要在广泛的技术栈中游刃有余。技术广度与深度的结合，使得架构师在面对不同的技术挑战时，能够从容应对，做出最优的架构设计和技术决策。

架构师需要对软件工程领域的各个技术板块都有全面的了解和融会贯通的能力。这些技术领域包括但不限于：

• 前端技术：如 HTML、CSS、JavaScript，以及 React、Vue、Angular 等前端框架。架构师需要理解前端技术的基本原理，掌握各类前端框架的特点和适用场景，以便在系统设计中合理选择前端技术栈。
• 后端技术：如 Java、C++、Python、Node.js、Go 等编程语言及其对应的框架。架构师需要对主流的后端技术有深入的理解，能够根据项目需求选择合适的语言和框架，并设计出高效、可维护的后端系统架构。
• 数据库技术：如关系型数据库（MySQL、PostgreSQL、Oracle等）、NoSQL 数据库（MongoDB、Redis、Cassandra 等）、NewSQL 数据库等。架构师需要熟悉不同类型数据库的特点和应用场景，能够根据系统的需求设计合理的数据库架构。
• 大数据技术：如 Hadoop、Spark、Flink 等大数据处理框架，以及 Kafka、RabbitMQ 等消息队列系统。架构师需要理解大数据系统的架构模式和数据流处理的基本原理，掌握如何设计高效的数据处理和传输管道。
• 云计算与容器技术：如 AWS、Azure、阿里云 等云平台，Docker、Kubernetes 等容器技术。架构师需要理解云计算的服务模式（IaaS、PaaS、SaaS），掌握自动化部署、弹性扩展、容器编排等关键技术，以便设计出高可用、可扩展的云端架构。
• 安全技术：如 SSL/TLS、OAuth、JWT、加密算法、身份验证与授权机制等。架构师需要了解安全技术的基本原理，对信息安全有整体意识，并掌握加密算法、访问控制、风险防范等安全技术，能够设计出安全的系统架构，保护系统免受各种安全威胁。
• 网络与通信技术：TCP/IP 协议、HTTP/HTTPS、RPC 框架、消息队列等，是分布式系统通信的基石。
• 前沿技术：架构师要对人工智能、区块链、云原生等前沿技术保持敏感和探索的态度。

除此之外，还需要对算法与数据结构、分布式系统等有比较深入的了解。

技术的广度让架构师拥有全局视角，技术的深度则让架构师对某些领域有专精的理解。两者相辅相成，缺一不可。

架构师需要在某些战略性技术领域有深厚的技术积累。比如在电商系统中，架构师可能需要对缓存、搜索、推荐等技术有深入研究。在金融交易系统中，架构师可能需要对低延迟、高并发、强一致性技术有深刻见解。

这种战略性技术积累一方面来源于架构师自身的学习和实践，另一方面也来源于团队的集体智慧。架构师要善于将团队中每个人的特长和经验汇聚起来，形成知识的结晶和分享。

架构师获取技术广度与深度的途径有很多，比如：

• 学习优秀开源项目，深入研读其源码实现，领会其设计思想。
• 参与技术社区，与同行交流切磋，跟进前沿动态。
• 阅读经典书籍和论文，汲取前人的智慧结晶。
• 动手实践，在项目中磨炼技术，总结提炼。
• 持续学习，把每一次问题和挑战都转化为技术进步的机会。

技术深度是架构师解决复杂问题的核心能力。在项目中，架构师不仅需要广泛的技术视野，还需要在某些关键领域具备深厚的技术积累，以应对复杂的技术挑战。

随着技术的不断更新，架构师需要构建自己的知识体系，将不断积累的知识进行系统化的整理和归纳。架构师可以通过编写技术文档、博客、笔记等方式，将自己的技术经验和见解记录下来，形成系统化的知识体系。

通过构建知识体系，架构师可以在面对复杂问题时迅速找到解决方案，同时也可以帮助团队成员更好地理解和应用这些知识。此外，知识体系的构建还可以帮助架构师更好地总结和反思自己的技术实践，不断提升自己的技术能力。

需要强调的是，技术广度和深度不是一蹴而就的，而是日积月累的结果。这需要架构师在平时的工作中有意识地广泛涉猎和专门钻研，在项目实践中不断积累和淬炼。

技术广度与深度并重，是架构师在复杂项目环境中脱颖而出的关键能力。技术广度使架构师具备广泛的视野，能够快速评估和应用新技术；技术深度则使架构师具备解决复杂问题的能力，能够在关键领域做出深刻的技术决策和创新。

通过持续学习和自我更新，架构师不仅能够保持技术上的领先地位，还能够在技术选择和创新中保持敏锐的判断力。通过构建系统化的知识体系，架构师能够不断优化和提升自己的技术能力，推动项目的成功交付。

这里多聊一点关于架构师的技术决策。

技术决策是架构师工作中的一个重要环节。面对不同的技术选择，架构师需要具备做出正确决策的能力。技术决策不仅影响到项目的技术实现，还会对项目的成本、进度、质量等方面产生深远的影响。

架构师在做出技术选择时，需要综合考虑多个因素，包括技术的成熟度、团队的技术能力、项目的具体需求、技术的可扩展性和可维护性等。例如，在选择数据库时，架构师需要考虑到数据的规模、访问模式、性能要求等因素，选择最合适的数据库方案。

在项目中，架构师需要不断探索新的技术解决方案，以提升系统的性能、可扩展性和可维护性。例如，通过引入微服务架构，架构师可以将单体系统拆分为多个独立的服务，提升系统的灵活性和可扩展性。

技术决策往往伴随着一定的风险。架构师需要具备风险管理的能力，能够识别技术决策中可能存在的风险，并设计相应的应对策略。如在引入新技术时，架构师需要评估其稳定性、兼容性、学习曲线等因素，避免技术风险对项目的顺利实施产生负面影响。

3. 全局视角与系统性思维

架构师除了要有深厚的技术功底，还需要具备全局视角和系统性思维。这是架构师必备的顶层设计能力，能让架构师站在更高维度审视系统，进行整体优化。

全局视角是指架构师要能从全局的角度来看待系统，而不是仅关注局部的技术细节。架构师需要在头脑中建立起一个宏大的技术蓝图，清晰地理解系统的技术边界、内外部依赖关系、数据流转方式等。

具体来说，架构师需要从几个全局维度来思考系统：

• 业务维度：深刻理解业务战略、业务需求和业务流程，确保系统架构与业务目标相一致，能支撑和引领业务发展。
• 技术维度：系统地分析技术现状、技术趋势和技术生态，基于技术路线图规划系统的技术演进方向。
• 质量维度：全面考虑系统的性能、可用性、安全性、可扩展性等质量属性，并推动质量要求在架构中落地。
• 团队维度：统筹考虑团队的人员技能、研发效能、协同方式等，设计出易于团队理解和落地的架构。同时参考康威定律和逆康威定律。
• 运维维度：充分考虑系统的部署、发布、监控、故障诊断等运维需求，并在架构中预留 SRE 的接口和手段。从部署架构的考虑总是。

从我们常见的架构来看，架构可以分为几个不同的层面和视角。不同的架构视角关注系统的不同侧面，共同构成了系统架构的全貌。

1. 业务架构：这个层面主要关注系统所服务的业务领域、业务流程、业务规则等。它是其他技术架构的基础和出发点。架构师需要深入理解业务需求和业务模型，确保技术架构能充分支撑和促进业务目标的实现。
2. 应用架构：这个层面关注系统的功能划分、模块组合、接口设计等。它定义了系统的功能模块如何满足业务需求，如何进行内部解耦和协作。常见的应用架构模式有分层架构、微服务架构、事件驱动架构等。
3. 数据架构：这个层面关注系统的数据实体、数据流转、数据存储等。它定义了系统的数据如何组织、管理、访问和维护。数据架构需要支持业务需求，并考虑数据安全、数据一致性等因素。常见的数据架构有数据仓库、数据湖、实时数据流等。
4. 技术架构：这个层面关注系统所采用的技术栈、开发框架、中间件等。它基于应用架构和数据架构，选择合适的技术组件来实现系统功能。技术架构需要考虑技术的成熟度、社区支持、团队掌握程度等因素。
5. 部署架构：这个层面关注系统如何在物理环境中部署、运行、升级和维护。部署架构也可以算作技术架构的一部分。它定义了系统的物理拓扑结构、服务器配置、网络设置、发布流程等。部署架构需要考虑系统的性能、可用性、伸缩性、安全性等非功能需求。
6. 安全架构：这个层面专门关注系统的安全防护。它从应用安全、数据安全、基础设施安全、访问控制等角度，设计全面的安全方案。安全架构需要评估系统面临的安全威胁，并制定相应的安全策略和措施。
7. 整体架构：这是一个更高层次的全局视角，它从战略高度审视组织的业务架构、数据架构、应用架构和技术架构，使之协调一致，互相支撑。它考虑的是一个组织的所有IT系统，而不仅仅是单个系统。

当然，还有一些其他的架构视角，如性能架构、集成架构等。重要的是，架构师要能在这些不同的视角之间自如切换，并理解它们的关联和影响。要用全局视角和系统性思维将这些架构层面串联起来，形成一个有机的统一体。

系统性思维的核心是对系统的整体性和关联性的深刻认知。系统不是各个部分的简单堆砌，而是由多个要素按照某种结构形成的具有特定功能的有机整体。系统中任何一个细微的改变，都可能影响到整个系统。

系统性思维中的一些关键点包括：

• 分解与组合：将复杂系统分解为若干个可管理的子系统，并考虑子系统之间的交互和组合方式。
• 抽象与建模：从混沌的现实中抽象出关键因素，建立简洁有效的系统模型，并在模型上进行推演分析。
• 正反馈与负反馈：考虑系统中的正反馈(自我增强)和负反馈(自我稳定)机制，并加以利用或控制。
• 短期与长期：既考虑当前的近期目标，也要放眼系统的长期愿景，进行前瞻性设计和决策。
• 整体与局部：在局部优化的同时，要考虑对整体目标的影响。避免局部利益损害整体利益。

架构师还需要运用系统性思维来进行风险管控。任何复杂系统都存在一定的风险和不确定性。架构师要有全局视角来识别系统的风险点，评估风险的可能性和影响程度，并制定风险应对预案。

风险管理的一个重要手段就是架构演进。架构不是一成不变的，而是需要在不断地监控、评估、改进中动态演化的。架构师要基于反馈数据，评判架构的健康度，识别架构可改进点，制定演进路线，循序渐进地优化系统。

全局视角和系统性思维是架构师用于驾驭复杂系统的有力工具。它们让架构师能超脱出表象，抓住事物的本质，洞察内在的规律。它们让架构师能在纷繁复杂的现实中理清头绪，找到最优解。

这种能力的培养需要架构师在理论学习和实践历练中不断积淀。在理论层面，架构师可以学习系统思维、复杂性科学、控制论（强烈推荐）等知识，开拓思维视野。而在实践中，架构师可以尝试从不同角度审视系统，进行多维度分析，将系统思维落地应用。

4. 沟通与协作能力

在系统架构设计和实现的过程中，沟通与协作能力的重要性不言而喻。架构师不仅是技术的专家，更是团队的桥梁和领导者。他们需要在跨团队、跨职能的环境中，清晰地传达设计思路，协调各方资源，推动项目朝着既定的目标前进。

架构师的一个核心职责是将复杂的架构设计转化为易于理解的概念，并有效地传达给不同背景的团队成员。清晰的表达能力不仅包括口头沟通，还包括书面沟通，如架构文档、设计图表、技术规范等。

在一个项目中，架构师需要面对不同背景和技能水平的受众，包括开发人员、测试人员、项目经理、产品经理、客户以及高层管理者。不同的受众对技术的理解深度和关注点各不相同，因此架构师需要根据受众的特点调整沟通的内容和方式。

对于开发团队，架构师需要详细解释架构的技术细节、设计模式、接口定义等，并确保开发人员理解并能够实现这些设计。对于产品经理和业务人员，架构师则需要将技术概念转化为业务价值，解释系统如何满足业务需求、提升用户体验、支持未来扩展等。

架构师需要与公司高层沟通，向他们汇报项目的技术进展、存在的风险以及需要的资源支持。与高层的沟通要求架构师能够从业务价值的角度来解释技术决策，并能够清晰地表达项目的需求和挑战。

复杂的系统架构往往难以通过语言或文字完全描述清楚。可视化工具如 UML 图、系统架构图、流程图等，能够帮助架构师更直观地展示系统的结构和工作原理。这些工具不仅有助于团队成员理解架构设计，还能作为讨论和评审的基础。

通过这些可视化工具，结合架构文档的输出，记录系统的设计决策、技术方案，为开发、测试、运维等各个环节提供了指导和参考。

一个好的架构师需要具备编写清晰、详尽且可维护的文档的能力。在编写架构文档时，架构师需要关注以下几个方面：

• 结构清晰：架构文档应有清晰的逻辑结构，包括系统概述、设计原则、模块划分、接口定义、技术选型、非功能性需求等部分。这样可以帮助读者快速找到所需信息。
• 语言简洁：文档中的语言应尽量简洁明了，避免使用过于复杂的术语或冗长的描述。对于不可避免的专业术语，建议在文档中提供简要解释。
• 图文结合：文档中应适当使用图示，如架构图、时序图、状态图等，以增强内容的可读性和理解度。
• 版本控制：架构文档应随着系统的演进而更新，确保文档始终反映当前的系统状态和设计决策。架构师需要为文档建立合理的版本控制机制，方便团队成员查阅历史设计和变更记录。

除了沟通，协作也是架构师的重要软技能。协作强调利益相关方之间的协同配合，形成合力，朝着共同目标前进。

架构师需要搭建协作的框架和机制，包括：

• 明确分工：根据架构设计合理划分任务，明确各方的职责边界，避免出现责任真空或重复工作。
• 建立规范：制定架构设计、开发实施、测试验收等各个环节的规范和流程，让协作有据可依。
• 定期会议：组织架构讨论会、设计评审会、进度问题跟踪会等，及时同步信息，发现和解决问题。
• 共享工具：使用需求管理、架构设计、缺陷跟踪等协同工具，实现工作成果的共享和可视化。
• 问题升级：建立问题升级机制，将无法解决的问题逐级上报，避免问题遗留和扯皮现象。

有效的沟通与协作可以让架构师事半功倍。架构师要善于利用沟通协作这个利器，去解决复杂问题，去达成共同目标。

5. 项目管理能力

架构师不仅仅是技术专家，更是项目的领导者和管理者。出色的项目管理能力，是架构师必备的领导力技能。架构师需要统筹项目全局，把控项目进度，调配项目资源，领导项目团队，最终确保架构设计在项目中得到高质量落地。

项目管理是一门复杂的科学和艺术。它涉及项目生命周期的方方面面，需要架构师在以下几个方面展现项目管理才能：

1. 项目规划与目标设定：成功的项目始于清晰的项目规划和目标设定。架构师需要与项目经理、产品经理及其他利益相关者密切合作，定义项目的范围、目标和关键里程碑。
2. 资源分配与调度：项目成功的关键在于有效的资源分配与调度。架构师需要根据项目的需求，合理分配开发人员、测试人员、设计人员等资源。
3. 进度跟进与风险管理：项目管理的另一关键是对进度的跟踪和风险的管理。架构师需要确保项目按计划推进，并能及时识别和应对风险。
4. 质量管理与交付：项目管理还包括对项目质量的管理和最终交付的把控。架构师需要确保项目产出符合预期的质量标准，并能顺利交付给客户或投入生产环境。

以上是从目标、资源、进度和风险、质量和交付的逻辑来看项目管理，也可以参考 PMP 相关的项目管理逻辑来看，如下：

1. 制定项目计划：架构师要根据架构设计，估算项目工作量，拆分项目任务，制定项目进度表，确定关键里程碑。
2. 控制项目进度：架构师要跟踪项目实施进展，监控里程碑达成情况，发现进度偏差，及时采取纠偏措施。
3. 管理项目范围：架构师要管控需求变更对架构的影响，必要时进行架构调整，避免架构蔓延或项目延期。
4. 调配项目资源：架构师要评估项目所需的人力、物力、财力等资源，合理调配资源，解决资源冲突。
5. 控制项目质量：架构师要建立架构评审和验收机制，把控架构实施的质量，确保交付物符合预期。
6. 管理项目风险：架构师要提前识别技术和管理风险，制定风险应对策略，最小化风险对项目的影响。
7. 领导项目团队：架构师要组建和激励项目团队，促进团队协作，化解团队冲突，提升团队战斗力。
8. 管理项目干系人：架构师要协调项目干系人(如业务方、测试、运维等)的诉求，平衡他们的利益冲突。

架构师的项目管理能力成长过程中可以从小项目做起，循序渐进，逐步承担更大更复杂的项目。要善于复盘项目，总结得失，举一反三。也要虚心向优秀的项目管理者学习，掌握先进的管理理念和方法，如敏捷管理、精益管理等。

建议考个 PMP 之类的项目管理证书，夯实自己在项目管理上的理论基础。

6. 质量保障与技术债务管理

在软件开发中，质量保障和技术债务管理是确保系统长期健康和可维护性的关键因素。

质量保障不仅仅是对于最终产品的质量控制，还包括在开发过程中，通过各种策略和实践，确保系统在功能性、性能、安全性、可维护性等方面达到预期标准。同时，技术债务是指在开发过程中为了快速交付而做出的技术妥协或欠缺的设计决策，这些债务如果不加以管理，将会随着时间的推移积累，导致系统的维护成本增加，甚至影响系统的稳定性和扩展性。

6.1 质量保障策略

质量保障是从开发的各个阶段入手，通过一系列策略和实践，确保系统的整体质量。架构师在质量保障中扮演着至关重要的角色，负责定义质量标准，制定质量保障策略，并监督这些策略的实施。

这个事情并不一定是架构师自己一个人来做，会有相关的 QA 同学来负责，但是作为架构师对于质量保障需要有清晰的认知和决策。

6.1.1 质量标准的定义

质量标准是质量保障的基础，架构师需要与研发、QA、产品一起，定义明确的质量标准。这些标准应涵盖系统的各个方面，包括功能性、性能、安全性、可用性、可维护性等。

• 功能性要求： 系统是否实现了预期的功能，是否满足了业务需求。架构师需要确保功能设计的合理性和完整性，并在开发过程中通过测试验证功能的实现。
• 性能要求： 系统在高负载下的表现是否符合预期。架构师需要定义性能指标，如响应时间、吞吐量、资源利用率等，并通过性能测试验证系统的性能表现。
• 安全性要求： 系统是否具备应对安全威胁的能力，如防止数据泄露、抵御攻击等。架构师需要定义安全标准，并通过安全测试和代码审查确保系统的安全性。
• 可用性要求： 系统的可靠性和稳定性是否满足用户的期望。架构师需要考虑系统的架构设计，确保系统能够应对故障和恢复，并通过可用性测试验证系统的稳定性。
• 可维护性要求： 系统的代码结构和设计是否易于理解和维护。架构师需要定义代码质量标准，并通过代码审查和静态分析工具确保代码的可维护性。

以上的质量标准落到项目中会有所偏重，如在满足功能性要求及性能要求的基础上，有些对于安全要求也有更严格的诉求。

通过定义明确的质量标准，架构师可以为项目的质量保障工作提供清晰的目标和方向。

6.1.2 质量保障措施

为了确保系统达到预期的质量标准，架构师需要在开发过程中采取一系列质量保障措施。这些措施包括但不限于代码审查、自动化测试、持续集成、持续交付等。

• 代码审查： 代码审查是质量保障的重要手段。通过对代码进行审查，架构师可以发现代码中的潜在问题，如逻辑错误、性能隐患、安全漏洞等。代码审查还可以促进团队成员之间的知识共享，提升团队的整体技术水平。
• 自动化测试： 自动化测试包括单元测试、集成测试、端到端测试等，它们是保证代码质量的重要工具。架构师需要推动团队建立全面的自动化测试体系，确保每次代码变更都经过充分的测试验证，避免引入新的缺陷。
• 持续集成（CI）： 持续集成是将代码变更频繁地集成到主干分支，并通过自动化构建和测试验证代码的正确性。架构师需要推动团队采用持续集成实践，确保代码变更能够快速发现问题并及时修复。
• 持续交付（CD）： 持续交付是在持续集成的基础上，进一步实现自动化的部署流程，确保系统能够随时交付到生产环境。架构师需要制定持续交付的策略，确保系统的部署过程稳定、可重复，并能够快速响应业务需求的变化。
• 静态代码分析： 静态代码分析工具可以在代码编译前发现潜在的代码质量问题，如未处理的异常、不安全的代码模式、代码复杂度过高等。架构师可以引入静态代码分析工具，并将其集成到持续集成流程中，自动检测代码质量问题。
• 技术回顾与优化： 在开发过程中，架构师应定期组织技术回顾会议，评估系统的质量状况，讨论存在的问题，并制定优化方案。通过持续的技术回顾和优化，架构师可以确保系统的质量水平不断提升。

通过这些质量保障措施，架构师可以在开发的各个阶段确保系统的高质量，并减少后期的维护成本。

6.1.3 质量保障的持续改进

质量保障不是一蹴而就的，它需要在项目的整个生命周期中不断改进。架构师需要通过持续的反馈和改进，逐步提升系统的质量保障水平。

• 反馈机制： 架构师需要建立有效的反馈机制，及时收集项目中的质量问题和开发团队的反馈。例如，通过代码审查工具、测试报告、用户反馈、生产监控等渠道，架构师可以获得系统质量的实时数据，并据此进行改进。
• 持续改进计划： 根据反馈的质量问题，架构师需要制定持续改进计划。改进计划应包括问题的根本原因分析、改进措施的制定和实施、改进效果的评估等。通过持续改进，架构师可以逐步提升系统的质量水平。

在持续改进过程中，对于前面的质量标准，需要有更细化一些的质量指标报表，或者质量地图类的可视化的方案，以能较直观的观测到质量的情况，通过质量指标这些来驱动整个质量的改进。

在质量指标中可以分为过程质量、产品质量和综合质量三个维度：

1. 过程质量指标过程质量指标反映了在软件开发过程中各项活动的规范性和有效性。常见的过程质量指标包括：
   • 需求变更率：反映需求的稳定性和可控性
   • 代码审查发现的缺陷率：反映代码质量和评审有效性
   • 单元测试覆盖率：反映代码可测试性和测试充分性
   • 集成测试缺陷密度：反映模块间接口匹配程度
   • 进度偏差率：反映项目进度的可控性

通过跟踪这些过程指标，架构师可以及时发现开发过程中的薄弱环节，并有针对性地改进过程质量。

2. 产品质量指标产品质量指标反映了最终交付产品的质量特性。常见的产品质量指标包括：
   • 缺陷密度：反映产品的功能正确性和稳定性
   • 性能指标：如响应时间、吞吐量等，反映产品的性能表现
   • 可靠性指标：如平均故障间隔时间、平均修复时间等
   • 易用性指标：如用户满意度、任务完成率等，反映用户体验
   • 可维护性指标：如代码复杂度、文档完备度等，影响产品后续维护

架构师需要建立产品质量评估模型，定期评估这些指标，以量化产品的质量状况。

3. 综合质量指标综合质量指标从更高层次评价项目的质量管理成效。常见的综合质量指标包括：
   • 质量成本：包括预防成本、鉴定成本、内部失败成本、外部失败成本，反映质量投入产出比
   • 质量满意度：涵盖客户满意度、用户满意度、团队满意度等，toC 一般以用户满意度。
   • 项目质量评分：对项目质量管理进行定性评估
   • 质量成熟度：参考 CMMI 等质量成熟度模型的要求

综合质量指标为项目质量管理提供宏观视角，有助于领导层做出正确的决策。

架构师要建立完善的质量度量体系，定义清晰的质量指标，通过可视化手段直观展现。通过持续跟踪质量趋势，评估改进效果，形成良性循环，助力项目质量不断提升。

同时，质量文化也很关键。架构师要在团队中倡导「质量第一」的理念，鼓励大家主动关注质量，形成人人重视质量的氛围。只有质量意识深入人心，质量保障的持续改进才有坚实基础。

6.1.4 质量保障的工具与技术支撑

质量保障需要工具和技术的有力支撑。合适的工具可以自动化重复性工作，提高效率;先进的技术手段可以发现难以察觉的缺陷，提升质量。架构师需要选择和使用恰当的工具和技术，为质量保障保驾护航。

• 静态分析工具： 静态分析工具可以不运行程序，而是通过分析源代码找出其中潜在的质量问题，如语法错误、安全漏洞、性能瓶颈、不良编码习惯等。常见的静态分析工具有 SonarQube、Checkstyle、FindBugs、PMD 等。引入静态分析可以尽早发现和消除代码质量隐患。

• 自动化测试工具： 自动化测试工具可以按照预定的测试脚本自动执行测试，大大提高测试效率和覆盖度。单元测试、集成测试、系统测试、回归测试、性能测试等各种测试类型都有相应的自动化测试工具。比如 JUnit 用于 Java 单元测试， Selenium 用于 Web UI 自动化测试，JMeter 用于性能压力测试等。自动化测试是保障系统质量的有力武器。

• 持续集成/持续交付(CI/CD)： 持续集成意味着频繁地将代码集成到主干，每次集成都通过自动化构建和自动化测试来验证。持续交付在持续集成的基础上，将验证通过的代码自动部署到类生产环境。引入 CI/CD 可以尽早发现集成问题，减少缺陷，同时提高交付效率。常用的 CI/CD 工具有 Jenkins、GitLab CI、Travis CI等，以及各云厂商的效能工具。

• 代码覆盖率工具： 代码覆盖率工具可以度量测试用例对代码的覆盖情况，包括语句覆盖、分支覆盖、路径覆盖等。通过代码覆盖率可以评估测试的充分性，发现测试盲点。常见的 Java 代码覆盖率工具有 JaCoCo、Cobertura 等。

• 缺陷管理工具： 缺陷管理工具可以记录、跟踪、管理项目中的缺陷或问题，形成缺陷知识库，为缺陷预防、缺陷定位、项目管理决策提供数据支持。比较常用的缺陷管理工具有 JIRA、Bugzilla、Redmine 等。

• 代码安全扫描工具： 随着安全问题日益突出，代码安全扫描工具受到越来越多的重视。这类工具可以自动检测代码中的安全漏洞，如SQL注入、跨站脚本攻击等，并提供修复建议。代表性的代码安全扫描工具有 Checkmarx、Fortify、SonarQube等。

• 性能剖析工具： 性能剖析工具可以分析系统运行时的性能表现，找出性能瓶颈和热点代码。常见的性能剖析工具有JProfiler、YourKit 等。借助这些工具，开发人员可以优化代码，架构师可以评估系统容量和伸缩性需求。

除了工具，架构师还需要运用各种质量保障的技术和方法，如故障注入、渗透测试、风险分析等，全方位提升系统质量。

架构师要审时度势地选择工具和技术，既要考虑其适用性和成熟度，又要平衡引入成本和学习成本。要让正确的工具用在正确的场合，创造最大价值。

质量保障没有捷径可走，需要工具、技术、流程、人员的齐头并进，更需要架构师高屋建瓴的顶层设计和坚持不懈的推动。唯有如此，质量的大厦才能根基稳固，巍然耸立。

6.2 技术债务管理

技术债务是系统开发过程中不可避免的现象，但如果不加以管理，技术债务将会逐渐积累，最终成为系统维护和扩展的巨大障碍。架构师在项目中需要重视技术债务的管理，通过有效的策略和实践，控制技术债务的积累，并在适当的时机偿还技术债务。

6.2.1 技术债务的识别

技术债务的识别是技术债务管理的第一步。架构师需要能够识别出系统中的技术债务，并评估其对系统的影响。

• 代码复杂度： 代码复杂度高的模块通常是技术债务的集中区域。架构师可以通过静态代码分析工具，识别出代码复杂度高的模块，并评估这些模块的维护性和扩展性。
• 设计不一致性： 在系统的设计过程中，可能会由于时间紧迫或需求变化导致设计不一致性。这些不一致性是技术债务的一种表现，架构师需要通过系统的架构审查，识别出设计不一致性，并评估其对系统的影响。
• 依赖管理问题： 系统中的过时依赖、不兼容的依赖或依赖循环也是技术债务的一种形式。架构师需要定期检查系统的依赖关系，识别出潜在的技术债务，并制定相应的解决方案。
• 技术负担： 使用过时的技术或滥用技术也是技术债务的表现。架构师需要评估系统的技术栈，识别出可能成为技术负担的组件，并计划技术栈的更新或替换。
• 缺乏自动化测试： 缺乏自动化测试特别是单元测试和集成测试的代码也是一种技术债务。架构师需要评估系统的测试覆盖率，识别出测试不足的模块，并制定相应的测试补充计划。

通过识别技术债务，架构师可以对系统的健康状况有一个全面的了解，并为技术债务的管理打下基础。

6.2.2 技术债务的评估与优先级确定

识别出技术债务后，架构师需要对技术债务进行评估，并根据其对系统的影响确定优先级。

• 影响评估： 技术债务的影响评估包括对系统性能、稳定性、可维护性、可扩展性等方面的影响进行分析。架构师需要评估技术债务对系统的长期影响，并根据影响的严重性确定技术债务的优先级。
• 偿还成本评估： 除了影响评估外，架构师还需要评估偿还技术债务的成本。这包括开发资源的投入、潜在的风险、业务交付的影响等。通过评估偿还成本，架构师可以权衡技术债务的偿还优先级。
• 业务优先级考量： 在确定技术债务优先级时，架构师还需要考虑业务优先级。如果某个技术债务对业务的影响较大，或阻碍了业务的扩展，架构师需要优先解决这些技术债务。
• 风险评估： 技术债务的积累可能带来系统的风险，架构师需要通过风险评估，确定哪些技术债务最有可能引发系统故障或严重影响业务。这些高风险的技术债务应当被优先偿还。

通过评估和优先级确定，架构师可以合理安排技术债务的偿还计划，确保技术债务的偿还对系统和业务的影响最小化。

6.2.3 技术债务的偿还策略

技术债务的偿还需要制定合理的策略，以在不影响业务交付的情况下，逐步减少技术债务的积累。

• 持续偿还策略： 持续偿还策略是将技术债务的偿还工作分散到日常开发中。架构师可以通过设定每个开发周期的技术债务偿还目标，逐步减少技术债务。例如，每个冲刺中分配一定的时间或资源用于偿还技术债务。
• 集中偿还策略： 集中偿还策略是针对某些严重的技术债务，集中资源进行一次性偿还。架构师可以在业务需求较少或系统维护期，组织团队集中解决技术债务，确保系统的健康发展。
• 技术重构： 对于积累较多技术债务的模块，架构师可以考虑进行技术重构。技术重构可以通过重新设计和实现，彻底解决技术债务，并提升系统的性能和可维护性。架构师需要在技术重构前进行充分的评估和准备，确保重构的风险可控。重构要谨慎。
• 预防性维护： 预防性维护是通过定期的系统检查和优化，防止新的技术债务产生。架构师可以制定系统的定期维护计划，定期检查代码质量、依赖关系、性能表现等，及时发现和解决潜在的技术债务。
• 技术栈更新： 随着技术的进步，系统使用的技术栈可能会逐渐过时，成为技术债务的一部分。架构师需要制定技术栈的更新计划，确保系统始终使用最新的技术，并避免技术债务的积累。

通过合理的技术债务偿还策略，架构师可以逐步减少系统中的技术债务，保持系统的长期健康和可维护性。

质量保障与技术债务管理是软件开发中至关重要的两个方面。通过有效的质量保障策略，架构师可以确保系统在功能性、性能、安全性、可维护性等方面达到预期标准，减少后期的维护成本。同时，通过合理的技术债务管理策略，架构师可以控制技术债务的积累，并在适当的时机偿还技术债务，保持系统的长期健康和可持续发展。

质量保障与技术债务管理之间存在紧密的联系，架构师需要将两者结合起来，形成一个完整的系统健康管理体系。通过持续的反馈和改进，架构师可以不断提升系统的质量水平和技术债务管理能力，支持系统的长期发展和业务的持续增长。

7. 创新与前瞻性思维

站在时代的潮头，引领技术的变革，是每一个架构师的终极追求。然而，惟创新与前瞻，才能不断开启未来的大门。这需要架构师跳出现有的思维定式，以创新的勇气、前瞻的眼光，重新审视架构的边界与可能。需要架构师在变革的路口，以革新的魄力、超前的谋略，开创新架构的蓝海。

创新，是架构师的灵魂。一个缺乏创新活力的架构，犹如一潭死水，终将腐朽。一个崇尚创新进取的架构，定能搏击长空，引领潮流。正如中台架构、微服务架构，无不是创新思维的结晶。

架构师要成为创新的鼓吹者和先行者。敢于质疑现状，勇于突破陈规，以创新的思路解决发展的难题。具体要做到：

1. 跳出框框看架构：要突破固有的思维框框，从更高维度审视架构。打破部门墙，跨越业务界，以开放的心态拥抱变化。多元思考，博采众长，在交叉融合中找到创新的源泉。
2. 在矛盾中找创新：要在矛盾和冲突中发现创新的契机。现有架构的不足之处往往蕴藏着创新的因子。对架构”吐槽”最多的地方，恰是创新的沃土。要化压力为动力，在问题解决中实现创新突破。
3. 在需求中找创新：要从业务需求的本质出发寻求创新。深入一线，贴近业务，感受需求的脉搏。洞察需求背后的真正诉求，挖掘需求中的创新潜力。需求是创新的原点，唯有需求至上，创新才有意义。
4. 在技术中找创新：要紧跟技术前沿，从新技术的应用中找到创新的灵感。云计算、大数据、人工智能等新技术的出现，无疑为架构创新提供了广阔的舞台。要放眼全局，审时度势，找准技术创新的切入点和落脚点。
5. 鼓励创新文化：要在团队中营造创新的土壤，倡导百花齐放、百家争鸣的创新文化。包容失败，宽容试错，让团队敢为天下先。建立创新激励机制，搭建创新交流平台，让创新成为架构演进的源动力。
6. 创新要快速验证：创新固然重要，但也要讲求方法和策略。新的架构创意需要经过快速的检验和迭代，灵活调整。可采用AB测试、灰度发布等方式，小步快跑，快速迭代。让创新水到渠成，落地生根。

可以说，创新是引领架构突围的利剑，是决胜未来的法宝。架构师要当仁不让地成为「创新者」，以「永不止步」的进取精神，开疆拓土，攻坚克难。在创新的路上，你就是引路人，你就是开拓者。创新的大旗就在你手中，创新的号角已经吹响，创新的航船正在起航。让我们携手共进，在创新中开启架构的新篇章!

如果说创新是架构突围的利器，那么前瞻性思维就是架构基业长青的根本。一个有远见卓识的架构师，应当立足当下，放眼未来，以前瞻的思维、未卜先知的洞察力，预判技术和业务的发展趋势，引领架构的变革方向。

前瞻性思维，招之则来，挥之则去。然而修炼前瞻性思维，却需要架构师拥有视野、格局、谋略三大要素：

1. 视野：架构师要具备广阔的技术视野。了解业界先进理念，把握技术演进脉络。追踪学术前沿，关注行业动态，保持对新事物的敏锐嗅觉。视野是前瞻性思维的”望远镜”，开阔视野方能纵览全局，洞悉先机。
2. 格局：架构师要胸怀技术发展大格局。技术创新不是单打独斗，而是融入行业生态的协同进化。要跳出自我的小天地，站在行业发展的制高点展望未来。格局是前瞻性思维的”指南针”，唯有恢弘格局，方能运筹帷幄，决胜千里。
3. 谋略：架构师要深谙技术演进的奇正之道。任何新技术的发展都不是一蹴而就，而是攻坚克难的过程。要洞察其中的机遇与挑战，权衡其中的得失与代价，在动态博弈中把握变革的时机和节奏。谋略是前瞻性思维的”运筹帷幄”，唯有高瞻远瞩，方能决胜未来。

视野、格局、谋略，构成了架构师前瞻性思维的「三驾马车」。三者相辅相成，缺一不可。唯有登高望远，才能纵览全局；唯有心怀天下，才能运筹帷幄；唯有谋定后动，才能决胜千里。

培养前瞻性思维，还需要架构师锤炼以下几项基本功：

1. 第一是技术敏感性。对最新最酷的技术嗅觉灵敏，保持如饥似渴的好奇心。时刻关注行业技术动向，追踪技术发展轨迹。从纷繁复杂的信息碎片中捕捉技术风向标。
2. 第二是产业洞察力。要透过技术现象看本质，洞察技术背后的驱动力和制约力。判断技术成熟度，思考应用场景，评估收益与风险。做技术发展的「千里眼」。
3. 第三是思维前瞻性。要习惯从长远角度思考问题，从一个趋势思考另一个趋势。在当下与未来间建立连接，描绘技术发展的路线图。唯有高屋建瓴，方能走在时代前列。
4. 第四是实践探索性。纸上谈兵终觉浅，唯有实践出真知。对前沿技术要勇于试水，敢于吃螃蟹。在实践中增强认知，找准方向，积累经验。
5. 第五是全局统筹力。顶层设计至关重要。要统筹考虑业务、技术、资源、风险等全局因素，权衡轻重缓急，兼顾当下与长远。唯有统筹谋划，方能稳健发展。

可以看出，前瞻性思维不是一蹴而就的。它来自知识的积累，来自经验的淬炼，更来自深邃的洞察和敏锐的直觉。架构师要在点滴中修炼，在积累中提升，让前瞻性思维成为融会贯通的本领、成竹在胸的智慧。

当下，新一轮科技革命和产业变革正蓬勃兴起。云计算、大数据、人工智能、区块链、5G 等新技术浪潮汹涌澎湃，新业态新模式层出不穷。这既是机遇，也是挑战。机遇在于，新技术为架构创新打开了崭新的想象空间；挑战在于，新业态对架构的灵活性、扩展性、稳定性提出了更高要求。

架构师要在纷繁复杂的技术长河中把握发展的主航道，在层出不穷的新业态中发现架构演进的新路径。要居安思危，未雨绸缪，做好架构转型的准备。唯有顺势而为，因势利导，方能立于不败之地。

总结

要成为一名优秀的架构师，以上七大核心能力缺一不可。

系统设计与建模能力帮助架构师构建出合理的系统架构，技术广度与深度确保架构师能够在技术上做出正确的决策，全局视角与系统性思维帮助架构师从整体上把握项目的方向，沟通与协作能力则确保架构师能够有效地领导团队。项目管理能力、质量保障与技术债务管理、创新与前瞻性思维这些能力共同支撑了架构师在项目中的成功。

在实践中，架构师需要不断学习和提升这些核心能力，才能在复杂多变的项目环境中游刃有余，带领团队实现技术和业务的双重成功。

优秀的架构师不仅是技术的专家，更是项目的引领者和团队的支柱。希望这篇文章能够为立志成为架构师的读者提供一些有价值的思考和启发。

以上

这本与其说是书，不如说是演讲实录。书的内容来源自张小龙在 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

2023 年 11 月份，我们见证了两次重大的网络服务故障：11 月 12 日下午，阿里云服务出现异常，导致依赖其服务的多个厂商及其产品功能受损，包括其自身的产品钉钉。紧接着，11 月 27 日晚，滴滴打车应用程序出现故障，直到 28 日中午才逐渐恢复正常。这次滴滴的服务中断超过了 12 个小时，引起了用户和司机的混乱和不便。

就在昨天，12 月 1 日上午，上海医保系统无法进行结算，网友形容「看病一分钟，排队两小时」，凸显了网络服务依赖的脆弱性。

特别一点说，滴滴出行在 2023 年 11 月 27 日发生的故障，使我们不得不重新思考我们对系统复杂度的认知。从滴滴的恢复过程中可以看出，系统经历了部分恢复、再次出现问题，数据混乱等现象。整个系统看似处于混乱之中，但在多方努力介入处理后，逐渐恢复稳定并重新运作。这个过程好比一个受伤的系统在逐步疗愈。

公众的反应也多种多样，有人归咎于滴滴的「降本增效」策略，有人认为是管理层的失误，还有人指责技术升级不当。但如果把滴滴看作一个整体的系统，它无疑是高度复杂的，由人员、组织结构和各种在线系统组成。这个系统的复杂性在平时可能被我们低估，因为每个人通常只关注自己负责的那部分工作。

要理解一个系统的系统复杂度，可以从四个维度来考察：组分复杂度、结构复杂度、功能复杂度和描述复杂度。

组分复杂性

组分复杂性是指一个系统中各个部分（或称为「组分」）的多样性、数量以及它们之间的交互关系所带来的复杂性。 这种复杂性主要体现在以下几个方面：

• 1. 构成复杂性：也就是系统由多少个不同的部分组成，这些部分又是如何相互关联和影响的。滴滴出行的系统由订单处理、司机分配、定位导航、支付处理、用户反馈等多个子系统组成。这些子系统都有自己的运行逻辑和规则，而且它们之间还需要相互配合和协调。这些系统的交互和协调就构成了滴滴的构成复杂性。
• 2. 分类复杂性：指的是系统内部的各个部分有多种多样，它们分布的规律性、差异性以及由于各个部分的不同性质带来的复杂性。如滴滴的用户包括乘客和司机，他们的需求和行为都各不相同。比如乘客可能有急需用车的，也有提前预约的；司机可能有全职的，也有兼职的。而滴滴系统需要根据这些不同的需求和行为来做出响应，如何处理这些不同的分类就构成了滴滴的分类复杂性。
• 3. 规模复杂性：这是指系统内部包含的部分的数量和种类的多少。数量越大，种类越多，系统的复杂性就越高。滴滴的用户数量非常庞大，每天需要处理的订单数量也是海量。这就要求滴滴的系统必须能够在短时间内处理大量的信息并做出决策，比如如何快速匹配乘客和司机，如何计算最佳路线等。同时，滴滴还提供了多种服务类型，如快车、专车、顺风车等，每种服务类型又有自己的规则和特性。如何管理这些大规模的数据和多样化的服务就构成了滴滴的规模复杂性。

结构复杂性

结构复杂性关注系统的整体结构以及各个部分之间的排列、组织和层次关系的复杂性。这种复杂性主要体现在以下三个方面：

1. 组织复杂性：这是指一个系统内部各个部分之间的组织方式有多么复杂。例如，一个公司的组织架构，有多少部门，这些部门之间是如何分工合作的，就构成了组织的复杂性。又或者像滴滴系统是由多个子系统组成的，包括订单处理系统、定位系统、支付系统、评价系统等等。这些子系统需要协同工作，以提供顺畅的出行服务。

2. 层次复杂性：这是指一个系统可以被划分为多少个层次或等级，以及这些层次之间的关系也会非常复杂。如滴滴的系统，从上层的应用架构，到底层的服务架构，再到更下面的物理架构层，每个层次都有其内在的复杂性，而层与层之间的交互和协作也会引入额外的层次复杂性。以基础设施为例，这些基础设施的任何故障都可能导致滴滴的线上故障。

3. 过程复杂性：这是指一个系统内部的运行和交互过程有多么复杂。滴滴的运行涉及到许多复杂的过程，如订单匹配、路线计算、费用结算等。这些过程中都涉及到了大量的计算和决策，而且经常需要实时地调整和优化。同时，滴滴的运行还受到外部环境的影响，比如交通状况的变化、法规政策的变更、天气变化等，这些都会影响到滴滴的运行过程，使其变得更加复杂。

结构复杂性就是由于一个系统内部各个部分之间的关系错综复杂，使得系统的行为和性质变得难以预测和理解。

功能复杂性

功能复杂性实际上描述了一个系统在不同情况下处理问题的难易程度，包括预测、保持和调控三个方面。

1. 预测复杂性：就像预测天气一样，系统未来的状态可能会因为很多不确定的因素而变得难以预测。如滴滴系统在未来某一时刻的状态，如，预测在特定时间和地点的需求量可能会因为许多因素（天气、节假日，甚至是附近有没有大型活动等）而变得相当复杂。

2. 保持复杂性：保持系统稳定正常的运转也需要对各种要素进行精细的平衡，如遇到大流量的冲击，安全攻击，甚至爬虫或者某些 BUG，想象你在平衡一只装满水的杯子，这需要非常多的复杂性和一些精细的调整。

3. 调控复杂性：如果你想改变系统的某些功能，就像在一个复杂的机器中更换部件一样，像增加某些功能，对于现有复杂度的影响，以及删减某些功能或子系统，对系统中的组分的影响，结构的情况等等。

在我们面对一个复杂系统时，对系统进行预测、保持和调控都是在钢丝上跳舞。

描述复杂性

简单来说，描述复杂性就是理解和描述一个系统需要多少工作量和信息量的度量。 稍微复杂一点，描述复杂性是从描述系统的状态的工作量、信息量以及存储量角度来定义系统的复杂性。它以数学的复杂性理论和信息论为基础，主要包括以下三个方面：

1. 计算复杂性：这是指解决一个问题所需要的计算资源，包括时间和空间，也就是我们在编程时常说的时间复杂度和空间复杂度。例如，一个问题如果需要很长的时间或大量的内存来解决，那么我们就说它具有高计算复杂性。

2. 算法复杂性：这涉及到解决问题的过程中的多样性和随机性。想象你正在解决一个复杂的拼图，需要尝试不同的拼接方法，这就是算法复杂性，描述了解决问题的过程中的步骤和方法有多复杂。

3. 有效复杂性：如果你要向别人解释一个很复杂的概念，你需要多少话才能解释清楚，这就是有效复杂性，代表了描述一个系统的规律性需要多少信息。

在这些方面中，计算复杂性和算法复杂性主要关注解决问题的过程，而有效复杂性则更多地关注对问题本身的描述。

上面四种复杂性中，组分复杂度和结构复杂度看起来会有一些相似的地方，容易搞混，它们关注的角度和内容有所不同：

1. 组分复杂性：这是关注系统中各个部分（或组分）的多样性、数量以及它们之间交互关系的复杂性。组分复杂性的关注点在于系统的各个组成部分以及这些部分之间的关联关系。例如，一个城市的交通系统中，公交、地铁、出租车、自行车等多种交通工具以及它们之间的转换和配合，这就构成了交通系统的组分复杂性。

2. 结构复杂性：这是关注系统的整体结构以及各个部分之间的排列、组织和层次关系的复杂性。结构复杂性的关注点在于系统的整体架构、层次关系以及系统运行的过程。例如，一个公司的组织架构中，不同部门的划分、部门之间的协作关系，以及公司运营、决策的流程，这就构成了公司的结构复杂性。

简单来说，组分复杂性着重于系统的各个部分和它们之间的关系，而结构复杂性则更加关注系统的整体架构和运行过程。在实际应用中，我们往往需要同时考虑这两种复杂性，以全面理解和处理复杂系统。

通过这种四种复杂性我们能较全面的评估我们所面对的系统的复杂度，不低估，也不过度夸大它的复杂性。

对系统复杂度的综合评估揭示了系统的脆弱性和潜在的优化路径，引导我们设计出更为韧性强、可适应性高的系统结构。这种洞察力使我们能够制定针对性的决策和策略，优化资源配置，创造更加流畅的用户体验，并在面对不断变化的需求和潜在危机时，保持服务的连续性与质量。

通过深入理解系统的组分、结构、功能和描述复杂度，我们不仅能够减少业务中断的风险，还能在持续的服务创新中保持竞争优势，实现系统的长期可持续发展。

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

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

认知成本

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

1. 学习成本：这是指为了掌握新的知识、技能或工具所需要的时间和精力。如一个开发同学需要学习一种新的编程语言，那么这就会产生学习成本。
2. 理解成本：这是指为了理解新的信息或知识所需要的时间和精力。如阅读和理解一份复杂的技术方案文档就会产生理解成本。
3. 处理成本：这是指为了处理信息，比如进行分析、整理或应用，所需要的时间和精力。如分析一份用户行为数据报告就会产生处理成本。
4. 决策成本：这是指为了做出决策，比如评估选项、权衡利弊、制定策略，所需要的时间和精力。如选择一个软件开发框架或选择一个市场策略就会产生决策成本。

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

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

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

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

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

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

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

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

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

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

沟通成本

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

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

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

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

1. 信息交流成本：包括团队成员之间进行面对面交流、写邮件、开会等方式的沟通所需的时间和精力。
2. 知识转移成本：当需要将知识或信息从一个团队成员传递给另一个团队成员时，可能需要进行培训、编写文档等，这都会产生一定的成本。
3. 协调成本：在团队成员之间协调工作，比如确定任务分配、同步项目状态、解决冲突等，都需要投入时间和精力。

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

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

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

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

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

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

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

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

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

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

非正常成本

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

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

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

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

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

小结

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

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

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

仔细回顾一下，有没有出现你的上级绕过你直接找你的下属来处理问题，而你一无所知，只有出了问题的时候才知道？有没有出现你发起了一个事情，任务已经交给下属/其它同事来跟进处理了，到截止时间，结果和你想象中的不一样？有没有出现你实在忍不住，亲自动手把那块代码写了，一边写还一边吐槽，也就十几分钟的事儿，跟他讲的时间都已经上线了……

如此种种，是不是很是亲切，经常会遇到。这到底是哪里出问题了呢？

如果把这些事项都当作一个项目来看的，这些项目中有三个主要角色：发起人（Sponsor）、负责人（Project Manager）和核心成员（Core Team Members）。上面的这些问题大多数是角色错位，职责分工不明确或者项目成员本身对于自己所在角色的认知不清晰导致的。

今天我们就聊聊这三个角色，以及经常会出现的问题。

发起人（Sponsor）

发起人是项目的发起者，他们通常是公司的高级领导人或决策者，有权利和资源来推动项目的实施。他们的主要职责和特点包括：

1. 确定项目的战略目标，并向所有相关方清晰地传达这些目标，一般不参与具体任务。
2. 提供必要的资源和资金以支持项目的实施。
3. 对项目有最终兜底责任，在必要时提供对项目的支持，解决可能对项目产生影响的问题和挑战。
4. 监督项目的进度，确保其符合预设的目标和期限，在大方向上正确。

发起人通常是关键利益相关方，他们提供项目必要的资源和支持，并在决策中扮演重要角色。然而，如果发起人的角色和职责没有被正确地理解和执行，可能会出现一些「坑」：

1. 不清楚角色：发起人需要知道他们的角色和职责，包括为项目提供资源、支持、决策和领导。如果发起人对自己的角色不清楚，可能会导致项目的推进中受到阻碍。

2. 缺乏参与：一般表现为撒手不管，把目标提了就不管了，作为发起人需要积极参与项目的关键决策，以确保项目的成功。如果发起人缺乏参与，可能会导致项目偏离目标，或无法解决关键问题。

3. 过度干预：与上面的缺乏参与相反，发起人如果过度干预项目的日常运作，可能会导致项目团队的困扰，影响项目的效率。

4. 缺乏支持：发起人需要提供项目所需的资源和支持。如果发起人不能或不愿提供足够的支持，可能会导致项目的进展受阻或者失败。

5. 沟通不畅：发起人需要与 PM 和项目团队保持良好的沟通，以确保项目的顺利进行。如果沟通不畅，可能会导致误解和冲突。

在上面的这些问题中，缺乏参与和过度干预是两个常见且严重的问题，这两个问题背后的原因是什么？

发起人可能因多种原因缺乏参与。这些原因可能包括时间和资源的限制，使他们无法深入参与每个项目；对团队的信任，使他们选择让团队自主执行；缺乏特定的技术或领域知识，使他们在技术性项目中保持距离；以及角色定位不明确，使他们不清楚他们在项目中的参与程度应该是多少。无论原因如何，发起人都需要保持对项目的关注，并定期与团队进行沟通和反馈，以确保项目的顺利进行。

发起人过渡干预的原因也有多种，概括起来为以下五点：

1. 太想要： 发起人对项目结果的强烈期待可能促使他们深度介入每个环节，并且确保结果符合期望。
2. 太着急： 发起人想快速拿到结果，这可能导致他们过度干预项目的进度，甚至可能在没有充分理解或考虑所有可能影响的因素的情况下，推动项目快速前进。
3. 不放心： 如果发起人对团队的能力或执行力有疑虑，他们可能会更频繁地插手过程中的工作。
4. 控制欲： 有些发起人有强烈的控制欲望，希望对每个项目细节都保持控制，这可能导致他们过度参与。
5. 不知道： 如果发起人对自身在项目中的角色不明确，他们可能会尝试涉足所有任务，而非专注于他们应该完成的职责。

这样的过度干预可能会导致一系列问题。首先，它可能会打乱团队的工作流程和效率，因为过多的干预可能会导致团队成员混乱或者反复更改方向。其次，它可能会破坏团队的士气，因为团队成员可能会觉得他们的专业能力或决策权被忽视。再次，过度干预会阻碍团队成员的成长，特别是对于 PM，过度干预可能剥夺他们解决问题和独立决策的机会，从而限制他们的职业发展和成长。最后，过度干预可能会阻碍项目的进展，因为发起人可能会过于关注细节而忽视了项目的整体进度。因此，发起人需要找到一个合适的平衡，既要关注项目的进展，也要尊重和信任团队的工作。

负责人（Project Manager）

负责人直接对发起人负责，是项目策划和执行的总负责，是项目团队的领导者。

PM 的主要职责包括以下四个部分：

1. 全面负责： PM 对项目的策划、执行和成功负有全责。PM 需要领导项目团队，完成全部项目工作，实现项目目标，满足客户需求。

2. 目标设定与资源分配： PM 需要与项目发起人协商确定项目目标，并平衡项目的资源、时间和风险。PM 需要带领团队制定一个多个达成共识了的项目计划。

3. 团队建设和沟通： PM 需要组建并领导核心团队，需要保持与团队成员的及时沟通，确保团队成员了解任务的背景和目标，以便高质量地完成任务。

4. 项目监督和沟通： 在项目执行过程中，PM 需要实时监控项目的进度，提供必要的指导，持续与团队和其他相关方沟通，以确保项目按照计划顺利进行。

对于 PM 来说，要达成上面的目标，必须要有强大的领导力、沟通能力、组织能力和决策能力，以及对项目管理的深入理解和专业知识。

在实际工作过程中，作为 PM，可能会出现以下的一些问题，看看这些问题里面有没有自己的身影：

1. 视角局限： 一些 PM 可能过于专注于执行任务，而忽视了他们作为领导者的角色。PM 不仅仅是执行者，他们需要负责项目的全面管理，包括规划、分工、监控和调整。解决这个问题的一个方式是提升 PM 的项目管理知识和技能，让他们了解到 PM 的职责远远超过了单纯的任务执行。

2. 角色误解：  PM 的角色不仅仅是协调者，他们还是项目的领导者和决策者。他们需要对项目的成功负全责，而不仅仅是「拿到一个鞭子到处抽」。PM 需要理解他们的角色，并尊重他们的职责。

3. 忽视相关方： 项目的成功不仅取决于项目团队的工作，还取决于与项目相关的所有方的合作。PM 需要理解并满足相关方的需求，与他们保持有效的沟通。否则，项目可能会因为没有满足相关方的期望而失败。

4. 与项目发起人的沟通不足：  PM 需要与项目发起人保持密切的沟通，确保项目的方向和结果符合发起人的期望。如果没有有效的沟通，项目的结果可能会与发起人的期望存在偏差，导致项目失败。

核心成员（Core Team Members）

核心成员向 PM 负责，其职责是对项目目标的实现提供关键支持，通过其专业技能和决策能力，推动项目的成功执行并解决项目过程中的重要问题。其主要职责包括：

1. 参与规划和决策： 核心成员通常会参与项目的规划和决策过程。可能需要提供专业的建议和意见，帮助 PM 制定计划和做出决策。这个非常重要。
2. 任务执行： 核心成员负责完成分配给他们的特定任务和工作。这可能包括设计、开发、测试、文档编写等各种任务。
3. 沟通和报告： 核心成员需要与 PM 和其他相关方进行有效的沟通。需要定期报告工作进度和结果，以便 PM 可以对项目进行有效的管理和控制。
4. 问题解决： 当项目遇到问题或困难时，核心成员需要积极找出问题的原因，并提出有效的解决方案。
5. 质量保证： 核心成员需要确保他们的工作满足项目的质量标准。他们可能需要进行自我检查，或参与项目的质量保证活动。

核心成员在项目管理中扮演着非常关键的角色，具体职责可能会根据项目的性质和规模有所不同。在实际的工作过程中，有一些常见的和核心成员相关的问题，如下：

1. 团队角色和职责不明确： 如果核心成员的角色和职责没有明确，可能会导致混乱和效率低下。核心成员应清楚了解他们在项目中的作用和期望。
2. 团队成员技能不匹配： 如果核心成员缺乏完成任务所需的技能或经验，可能会威胁到项目的成功。确保核心成员具有执行他们角色所需的技能和知识至关重要。
3. 团队沟通不足： 如果核心成员之间或者领导者与核心成员之间的沟通不充分，可能会导致误解和冲突。建立开放和有效的沟通机制至关重要。
4. 核心成员过多： 如果核心成员过多，可能会导致沟通和协调变得复杂，影响项目的推动。合理管理核心成员规模和结构，或者建立有效的大型团队管理策略，可以帮助解决这个问题。

其它坑

对于这三个角色，我们常常会踩一些坑而不自知，或者明知道是坑也忍不住踩了进去。

首先，三个角色「发起人、负责人和核心成员」都有可能面临「不知道自己不知道」的问题。这里最常见的表现是对当前所处的角色不清晰、对角色的职责不清晰，不知道应该是这样。为此，我们需要不断地学习和探索，以增强自己对项目管理的理解和自我认知。

其次，「知行不一」也是一个常见的问题。在认知上没有问题或者问题不大，但是实际执行时却做不到，无法达到预期，可能是自我管理的问题，比如各种原因控制不住自己，一直想插手等等。这就需要我们提高自我管理能力，包括情绪管理、时间管理和责任管理。需要学会信任团队成员，允许他们犯错误并从错误中学习，而不是总是亲自介入。同时，也需要学会管理自己的时间，把宝贵的时间用在最重要的任务上，而不是溜进琐事的无尽轮回中。

第三个问题是「短视」，只想着解决了眼前的问题，搞乱了整个事情，搞乱了机制和整盘棋。这可能是因为过于关注眼前的问题，而忽视了整个项目的大局，或者为了短期内的效益而牺牲了长期的利益。这需要发起人、负责人和核心成员时刻记住，他们的决策不仅会影响到眼前的任务，也会影响到整个项目的运行。需要考虑每个决策的背后，不仅仅是短期的结果还有长期的影响。为此，需要学习并运用项目管理的方法和工具，例如风险评估、影响分析等，以帮助更准确地预测每个决策的可能后果。

对于如何应对这些问题，我们都需要有耐心，用长沙话来说就是「耐得烦」，尤其是在面临困难和挫折时。多反思自己的决策，思考可能的后果，并努力做出最好的选择。此外，还需要在工作中积极合作，通过观察和学习来提升自己的技能和认知。如果能够做到这些，那么项目就成功了大半。

最后，「独木不成林」，一个人能力终归有限，这是对个体力量的客观认识。即使一个人的技能极为出众，他的时间和精力也是有限的。我们需要与他人合作，共享知识，共享经验，共同面对挑战。通过团队的力量，我们可以实现那些单个个体无法达到的目标。

最后思考：如果把工作中这些事情都当作一个个项目来管理，思考一下，在项目管理过程中，你的角色是什么？你这个角色的职责是什么？你把这个角色的本份做到位了吗？

当没有明确的立项过程时，目标模糊、资源浪费、沟通困难、出现项目风险等问题都会时有发生，从而影响整个项目的实施效果和公司的业务发展。

1 什么是立项

立项是一个组织或公司决定开始一个新项目时的决策过程，这个过程涵盖了对项目需求的明确、项目目标的设定、可行性的评估、资源的分配和风险的识别及管理等关键步骤。通过立项过程，组织能确保每个项目有明确的目标、适当的资源分配、风险控制措施以及一个清晰的执行计划，从而提高项目的成功率和效率。

立项的本质是一个综合的决策过程，其中项目的各干系方对目标、方案、成本、风险和里程碑等重要预期进行对齐，以便做出是否启动项目并如何分配资源的决定。

2 立项的作用

立项就像是给项目开个「导航」，帮助我们明确要去的目的地，规划好路线，分配好需要的人和物，预防可能的风险，确认能否按计划到达，并让所有人都了解这个「旅行计划」，以提高我们的旅行效率和成功率。具体一些，包含以下六个作用：

1. 明确目标：立项过程有助于明确项目的目标和期望结果，使所有参与者对项目的方向和目标有共同的理解。如我们在开发一个新的移动应用的立项过程中，项目组会明确这个应用需要解决的用户问题，预期的用户量，以及市场的目标定位等。

2. 资源分配：立项过程可以帮助组织确定项目的所需资源，包括人力、物力、时间和资金，并有效地进行分配。如我们在进行一次大型的在线活动的立项过程中，会确定需要多少开发人员来构建和维护活动页面，需要的市场推广预算是多少，以及活动的时间表等。

3. 风险管理：立项过程中的风险评估和管理，可以帮助识别和处理可能影响项目实施的风险，并提前制定应对策略。如在立项过程中，可能会识别到政策、数据隐私等风险，并提前规划相应的风险应对措施。

4. 确保项目的可行性：通过立项过程中的可行性研究，可以确保项目在技术、收益、时间等方面的可行性，避免投入大量资源后发现项目无法实现。如最近比较火的 AIGC，在立项时会进行技术可行性分析，以确保所需的算法能力和数据在现有条件下可行。

5. 提升效率和效果：有了明确的立项过程，可以提高项目管理的效率，减少不必要的错误和返工，提高项目的成功率。

6. 增强沟通和协作：立项过程有一个关键动作是对齐，当目标对齐后，每个人都清楚自己的角色和任务，也明白项目的整体方向，这有助于增强项目各方的沟通和协作。

3 立项流程

立项流程可以分为三个阶段，准备阶段，决策阶段、对齐阶段。

3.1 准备阶段

准备阶段是立项中花费时间最长的阶段，是立项的主体工作。

在这个阶段，项目团队需要深入理解项目的需求，研究市场环境，评估项目的可行性，以及预测可能的风险。所有这些工作都需要大量的时间和精力。

这些工作最后落地的交付物是项目提案，可能是一份文档，也可能是一堆文档，项目提案中包括项目的目标、预期结果、工作计划、预算、资源需求等。

项目提案将为项目的后续执行提供清晰的指导，也将为项目的评估决策阶段提供关键的信息。准备阶段是整个立项过程中最为关键的阶段，也是决定项目能否成功的重要因素。

项目提案主要是用来回答下面的问题：

• 为什么要做？可不可以不做？可不可以少做？可不可以晚点做？
• 要做什么？
• 有没有能力/资源做？
• 什么样叫做好了？成功的标准是什么？
• 怎么做？有哪几步？里程碑是怎样的？
• 有什么风险？

一个提案可能是一个正式的文件、一份演示文稿 PPT、甚至是一封简单的电子邮件。但是提案结构一般都会包括以下几个主要部分：

1. 概述：包括项目的名称、目标、主要利益相关者以及总体的项目描述。

2. 背景：解释为什么提出这个项目，包括市场需求、商业机遇或问题解决等。主要明确现状、剖析问题并给出建议解决方向。

3. 项目目标和范围：详细描述项目要达到的具体目标和定义项目的范围，包括项目要做的事情以及不包括的事情。落地过程一般是提炼需求、总结项目方向、项目可实现价值等。

4. 调研及可行性分析：针对上面的问题，需求，结合组织内外的因素，评估项目的技术可行性、经济可行性、法律可行性和运营可行性等。

5. 成功的标准：定义项目的成功标准。这可能包括在指定的时间和预算内完成项目，以及用户对新功能的满意度等。

6. 项目计划：包括项目的主要阶段、关键里程碑、预期成果和详细的时间表。细节呈现可以有一个时间轴之类的图。

7. 项目团队和资源：描述项目团队的结构和成员，以及项目所需的其他资源，如资金、设备和技术。

8. 风险评估：识别和评估可能影响项目成功的风险，以及应对这些风险的策略。风险可能来自许多不同的来源，包括政策要求、法律法规、技术、预算、进度、人力等。

每个项目提案的内容可能会有所不同，具体取决于项目的性质和复杂性，以及组织的要求和偏好等。

3.2 决策阶段

在项目决策阶段，项目提案会被提交给负责决策的人或团队进行审查。根据组织结构或者提案的重要程度，这可能是公司的高层领导团队，部门领导团队或者是专门的审查团队。以下是在决策阶段可能涉及的内容：

1. 项目提案审查：决策者会仔细阅读项目提案，理解项目的目标、计划、预期的收益和风险等。他们可能会寻求专家的意见，或者进行附加的研究以验证提案中的信息。

2. 问题和澄清：决策者可能会对提案中的某些部分有疑问，或者需要更多的信息。这可能会通过与项目团队的会议、电子邮件或其他形式的通信来解决。

3. 项目比较和优先级设置：如果有多个项目提案，决策者可能需要比较他们的优点和缺点，以决定哪个项目应该优先进行。这可能会涉及到对项目的潜在收益、风险、对公司策略的贡献等方面的评估。

4. 决策：最后，决策者会根据提案和他们的评估做出决定。他们可能会批准项目，拒绝项目，或者请求更多的信息或修改。

5. 反馈和沟通：无论决定如何，都应该把它及时和清晰地传达给项目团队和其他相关的利益相关者。如果项目被批准，那么就需要开始实施项目计划。如果项目被拒绝，应该提供反馈，以便项目团队可以了解原因并在将来改进他们的提案。

根据项目的重要程度，适用范围，决策通常涉及以下几个层次：

1. 战略级决策：这是最高级别的决策，也可以称之为公司级决策，通常由公司的最高管理层进行。他们会评估项目提案是否符合公司的整体战略，是否有助于公司的长期发展，以及是否值得投资。可能会考虑一系列的因素，如市场趋势、竞争环境、公司的资源和能力等。

2. 部门级决策：这些决策通常由部门的领导们进行。他们会评估项目提案是否符合部门的目标和计划，是否有助于部门的发展，以及是否符合部门的资源和能力。他们可能会考虑一系列的因素，如部门的策略、人力资源、预算等。

3. 项目级决策：这些决策通常由项目经理或项目团队进行，属于常规决策。我们会评估项目提案的具体细节，如项目的目标、任务、计划、预算、风险等。也可能会需要修改提案的一些细节，以确保项目的可行性和成功率。

这些决策级别并不是严格的分割，而是相互影响和交织。如一个项目提案可能需要在战略级和部门级之间进行多次的审查和修改，以确保它既符合公司的战略，又符合部门的需求。同时，项目级的决策也会影响到项目提案的内容和形式，从而影响到上级的决策。

3.3 对齐阶段

对齐阶段是在项目提案被初步接受后，各相关部门或团队就项目的具体执行细节进行协调和确定的阶段，是一个信息同步对齐，节奏同步对齐阶段。

在项目立项过程中的对齐阶段，形式、内容、范围和后续机制的具体设定通常会因项目的特性和组织的需求而变化，以下是一些常见的实践：

形式：

• 会议：这可能是最常见的对齐形式，包括面对面的会议和在线会议。会议可以让所有相关的人员在同一时间讨论项目的各个方面，及时解决问题和疑问。

• 邮件和文档：对于一些需要详细记录或者不需要立即回复的问题，邮件和文档可能是更好的选择。它们可以让人们有更多的时间来思考和回复，也可以方便地保存和查阅。

• 即时消息（IM）群聊：使用企业微信，钉钉等工具创建的项目群组。这样的群组可以让团队成员进行实时的沟通，快速解决问题，同时也可以记录下来所有的对话，方便后期查阅。

• 公司通知/公告：这是非常正式的方式，如果项目的内容需要通知到整个公司，或者特定的部门或角色，可以通过公司内部的通知系统来发布相关信息。这可以是公司的内部网站、邮件列表、公告板等。

• 项目管理软件：如 Jira，Tapd 等可以用于管理项目的工具，可以让团队成员查看项目的进度，分配任务，跟踪问题等。

范围：

• 内部范围：涵盖公司内部所有相关的部门和团队，包括项目团队、销售团队、营销团队、财务部门等。
• 外部范围：如果项目涉及到外部的合作伙伴或供应商，他们也可能需要参与到这个过程中。

内容：

• 项目目标和战略对齐：确认项目的目标和战略与公司的整体战略是否一致，是否有助于实现公司的长期目标。
• 资源分配：讨论和决定项目需要的各种资源，包括人力、资金、设备等，以及这些资源如何分配和使用。
• 风险评估：识别和评估项目可能面临的各种风险，以及如何预防和应对这些风险。

后续机制：

• 定期的跟进会议：为了确保项目的执行按照计划进行，可以设置定期的跟进会议，如每周或每月一次，让所有人都能及时了解项目的进展和可能的问题。
• 评估和反馈机制：在项目执行过程中，需要一个系统的评估和反馈机制，以便及时发现和解决问题，调整计划和策略。这可以通过定期的项目审查、员工反馈、客户反馈等方式实现。

在对齐阶段，关键的一点是保持良好的沟通和协调，确保所有相关的人都明白项目的目标和计划，以及他们在其中的角色和责任。

4 立项常见问题

从上面立项流程的三个阶段来看，每个阶段都有可能会出现一些问题：

4.1 准备阶段常见问题

在这个阶段，应集中精力明确项目的目标、需求、预期结果和实施方式。其常见问题如下：

• 需求定义不明确：在项目提案阶段，对项目的需求和目标应该有明确的定义。如果在这个阶段需求和目标定义模糊，可能会导致提案内容与实际需求不匹配，或在后续阶段引发混乱和效率低下。清晰、准确的需求定义是项目成功的关键。

• 提案不完善：在项目提案阶段，提案应该充分考虑项目的所有关键方面，包括预期的时间表、预算、人力资源需求，风险等。如果提案中缺乏这些关键信息，可能会在项目评估决策阶段造成项目被拒绝。一个全面、详尽的提案可以帮助评估者更准确地理解项目的需求和潜在价值。

• 项目产投不合理：指的是项目预期的产出（如产品、服务或其他结果）与投入（如时间、资金、人力等资源）之间的比例不合理。如果投入过大而产出有限，那么项目可能不会为组织带来足够的收益，这可能会导致项目在评估决策阶段被拒绝。

• 项目资源投入不聚焦：指的是项目的资源被分散投入到许多不同的任务或活动中，而不是集中在关键的任务或活动上。这可能会导致项目的效率低下，或者关键任务因资源不足而延期。

• 提案权错配：提案是整个项目立项的主体内容，它的权力错配严重时会导致整个项目的失败。提案权错配可以分为两种：跨部门的错配和层级的错配。跨部门错配一般发生在提案的制定和执行由不同的部门负责，如 A 部门负责制定提案，但 B 部门负责实施提案。这种错位可能导致沟通困难和理解差异，因为制定提案的部门可能对执行提案的部门的能力和限制了解不足，反之亦然。为了避免这种错位，可能需要更紧密的跨部门合作，或者建立一个跨部门的团队来共同提出和实施提案，或者执行类似于「谁主张主举证」的原则，谁提案谁执行，谁干活谁提案。层级错配一般发生在高层领导制定提案，而实际工作团队负责实施时。这可能导致提案与实际工作的脱节，因为高层领导可能对实际工作的具体细节和挑战了解不足。为了避免这种错位，可能需要更多的底层参与及权力下放。

4.2 评估决策阶段常见问题

在这个阶段，主要任务是评估项目提案是否可行、价值、收益、风险以及对资源的需求。可能出现的问题包括：

• 评估标准不明确：在项目评估决策阶段，评估标准应该尽可能地清晰和公正。如果评估标准不明确或者不公正，可能会导致优秀的项目提案被忽视，或者不合适的项目被接受。此外，如果项目的评估标准不公正，可能会引发团队冲突，影响项目的整体执行和效果。

• 决策过程不透明：在项目评估决策阶段，决策过程应该尽可能地透明。如果决策过程不透明，可能会导致团队成员或其他利益相关者对决策的公正性和合理性产生疑虑。这种疑虑可能会导致与项目相关的人员的信心下降，影响他们的工作效率和项目的最终结果。

• 项目可行性评估不准确：在项目评估决策阶段，项目的可行性是一个重要的考虑因素。如果对项目的可行性评估不准确，可能会导致项目在实施阶段出现大量的问题，或者项目无法实现预期的收益。

• 收益预期过高或者过低：在项目评估决策阶段，对项目的收益预期应该尽可能地准确。如果预期过高，可能会导致项目在完成后无法实现预期的收益；如果预期过低，可能会导致项目在评估决策阶段就被错误地拒绝。

• 风险评估不足：在项目评估决策阶段，应该对项目可能出现的风险进行充分的评估。如果对风险的评估不足，可能会导致在项目实施阶段出现意外的问题，从而影响项目的成功。

4.3 对齐阶段常见问题

在这个阶段，主要任务是确保所有的利益相关者都对项目的目标、进度、责任和期望有相同的理解。其常见问题包括：

• 沟通不足或者误解：在项目对齐阶段，所有的利益相关者都应该对项目的目标、进度、责任和期望有清晰的理解。如果在这个阶段没有进行充分的沟通，或者存在误解，可能会导致在项目执行阶段出现混乱和冲突。

• 角色和责任不明确：在项目对齐阶段，应该明确每个团队成员和利益相关者的角色和责任。如果角色和责任不明确，可能会导致一些工作被遗漏，或者一些任务没有被正确地完成。

• 期望管理不当：在项目对齐阶段，应该对项目的预期结果进行明确的设定和沟通。如果项目的预期结果没有被正确地理解或接受，可能会导致项目在执行阶段出现问题，因为实际的结果可能无法满足一些利益相关者的期望。

5 小结

前面我们全面地探讨了项目立项的重要性、含义、作用、流程，以及可能出现的问题。立项不单是一个项目开始的决策过程，而是一个综合性的决策过程，涉及目标设定、资源分配、风险管理等多个环节。立项的本质是项目各方对目标、方案、成本、风险和里程碑等重要预期进行对齐，以便决定是否启动项目并如何分配资源。

立项可以帮助明确目标，合理分配资源，提前识别和管理风险，确认项目的可行性，提升效率和效果，增强沟通和协作。立项过程包括三个阶段：准备阶段、决策阶段、对齐阶段。每个阶段都有其关键工作，并可能出现一些常见问题，如需求定义不明确、评估标准不明确、沟通不足或误解等。

总的来说，立项是确保项目成功的重要环节，需要得到足够的重视和正确的处理。

这些指标量化着我们的工作和目标，让我们朝着目标前进，如果指标有问题，也会导致走偏，或者为了指标而玩数字游戏。

当迷惑于指标，或者指标有问题的时候，需要停下来思考一下：

• 指标是什么，可以分为几类？
• 指标有什么价值？
• 指标是如何生成的？制定指标的过程中有什么讲究？
• 如何评判一个指标的好处？
• 跟进指标的过程中有什么注意点？
• 对指标进行复盘时要看哪些点？

指标是什么

指标的本质是一种衡量工具，它提供了一个客观的、定量的方法来评价某个特定的目标或过程的性能或结果。换句话说，指标是把抽象的目标或过程转化为可以衡量和跟踪的具体数值，是一个由虚转实的工具。

指标的设计和选择必须反映出我们所关注的核心问题和目标。比如，如果我们的目标是提高产品质量，那么我们需要的指标可能包括产品缺陷率，客户满意度等。

同时，指标也是一种沟通工具。它们可以帮助团队成员理解目标，以及衡量他们的工作是否有助于实现这些目标。当所有人都清楚地知道他们的工作如何对公司的总体目标产生影响时，他们可能会更积极地参与和投入。

总的来说，指标的本质是将目标和过程量化，以便于衡量和沟通，从而推动团队或组织向预定的目标前进。

从价值的角度来看，指标在企业管理和决策中发挥着重要的作用：

1. 提供信息和见解：指标能够提供实时的、可量化的信息，帮助企业了解其运营状况和业绩表现。

2. 支持决策制定：通过分析指标，企业可以更好地理解其优势和短板，从而制定更有效的策略和决策。

3. 跟踪进度和绩效：企业可以使用指标来监控项目进度、员工绩效等，以确保目标的实现。

4. 促进连续改进：指标可以揭示存在的问题和改进的空间，从而推动企业持续改进。

5. 提高透明度和问责制：清晰、明确的指标可以提高企业的透明度，并有助于问责制的实施。

从分类的角度来看，指标可以根据不同的分类方法进行分类：

1. 输入、过程、输出和结果指标：

   • 输入指标：衡量投入的资源，如资金、人力和时间。
   • 过程指标：衡量活动或操作的效率和效果，如生产速度、错误率等。
   • 输出指标：衡量产出的数量或质量，如生产量、销售额等。
   • 结果指标：衡量最终的结果或影响，如客户满意度、市场份额等。

2. 财务和非财务指标：

   • 财务指标：关于财务表现的指标，如利润、收入、现金流等。
   • 非财务指标：关于非财务表现的指标，如客户满意度、员工满意度、环境影响等。

3. 主观和客观指标：

   • 主观指标：基于个人观点和感觉的指标，如员工满意度、客户满意度等。
   • 客观指标：基于可观察和可度量的事实的指标，如销售额、生产量等。

4. 滞后和领先指标：

   • 滞后指标：反映过去表现的指标，如上个季度的销售额、去年的利润等。这些指标通常用来评价过去的表现。
   • 领先指标：预示未来表现的指标，如新订单量、客户满意度等。这些指标可以帮助预测和改善未来的表现。

分类方法可以根据需要混合使用，以创建最适合特定情境的指标，比如一个指标可能是客观指标，同时也可能是财务指标和结果指标。

制定指标

制定有效的指标是一个结构化的过程，涉及对组织的目标、战略和关键活动的深入理解。

对研发团队来说，不同团队在不同时期制定的指标可能会有所不同，这主要取决于团队的特定目标、战略方向、业务需求、以及所处的市场和行业环境的变化。换句话说，指标的制定需要根据团队当前的业务重点和未来的发展目标，同时考虑到外部环境的影响，以确保指标的相关性、实效性和灵活性。

一般来说，研发团队的指标制定大概可以包括以下的逻辑：

1. 明确目标：目标是什么，这是制定任何指标的首要步骤。研发团队的目标可以包括开发新产品，提高现有产品的性能，提高生产效率，减少产品缺陷等。

2. 确定关键活动：关键活动应与团队的目标紧密相关。例如，如果目标是开发新产品，关键活动可能包括市场调研，产品设计，原型开发，测试，生产等。

3. 确定度量标准：对于每个关键业务活动，确定可以衡量其性能的度量标准。例如，项目管理的度量标准可能包括项目的按时完成率和预算执行率；产品设计的度量标准可能包括设计的创新程度和用户满意度；编码的度量标准可能包括代码的质量和效率；测试的度量标准可能包括测试的覆盖率和缺陷发现率；质量控制的度量标准可能包括产品的缺陷率和客户满意度。

4. 制定具体指标：基于度量标准，制定具体的指标。每个指标都应有明确的目标值和时间框架。例如，项目按时完成率的目标值可能是90%，时间框架可能是每个季度；代码质量的目标值可能是每1000行代码中缺陷数少于5个，时间框架可能是每个项目。

5. 收集和分析数据：这是衡量和跟踪指标的关键步骤。数据可以来自内部（如项目管理系统，质量管理系统等）或外部（如市场研究，客户反馈等）。

6. 定期审查和调整指标：随着业务目标和环境的变化，可能需要调整或更新指标。这要求团队周期性地评估指标的有效性，并根据需要进行调整。

在制定研发团队的指标时，需要考虑到团队的特性，如团队的规模，成员的技能，资源的可用性等。此外，也需要考虑到业务的特性，如市场环境，竞争态势，客户需求等等。

评判指标好坏

当我们制定了指标后，如何评判一个指标的好坏，什么样的指标是好的指标，什么样的指标是不好的指标？

评价指标的好坏，通常要参考以下几个关键标准：

1. 相关性：好的指标应与团队或组织的目标和策略密切相关。如果一个指标与组织的目标没有直接的关系，那么它可能就不是一个好的指标。比如落地 XXX 个方案和在 XXX 个客户中落地 XXX 个方案是两个完全不同的相关性的指标。

2. 可度量性：好的指标应该是可以量化的，这样才能进行准确的跟踪和测量。如果一个指标无法量化，那么很难判断是否达到了目标。

3. 可行性：好的指标应该是可以实际操作和实施的。如果收集一个指标的数据需要花费大量的时间和资源，那么这个指标就可能不是一个好的指标。

4. 敏感性：好的指标应该能够反映出关键业务活动的变化。如果一个指标对业务活动的变化反应迟钝，那么它可能就不是一个好的指标。

5. 有预测价值：好的指标应该能提供有关未来性能的信息。如果一个指标只能提供历史数据，而不能用来预测未来，那么它就可能不是一个好的指标。

6. 易于理解和解释：好的指标应该是明确的，易于理解和解释的，这样所有的团队成员都可以理解这个指标的含义和重要性。

评价指标的好坏需要考虑多个因素，包括指标的相关性、可度量性、可行性、敏感性、预测价值、以及是否易于理解和解释。在制定和选择指标时，需要根据具体的业务需求和环境，权衡这些因素，选择最合适的指标。

当我们看到一个指标时，感觉像是看一个模糊的地图，它与我们真正要达到的目的地关系不大，无法具体量化我们的进步，难以实施和操作，对我们的行动反应慢，不能预测我们未来可能遇到的情况，而且还难以理解和解释。这样的指标无法帮助我们清晰地了解自己的表现，也无法有效地指导我们改进工作，甚至可能让我们误入歧途，此时就需要更新指标。

说到指标这种量化场景，就不得不提一下 SMART 原则，在这种带量化性质的场景，SMART 原则是一个非常好用的原则。

在指标制定的过程中也有一些坑，大概梳理了一下，看看你有没有遇到过：

1. 指标不够具体：如果指标模糊不清，团队成员可能会对应该集中精力在哪里感到困惑，这会导致效率低下并可能阻碍目标的实现。

2. 过度依赖「虚荣指标」：虚荣指标是指那些看起来很好，但实际上对业务的核心目标贡献不大的指标。例如，网站的页面浏览量可能是一个虚荣指标，如果它不能转化为实际的用户参与或销售。

3. 指标过多：过多的指标可能会导致注意力分散，使人们难以确定应该关注哪些最重要的事情。而且，过多的指标也可能导致数据收集和分析的工作变得过于复杂和繁重。

4. 指标设置过于理想化：如果指标过于理想化，可能会导致团队成员感到挫败，并可能抑制他们的积极性。要确保指标既有挑战性，又具有可达成性。

5. 未能定期审查和更新指标：随着业务环境的变化和组织目标的演化，原先设定的指标可能不再适用。因此，必须定期审查并更新指标，以确保它们持续对组织有价值。

6. 未考虑指标可能带来的副作用：有时，指标可能会导致意想不到的负面结果，因为人们可能会过于专注于达成指标，而忽视了其他重要的事情。例如，过度关注销售指标可能会导致客户服务的质量下降。

要解决这些问题，关键是对你的业务目标有深入的理解，明智地选择和使用指标，并定期审查和调整你的指标体系。

跟进指标

跟进指标是一个持续的过程，需要定期检查和评估以确保指标的达成，从而达成目标。以下为我们常用的一些跟进指标的方法：

1. 定期检查：可以是每周、每月或每季度的检查，具体取决于我们的目标和业务需求。在这些检查中，可以查看每个指标的最新数据，了解是否在达成目标的道路上取得了进展，以及和目标的差，风险、信心值等。

2. 可视化：使用类似于数字仪表板的组件，自动收集和显示关键指标的数据，使能够一目了然地看到所有重要指标的最新状态。复杂一些，可以搞一个专门的数据可视化工具；简单一点，一个简单的电子表格也行。

3. 定期报告：定期报告和定期检查不同，定期检查是自己的行动，定期报告是在定期检查的基础上，形成自己的总结，并周知给相关方，其作用更多是沟通逻辑。定期向团队和其他相关人员（如管理层）汇报关键指标的进展。这可以帮助保持透明度，也可以让所有人都对目标的进展保持了解。

4. 分析和解释数据：仅仅收集数据是不够的，还需要对数据进行分析并解释其含义。例如，如果一个指标的表现比预期差，需要找出可能的原因，并提出改进的策略。

5. 调整和优化：如果某个指标的表现持续低于预期，或者发现了一个更好的衡量方法，我们可能就需要调整或优化指标。记住，指标应该是灵活的，并能随着业务需求和目标的改变而变化。

通过这些方法，我们可以确保我们的指标始终保持相关和有效，同时也可以确保我们的团队在达成目标的道路上始终保持正确的方向。

在跟进的过程中，有一些常见的问题也是需要注意一下的：

1. 过度关注指标，忽视目标：有时，团队可能过于关注达到指标，而忘记了这些指标背后的真正目标。例如，一个团队可能过于关注提高销售额的指标，而忽视了客户满意度或产品质量。

2. 数据收集和分析的问题：如果没有足够的资源或正确的工具进行数据收集和分析，可能会导致指标结果不准确或被误解。

3. 指标操纵：当人们的绩效考核与指标紧密相关时，可能会出现操纵指标数据以达到个人目的的情况。例如，销售员可能会推迟一些销售，以便在下一个评估周期中看起来表现更好。

4. 指标失衡：有时，过于重视某一指标可能导致其他重要指标被忽视，从而造成业务的失衡。例如，过度关注成本削减可能会牺牲产品质量。

5. 指标过时：随着业务环境的变化，一些原本有效的指标可能变得不再相关或有效。固执地坚持使用这些过时的指标可能会导致做出错误的决策。

6. 对指标的误解：如果团队对指标的理解不准确，可能会导致他们采取错误的行动。因此，确保团队对指标的正确理解非常重要。

复盘指标

当到一个里程碑，或者到一个 OKR 周期结束，需要阶段性的停下来做一下复盘总结。

而在复盘总结的过程中，指标的复盘是相当重要的一环。通过复盘指标这一种反思过程，能够帮助你理解哪些指标有效，哪些需要改进或淘汰。我们可以从如下的几个方面来复盘指标，这和上面评判指标的好坏也是相关的：

1. 评估指标的有效性：看看每个指标是否帮助我们接近目标。如果一个指标的改进并没有带来预期的效果，那么这个指标可能需要重新考虑。

2. 检查指标的相关性：评估每个指标是否与我们的主要目标和战略保持相关。如果一个指标不再相关，那么可能需要将其替换为一个更相关的指标。

3. 考虑指标的易度量性：如果一个指标难以度量或数据难以收集，那么可能需要寻找一个替代的、更易于度量的指标。

4. 反思指标的预测价值：看看每个指标是否能有效预测未来的表现。如果一个指标的表现与未来的结果没有强烈的关联，那么可能需要将其替换为一个有更强预测性的指标。

5. 获取反馈：向团队成员和其他利益相关者获取反馈，了解他们对当前指标的看法。他们可能会提供有价值的观点和建议，帮助改进指标。

通过定期复盘指标，我们可以确保指标始终与目标和战略保持一致，从而更有效地驱动团队向目标前进。

小结

指标的本质是一个衡量工具，一个由虚转实的工具，它提供了一个量化的方式来评估和追踪一个组织、团队或个人在达成特定目标或目标集合上的表现和进度。它们将目标和表现转化为可以度量和比较的数据，从而支持决策、驱动行为，并帮助了解是否按照预期的方向发展。

然而，尽管指标是一种强大的工具，但它们只是工具，不能替代全面的判断和考虑。选择和使用指标时，应始终考虑其背后的目标和上下文，并注意避免只关注指标而忽视实际效果的陷阱。

如果一个问题是交到我们这里来解决，尽量成为问题解决者。

成为问题解决者

成为问题的解决者意味着什么？

对于技术管理者来说，意味着我们要负责任地处理问题，去解决问题，而不是转发，一定是要对问题本身有认知，有判断后再去处理，再去解决，而不是简单地将问题转发给其他人。这就要求我们深入全面的了解问题的背景和现状，分析问题的根源和可能的解决方案；这就要求我们具备批判性思维、解决问题的能力，以及对我们负责的业务领域和技术领域有深入的理解。

也意味着技术管理者要对他的决策和行动负责。我们不仅要解决当前的问题，还要预防未来可能出现的问题，有前瞻性的思维，能够预见可能出现的问题，并提前做好准备。

对于一线开发同学来说，意味着我们要负责任地处理问题，去解决问题，而不是转发，不是简单地把问题推给其他人，需要负责任并主动的去寻找解决方案。这需要我们深化对问题的理解，探索可能的解决方案，然后付诸行动。这不仅要求我们具备强大的技术能力，也要求我们有独立思考和解决问题的能力。

在面对问题时，我们不应该急于求成，而应该耐心分析，找出问题的根源。这可能需要我们查阅相关文档和资料，或者利用调试工具进行深入地分析。我们必须理解问题的本质，以便找出最有效的解决方案，可能最终只是改一个配置或一行代码。

同时，我们需要主动地与团队其他成员，甚至是来自其他团队的同事沟通交流，分享我们的发现和思考，听取他们的意见和建议。这将帮助我们从不同的角度看待问题，可能会发现一些我们之前未曾注意到的解决方案。也可以问问 AI ，它懂得比我们多。

此外，我们还需要积极地跟踪问题的解决进度，确保我们的解决方案能够有效地实施，并能够在实际环境中正常工作。如果我们的解决方案存在问题，我们需要有勇气承认错误，重新回到问题的起点，找出新的解决方案。

如何成为一个好的问题解决者，问题的解决有没有方法论或套路？

从问题的分类来看，问题可以分为以下三类。：

• 应急响应类：这类问题通常需要立即解决，以防止问题进一步恶化。解决这类问题通常需要快速反应和短期改进措施。例如，系统突然宕机，需要立即修复。

• 深度分析类：这类问题通常涉及到系统性的、复杂的、长期存在的问题，需要深入分析问题的根源并找出解决方案。例如，产品的用户留存率持续下降，需要通过数据分析、用户访谈等方式深入理解原因，并制定相应的解决策略。

• 追求卓越类：这类问题更多地关注如何优化和改进现有的流程和系统，预防问题的发生，并提升整体的效率和效果。例如，团队的开发流程效率低下，需要通过对工作流程的持续改进和优化，提高团队的工作效率。

从问题解决的过程来看，成为问题解决者，无论是面对应急响应类问题、深度分析类问题还是追求卓越类问题，都可以遵循以下的方法论：

1. 理解问题：全面、深入地理解问题的背景、现状和影响，探究问题出现的原因以及它对工作、团队或公司的影响。
2. 分析问题：进行深入的分析，找出问题的根本原因。可能需要查阅相关文档、与相关人员进行交谈或使用数据分析工具。
3. 设定解决目标：明确问题解决的目标或期望结果，设定一个明确且可衡量的目标，以便知道何时问题已经被解决。
4. 寻找解决方案：根据问题的原因，寻找可能的解决方案。可能包括改变现有的过程、引入新的工具或技术、提供培训和教育等。
5. 实施解决方案：找到解决方案后，付诸行动，实施解决方案。可能需要与其他人协作，或者独立完成。
6. 评估结果：实施解决方案后，评估结果，看看是否达到了预期目标。若未达到预期，可能需要重新考虑解决方案，或者寻找新的解决方案。
7. 反馈和改进：问题解决是一个持续的过程，需要不断地反馈和改进。从失败和成功中学习，以便在将来更好地解决问题。

当然，从另一个方面来说，成为问题的解决者并不是成为所有的问题的解决者，成为问题的解决者也并不意味着我们要独自一人去解决所有的问题。在需要的时候，我们应该寻求他人的帮助，与他人合作，共同解决问题。我们要记住，我们不是工作中的孤岛，我们是一个团队，我们需要彼此的帮助和支持，才能更好地解决问题。

做一个好传声筒

对于一个技术管理者来说，特别是团队大一些的技术管理者来说，根本做不到事事亲自来做或跟进，此时就需要在对事情有一个基本的判断后，将事情指派给某一个同学来处理，做一个好传声筒。

对于一个一线开发同学来说，当一个事情虽然到你这边了，而你没有精力去解决的时候，可以寻求他人或上级的帮助，当有其它人介入后，将当前问题说清楚，交接清楚，做一个好传声筒。

那什么是好传声筒？

好传声筒是「把饭喂到嘴里」。当你需要拉一个人来解决问题，或者要把相关信息传递给他，需要把事情的前因后果都讲清楚，把要传达的内容传达到位，而非仅仅是将问题原封不动的转发给他。这就意味着你需要用尽可能清晰和明确的方式，阐述问题的背景，问题的现状，以及预期的解决结果。你需要告诉他如何才能有效地解决这个问题，以及为什么我们需要他来解决这个问题。

一个好传声筒更是需要具备一定的判断力和思考能力，能够在传递信息的过程中进行筛选和整合，把对方需要的信息准确、完整地传达出去，同时避免不必要的信息干扰。这就需要我们有良好的理解力和表达力，能精准地把握信息的关键点，清晰地表述出来。

此外，作为一个好传声筒，我们还要学会尊重和理解接收信息的人。我们需要理解他们的需求，他们的困惑，以及他们的期望。我们需要用他们能理解和接受的方式，来传递我们的信息。这就需要我们有良好的沟通技巧，有同理心，有耐心。

同时，我们也要注意保护信息的安全和隐私，避免不必要的信息泄露，这是我们作为传声筒的基本职责和底线。

一个好传声筒不仅仅是传递信息的工具，更是沟通和解决问题的桥梁。作为一个好传声筒，我们需要有良好的理解力和表达力，有独立思考和判断的能力，有良好的沟通技巧和同理心，以及对信息安全和隐私的尊重。

特别要注意的一点，在 IM 沟通的时候不要把聊天记录直接转发，这里可能会带来一些问题，如：

1. 隐私问题：聊天记录可能包含敏感信息或个人信息。在没有得到原始对话者的同意的情况下转发这些信息，可能会侵犯他们的隐私权。

2. 信息过载：聊天记录可能包含大量的信息，其中只有一部分是相关的或有用的。直接转发整个聊天记录可能导致接收者感到信息过载，难以找到重要的信息。

3. 上下文丢失：聊天记录中的信息可能需要上下文才能理解。如果接收者没有这个上下文，他们可能会误解信息的含义。这点特别重要，也特别常见。

在传递信息的过程中我们可以有一些结构的表述来帮助确保信息清晰、准确且易于理解。以下是一些可能的方法：

1. 使用列表和子列表：较常用的一种方式，这可以帮助组织信息，使其更加清晰。例如，你可以列出问题的主要部分，然后为每一个部分提供详细的子列表。

2. 使用图表和图像：视觉元素可以帮助接收者更好地理解和记住信息。例如，可以使用流程图来解释问题解决的步骤，或者使用图表来展示数据。虽然这有点费劲，但是效果会好很多，不常用，主要应用于相对重要的场合。

3. 使用模板和框架：例如，你可以使用 STAR 框架（Situation、Task、Action、Result）来描述问题和解决方案。首先，描述 Situation（情境），即问题出现的上下文或背景。然后，描述 Task（任务），即你或接收者需要完成的任务。接着，描述 Action（行动），即你或接收者需要采取的行动。最后，描述 Result（结果），即预期的结果或解决方案。

4. 使用明确的语言：避免使用术语或行话，除非你确定接收者理解它们。使用简单、明确的语言可以帮助确保信息的准确性。

5. 提供足够的背景信息：如果使用了 STAR 原则，这个基本都会讲清楚，如果没有，也需要在描述问题或解决方案时，提供足够的背景信息可以帮助接收者理解其重要性和紧迫性。

6. 重复关键信息：重要的事情说三遍。人们通常需要听到或看到信息几次才能记住它。通过重复关键信息，你可以帮助接收者记住和理解它。

要成为一个好传声筒，不仅要能够准确、清晰地传递信息，还要能够使用合适的方法来组织和呈现信息，使其易于理解和记住。

如果我们做到了成为问题解决者和好传声筒，那会带来什么？

从团队协作的角度来看：

1. 提升团队效率：团队成员能够独立解决问题和有效地传递信息，这大大提高了团队的工作效率和生产力。
2. 增强团队凝聚力：通过共同解决问题，团队成员之间的关系会得到加强，增强了团队的凝聚力。
3. 建立信任和尊重：当团队成员能够负责任地解决问题和准确地传递信息时，这能够在团队内部建立信任和尊重。
4. 提高团队的问题解决能力：团队成员遇到困难时，他们会学会如何解决问题，这提高了整个团队的问题解决能力。
5. 保护团队的信息安全：作为一个好传声筒，团队成员会更注重保护信息的安全和隐私，从而减少团队面临的风险。

从个人发展的角度来看：

1. 提升个人能力：通过解决问题和有效地传递信息，个人的专业能力、沟通技巧和批判性思维能力都得到了提升。
2. 培养责任心和勇气：负责解决问题和传递信息的过程，会培养个人的责任感和勇气。
3. 提高问题解决能力：在不断地解决问题中，个人的问题解决能力将得到锻炼和提高。
4. 增强信息保护意识：作为一个好传声筒，个人在处理信息时会更加注重信息的安全和隐私，增强了信息保护意识。

总的来说，成为问题解决者和好传声筒，不仅可以提高团队的效率和凝聚力，提升团队的问题解决能力，还可以帮助个人提升专业能力，培养责任感和勇气，提高问题解决能力，增强信息保护意识。

小结

在前面我们探讨了在工作中如何成为问题的解决者和优秀的传声筒。对于问题解决者，所需的素质包括对问题的深入理解、批判性思维、对业务和技术领域的深入理解，以及对自身决策和行动的责任意识。对于传声筒，关键在于准确、清晰地传递问题的背景、现状和预期解决结果，同时需要有判断力和思考能力、尊重和理解接收信息的人、以及对信息安全和隐私的保护。

在日常工作中，我们既可能是问题的解决者，也可能是问题的传声筒。但无论我们处于哪种角色，都需要不断提升自身的能力和素质。在实践中，我们应该寻找一个平衡点，既要有解决问题的决心和主动性，也要有智慧知道何时寻求他人的帮助。只有这样，我们才能真正成为一个高效的技术团队，每个成员都是问题的终结者，同时也是团队协作的重要组成部分。