1 为什么会有异地团队

当一个企业成长到一定程度后，往往会在多地建立研发中心或者业务中心，这里企业的考量可能会有如下的一些点：

1. 人才资源：不同的城市和地区可能具有独特的人才资源，通过在多个城市建立研发中心，公司可以吸引和招聘到更多具有不同技能和背景的优秀人才。这有助于公司在保持竞争力，并确保能够获取到足够的人才来支持研发和业务需求。
   比如深圳是中国的高新技术产业中心，其在硬件制造、消费电子、通信技术等方面具有很强的竞争力，对硬件制造、物联网、人工智能等领域拥有丰富经验的工程师较多，并且由于深圳地理位置优越，靠近香港，拥有国际化的人才环境，因此在跨境项目和多元文化沟通方面具备优势；
   又如北京是中国的政治、文化和教育中心，拥有众多顶级高校和研究机构，拥有大量理论研究和技术创新方面的顶尖人才，北京的互联网行业较为成熟，尤其是在互联网+政务、在线教育、大数据等方面有较多经验的人才。

2. 市场覆盖：在多个城市设立研发中心有助于公司更好地了解和适应不同地区的市场需求。这可以让公司更迅速地响应市场变化，提供更符合客户需求的产品和服务。

3. 成本优化：不同地区的劳动力成本、房地产成本和生活成本可能存在差异。在多个城市建立研发中心可以让公司充分利用各地的成本优势，降低整体运营成本。如一些深圳/北京的公司，会把一些研发中心放到西安、成都、武汉、长沙等城市。

4. 政策支持：一些城市为了吸引优秀企业入驻，可能会提供各种政策支持，如税收优惠、低息贷款、用地优惠等。在多个城市建立研发中心可以让公司充分利用这些政策优势，降低研发成本。

除此之外，还有风险分散的考虑，技术合作与创新等等，最终都是帮助公司获得更多的资源和优势，提高整体竞争力。

2 异地团队会有什么问题

以技术团队为例，当有多个技术团队在不同的城市后，与所有技术团队在同一个地方相比，会有一些问题出现，主要分为以下的 4 个方面：

2.1 团队建设和凝聚力打造困难

由于缺乏面对面交流和互动，异地团队成员之间可能难以建立信任和凝聚力。而团队建设和凝聚力是影响团队绩效的重要因素。当技术团队分布在不同城市时，团队建设和凝聚力可能受到以下方面的影响：

1. 面对面交流机会少： 当团队成员分布在不同城市时，他们的面对面交流机会将大大减少。面对面交流有助于加深团队成员之间的了解、建立信任和加强团队凝聚力。例如，共同参加团队活动、庆祝生日等场合，能增强团队成员之间的情感联系。而分布在不同城市的团队成员可能很难享受到这些互动的机会。

2. 困难的团队文化塑造： 一个健康的团队文化对于团队建设和凝聚力至关重要。在异地团队的情况下，公司需要付出更多的努力来塑造统一的团队文化。例如，各地团队可能在工作习惯、价值观、沟通方式等方面存在差异，这些差异可能导致团队凝聚力降低。

3. 时空的隔阂： 异地团队面临地理距离的挑战，以及各地工作安排导致的时间不一致的问题。这种情况下，团队成员可能较难以达到理想的实时沟通，而在中国实时沟通是大部分公司的必备品，大家更习惯于实时的沟通，而不是异步的非实时沟通。

4. 缺乏有效的团队认同感： 异地团队成员可能会感到自己与其他团队成员的联系较弱，这会导致他们缺乏对整个团队的认同感。例如，一个异地团队成员可能对其他城市团队的工作情况和成果了解较少，难以形成归属感和共同的目标。

2.2 项目管理及实时协同难度大

异地团队成员可能难以实时协作，尤其是涉及紧急问题或需要即时反馈的情况。项目管理及协同难度增大主要表现在以下的 3 个方面：

1. 沟通成本上升：当团队成员分布在不同城市时，团队之间的沟通成本会显著增加。团队成员需要通过电话、电子邮件、即时通讯等工具进行沟通，这可能导致信息传递的延迟和误解。例如，一个团队成员在深圳提出一个需求变更，另一个团队成员在上海可能需要数小时甚至一天后才能了解到这一变更，从而影响项目进度。

2. 快速应对变化的能力变弱：异地团队可能在应对突发事件和变更需求时存在局限。假设一个重要客户要求对产品进行紧急修改，跨城市的团队成员可能需要在短时间内协调资源和安排工作，而地理隔离使得这一过程变得更加困难。

3. 时间管理和跨团队协调困难：不同城市的团队可能存在不同的工作时间和节假日安排（比如某个城市因为办公场地原因而全员居家），这可能导致某些任务在协作过程中出现延迟。例如，在一个紧急 bug 修复的情况下，由于一个城市的团队正在度假，另一个城市的团队需要独自解决问题，可能导致修复速度变慢。

2.3 监督和管理困难

在异地团队中，监控和评估团队成员的绩效可能较为困难。管理者需要找到合适的方法和指标，以便对团队成员的工作成果进行公平、准确的评估。监督和管理困难主要包括以下的一些情况：

1. 工作状态难以掌握：由于地理隔离，管理者可能无法直接了解团队成员的工作状态和情况。例如，一个城市的团队可能遇到了技术难题，导致项目进度受阻，但管理者由于无法亲自与团队成员交流，可能难以及时发现问题并采取相应措施。

2. 绩效评估困难：在异地团队中，评估团队成员的工作绩效可能变得更加困难。由于缺乏面对面交流，管理者可能无法准确评估团队成员的工作质量和效率。例如，一个城市的团队成员可能在某个任务上花费了较长时间，但管理者无法确定这是否是由于技术难题还是工作效率低下。

3. 难以建立信任和团队凝聚力：地理隔离可能导致管理者难以建立与团队成员的信任关系，从而影响团队凝聚力。例如，一个城市的团队成员可能对管理者的决策表示质疑，由于无法进行面对面沟通，管理者可能无法充分解释决策背后的原因，从而导致信任度降低。

4. 协调和调动资源困难：异地团队的管理者可能在协调和调动资源方面面临挑战。当项目需求发生变化或出现紧急问题时，管理者需要快速协调各地团队的资源，但地理隔离可能使这一过程变得更加复杂。例如，在一个紧急项目中，管理者需要从多个城市的团队中调集人力资源，但由于异地情况，这可能导致资源调配的速度和效果受限。

整体来说，主要是由于沟通与协作问题导致的各种延展性问题。缺失的面对面沟通、缺少肢体语言、表情语言等，可能导致信息传递不畅、误解和沟通成本的增加。我们无法彻底解决这些问题，但是能通过一些手段来缓解。

3 三大模式

为解决上面这些问题，我们在工作中发现了一些在不同的环境和场景中具有普遍适用性的解决或缓解问题方法，以模式的形式表述出来。

3.1 代理模式（Proxy Pattern）

代理模式在团队管理中可以被用于创建一个协调人或代表角色，负责处理某个团队或多个团队之间的沟通与协作。代理角色在此情景下充当一个中介，处理跨团队的需求、问题解决和资源协调。代理模式有助于简化沟通流程，提高团队协作效率。

具体实施方案：

• 为每个团队或职能领域设立代理角色，如前端代理、后端代理、QA 代理和移动端代理。
• 代理角色负责处理跨团队的需求和问题，同时将反馈和解决方案传递给相应团队。
• 组织定期的代理角色会议，让代理们相互沟通和协作，以确保团队目标的达成。
• 建立代理角色的沟通汇报机制，如定期晨会、周报和项目维度的回顾会。

3.2 门面模式（Facade Pattern）

门面模式提供了一个统一的接口来访问子系统中的一组接口。在团队管理中，可以创建一个统一的协调角色（如项目经理或技术负责人），该角色负责协调团队成员的工作，并充当各个团队之间的沟通桥梁。这有助于确保团队之间的沟通更加高效，降低沟通成本。

具体实施方案：

• 设立项目经理、技术负责人或者某个业务模块的 DRI 角色，负责跨团队协调和沟通。
• 为每个团队成员分配具体的职责和任务，以便在项目经理或技术负责人的协调下高效协作。
• 定期召开跨团队会议，确保团队之间的沟通畅通，及时解决问题。

门面模式和代理模式看起来有一点相似，其本质上是有区别的，区别在于授权的范围，门面模式不用太关注其内部实现，而代理模式在管理上要更深入细节一些。

在实际应用中，我们通常在各职能和各业务模块中使用代理模式，而针对不同的区域使用门面模式，由当前地区的负责人提供统一的输出。

3.3 观察者模式（Observer Pattern）

观察者模式在团队管理中可以应用于实时通知和信息共享。当一个团队成员对项目状态或任务完成情况进行更新时，其他相关成员可以作为观察者实时收到通知。这种模式有助于保持团队成员之间的信息同步，提高沟通效率。

具体实施方案：

• 为团队成员创建一个共享平台，如任务管理工具、项目管理系统等。
• 当某个团队成员更新任务状态或项目信息时，系统自动通知其他相关成员。
• 通过观察者模式，确保团队成员之间的信息同步，减少冗余沟通。

4 六项注意

4.1 相互信任

信任是团队协作的命脉。要想促进并保持长久的关系，你就必须信任他人，他们也必须信任你。与此同时，他们还必须相互信任。

信任来自相互理解对方的价值观、个人经历和立场。为了实现这一目标，我们必须承认自己的弱点，我们必须开放。这样我们才能够建立起共同的价值观和彼此信任。

信任在异地团队中有如下的好处：

1. 提高团队凝聚力：信任关系有助于增强团队成员间的默契，从而提高团队凝聚力。当团队成员信任彼此时，他们更愿意携手合作，共同解决问题。
2. 提高工作效率：信任关系可以促使团队成员更加开放地分享信息、资源和建议，从而提高整体工作效率。当团队成员相互信任时，他们更可能分享自己的想法和专业知识，共同解决问题。
3. 降低沟通障碍：信任有助于消除团队成员间的沟通障碍，提高沟通效果。当团队成员彼此信任时，他们更愿意倾听对方的意见，以开放的态度接受建议和批评。
4. 降低管理成本：信任关系有助于减轻管理压力，降低管理成本。当团队成员相互信任时，他们更可能自我管理，减少管理者的介入。
5. 增加创新和风险承担：信任关系有助于创造一个安全的环境，使团队成员更愿意尝试新的想法和承担风险。当团队成员彼此信任时，他们更可能勇于创新和承担失败的风险。

建立相互信任关系的方法，以下是一些常见的方法：

1. 增加沟通：

   • 定期开展团队会议，让团队成员分享项目进展、遇到的困难和解决方案。
   • 鼓励一对一交流，让团队成员有机会深入了解彼此的工作、兴趣和需求。
   • 举办团队活动，如团队建设、庆祝活动和知识分享，促进团队成员间的互动和信任。

2. 增加透明度：

   • 使用项目管理工具，让团队成员能够实时查看项目进度和任务分配。
   • 定期分享业务战略、目标和团队绩效，让团队成员了解公司的发展方向。

3. 赋予责任和权力：

   • 根据团队成员的专长和兴趣分配任务，让他们在完成任务时有更大的自主权。
   • 鼓励团队成员在解决问题时提出建议和改进方案，展现对他们的信任。

4. 鼓励支持和合作：

   • 创建一个支持性的氛围，让团队成员在遇到问题时不惧于寻求帮助。
   • 鼓励团队成员互相学习、分享经验，以解决共同面临的问题。

5. 表扬和认可：

   • 在团队会议上表扬团队成员的优秀表现和努力。
   • 为表现突出的团队成员提供奖励，如奖金、晋升和表彰。

6. 建立公平的环境：

   • 确保团队中的决策过程透明，鼓励团队成员参与讨论和决策。
   • 设定明确的激励和奖惩

4.2 仪式感

在异地管理中，仪式感是一种有意识地营造正式或非正式场景，以传递重要信息、强化文化价值观、增强团队凝聚力和提升员工信任感的方式。

在异地团队中，恰当的仪式感具有以下好处：

1. 增强团队凝聚力：仪式感有助于让团队成员感受到归属感和团队精神，从而增强团队凝聚力。
2. 传递公司文化和价值观：通过仪式感，可以传递公司的文化和价值观，帮助团队成员更好地理解和认同这些价值观。
3. 提升员工士气和信任感：仪式感可以激发团队成员的积极性和参与感，从而提高员工士气和信任感。
4. 建立清晰的期望和目标：仪式感有助于确立团队成员的期望和目标，提高工作效率和执行力。

那如何建立恰当的仪式感呢？

1. 定期召开团队会议：固定时间、地点召开团队会议，让团队成员汇报进展、分享经验、讨论问题。如每周一召开全体成员参加的在线例会，或者对于管理团队，定期如开包含问题同步和处理，学习分享的管理例会。
2. 庆祝重要节点和成就：为团队的重要成就和里程碑设立庆祝活动，以增强团队成员的归属感和自豪感。如在项目完成时，举办在线庆祝活动，表彰优秀团队成员。
3. 组织团队建设活动：定期组织线上或线下的团队建设活动，增进团队成员间的联系和互动。如每季度举办一次线上游戏比赛，增强团队成员之间的合作和交流。
4. 激励和认可：对团队成员的努力和成果给予表扬和认可，提高他们的信任感。如每月颁发「最佳团队贡献者」奖项，表扬表现优秀的团队成员。
5. 传递公司文化：通过仪式感传递公司文化，帮助团队成员理解和认同公司的价值观。如每年举办一次公司文化分享活动，邀请公司领导和团队成员分享公司文化和价值观。

4.3 严格目标管理，注重结果

在异地技术团队管理中，严格的目标管理和注重结果至关重要，因为这有助于确保项目按时完成、质量达标，并提高团队成员的工作效率和执行力。

以下是实行严格目标管理和注重结果导向的好处：

1. 明确工作目标：设定清晰的目标和期望，帮助团队成员明确工作重点，避免资源浪费和目标模糊。
2. 提高工作效率：明确的目标和期望有助于团队成员更高效地完成任务，降低拖延和低效的可能性。
3. 便于评估和改进：结果导向的管理使团队可以通过衡量实际成果来评估工作效果，从而找出不足并进行改进。
4. 激发团队成员积极性：目标明确、注重结果的管理方式有助于激发团队成员的积极性和责任心，鼓励他们为实现目标而努力。
5. 有利于项目按期完成：严格的目标管理和注重结果有助于确保项目按计划进行，按时完成，避免延期。

那么如何实施严格的目标管理和注重结果导向？有如下 7 个方法

1. 设定明确的目标：为项目和团队设定明确、可衡量、可达成的目标。如在项目开始时，为团队设定一个明确的项目交付日期，并明确交付内容的具体要求（也就是大家常说的 deadline 是第一生产力）。
2. 制定详细的计划：为实现目标制定详细的计划和进度表，包括任务分配、时间安排等。如使用项目管理工具（如Trello、Jira等）制定详细的任务列表和时间表，如果没有这些工具，搞个在线表格也是极好的。
3. 定期检查进度：定期与团队成员沟通，了解项目进度和遇到的问题，确保项目按计划进行。如定期的项目晨会（可以按周，或按天，也可以一周两次，根据实际情况调整），让团队成员报告各自的任务进展和遇到的问题。
4. 强调结果导向：鼓励团队成员关注实际成果，以实现预定目标。在管理过程中对团队成员的绩效评估更注重实际完成的任务和贡献，而非工作时长或其他表面指标（不要卷加班）。
5. 及时反馈和调整：根据实际进度和成果，及时给予团队成员反馈，调整目标或计划。如当发现某个任务进度落后时，及时与相关成员沟通，分析原因，并调整计划或提供支持。如当发现某个任务进度落后时，及时与相关成员沟通，分析原因，并调整计划或提供所需资源，以确保项目仍能按时完成。
6. 定期总结和复盘：项目结束后，与团队成员一起总结经验教训，分析成功与失败的原因，以便在未来项目中持续改进。如项目结束后，组织团队进行复盘会议，总结项目的优点和不足，制定改进措施。或者迭代结束后做一些回顾。

我们在团队管理中，目标管理是一个非常重要的点，一定要自己主导，不能授权，作为一个技术团队的负责人，方向是你来定的，未来在你的手里

4.4 扁平、弹性的组织架构

在异地技术团队管理中，组织架构至关重要，因为组织架构会影响团队的沟通效率、决策速度、责任分配和协作。适合异地技术团队的组织架构应具备以下特点：扁平化、模块化、弹性和高度协作。

1. 扁平化：扁平化的组织结构有助于提高沟通效率，减少信息传递过程中的失真和延迟。扁平化组织中，每个成员能够直接向上级汇报，决策速度更快，执行力更强。

2. 模块化：将工作划分为具体的、相对独立的模块，有助于提高团队的协作效率。每个模块可以由一个或多个团队负责，这样可以减少跨团队协作的复杂度，降低沟通成本。

3. 弹性：适应不断变化的项目需求和团队规模，组织架构需要具备一定的弹性。弹性的组织架构可以快速调整资源分配和团队规模，以满足项目发展的需要。

4. 高度协作：鼓励团队成员之间的协作和互助，以提高工作效率和质量。高度协作的团队可以更好地应对复杂问题，减少重复劳动和资源浪费。

以下是如何实现适合异地技术团队的组织架构：

1. 利用技术手段优化沟通：使用沟通和协作工具（如钉钉、企业微信、飞书、Microsoft Teams等）提高沟通效率，方便团队成员跨地域、跨部门协作。
2. 决策下放：授权团队成员在其负责领域做出决策，提高决策速度。如将需求评审的决策权下放至小组 leader 或 DRI，甚至一线开发，让他们根据自己的专业知识对需求进行评估和调整。
3. 设立技术负责人或项目经理：在每个地区或团队设立技术负责人或项目经理，负责协调团队成员的工作，确保项目顺利进行。如在各城市的团队中各设立一名项目经理，负责当地团队的项目进度和资源协调。
4. 定期进行跨团队沟通：组织定期的跨团队会议，让各个团队分享进展、问题和解决方案。这有助于提高团队间的了解和协作。如每两周组织一次跨团队分享会议，让各个团队汇报自己的进展和挑战，共同寻找解决方案。
5. 提供培训和支持：为团队成员提供技能培训和支持，以便他们更好地适应组织架构变化。如提供关于敏捷开发、跨部门协作等方面的培训课程，帮助团队成员提高工作效率和协作能力。
6. 鼓励创新和变革：建立一种鼓励创新和变革的文化，让团队成员敢于尝试新方法，优化工作流程。如设立创新奖励计划，对于提出改进方案并成功实施的团队成员给予奖励。或者团队负责人亲自来参与或推进一些创新的事项，如最近的比较热的 AI。

4.5 统一的技术栈

在异地技术团队管理中，统一技术栈非常重要，因为它能为团队带来以下好处：

1. 提高协作效率：统一技术栈能确保团队成员之间更容易进行技术交流和协作，避免因技术差异导致的沟通障碍和额外工作量。
2. 降低维护成本：使用相同的技术栈，使得维护、调试和优化工作更加简单，减少因为技术差异导致的额外成本。
3. 增强团队能力：统一技术栈有助于团队成员互相学习，提高整体技术能力，使得团队在面对复杂项目时更具备应对能力。
4. 简化招聘和培训：统一技术栈使得招聘和培训过程更加简单，因为公司可以针对特定技术栈进行招聘和培训，提高招聘效率和培训质量。

为实现统一技术栈，我们可以采取以下方法：

1. 制定技术规范和标准：制定统一的技术规范和标准，确保各地团队遵循相同的技术实践。如制定统一的编码规范、代码审查标准和自动化测试要求。
2. 组织上增加架构设计的职能或者技术通道的职能组织: 通过组织的方式构建技术栈统一的土壤。
3. 搭建技术共享平台：创建内部技术分享平台，让团队成员分享技术心得、问题解决方案和最佳实践，有助于统一技术理念和实践。如搭建一个内部的技术博客平台，鼓励成员撰写和分享技术文章。
4. 统一基建和开发流程中的系统: 通过使用工具的统一达到技术栈的统一。
5. 选型时充分调查和论证：在技术选型阶段，充分调查并论证各种技术方案的优缺点，确保选择的技术栈适合公司的业务需求和发展战略。
6. 定期评估和调整：定期评估技术栈的合理性和有效性，根据项目需求和团队能力进行调整，以保持技术栈的统一性和先进性。如每年定期组织技术栈评审和审查，了解目前所使用的技术栈是否仍然满足业务需求，或者是否有新技术可以更好地支持业务发展。

通过以上方法，异地技术团队可以实现技术栈的统一，从而提高协作效率、降低维护成本、增强团队能力，并简化招聘和培训过程。这将有助于提高团队整体的研发效能，使得公司在面对市场竞争和业务挑战时更具备优势。

4.6 高效的沟通机制

异地团队最突出的问题是沟通问题，在我们平常的沟通过程中需要选择合适的沟通渠道和做有准备的沟通。良好的沟通有如下的好处：

1. 能提高沟通效率：采用合适的沟通方式可以确保信息准确、及时地传递给相关人员，避免因沟通不畅导致的误解和冲突。
2. 增强团队凝聚力：良好的沟通方式有助于增进团队成员之间的理解和信任，提高团队凝聚力。
3. 减少资源浪费：有效的沟通方式能够减少不必要的会议和重复工作，降低资源浪费。
4. 支持项目管理：清晰的沟通方式有助于确保项目进度、需求和问题得到及时解决，保障项目顺利进行。

我们可以通过如下的一些方式达到比较高效的沟通机制：

1. 明确沟通目标和内容：在沟通开始前，明确沟通的目的、内容和预期结果。如：在项目会议开始前，列出讨论议题、相关人员和预期决策。
2. 选择合适的沟通渠道：根据沟通内容和参与人员，选择合适的沟通渠道。如：对于紧急问题，可以使用电话或即时通讯工具（如微信、钉钉等）进行沟通；对于团队日常工作，可以使用邮件或者项目管理工具（如Jira、Trello等）进行沟通。
3. 建立沟通规范：制定团队沟通规范，确保沟通有效进行。如：要求团队高效会议，或者要求团队成员在邮件中使用清晰的主题行、合理的收件人列表以及简洁明了的正文。
4. 鼓励开放和诚实的沟通：营造一个鼓励团队成员开放、诚实地表达观点和需求的氛围。如：在团队会议上，鼓励成员提出问题、建议和想法，避免惩罚性的反馈。
5. 定期进行沟通培训：为团队成员提供沟通技巧培训，以便他们更好地进行沟通。如：提供关于有效沟通、团队协作等方面的培训课程。

值得注意的是，异地的沟通中尽量少用邮件，邮件适用于传达信息和事实，撰写时还需要注意措辞，以防误会的发生。

单纯的文字无法传递情绪，如果要传达你的想法时，最好拿起电话进行视频，通过视频也能制造多次「见面」的机会更有利于建立信任。

现在用 IM 类工具也比较多了，在清晰的文字表达的基础上，多用表情包。

5 后记

上面说了这么多，有点啰嗦，简单点来说就是：多见见，多一起喝点酒，多一起搞定一些事情，保证基本的机制、流程、标准、工具和系统，也就差不多了。

异地的问题表象是见不着，核心要解决的是效率的问题。

技术团队的管理更多的还是人的问题，还是需要有情感的交流和因为长时间的一起工作而产生的向心力。 我们所做的这些仅能缓解这些问题。

当然，可能有同学会更喜欢异地/远程的工作协同模式，此处因人而异，从个人的角度来看：从团队的角度，从效能的角度，本地化团队会是更高效的选择。

当然以上的模式和注意事项在非异地团队的情况下也是可以使用的，而且效果会更好，因为这些的本质是授权管理和过程管理的逻辑。

在技术团队的日常管理工作中，一个管理者做得最多的事情是决策、开会，最不想看到的是线上事故，线上事故给技术团队带来非常大的冲击，而给线上系统带来风险最大的研发环节是线上环境的变更，甚至有人说：「没有变更就没有问题」，对此我们不置可否，但这些变更之所以会导致事故，从根源上来讲大部分是技术同学犯了错。

这里的决策、会议，变更，错误合起来是我们日常工作中的大部分。而对于这些的基本认知是一个技术管理者在带团队过程中逐步提升的，今天我们就来聊聊这 4 个基本认知。

1 决策

在带团队的过程中我们会做非常多的决策，如去决策是否投入足够大量的人力满足某个业务，或者升级架构，或者构建某个流程机制等等。

这些决策中从服务于时间维分为两种：

• 当下的决策，如评估需求优先级，先做什么，后做什么，关注的是当下和已有的；
• 未来的决策，如评估技术架构演进、团队演化和发展等等，关注的是未来。

当下的决策在我们的工作中最常用于评估产品需求、评估技术方案或实现方案。

对于产品需求，技术管理者的作用是把价值不高，或者没有价值的需求干掉，不让其进入研发，不让公司的人力成本白白浪费掉。一般我们会对于提需求的同学问如下的问题：

1. 为什么会有这个需求？ 一般是想看这个需求是怎么来的，用户故事是怎样的；
2. 这个需求的价值是什么？ 一般是想看这个需求做了之后对产品或业务的好处，看产出；
3. 如何度量这些价值？ 一般是想通过数据看到需求的价值，把价值反馈在指标上，如营收指标、效率指标等。

对于技术需求或技术方案，技术管理者的作用是来评估当下的选择是否正确。一般我们会评估如下的点：

1. 有没有做过方案评估，即有没有评估过业内的方案、公司内的方案以及对于当下的现况的分析；
2. 是否合理的方案，有没有明显的缺陷或漏洞；
3. 有没有显得特别高大上，特别先进，防止过度设计，浪费资源。

未来的决策更多是管理者站在当下思考团队的发展，人员的发展和技术架构的发展等，是一种未雨绸缪的远见。

是基于公司战略，在组织的先进性、技术的先进性的前瞻性布局。如现有的人才梯队和人才密度是否能满足公司三到五年的发展，现在的技术架构是否能满足公司三到五年后的战略，对于行业内新的技术是否我们需要扩大资源投入，去预研并应用在业务中。

这些前瞻性的决策都是管理者基于对公司业务和业务未来发展有足够的认知和理解后做的。

我们所做的这些决策都是以有限的资源达成我们的目的，其本质是资源的分配。当我们分配资源的时候，最最重要是看投入产出比以及和公司战略的方向是否一致。

2 变更

这里的变更是指生产环境的变更。首先我们看一下定义，什么叫生产环境？生产环境是指服务于客户的应用及其运行环境，以及和这些环境相关联的环境和系统。

如果一个应用或环境和生产环境有接触，那它也是生产环境。

什么叫变更管理，变更管理包括什么？

变更管理是指以可控的方式对线上的服务、配置或基础设施进行变更，从而减少变更对业务和服务质量的影响，快速处理变更可能带来的问题，提升系统的稳定性。

在日常工作中我们见到变更有如下 4 种：

1. 应用变更，也称为代码变更，是我们最最常见的变更类型，主要是通过修改代码改变应用程序并通过发布系统发布到线上。这也是我们变更管理中风险最大的地方，因为变更的人，变更的位置和逻辑等都是不确定的。除了正常的发布变更，应用的回滚也是应用变更的一种，因为其改动了线上的应用；
2. 配置变更，是指应用系统的配置变更，一般是通过配置系统来变更，触发线上应用的热更新或滚动，配置如果是写死在代码中，会变为代码变更；
3. 基础设施变更，此变更一般是运维同学来操作，可能涉及网络设施变更，服务解析变更等等，如 DNS 的解析，网络安全配置等等，这些都算到基础设施变更里面，而不是配置变更，又如宿主机挂了，需要替换宿主机，此时也会导致基础设施的变更；
4. 容量变更，此处单独列出是因为相对于基础设施，容量变动的影响逻辑不一样，其主要是通过垂直或水平的方式提升系统的容量，特别是当出现容量告警的时候，此变更经常由运维同学手动，或者系统自动触发。

那么如何控制变更？这里我们先提一下变更管理的标准流程。

变更管理的标准流程：

1. 变更申请：在我们的流程中可能是创建发布记录，或者申请紧急发布
2. 变更评审：变更评审主要是检查变更过程是否完备，以降低变更的风险，其包括如下内容：

   1. 就绪分析：材料是否完备，人员、设备、软件、网络是否就绪，测试是否达到上线要求等。
   2. 风险分析：架构、性能、业务、合规等方面的风险评估，变更内容是否属于需求范围，变更是否可控。
   3. 重要程度：变更属于一般、重要、紧急、标准哪一种。
   4. 变更审查：内容是否满足业务需求，内容是否通过测试，测试是否全面、有效。
   5. 应急管理：变更步骤、应急方案、回滚方案、应急预案是否完备。
   6. 变更实施：变更计划时间如何安排，发布及回退操作步骤是否完备，自动化步骤情况。
   7. 变更验证：变更涉及的业务、技术验证方法与时间安排。
3. 变更审批：相关负责人对于变更评审的结果进行确认，并审批通过。
4. 变更执行

   1. 根据发布计划执行发布操作，一般应该有一个灰度的过程；
   2. 验证线上功能并回归主流程；
   3. 持续灰度，观察用户直到灰度完成。
5. 变更验收

   1. 对发布的功能进行验收，对于影响范围内的功能进行验收，对业务主流程进行回归验收；
   2. 留守，并观察日志、监控服务负载等，这个操作是为了及时发现验收检查漏掉的问题，或者及时处理隐藏的问题，以减少变更后产生的问题对线上业务的影响。

我们做这个流程是形式上的安慰，还是僵化的惯性，还是能真正地解决问题，是我们在做这个流程以及执行这个流程中需要着重思考的问题。

在变更前，即我们变更线上环境前需要自己做 Code Review，以及交叉的检查，以尽量减少问题流转到后面的操作中，节省问题的处理成本。

变更管理没有银弹，我们能做的是控制节奏，敬畏线上，以更机制化的方式提前发现问题并解决问题。

3 会议

会议是一个相互沟通、交互信息、形成一致看法，从而解决问题的管理工具。

从会议的定义来看，会议是一些人有组织、有领导地为了某种目的而进行讨论和商议的集会。

当我们思考一个会议要不要开时，可能需要先思考这个会议的目的是什么。

如果一个会议没有需要讨论的地方，没有明确的目的，可能大概率是一个不需要开的会的，又或者仅仅是一个简单的信息同步，直接文档或者在群里同步就可以了。除非文档没法完全解决问题，比如一些战略的宣讲，一些大的事项的发布，需要有一个仪式感的会，现场答疑的会。

如果发现两个会的参会人差不多，那么是否取消其中的一个会呢？不一定，看目的是否一致，如果解决的问题不一样，可以同时存在。

回顾我们常开的几种会议。

• 项目例会：项目信息同步，问题卡点讨论，待办相关同步，这里的项目例会又包括常规项目例会和专项的项目例会，是项目管理中的信息渠道；
• 管理例会：团队仪式感必不可少的部分，除了事项的讨论，还有一个作用是发散的聊天，不用那么严肃，闲谈之中迸发一些火花，并达成一些共识和认知上的一致；
• 单独定期沟通会议：更私密一些的沟通会议，除了常规事项同步，更多的是一个散而不散的个人想法、规划、思路等的探讨；
• 复盘会议：对特定事项和问题的总结，讨论，属于常规会议机制的一种，起总结，沉淀的作用；
• OKR 会议：目标对齐，起方向对齐的作用；
• 需求规划会：有计划的对于需求进行规划，评审，然后进入迭代，开发测试并交付；
• 技术方案评审会：严格准入技术方案，集众人之力评估方案的可行性，看是否有什么缺漏。

着点讲一下周会，周会我们一般是指周例会，属于例行会议的一种，按周或双周召开。

周会的目的是根据会议的属性，定期回顾讨论总结指定的项，可能是专项，也可能是过程中的事项或突发的事情等。开会的目的主要是交流和讨论，那么在周会上我们讨论什么，在确定讨论内容之前，我们先看看哪些不要在周会上讨论：

1. 紧急的事情不适合在周会讨论，出现的时候直接搞定；
2. 非跨团队的问题不适合周会讨论；
3. 纯执行细节问题不适合周会讨论；
4. 大方向决策问题不适合周会讨论。

总结下来，就是涉及与会各团队的，对整体性计划或者需要协同配合的问题，或者里程碑式的改进型问题适合在周会上讨论。

当然，也不绝对，这还是一个人治的过程。

如果是你一个会议组织者，在组织一个会议的时候，需要考虑以下三件事：

1. 这个会议最重要的事情是什么，是想解决什么问题？想讨论什么？
2. 能否达到目标？ 大家对于目标是否有所了解？
3. 如何达到目标？ 达到目标的关键路径是怎样的？干系人都在吗？

4 错误

工作中我们会出一些错误，生活中我们也会出一些错误，这些错误可能会影响同事朋友，或者影响线上产品，公司业务，甚至可能会造成个人或公司的经济损失，错误有其类型，在了解了这些类型后，我们可以适当的减少出错或规避这些错误。

从个人的角度来看，错误可分为成长之错，无心之错和性恶之错。

1. 成长之错，我们都是从懵懂孩童，成长为有知识的学生，到长大成人，出来工作，工作中也是从不会到会，到熟练和精通，在这个过程中，正是因为一个个的错误，才成就了我们的成长，成长之错为正常之错，可允之；
2. 无心之错，非有意为之的错误，一时失察导致工作出现错误，从而给别人带来不好的影响，或者粗心导致过错，其出发点都非有意，出错了就认，改过即可，不可连续；
3. 性恶之错，以人性之恶为出发点或者动机，此种错不可原谅。

从工作的角度，错误可以分为超出型错误，信息型错误，粗心错误，态度型错误和风险型错误。

1. 超出型错误，当你尝试去做能力之外挑战的时候，或者你不熟悉的领域或知识盲区，或者超出当前因为自身能力或其他条件的束缚，做得不够好而犯的错。比如一些新的想法的落地，一些新技术的试点等等，这些都没有人前人尝试过，至少在当前范围内没有，此时可能会遇到想象不到的坑，或者无法解决的问题，从而出现错误，甚至失误。这种创新或者超前的错误是可以接受的；
2. 信息型错误，属于信息不对等，或者信息不全，知识不全面导致的错误，特别是对于工作中面对某个项目一些信息没有，或者没有去全面了解背景信息从而做出错误的决策，这种错误不会反复出现，但尽可能避免在不同类型的事情上犯同类型的错误；
3. 粗心错误，这种比较常见，与无知错误不同，这种情况是你明明知道怎么回事，但是因为不小心或者忘记了而导致的错误，如果是粗心之人，可能会一错再错，此时需要反思自己，以某种方式规避；
4. 态度型错误，指做事的态度有问题，比如眼看自己负责的一件事情要出问题或者已经出问题了，但是没有想办法去解决，没有付出努力，而是躺平，让事情自己变坏，甚至影响面不可控，这种错误是不允许的；
5. 风险型错误，主动去做事情，但风险很高，是否会犯错不受自己的控制。比如你面临一个重要的选择，但在结果出来之前，你之前掌握的所有信息都无法告诉你哪个选择是绝对正确的，你只能去做自己认为是大概率的选择。而这种错误在工作中是极有可能遇到的。

对于工作中的错误我们应该如何减少或者规避呢？

1. 超出型错误，从公司层面或者团队层面提供一些培训，或者在新人安排导师，提升大家的能力，或者通过流程机制让更有经验或者能力更强的人对于新的内容做一些把关；
2. 信息型错误，信息型错误可以在公司层面搞定完善的文档和快捷的查询机制，任何技术或产品讨论以及达成的共识，要尽可能用某种沟通渠道发送到所有相关的人。让大尽可能的掌控更全面的信息；
3. 粗心错误，设定一些机制来规避，如复盘机制，通过复盘，深挖过程中的问题，总结经验，为后续减少此类问题做准备，同时可以在流程上做一些 check 机制，通过多人的 check 减少错误的出现；
4. 态度型错误，本着治病救人的态度先看看，如果实在不行，考虑换个人吧；
5. 风险型错误，针对高风险的事情，尽可能的准备一个 PlanB，当事情没有按我们预想的方向发展时，启用 PlanB，减少损失，这也是我们下棋时通常会用到的策略，走一步，想三步。

从团队来看，一个人犯错，可能是人的问题，一群人犯错，一定是机制或系统出了问题。

当然，工作中我们允许试错，但是不能一错再错，避免一些不应该犯的错误，最大可能从错误中成长，这才是我们应有的态度。

除了以上，《清单革命》中说人类的错误可以分为两大类型。第一类是「无知之错」，我们犯错是因为没有掌握相关知识。第二类是「无能之错」，我们犯错并非因为没有掌握相关知识，而是因为没有正确使用这些知识。

现在，我们面临的错误更多的是「无能之错」，也就是如何持续、正确地运用我们所掌握的知识。「无知之错」可以原谅，「无能之错」不被原谅。

5 后记

管理是门实践的科学，大多数的书籍和文章都是个人或组织的经验之谈，没有公理，只能在俗世不断修行和精进，以求能「知行合一，止于至善」。

★ 你好，我是潘锦，超过 10 年的研发管理和技术架构经历，出过书，创过业，带过百人团队，也在腾讯，A 股上市公司呆过一些年头，现在在一家 C 轮的公司负责一些技术方面的管理工作。早年做过 NOI 和 ACM，对前端架构、跨端、后端架构、云原生、DevOps 等技术始终保持着浓厚的兴趣，平时喜欢读书、思考，终身学习实践者，欢迎一起交流学习。微信公众号：架构和远方，博客： www.phppan.com

”