DDD 主要解决以下问题：

1. 业务复杂性：现实世界的业务领域往往非常复杂，涉及各种业务实体、业务规则和业务流程。领域建模通过将复杂的业务领域划分为若干个界限清晰的子领域，并提炼出每个子领域的核心概念和关系，来管理和应对业务复杂性。

2. 沟通鸿沟：业务专家和技术团队往往使用不同的语言和思维方式，导致沟通障碍和理解偏差。领域建模强调建立一种团队共享的统一语言，通过将业务概念和规则显式地表达在领域模型中，促进业务和技术之间的有效沟通。

3. 软件弹性：随着业务的不断发展和变化，软件系统也需要随之演进。但是，如果软件设计没有准确反映业务领域，后续的变更就会变得困难和混乱。DDD 通过识别出领域中的不变量和变化点，并使用合适的设计模式和架构风格来封装和管理变化，提高软件的弹性和可维护性。

为了解决这些问题，DDD 提出了一系列原则和实践，包括：

• 界限上下文：将复杂的业务领域划分为多个界限明确的上下文，每个上下文对应一个特定的业务语境。
• 统一语言：在每个界限上下文中，开发团队和领域专家应该使用同一套语言来描述业务概念和规则。
• 领域模型：通过分析业务领域，提炼出核心的业务概念、业务规则和业务逻辑，并用对象模型来表示。
• 分层架构：将软件系统划分为用户界面、应用层、领域层和基础设施层，并确保依赖关系始终朝向领域层。

DDD 的发展历程大致如下：

• 20 世纪 90 年代，随着面向对象分析与设计(OOAD)的兴起，人们开始关注如何将现实世界的业务概念映射到软件对象中。
• 2003 年，Eric Evans 出版了《领域驱动设计》一书，系统地阐述了领域建模的原则和实践，标志着 DDD(Domain-Driven Design)的诞生。
• 此后，DDD 逐渐受到业界的广泛关注和应用。一些知名的 DDD 实践者，如Vaughn Vernon、Udi Dahan 等，通过著作和演讲进一步丰富和发展了 DDD 的理论体系。2014年，Vernon 出版了《实现领域驱动设计》一书，详细阐述了 DDD 在架构设计、领域建模、代码实现等方面的最佳实践，成为 DDD 实践者的重要参考。
• 近年来，随着微服务架构的兴起，DDD 在微服务设计中得到了广泛应用。一些新的概念和模式，如事件风暴、限界上下文、命令查询职责分离(CQRS)等，进一步扩展了 DDD 的实践边界。

近年来，DDD 持续受到关注，并在实践中不断发展：

1. 事件风暴(Event Storming)：由Alberto Brandolini提出，通过识别领域事件来快速建立领域模型，加速了DDD的建模过程。
2. CQRS和事件溯源(Event Sourcing)：将领域模型的读写职责分离，并将所有的状态变更记录为事件，提高了系统的性能和扩展性。
3. 领域故事(Domain Story)：将用户故事(User Story)提升到业务领域的层次，用业务语言描述系统的功能需求，加强了业务视角的引入。
4. 领域驱动的微服务设计：以 DDD 为指导，从业务领域的角度识别和拆分微服务，提高了微服务的内聚性和自治性。

当前，领域建模和DDD 已经成为应对复杂业务系统设计的重要工具和方法论。以下是一些最新的发展趋势：

1. 结合敏捷实践：DDD 强调在开发过程中持续深化对领域的理解，并通过频繁的反馈和调整来完善领域模型。这与敏捷开发的迭代优化理念高度一致。当前，越来越多的团队尝试将 DDD 与 Scrum、看板等敏捷实践相结合，通过跨职能团队协作、领域故事映射(User Story Mapping)等技术来加速领域建模的过程。

2. 领域事件驱动：随着 Event Sourcing 和 CQRS 等架构模式的普及，领域事件(Domain Event)成为连接领域模型与技术实现的重要媒介。通过显式定义领域事件，并以事件驱动的方式编排业务流程和数据同步，可以提高系统的扩展性和性能。

3. 开发工具支持：越来越多的建模工具和开发框架开始提供对DDD的原生支持。例如，EventStorming 工具支持在线协作完成事件风暴;MPS(Meta Programming System)等语言工作台支持以领域特定语言(DSL)的方式直接表达领域模型;Axon、Eventuate等框架提供了事件溯源和CQRS的开箱即用支持。这些工具的成熟，大大降低了DDD的实施门槛。

4. 企业级应用：DDD 典型地应用于单一企业内部的复杂业务系统。而随着企业数字化转型的深入，DDD 在企业级应用架构中也开始发挥越来越重要的作用。通过运用 DDD 原则，建立清晰的业务领域边界和上下文映射，可以指导企业级应用的领域划分、系统解耦、服务化演进等架构设计工作。

通过上面的内容我们对于领域驱动设计有了一个初步的认知，DDD 为设计和开发复杂业务系统提供了行之有效的指导原则和实践指南。

那从技术团队管理的角度来看，有哪些相似点，又有哪些不同，DDD 的原则及其解决问题的过程对于技术团队管理者来说又有哪些借鉴的地方，对此有如下的 6 点思考：

1 管理复杂度

DDD 的核心在于管理业务复杂性。通过将复杂的业务领域划分为若干个界限清晰的子领域，并在每个子领域中提炼出核心业务概念和业务规则，DDD 帮助我们深入理解业务，并将其转化为可执行的软件模型。这一点对于应对日益复杂的业务需求至关重要。

DDD 面对复杂的业务领域，会进行领域划分，识别出核心域、通用域、支撑域等不同的子领域。通过划分领域边界，我们可以更好地管理复杂性，分而治之，让每个子领域都有明确的职责和边界。同时，领域边界划分也有助于识别领域内的关键概念、业务规则和约束条件。

技术团队管理同样面临复杂性的挑战。随着团队规模的扩大和业务需求的增长，团队内部的沟通协作、技术决策、资源调配等问题日益复杂。

管理者需要采用合适的组织结构和管理实践，将复杂的团队工作划分为可管理的模块，并在模块间建立清晰的职责边界和接口协议。

并且划分团队边界和职责，根据系统架构和业务需求，设计出合理的团队结构和职责分工。每个团队或角色都应该有明确的边界和交付物，避免出现职责交叉或责任真空的情况。通过职责边界划分，团队成员能够专注于自己的工作，提高工作效率和质量。

领域边界划分和团队职责划分的相似之处在于，它们都是为了应对复杂性，通过「分而治之」的方式来管理复杂度。

2 统一语言

DDD 强调在每个界限上下文中建立统一语言，即业务专家和开发团队应该使用同一套语言来描述业务概念和业务规则。统一语言有助于消除业务理解上的歧义，减少需求遗漏和错误理解，提高沟通效率。

在技术团队管理中，统一语言也扮演着类似的角色。团队成员来自不同的背景和专业，彼此之间容易产生理解偏差。技术团队管理者需要在团队内部形成一套统一的技术语言体系，包括架构原则、设计模式、编码规范、质量标准、开发语言等。确保所有人对工作内容有相同的理解。

统一的技术语言有助于提升团队的协作效率，减少技术债，促进知识共享和经验传承。

统一语言在领域建模和技术团队管理中的共通点在于，它们都强调语言的一致性对于沟通效率和工作质量的重要性。

这本质上是一个成本问题，减少过程中的沟通成本，通过统一语言实现有效协作，正所谓「言语齐，则民聚；言语不齐，则民散」。

业务统一语言强调与领域专家的有效沟通，而技术统一语言更强调团队内部的协作。二者需要相互配合。

3 分层架构的设计

DDD 提出了分层架构的设计原则，即将软件系统划分为用户界面、应用层、领域层和基础设施层，并确保依赖关系始终朝向领域层。

分层架构有助于隔离业务逻辑与技术实现，保持领域模型的纯粹性，提高系统的可测试性和可维护性。

技术团队管理同样强调分层管理。随着团队规模的增长，扁平化管理将变得难以为继。管理者需要在团队内部建立起适当的管理层级，并在各层级间合理划分职责和权力。

过于复杂的层级会导致信息传递失真和决策迟滞，而过于扁平的结构又可能让管理失控。管理者需要在二者间寻找平衡。

分层架构是管理复杂性的有效手段。但软件分层架构强调上层依赖下层，而管理分层强调上层指挥下层。

软件分层追求的是关注点分离和依赖最小化，管理分层追求的是指挥与协作的最优化。二者分工不同，但目标一致：通过恰当的分层，让复杂系统变得可控和高效。

4 持续迭代优化

DDD 强调通过持续迭代和反馈来优化领域模型。

这是一个渐进的过程，团队在每个迭代周期中，都要对已有的领域模型进行评估和改进，通过引入新的业务洞见、技术创新等来持续迭代优化模型。这种持续优化的实践，确保了领域模型能够随业务变化而演进，始终保持与业务需求的紧密匹配。

技术团队管理同样需要持续迭代优化。优秀的管理实践并非一蹴而就，而是在持续实践中逐步完善。

管理者需要在每个迭代周期中，评估现有的管理实践，识别可以改进的地方，并基于反馈不断优化。彼得·德鲁克说：「管理的本质不在于知而在于行」。

常规我们会通过定期的回顾总结会议，团队成员分享工作中的经验教训，识别出可以改进的地方，并制定行动计划。当然，不局限于总结会议，可以是沙龙或者其它非正式一些的方式，但是组织逻辑还是要按高效会议的逻辑组织。

通过持续不断的自我优化，团队能够在实践中不断成长，提高工作效率和质量，适应不断变化的技术挑战，始终保持与团队需求的动态匹配。

持续迭代优化是 DDD 和技术团队管理的共同追求。二者都认识到，在复杂多变的环境中，唯有持续改进，才能保持竞争优势。但 DDD 关注的是领域模型的持续优化，技术团队管理关注的是管理实践的持续完善。二者殊途同归：领域驱动为优化指引方向，管理实践为优化提供载体。

5 平衡战术和战略目标

DDD 在战术设计和战略设计间寻求平衡。战术设计关注软件的实现细节，如聚合、实体、值对象等；战略设计关注高层的业务架构，如界限上下文、上下文映射等。

DDD 认为，只有战术与战略协调一致，才能实现业务目标。过度关注战术实现，可能导致偏离业务方向；过度关注战略规划，可能导致落地困难。需要在二者间寻求平衡。

技术团队管理同样需要平衡战术执行和战略规划。战术执行确保团队高质量、高效地完成当前的项目任务，交付满足业务需求的软件产品，关注当下的交付质量和效率，战略规划关注团队成员的能力成长，通过培训、指导等方式提升团队的整体技术实力，关注长期的技术演进和团队发展。

管理者需要在二者间权衡取舍：过度关注战术执行，可能会陷入短期主义，积累技术债；过度关注战略规划，可能会脱离现实，导致执行力不足。

优秀的技术团队管理者，需要在战术执行中体现战略意图，在战略规划中考虑战术现实。

平衡战术和战略是 DDD 和技术团队管理的共同诉求。二者都强调在理想和现实、当下和未来间寻求平衡。DDD 在战术实现和战略规划间权衡，技术团队管理在短期目标和长期发展间平衡。二者殊途同归：领域驱动为战略导向，技术驱动为战术赋能。

6 聚焦核心价值

DDD 的终极目标，是通过领域建模和设计，让软件聚焦和体现业务的核心价值。通过提炼核心域和通用域，DDD 让团队优先保证核心业务的软件质量和交付效率。

通过聚焦核心领域，我们可以将有限的资源投入到最能体现业务价值的地方，构建出反映企业核心竞争力的领域模型。

同时，对于非核心的通用域和支撑域，我们可以采用购买、外包等方式来降低复杂度，聚焦核心。

技术团队管理需要聚焦团队的核心竞争力。面对有限的资源和无限的需求，管理者需要做出取舍，让团队聚焦最能体现其专业优势和商业价值的领域。

对非核心业务，可以考虑外包或购买现成解决方案；对通用功能，可以考虑复用或使用开源方案。

管理者需要带领团队持续思考：什么是我们的差异化优势？什么是我们的核心竞争力？ 并围绕这个核心持续打磨和升级。

聚焦核心价值是 DDD 和技术团队管理的终极诉求。DDD 聚焦领域核心，技术团队管理聚焦团队优势。聚焦价值，体现价值。

7 小结

DDD 提供了一个解析和管理复杂性的思维框架，其核心理念和实践，如持续迭代优化、应对变化和不确定性、平衡战术和战略目标、聚焦核心价值、领域边界划分、分层架构等，都对技术团队管理有深刻启示。

这启示我们以系统性思维审视复杂性，以适应性领导拥抱变化，以持续成长的心态追求卓越，以跨界协作的方式创造价值。

正如 Albert Einstein 所言:”复杂的问题不能用产生它的思维方式来解决。” 领域驱动设计给了我们一种突破旧有思维方式的新视角。

技术团队管理的艺术，在于洞察人性，激发潜能。而领域驱动设计的智慧，在于洞察业务本质，拥抱技术变革。二者相互交织，共同指引我们在不确定性中前行。

作为技术管理者：

• 我们要成为连接业务与技术的「架构师」，引领团队用创新点亮未来;
• 我们要成为引领变革的「领航员」，带领团队在不确定中破浪前行;
• 我们更要成为成就他人的「园丁」，营造持续成长的土壤，让每个生命绽放光彩。

以匠心，以爱心，以卓越之心

以上

所谓的「异类」只是站在我们的角度来看的，根据员工的行为表现和团队影响，大致可以分以下的 5 类：

1. 特立独行型：这类「异类」员工往往有自己独特的工作方式和处事风格，不太愿意随大流，喜欢标新立异。他们通常有很强的独立思考能力和创新意识，能够给团队带来新的视角和思路。但同时，他们也可能不太擅长团队协作。
2. 专业领域型：这类「异类」员工在某一专业领域有极高的造诣，是团队的领域专家。他们对自己的专业领域有极高的要求和热情投入，但可能对团队的其他事务不太感兴趣。
3. 性格气质型：这类「异类」员工的个性比较鲜明，可能是性格孤僻、不善言辞，也可能是个性张扬、言语犀利。他们在团队中可能显得格格不入，容易产生误解和矛盾。
4. 行为习惯型：这类「异类」员工在工作中可能有一些特殊的行为习惯，比如工作时间特立独行、沟通方式比较直接等。这些习惯可能与团队的工作节奏和沟通方式不太一致，容易引起不适。管理者需要通过交流和反馈，帮助他们认识到自己的行为对团队的影响，并逐步进行调整。
5. 价值观念型：这类「异类」员工的价值观念与团队的主流价值观存在一定差异，这种差异可能体现在工作态度、职业操守等方面。

以上分类并非互斥，一个「异类」员工可能同时具有多个类型的特征。

以上类型的同学我们都有可能遇到，特别是技术团队管理过程中尤为明显，那作为一名成熟的管理者，应该怎么做呢？ 首先需要拥有一颗开放和包容的心，说起来容易，但做起来挺难的，因为这是与人性在拉扯。

人，生而不同，每个人都是独特的个体，都有自己的优缺点和特质。「异类」员工的存在，恰恰体现了团队的多元化，他们为团队注入了不同的思想和视角。对于他们的特质，我们应该予以尊重和欣赏，而不是简单地把他们定义为「问题员工」。

但同时，管理者也需要有原则和底线。团队协作时，如果「异类」员工的言行举止严重影响了团队的正常运转，对业务目标的达成造成负面影响，那么我们就有必要及时干预。这就要求我们要事先厘清团队的规则和红线，并且要把对员工的要求心中有数，这是我们应尽的职责。

那红线是什么？我理解红线包括以下 5 个：

1. 价值观红线：违背公司的核心价值观，持有与公司文化完全相悖的价值理念。
2. 原则红线：违背基本的职业操守和个人品德，如欺诈、泄密、剽窃等。
3. 规则红线：严重违反公司和团队的规章制度，屡教不改，对团队秩序造成恶劣影响。
4. 绩效红线：工作严重不达标，绩效长期低下，且没有改进的意愿和行动。
5. 行为红线：言行举止严重影响团队氛围，或者影响团队的整体执行力，或给公司声誉造成负面影响。

作为管理者，需要全面了解每一个「异类」员工的特点，因人而异地进行管理和引导，发挥他们的优势，帮助他们克服弱点，让他们在团队中找到合适的位置，为团队创造更大的价值。同时，也要持续塑造团队文化，营造包容、开放、互信的团队氛围，让「异类」员工感受到团队的温暖和力量，愿意与团队共同成长。

在面对这些同学时，我们先厘清是不是我们的胸怀问题，看看是否是我们的胸怀不够开阔，是否没有给予员工足够的包容和理解；有没有把规则讲在前面，有没有把要求讲在前面？有没有给员工改进的机会和空间？如果确定不是胸怀问题，规则和要求都讲了，并判断他确实改不了，那就需要处理了。

在处理「异类」员工时，我们需要区分两种情况：

一个是是否是触了红线，是否是不能原谅的，那是就只有一条路了，离开这个公司，这里对大家都负责任的做法。

另一个是没有触及红线，只是理念的不一致，或者你们之间无法合作，在认知上无法达成一致，但是其人确实有能力，只是和你不太匹配，那么建议转岗或者换个地方试试。

不同的环境、不同的领导风格，可能更能激发员工的潜力。调岗也能让员工获得新的成长机会，开阔视野。

这些处理过程中，我们都需要与员工充分沟通，了解员工的想法，对员工的能力和特点有全面的认识。调岗决不能成为管理者推卸责任、逃避问题的借口。如果调岗后问题仍然存在，管理者就需要反思是否是自身的管理方式出了问题，是否给了员工足够的支持和指导。

在团队管理过程中遇到「异类」员工是一件正常的事情，也是一个管理者成熟的必经之路。

本着善良之心，做周全之举，事不过三

工资不仅仅是员工为其劳动力所获得的经济补偿，它在现代社会中扮演着多重作用。

首先，工资是确保员工基本生活需要的关键。通过为个人和家庭提供必要的经济资源，工资支持了社会成员的基本生存和福利水平。这种直接的经济支持功能对于维持社会稳定和个人福祉至关重要。在更广阔的意义上，工资水平反映了社会对不同职业的经济评价和需求，它影响着劳动力市场的供需关系，进而决定了资源在不同行业和职业间的分配。

其次，工资对于劳动力市场的调节具有中枢作用。它是激励机制的核心，可以影响员工的工作表现和生产率。一个合理并具有竞争力的薪酬结构能够吸引和保留关键人才，促使员工提升专业技能，并且激发创新。工资还可以作为一种反馈机制，通知员工他们的表现和努力被组织如何认可。因此，工资水平和结构在人力资源管理中扮演着关键的角色，它们直接关联到员工的职业发展和职业满足感。

最后，工资在社会经济结构中起到了传递和分配收入的作用。工资收入的分配公平性是衡量社会经济正义的重要指标之一。工资差异过大可能导致社会不平等和矛盾的加剧，而工资增长与经济增长的同步则有助于提高整体的生活标准，并促进社会的和谐发展。此外，工资水平的波动对消费者购买力有着直接影响，进而影响总需求、储蓄和投资，对经济活动产生深远影响。因此，工资政策应当与经济政策协同发展，共同促进经济的可持续增长与社会福祉的提升。

奖金

相较于工资，对于奖金的逻辑不清楚的同学更多。

奖金通常是金钱形式的，旨在奖励员工过去一段时间内的出色表现，或是激励未来的高绩效。

奖金的支付可以是预期的，比如年终奖、销售提成等，也可以是非预期的，比如特别奖励或意外利润分享。奖金可以是固定金额，也可以是与绩效指标挂钩的百分比额度。

其中年终奖是指行政机关、企事业单位根据其全年经济效益和对雇员全年工作业绩的综合考核情况，向雇员发放的一次性奖金。

年终奖是奖金，和工资不同，他是一次性的，而且是根据大环境、公司效益和个人绩效考核情况综合考量的分配结果。

奖金是一种激励手段，是建立在有劳有获、相对公平基础上的奖励，注意，这里是相对公平，如果是平均主义的公平，那是对努力工作且绩效优秀同学的最大不公平。

在 2010 年，马云的年终邮件中有提到明确的「奖励观」：「奖金不是福利，奖金是通过努力挣来的。它不可能人人都有的，也不可能每个人都一样。它不是工资的一部分，而是因为你的业绩超越了公司对你的期望值。」

奖金不是福利，一定是根据公司效益和员工的具体表现来分配的，这里的关键词是公司效益、具体表现、分配。

对于奖金，我们需要对几个要素有清晰的认识：公司效益、个人具体表现和分配公平性。

首先，公司效益是决定年终奖池大小的基础。如果公司当年的经济效益不佳，或许连年终奖的发放都成问题。因此，我们需要意识到年终奖并非理所当然，其前提是公司有足够的盈利来支配这部分额外的支出。

接着，个人具体表现的考核是确保奖金分配合理性的关键。一般而言，公司会根据我们的 KPI 完成情况、项目贡献、团队合作等多个维度来评估其年度表现。为了确保公平，这些评估标准应该是事先明确、透明，并且对所有员工一致适用的。多说一句，标准是透明的，但是评估是主观的。

最后，分配公平性是维持团队士气的重要因素。大家对年终奖的期待与其自身的付出紧密相关。如果分配过程中出现了明显的不公平现象，比如同样努力的员工因为非业绩因素（如办公室政治）而获得不同的奖金，这会破坏团队的凝聚力和大家的工作积极性。

除了以上三个点，一些大一些的公司还会有部门绩效、项目绩效或奖金分配等。比如最近流出来的腾讯年终奖的情况，一些好的部门或项目其年终奖会比一般的部门多好几倍。

年终沟通

为了更好地沟通和管理年终奖，有一些建议或许可以帮助到技术团队管理者：

1. 提前沟通: 年初就应该向团队明确年终奖的评定标准和分配机制，确保透明度，让员工知道如何通过自己的努力影响年终奖的结果。这其实有些理想化，一般的公司都会有一个年终奖分配的「潜规则」。
2. 过程中的表现反馈: 定期与员工进行一对一的绩效回顾和沟通，帮助他们了解自己当前的表现并给予改进的指导，持续的管理好预期。
3. 客观评估和主观绩效: 有一套公正、客观的绩效评估体系，尽量减少主观判断的干扰，但是对于绩效和最终的结果是主观的判断。
4. 差异化奖励: 明确表达公司鼓励高绩效的文化，让员工理解奖金与个人表现的直接关联。
5. 情感管理: 预见到可能会有不满情绪的出现，应该准备好如何处理员工的情绪反应，并给予合理的解释和心理支持。对于一线同学，尽量是至少 N + 1 层的年终沟通。

小结

从激励的逻辑来看，年终奖作为一种延迟满足的激励手段，充分利用了期望理论中的「预期」和「价值」两个构成要素。

当我们对于可能获得的年终奖持有预期，并对此投入更多的工作努力，因为这种潜在的奖励具有较高的价值。这种预期会激活我们的内在动机，驱使我们在日常工作中追求卓越，从而实现个人的职业发展和提升工作绩效。

年终奖的期待也创造了一种正向反馈循环，即我们知道我们的额外努力不仅受到认可，而且会在年底得到实质性的奖励，这进一步加强了工作动力。

在更深层次的意义上，年终奖体现了公司对员工贡献的尊重和价值的认可，从而与员工建立起一种基于信任和相互尊重的关系。

这种关系超越了简单的工资交换，而是基于对员工全年工作的综合评价和公司整体成果的共享。

因此，年终奖不仅仅是一种物质上的奖励，更是一种精神上的鼓励，它传递了公司对员工的关怀和对团队努力的认可，这种认可在无形中强化了员工的自我价值感，激发了他们对于未来工作的热情和对组织的忠诚。

简而言之，年终奖既是对过去的肯定也是对未来的投资，它将个人的成就与组织的目标紧密地结合在一起，促使个体与集体同步向前发展。

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

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

如果把这些事项都当作一个项目来看的，这些项目中有三个主要角色：发起人（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. 核心成员过多： 如果核心成员过多，可能会导致沟通和协调变得复杂，影响项目的推动。合理管理核心成员规模和结构，或者建立有效的大型团队管理策略，可以帮助解决这个问题。

其它坑

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

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

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

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

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

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

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

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

成为问题解决者

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

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

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

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

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

同时，我们需要主动地与团队其他成员，甚至是来自其他团队的同事沟通交流，分享我们的发现和思考，听取他们的意见和建议。这将帮助我们从不同的角度看待问题，可能会发现一些我们之前未曾注意到的解决方案。也可以问问 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. 增强信息保护意识：作为一个好传声筒，个人在处理信息时会更加注重信息的安全和隐私，增强了信息保护意识。

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

小结

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

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

如何有效的管理团队已经成为企业成功的关键因素之一。特别是在技术团队，在管理过程中都面临一些共性问题，如沟通不畅、目标不明确、流程混乱、人才流失等等。这些问题在很大程度上影响了团队的效率和产出。

针对这些问题，我们将在本文中探讨什么是团队，团队的发展过程，以及如何有效的管理团队。

1 什么是团队

1.1 定义团队

从定义上来看，团队是为了达成某一承诺的共同目标而相互协作的一群人。

团队可以被定义为一组由个体组成的实体，这些个体共享共同的目标，对其达成负有责任，并通过相互协作以实现这些目标。这个定义包含了团队的两个关键特性：目标的共享性和协作的必要性。

1. 共享的目标：团队的成员都应该对共同的目标有清晰的理解，并对达成这些目标有共享的承诺。这可能是完成一个项目，解决一个问题，或者达到一个业绩目标。这种对目标的共享理解和承诺为团队提供了方向，并保证了所有成员都在努力的推动团队向着同一方向发展。
2. 相互协作：团队的成员需要通过相互协作来达成这些目标。这可能涉及到分工协作，相互学习，以及共享资源和信息等行为。相互协作不仅可以提高团队的效率，也能促进团队成员之间的关系，增强团队的凝聚力，从而提高团队的整体效能。

除此之外，还有相互依赖、尊重、信任和有效的沟通。

1.2 团队是一个开放系统

从整体上来看，团队是个动态复杂的开放系统

团队是由多个相互依赖、相互影响的部分组成的，这些部分包括团队的成员、团队的结构、团队的目标，以及团队的工作流程等。团队的各个部分都是动态的，都会随着时间和环境的变化而变化。其拆解来看可以分为三部分：

1. 动态： 团队的状态和行为会随着时间改变。这可能是由于团队成员的交互、团队成员的更换、新的任务或目标的设定，或者团队成员的个人成长和发展。

2. 复杂： 团队的行为和效能不仅取决于个体成员的行为，还取决于这些成员之间的交互和关系。因此，理解和管理团队需要考虑到这种复杂性。

3. 开放系统： 团队不是孤立存在的，而是和周围的环境相互作用的。这可能包括其他团队、组织的其他部分、组织的领导、客户、供应商、法规和社会文化等。这些外部因素都可以影响团队的行为和效能。

1.3 团队组成框架

从组成框架来看，团队包括 PCP、SCP 和 ICP 三个层面

任务程序（PCP）、社会程序（SCP）和个体程序（ICP），这三个层面共同构成了团队的基本框架，它们互相交织、互相影响，共同推动了团队的运行和发展。

1. 任务程序（PCP）：任务程序是团队为了实现共同目标而进行的工作流程和规范。这可能包括任务分配、决策制定、问题解决等一系列的工作程序。一个有效的任务程序可以提高团队的效率，确保团队的工作有序进行，帮助团队成功地完成其目标。
2. 社会程序（SCP）: 社会程序是团队中的人际交往和沟通方式，它决定了团队内部的氛围和文化。有效的社会程序可以增强团队的凝聚力，提高团队成员的工作满意度，促进团队成员之间的良好关系。一些如决策程序、冲突解决机制和团队建设活动等，都是社会程序的重要组成部分。
3. 个体程序（ICP）:个体程序是指团队成员各自的行为模式和工作方式，它受到各个成员的个性、技能、经验等因素的影响。团队成员的个体程序会影响到团队的整体效能，因此，管理者需要关注团队成员的个体程序，尽可能地提供适合各个成员的工作环境和条件，以发挥他们的潜力。

总的来说，团队可以被视为一个由任务程序、社会程序和个体程序共同构成的复杂系统。这个系统中的各个部分都是相互关联、相互影响的，只有当这三个部分都有效地运作时，团队才能够高效地运行，成功地实现其目标。

2 团队管理的发展过程

我们常用的团队模型包括 Bruce Tuckman 的团队发展模型，Hersey-Blanchard 情境领导理论，Drexler/Sibbet 团队绩效模型。这三个模型各有偏重：

• Tuckman 的模型主要是为了解决团队成长过程中的冲突和团队动态问题。它帮助团队理解团队发展的自然进程，并通过理解各个阶段的特点，来更好地应对团队中出现的冲突，提高团队合作的效率。
• Hersey-Blanchard 模型的重点是领导风格如何应对团队成员的成熟度变化。它主要解决的是领导者如何根据团队成员的成熟度和能力级别，灵活地改变自己的领导风格，以激励团队成员，提高团队效能。
• Drexler/Sibbet 模型着重于团队的任务完成和效能提升。它解决的主要问题是如何通过明确的目标设定、建立信任、承诺和高效协作，帮助团队在完成任务的过程中提高效率和效果。同时，它也强调了团队在项目结束后的反思和更新。

这里我们主要是根据 Bruce Tuckman 的团队发展模型来看团队的发展过程。

2.1 团队发展模型

Bruce Tuckman 的团队发展模型是一种描述团队从最初形成到最终达到高效运作的理论模型。这个模型最初在 1965 年被 Tuckman 提出，原本包含四个阶段：形成、激荡、规范和执行。然后，在 1977 年，Tuckman 和 Mary Ann Jensen 添加了第五个阶段：解散/休整。

以下是这五个阶段的详细描述：

2.1.1 形成阶段

在形成阶段，团队成员刚刚被组织在一起，他们可能对团队的目标、结构和领导者感到不确定或不安。成员们可能会表现得比较矛盾，既希望被接纳，又害怕过度投入。通常，成员们会对领导者寻求指导和明确的指示。

在此阶段，主要解决的问题是团队成员的熟悉和初步建立关系。团队成员可能会对彼此、团队的目标和期望、以及他们在团队中的角色感到不确定。这个阶段要解决的问题包括：

• 什么是我们的团队目标？
• 我们每个人的角色和职责是什么？
• 如何分配和管理任务？
• 我们的工作流程和通信方式是什么？
• 我们如何决定和解决问题？

针对这些问题，我们有一些常用的应对策略：

• 生命地图：这是一种让团队成员分享他们的个人历史和经验的方法，让大家更好地了解彼此，建立信任和熟悉度。
• MBTI：MBTI（Myers-Briggs Type Indicator）是一种性格类型指标，由凯瑟琳·库克·布里格斯和她的女儿伊莎贝尔·布里格斯·迈尔斯在二十世纪中叶创立。这种指标基于荣格的心理类型理论，用于评估个体的性格特质和倾向。通过使用 MBTI，我们可以理解团队成员的个性类型，这有助于增进团队内的理解和接纳。
• 团建活动：通过组织团队建设活动，我们可以通过共享的经验和挑战来增强团队的凝聚力。俗一点，喝点小酒不错，不俗一些，可以一起搞点事情，比如一起解决某个问题。
• 新成员欢迎仪式：通过举行欢迎新成员的仪式，可以让新成员感到被接纳和重视。
• 团队画像：提供一个框架，帮助团队成员理解和识别团队整体特征、动态和关系的工具。它可以是一幅图像，一张图表，或者一个模型，描绘出团队的结构，成员的角色，团队的目标，以及团队中的关系和互动等。

2.1.2 激荡阶段

在激荡阶段，随着团队成员开始表达个人观点，冲突可能会开始出现。团队成员可能会对团队的目标、任务分配、工作方法或团队的领导产生分歧。这个阶段可能会有所挫折，但也是团队发展的重要阶段，因为它可以帮助清晰地定义团队的方向和结构。

在此阶段，主要解决的问题是团队内部的冲突和分歧。团队成员可能会对团队的目标、工作方式或他们在团队中的角色产生分歧。这个阶段要解决的问题包括：

1. 职责和角色的定义：团队成员对自己的角色和职责是否有清晰的认识？是否存在角色冲突或不清晰的地方？

2. 决策制度：团队有明确的决策流程吗？谁有权做重要决定？团队成员是否对这一流程感到满意？

3. 沟通效率：团队的沟通是否畅通？是否存在信息传递不准确或不完全的情况？

4. 冲突解决机制：团队内部出现冲突时，有明确的解决机制吗？成员们是否知道如何提出和解决问题？

5. 团队文化和价值观：团队的价值观是否明确？成员们是否接受并认同这些价值观？

6. 信任和尊重：团队成员之间是否存在足够的信任和尊重？是否有开放的、支持性的环境，让成员们能够表达自己的观点和感受？

7. 团队合作：团队成员是否能有效地合作？是否有明确的工作流程和配合机制？

针对这些问题，我们有一些常用的应对策略：

• 团队委任状：通过明确团队的目标、角色和工作方式，可以帮助团队达到一致。
• 团队原则：团队成员共同确定的行为准则和期望，这有助于他们更有效地协作。
• 1 对 1会议：通过私人会议，可以促进直接的沟通和反馈，增强信任和理解。
• 情感银行：通过积极的行为和互动，可以建立和保持信任，这是团队协作的重要基础。
• 处理冲突：使用各种冲突解决策略来处理团队内部的分歧和冲突。
• 建设性反馈：团队成员需要学习如何提供和接受反馈，这对改进工作效率和团队关系至关重要。
• 双赢思维：鼓励团队成员寻找既能满足所有人需要又能满足个人需求的解决方案。

2.1.3 规范阶段

在规范阶段，团队成员开始解决在激荡阶段出现的冲突，并开始建立更深的相互理解和协作。团队成员开始对团队的目标、角色和工作方式达成一致。团队凝聚力增强，团队成员开始更加尊重彼此，建立更强的关系。

在此阶段，主要解决的问题是团队的凝聚力和工作方式。团队成员开始形成一种共享的工作方式和行为准则。这个阶段要解决的问题包括：

1. 如何建立并维护有效的团队规则和行为规范？
2. 如何设计和实施有效的沟通机制以保证信息的准确及时传递？
3. 如何提供具体且有效的反馈，促使团队和个人的持续发展？
4. 如何监控和调整团队的工作效果以及内部的关系和氛围？
5. 当团队或个人取得成就时，应如何进行有效的庆祝和认可以提高团队的凝聚力和动力？

针对这些问题，我们有一些常用的应对策略：

1. 创建并传播团队原则和规则：建立清晰、明确的团队原则和规则是创建健康团队文化的关键。这些原则和规则应该包括团队的使命、价值观、行为标准以及决策流程等内容。所有团队成员都应参与到创建过程中来，这样可以确保这些原则和规则得到大家的认同。一旦原则和规则确定，就需要通过各种方式（比如团队会议、内部通讯等）在团队中进行传播，并在日常工作中持续实施和维护。

2. 提供及时的反馈并处理冲突：反馈是提升团队效率和效果的重要工具。建设性反馈应该是具体的、积极的，旨在帮助团队成员改善工作效果和个人发展。1 对 1的沟通机制可以提供一个私密的环境，让团队成员能够分享他们的观察、想法和感受。如果出现冲突，应立即进行处理。处理冲突的过程应以理解和解决问题为目标，避免指责和争吵，寻求双赢的解决方案。

3. 庆祝成功和成就：庆祝仪式是提高团队士气和增强团队凝聚力的有效方式。当团队或团队成员达到一定的目标或取得了显著的成就时，应进行适当的庆祝和认可。庆祝的方式可以多种多样，比如组织团队聚餐、颁发证书或奖杯、公开表扬等。重要的是，庆祝应该是真诚的，要让团队成员感到他们的努力和贡献得到了认可。

2.1.4 执行阶段

这是团队发展的最后一个阶段，团队已经达到了高效运作的状态。在这个阶段，团队成员能够自我管理，解决冲突，并且能够有效地完成任务。团队的目标已经很清晰，所有的团队成员都对此有深入的理解，他们都为达成这个目标而努力工作。

在此阶段，主要解决的问题是团队的效能。团队已经形成了一种有效的工作方式，并且能够高效地完成任务。这个阶段要解决的问题包括：

• 如何保持和提高团队的效能？
• 如何适应和应对新的挑战和变化？
• 如何确保每个人都能持续地学习和发展？

针对这些问题，我们有一些常用的应对策略：

• 教练技术：通过使用教练技术，可以帮助团队成员提高他们的技能和效率，从而提高团队的效能。
• 更新团队规则：团队的发展和变化可能需要我们更新团队的工作方式和期望。
• 授权：团队领导人可以让团队成员有权做出决策，这样他们能更好地完成任务和承担责任。

2.1.5 休整阶段

这是 Tuckman 和 Jensen 后来添加的阶段。在这个阶段，项目或任务完成后，团队开始解散。团队成员可能会对团队的解散感到不安，尤其是当他们在团队工作中建立了强烈的归属感和相互依赖时。这个阶段的关键是确保团队的努力和成果得到认可，同时支持团队成员进行过渡。

在此阶段，主要解决的问题是团队的结束和转变。当团队的任务或项目结束时，团队可能需要解散或进行重组。这个阶段要解决的问题包括：

• 如何处理团队成员的情绪和反应？
• 如何确保团队的知识和经验能够被保留和传递？

需要注意的是，这个模型并不是严格线性的，团队可能会在不同的阶段之间来回移动，甚至可能会跳过某些阶段，或者同时具备两个或多个阶段的特点。

2.2 领导者的成长阶段

以上是团队的发展过程，对一个团队的管理者来说，也有一个类似的发展过程，用《礼记·大学》中我们特别熟悉的一句话来概括就是：「修身齐家治国平天下」。这是一句讲自我修炼，一生成就的四个阶段，将其映射到团队领导者的成长上看，也是适用的。

1. 修身（个人）： 在这个阶段，重点是发展个人能力。这包括技术知识、专业技能、时间管理、沟通、解决问题的能力等。个人也需要建立自我驱动和自我学习的习惯，这样他们可以不断地学习新的技能和知识。

2. 齐家（团队）： 当从个人转向团队的角色时，需要发展一种新的技能集。这包括领导力、决策能力、团队建设、冲突解决、激励和教育团队成员等。领导者需要从个体视角转向集体视角，思考如何提高团队的整体效能，而不仅仅是提高个人的产出。

3. 治国（组织）： 当领导者从团队管理转向组织管理时，他们需要开始考虑更为复杂的问题。这包括组织战略、组织结构、文化建设、财务管理、风险管理等。领导者需要考虑如何建立和维护一个高效、稳定、健康的组织。

4. 平天下（行业/社会）： 在这个阶段，领导者需要考虑他们的组织如何影响更大的社会和行业环境。这涉及到公共政策、行业标准、社会责任等问题。领导者需要考虑如何利用他们的影响力来推动行业的发展，以及如何通过他们的决策和行动来产生积极的社会影响。

每一个阶段都需要领导者具备不同的技能和认知，领导者需要根据不同的角色和责任来适应和发展。

3 有效的团队管理

有效的团队管理是指通过一种系统化的方式，领导一个团队，运营之，以实现既定的目标。这包括以下几个关键要素：

1. 明确的目标：团队需要有一个明确和共享的目标或愿景，以指导其工作和决策。

2. 卓越的领导：团队需要有一个或多个能够激励和指导团队的领导者。这包括设定明确的期望，提供反馈，处理冲突，以及帮助团队应对挑战。

3. 明确的角色和责任：每个团队成员需要明确他们的角色和职责，以确保所有的任务都能得到有效的处理。

4. 良好的沟通：团队需要有良好的沟通机制，以促进信息和想法的分享，解决问题，以及提高团队的协调性和效率。

5. 有效的系统和流程：团队需要有一套有效的系统和流程来支持其日常运作。这可能包括决策制定的流程，任务管理的工具，以及反馈和评估的机制等。

6. 良好的团队关系：团队成员之间需要有良好的工作关系，以提高团队的凝聚力和满意度。

将其概括一下，就是包括方向，领导力、角色分工、系统、沟通和关系六个方面。这六点是基础，在此基础上，有效的团队管理也需要有适应性和灵活性，以应对不断变化的环境和挑战。这可能包括调整团队的目标，改变工作方法，以及提供持续的学习和发展机会等等。接下来我们从这六个方面来阐述如何有效的管理团队。

3.1 方向

带团队如大海行舟，方向是第一要务。为什么要有方向，因为当所有人都对方向有共同的理解，并且同意并承诺支持这个方向时，他们有更大概率的有效地合作，并积极地向目标前进。

方向主要关注三个问题：团队的目标和战略是否明确？每个团队成员是否理解并认同这些目标和战略？团队的目标是否需要随着环境的变化进行调整？

方向在团队管理中非常重要，原因有以下几点：

1. 共享目标：一个明确的方向为团队提供了一个共享的目标或愿景。这可以帮助团队成员理解他们的工作为何重要，以及他们的努力如何帮助团队实现其目标。

2. 决策指导：方向也提供了一个框架，用于指导团队的决策和优先事项。团队成员可以根据团队的目标来决定他们应该如何分配资源，选择哪些任务，以及如何执行这些任务。

3. 提高凝聚力：当团队成员对团队的方向有共同的理解和认同时，他们可能会感到更加投入和满足。这可以提高团队的凝聚力和满意度。

4. 提供动力：明确的方向也可以为团队提供动力。团队成员知道他们正在追求的目标，了解他们的工作如何贡献于这个目标，这可以激发他们的积极性和热情，将从被动执行任务变为主动推动目标的实现。

5. 测量进度：最后，方向可以帮助团队测量其进度和成效。通过比较当前的状态和目标，团队可以了解他们在实现目标方面的进度如何，以及他们是否需要改变策略或方法。

在我们做战略沟通，或者在探讨方向时，需要考虑以下三个方向：

• Why：为什么我们要这样做？这通常涉及到组织的使命、愿景或核心价值观。
• What：我们要做什么？这是具体的目标或战略。
• How：我们如何做到这一点？这包括实施战略的具体步骤或方法。

要想达成方向的一致，有许多方法，我们常用的方法如下：

1. 一对一讨论： 领导者可以与每个团队成员单独会面，讨论并达成共识。

2. 集体共创： 可以组织工作坊或大会，让所有人都有机会参与讨论和决策。

3. 单方宣导： 在某些情况下，领导者可能需要明确阐述他们的观点，并期望团队成员接受和支持。

无论选择哪种方式，最重要的是确保每个人都有机会表达他们的观点，并且他们的观点被认真考虑。这样才能保证达成真正的共识，而不仅仅是表面的一致。

3.2 领导力

经常有人说「领导者决定了团队的基因」，这说明领导者的行为、决策、态度、价值观和领导风格对团队的特质和行为有着重大影响。就像基因决定了生物的特性一样，领导者的特质和行为也可以决定团队的「特性」。其主要体现在以下 4 个方面：

1. 设定价值观和期望：领导者通常会设定团队的价值观和期望，这些价值观和期望形成了团队文化的基础。例如，如果领导者重视创新和风险承受能力强，那么团队可能也会发展出一种鼓励尝试新事物和接受失败的文化。

2. 塑造行为和决策：领导者的行为和决策模式对团队成员有示范作用。例如，如果领导者以开放和透明的方式进行决策，那么团队成员也可能会采取同样的方式。

3. 激励和驱动：领导者通过他们的激励策略影响团队的动力和表现。如果领导者激励团队成员追求卓越和持续改进，那么这可能会成为团队的一个核心驱动力。

4. 选择和发展人才：领导者在招聘和发展人才方面的决策也会影响团队的特性。例如，如果领导者倾向于招聘具有强烈团队精神和合作能力的人，那么整个团队可能也会具有这些特性。

在领导者改变团队的过程中，领导的领导力是一个非常重要的因素，在团队管理和组织成功中扮演着重要的角色。

当你在管理岗位上时，看看以下的一些陷阱你有没有遇到过：

1. 过度放权或忽视领导职责：领导者有时可能会过度放权，以至于放弃了领导权力，并忽略了团队管理的各种要素，如ICP/SCP/PCP（Input/Control/Process）。可能过于乐观地认为，只要给团队足够的自由，一切都会按计划进行。然而，这是一种误解。领导者不仅要放权，还要根据团队的成熟度正确使用权力，以及情景管理。我们应该与团队一起工作，帮助解决难题，而不是完全放手。

2. 以自我为中心，忽视团队需求：领导者可能过于关注自己的想法和目标，而忽视了团队的需求和感受。可能把人性假设得太理想化，缺乏对团队的爱和耐心。领导者应该以团队的理解和需求为出发点来进行沟通和赋权。他们也应该愿意为提高团队的能力付出努力，包括必要时进行人员调整。

3. 过度依赖自我思考，忽视团队输入：领导者可能会认为自己已经清楚了解了所有问题，结果导致团队成员只是执行者，没有参与决策的机会。这种做法可能会阻碍团队成员的发展和创新。领导者应该把团队成员视为平等的伙伴，愿意花时间进行沟通和同步，并相信他们具有巨大的潜力。

4. 过度参与执行，忽视领导职责：有些领导者可能过于关注执行任务，以至于忘记了他们的领导职责。他们可能会在周会上跟进每项任务，但忽视了作为领导者的责任，包括设定战略，提供支持，和激励团队。领导者应该意识到他们是团队的扩大器，他们的主要职责是领导和赋能，而不仅仅是执行任务。

5. 避免冲突：领导者可能会避免处理团队之间的冲突，以希望保持和谐。然而，未解决的冲突可能会升级，影响团队的士气和效率。领导者应该勇于面对和解决冲突，而不是避开它。

6. 过度承诺：有些领导者可能会对团队成员或者与他们合作的人过度承诺，这可能会导致资源过于紧张，或者在无法达到承诺的时候失去信任。领导者应该明白他们的能力范围，并理性地做出承诺。

7. 忽视个人发展：领导者可能过于专注于团队的目标，而忽视了他们自己的个人成长和发展。这可能导致他们的技能和知识变得过时，无法有效地领导团队。领导者应该意识到，他们自己的发展同样重要，他们需要不断地学习和提高。

8. 忽视人才培养：领导者可能过于关注短期的目标，而忽视了人才的培养。这可能导致团队的长期发展受到限制。领导者应该投资于人才的培养，为团队的未来做好准备。

9. 抵制变革：领导者可能对变革持防御态度，尤其是当这些变革可能影响他们的权力和舒适区时。然而，变革是必要的，领导者应该积极接受并驱动变革，以变化应对不断变化的环境。

每个领导者都可能面临这些陷阱，关键在于认识到它们，然后采取行动来避免或者克服它们。避免这些陷阱需要领导者具有深度的自我认识，对团队的尊重和理解，以及对长期目标和策略的清晰理解。

那么，领导力是什么？

领导力是一种复杂的能力，包含多个层面。领导作为团队绩效的放大器，他们的作用和影响占团队成功要素的 70%，他们的角色既不是独自承担所有工作，也不是放任不管，而是负全责。领导力有一个基本框架，可以分为以下 6 个层面：

1. 战略层面：这涉及到制定和实施长期目标和策略，以及识别和适应外部环境的变化。领导者在这个层面需要展示出前瞻性和战略性思考。

2. 人际层面：这涉及到与团队成员、客户、合作伙伴等各方进行有效的沟通和协作。领导者在这个层面需要展示出强大的沟通、协调和冲突解决能力。

3. 任务层面：这涉及到设置和实现具体的目标，以及管理和分配资源。领导者在这个层面需要展示出强大的组织、规划和执行能力。

4. 发展层面：这涉及到培养和发展团队成员，以及自我学习和成长。领导者在这个层面需要展示出教育、指导和激励他人的能力，以及开放性和学习意愿。

5. 情绪层面：这涉及到理解和管理自己和他人的情绪。领导者在这个层面需要展示出较高的情商，包括自我意识、自我管理、社会意识和关系管理。

6. 变革层面：这涉及到驱动和管理变革，以适应不断变化的环境。领导者在这个层面需要展示出创新思维、灵活性和适应性。

换成宝洁的 5E 领导力模型来描述，即：高瞻远瞩(Envision)，凝聚他人(Empower)，发展他人(Encourage)，激励人心(Educate)，和高效执行(Evaluate)。

1. 高瞻远瞩（Envision）： 领导者需要有构建愿景的能力，能够给整个组织指明方向，激发团队内心的激情。好的愿景应该符合外部市场、用户和业务现阶段的需求，有足够的力量解决业务目前面临的根本问题，并且不只是口号，而要有实际的行动路线。要设计一个好的愿景，可以参照行业标杆，找出关键路径，建立 KPI。领导者需要清晰、有说服力地表述这个愿景，并展示出他们如何带领团队实现这个愿景。

2. 凝聚他人（Engage）： 领导者需要将员工、同事、客户甚至老板纳入自己的愿景达成梯队，让每个项目的所有参与者都把这个项目当成重要的项目。在这个过程中，需要保持开放的沟通，同步进展和规划，让每个人都有机会了解项目的全局情况并参与其中。这包括倾听他人的观点，尊重和理解他们的需求，以及鼓励他们在实现共同目标的过程中扮演积极的角色。

3. 发展他人（Enable）： 领导者需要确保团队有信心、有能力、有精力来做好自己的那部分工作。这包括提前告知工作需求和意义，提供全面的信息，及时提醒需要的方向调整，以及在可控的范围内给予团队犯错和改进的机会。

4. 激励人心（Energize）： 无论困境逆境，领导者需要保持团队的斗志。这可以通过保持积极的态度，使用幽默来化解压力，及时庆祝小胜利，反馈表扬，以及了解并回应每个人的想法来实现。

5. 高效执行（Execute）： 领导者需要保证任务的完美执行。这包括梳理工作，做好分配和排期，让每个人都有机会参与，不遗余力地寻求帮助，以终为始，及时检查里程碑，以最终体验为目标。

作为一名领导者，需要持续的自我反思和对团队的深深关爱，时刻反思 ，时刻反思自己的行为和决定，以确保它们都是以团队的最佳利益为导向的。这意味着你需要放下自我，优先考虑团队的需求和利益。在决策时，你需要考虑的是决策对团队的影响，而不仅仅是对自己的影响。此外，你需要建立一个开放和透明的环境，鼓励团队成员提供反馈，以帮助你更好地理解他们的需求和期望。

同时许以 严格的爱。严格的爱是建立在对标准、规则和期望的坚持上的。这意味着你需要设定明确的期望，使团队知道他们需要达到什么样的标准。你也需要坚持规则和程序，确保所有的工作都按照既定的方式进行。同时，你需要提供及时和具有建设性的反馈，帮助团队成员理解他们需要如何改进。在这一过程中，你也需要给予团队成员必要的支持和关心，以帮助他们达到这些标准。

如 Python 中的「鸭子模型」：如果一个对象能够完成你需要的操作（也就是它“走起来像鸭子，叫起来像鸭子”），你就可以把它当作鸭子来对待（即不在乎它的真实类型或类别）。

如果你像领导者一样思考，像领导者一样讲话，像领导者一样行动，那你就是一个合格的领导者。

3.3 角色和分工

在有效的团队管理中，角色和分工十分关键。明确的角色和分工可以确保团队的高效运作，减少重复工作和冲突，同时也能让每个团队成员明确自己的责任和期望。

首先，我们需要根据团队的战略和核心任务来规划组织结构，即「先岗再人」的原则。这一步包括：

1. 基于战略和核心任务的组织规划：在招募团队成员之前，我们需要首先明确团队的目标和任务，以确定所需的角色和这些角色在组织中的位置。

2. 任务性质和管理范围的团队分工和分层：根据任务的性质和管理范围来决定团队的结构和角色分配。这样可以帮助每个人清楚地理解他们的职责和与其他团队成员的关系。理解团队分工和分层就像是在打造一支足球队。首先，你需要了解比赛的规则和每个位置的特点（任务性质）。例如，守门员的任务是防守，而前锋的任务是进球。然后，你需要决定哪个球员去打什么位置（团队分工）。这取决于他们的技能和才能，以及他们与其他球员的协作方式。你还需要了解每个位置在球场上的位置（管理范围）。例如，队长可能需要管理全队的战术，而边锋可能只需关注自己的区域。最后，你需要明确哪些位置是领导位置，哪些位置是执行位置（团队分层）。例如，队长和教练需要做战略决策，而前锋和中场球员需要执行这些决策。

3. 明确关键岗位：我们需要确定哪些是关键岗位，这些岗位在实现团队目标和任务上起着决定性的作用。

接着，我们要遵循「强将精兵高产出」的效率原则，以提高团队的效率：

1. 强将是核心：强将被视为团队或组织的核心，因为他们拥有推动力、领导力、专业知识和技能，同时他们的行为和态度常常被其他团队成员视为模范。他们不仅能推动团队前进，提供专业的解决方案，还能通过他们的领导力引导和协调团队的工作。另外，他们的存在为团队提供了稳定性和信任，特别是在面对挑战的时候，他们的冷静和果断能帮助团队保持稳定并继续前进。

2. 精兵至关重要：精兵是团队或组织的重要组成部分，他们的专业技能、执行力、稳定性和团队协作能力对于团队的成功起到了关键的作用。他们不仅能以高效和质量的方式完成任务，提升整个团队的效率，也通过他们的纪律性和可靠性为团队提供了稳定性。同时，他们的协作精神让他们能够与团队中的其他成员携手合作，共同推动团队的进步。并且，他们的专业性和忠诚度也使他们成为未来领导角色的有力候选人。

最后，当团队规模越大，结构越复杂时，我们更需要重视核心团队的建设和分层管理，以形成像涟漪一样向外扩散的效应，拆解下来分为三个关键点：：

1. 核心团队的建设：随着团队规模的扩大和结构的复杂化，建设一个强大的核心团队变得越来越重要。核心团队的成员应具有关键的角色或岗位，并且能够对组织的目标和决策产生直接影响。

2. 分层管理：应使用分层管理的方式来应对团队规模的增长和结构的复杂化。每一层都有自己的职责和管理者，以保持信息流和决策过程的效率。

3. 涟漪效应：一个强大的核心团队和有效的分层管理系统可以在整个组织中产生积极的影响，就像在水面上投下一颗石子会产生涟漪一样。可以提高整个团队的效率和生产力。

随着团队规模的增长和结构的复杂化，我们应更加重视核心团队的建设和分层管理，以实现有效的组织管理和协同工作，从而产生涟漪效应，提高整个团队的效率和生产力。

3.4 系统

这里的所说的系统是一种整体观念，强调整体大于部分之和，部分之间的互动关系对整体的性质和功能有决定性的影响。以系统观来解决问题。

系统可以理解为一套组织的流程、规则和机制，这些流程、规则和机制协同工作，以实现组织的特定目标。系统观强调整体性和协同性，而不仅仅是单个流程或机制。

有效的团队管理中的系统，包括了流程（如工作流程、决策流程）、规则（如政策、规章制度）和机制（如奖励机制、反馈机制）。这些元素相互关联，共同构成了一个整体，以实现团队的目标。系统的设计和实施主要是为了解决团队管理中的各种问题，如效率低下、信息流通不畅、决策错误、员工满意度低、团队目标达成困难等问题。

系统中的各部分都建议遵循目的、痛点、方案、行动的逻辑来走，这其实也就是我们之前聊过的解决问题方案中的第二类方法，深度分析类问题。

系统的建设和实施需要以下几个步骤：

1. 明确目的：首先，需要明确系统的目的，即希望通过系统解决什么问题，实现什么目标。

2. 识别痛点：然后，需要识别和分析现有的问题和痛点，这将为系统的设计提供依据。

3. 制定方案：根据目的和痛点，制定相应的流程、规则和机制。这可能包括重新设计工作流程，制定新的政策，或设置新的奖励机制等。

4. 实施行动：将方案落实到实际行动中，这可能需要培训员工，改变工作方式，或调整资源分配等。

5. 持续优化：在实施过程中，需要收集反馈，评估效果，然后根据结果进行调整和优化，使系统能够更好地服务于团队的目标。

这里的系统是指一系列的流程、规则和机制。今天我们主要简单聊一下流程和运营机制。

3.4.1 流程

对于流程建设，它的核心并不仅仅是管理者制定内部规章的过程，而更是一个机会，一个可以总结和提炼团队内部的最佳实践，同时也是管理者对于自身权力的一种约束。流程建设是将团队实践中的隐性知识沉淀为明文规定的最佳工具。

流程本质上是人与任务的有效组合。 它是为了完成特定目标或任务，人们进行的一系列逻辑相关的，跨时间和空间的活动集合。流程是将投入转化为产出的方法，通常包含三个组成部分：投入、转换活动和产出。具有系统观点的人会将组织视为一个流程，而不是各自独立的部门。

流程中的专责化的含义并不是专门的机构或者人员来负责团队所有的标准流程建设，而是谁负责工作，谁就应该负责流程的建设工作。流程建设是一种实践性的工作，源于实际工作，服务于实际工作。如果由专职人员负责流程，可能会导致一线管理者在责任上有所缺失。

流程是一个过程性的制度，需要在过程中发现问题，解决问题，并随着业务的发展和变化进行持续迭代。当某些流程不再适用时，我们需要主动发起优化，按照更优的方向优化流程，精简冗余的流程，追求极简。

一个组织实际上是由各种流程串联起来的。这些流程可能并不都是书面的，但一定隐藏在团队的常规操作和员工的习惯中。组织的工作效率在很大程度上受到流程的影响，组织的运行本质上就是业务流程的运行。

每个管理者都应该学会建立和优化流程。建立流程的目的是高效管理业务，让大家可以按照流程解决问题，尤其是跨团队的问题，而不是寻找人来解决；每件事情都可以按照流程来解决，而不是频繁的开会沟通。那么如何来构建有效的流程呢?

1. 从实际出发：流程建设应该是为了解决实际问题或提高某个事情的效率，而不是为了流程本身。比如，如果在人力调度问题上需要频繁地找各级领导开会讨论，明显存在效率问题。为此，我们可以制定一个人力调度的流程，明确需要提供的信息，哪些人需要讨论，哪些人需要审批等。在此之后，大家可以按流程执行，无需频繁地找各级领导开会。

2. 灰度执行：流程建设完成后，不应立即全面实施，而应该先在某个部门或业务部门进行试点，发现可能存在的问题，如流程的顺序、时限等，然后有针对性地对流程进行优化和完善，再逐步扩大试点范围，最后全面实施。这个逻辑和我们服务灰度的逻辑是一致的，尽量减少新变化的影响范围，使变化更好地落地。

3. 持续迭代：流程全面实施一段时间后，需要对流程进行复盘和回顾，而不是一旦流程建立就不再关注。例如，如果公司是从事 toC 业务，现行的研发流程是双周迭代，运行了一段时间。但现在，公司要转向 toB 业务，这时候就需要重新审视双周迭代的流程，看是否需要优化，以满足新的业务需求。

在流程的构建过程中需要注意不是所有的事情都需要建立流程，关键的流程能够大大提升团队的效率，在出现以下的情况时，我们就需要注意是否要创建新的流程或者优化流程了：

1. 刻意跟进的重要不紧急（突破创新）的事情
2. 多方共同参与，提升协同效率（流程/角色/决策等需要配置）
3. 日常的重复性工作

流程建设是一个动态的过程，需要管理者从实际工作出发，灰度执行并持续迭代，以达到提升工作效率，解决问题的目标。

3.4.2 运营机制

运营机制是一套规范团队运作的方法和流程，它解决的是如何有效管理和协调团队资源，以实现团队的目标。它的本质是制度和流程，它旨在提高团队的效率，减少混乱，提升团队的协作能力，以及适应环境的变化。

在有效的团队管理中，以下是关键的运营机制：

1. OKR 跟进：OKR（Objectives and Key Results）是一种目标设定框架，它明确了团队的目标（Objectives）和衡量目标实现程度的关键结果（Key Results）。团队需要定期跟进 OKR，以确保目标的实现。这个过程包括定期检查关键结果的进展，以及调整策略以更好地实现目标。

2. 常规基础工作：这是团队日常运营的重要组成部分，包括任务分配、项目管理、报告编制，以及其他常规的管理工作等。这些工作是确保团队正常运行的基础，也是团队能够有效执行其职能和达成目标的基础。

3. 处理突发问题/bug：在日常运营中，团队可能会遇到突发的问题或者 bug。团队需要有处理这些问题的能力，这包括快速定位问题，制定解决方案，并执行修复。这种能力不仅可以避免问题对业务造成影响，也是提升团队解决问题能力的重要方式。

除此之外，还有关于团队、领导和反馈的一些机制，详细内容在前面讲过，这里带一下：

1. 明确的角色和职责：一个高效的团队需要有一个核心团队，其中每个成员的角色和职责都应该明确。这可以确保每个人都明白自己的工作是什么，以及如何与其他团队成员协作。明确的角色和职责，可以提高团队的协作效率，也可以有效地避免工作的重复和遗漏。

2. 团队领导的责任：团队的领导者（Owner）是决定团队成功的关键因素。他们需要对团队的成功负责，这包括确定和维持团队的战略方向，做出关键的判断和决策，以及协调资源以支持团队的工作。适当的领导可以激发团队成员的潜力，驱动团队的创新和进步。

3. 定期的跟进和反馈：团队需要进行定期的跟进和反馈，这包括周度跟进和月度跟进，以及在关键节点的洞察。这些跟进和反馈可以帮助团队了解他们的进展，发现问题，并在需要的时候做出调整。定期的跟进和反馈，也是团队持续改进和学习的重要机制。

通过以上这些运营机制，团队可以确保目标的实现，日常工作的正常推进，以及在遇到问题时能够有效地解决。这也可以帮助团队建立一个明确的定位和团队精神，使成功成为一群人共同的事情。

从流程观到系统观，是一个从关注单个流程或机制，到关注整个系统如何协同工作以实现目标的转变。这需要明确目的，识别痛点，制定并实施方案，最后通过收集反馈和持续优化，以实现系统的最大价值。

有系统观的团队管理，能使团队运行更高效、更有序，有助于提高工作效率，减少错误，提升员工满意度，最终实现团队的目标。同时，通过系统的反馈机制，可以不断学习、优化和改进，从而实现组织的持续改进和发展。

3.5 沟通

在团队管理中，沟通是一个至关重要的组成部分。沟通是团队成员之间交换信息、观点、想法和感受的过程。沟通不仅仅是说出自己的想法，更重要的是倾听和理解他人的观点。在沟通过程中，我们应首先接纳对方的观点，然后再去理解。这样的沟通方式可能更容易促成有效的合作。

沟通从种类上来分，可以分为语言沟通或非语言沟通、口头沟通和书面沟通、正式沟通和非正式沟通，向上沟通、向下沟通和平级沟通等。

• 语言沟通或非语言沟通是从沟通的载体来区分，语言沟通包括书面沟通和口头沟通，非语言沟通包括面部表情，身体语言等；
• 口头沟通和书面沟通是从语言的载体来区分，口头沟通有会议、面谈、演讲、电话等，书面沟通有电子邮件、信函、刊物（电子和非电子）、报表、通讯录等传递书面文字的手段。口头沟通的特点是快速传递和反馈，但是可能传递过程中会失真，书面沟通更偏向于单向沟通、一般会缺少反馈且耗时较多。
• 正式沟通和非正式沟通更多的是在组织层面，通过是否具有系统性和结构性来区分。正式沟通是从组织所规定的路线和程序进行信息的传递和交流，如组织间的信函、内部的文件、汇报、会议等等；非正式沟通一般是线下的一些闲聊、喝酒时的吹牛以及一些小道消息等。
• 向上沟通、向下沟通和平级沟通，这里主要是以组织层级间沟通的对象为区分，以方向表述对象群体。向上沟通一般是指向你的老板沟通，即所谓的下情上达；向下沟通是指向你的下属沟通，即所谓的上情下达；平级沟通是指横向的沟通，如一些平级的部门负责人之间的沟通，以交接意见，互助互赢为主。

沟通的主要目的有几个方面。首先，沟通可以帮助团队的成员对团队的目标、任务、策略和进度有清晰的理解，这需要我们寻找合适的沟通「切入点」。其次，沟通也可以帮助解决可能出现的误解或冲突，这需要我们正确对待和处理抱怨。最后，沟通可以增强团队的凝聚力和合作精神，这需要我们建立完善的内部沟通机制，消除沟通障碍，确保信息共享，引导团队成员之间进行充分的沟通。

沟通在团队管理中的重要性不可忽视。首先，良好的沟通可以加强团队的协作效率，帮助团队成员更好地理解和接受团队的目标和策略。其次，通过沟通，我们可以及时发现和解决问题，避免小问题演变成大问题。此外，通过有效的沟通，我们可以建立一个开放、透明的工作环境，增强团队的凝聚力和合作精神。

有效的沟通方法包括以下几个方面：

1. 定期的团队沟通：可以通过团队会议，一对一的交谈等方式进行定期的沟通，以确保团队成员对团队的目标和策略有清晰的理解。

2. 寻找沟通的「切入点」：寻找合适的沟通「切入点」可以使沟通更为有效。这可能是一个共享的目标，一个共同关注的问题，或者一个相关的话题。

3. 消除沟通障碍：消除沟通障碍，确保信息的准确、及时和有效的传递。这可能包括明确的表达，有效的倾听，以及建立开放和透明的沟通环境。

4. 处理抱怨：对于抱怨，我们应该先理解抱怨的原因，然后提供有效的反馈，最后寻找和实施解决方案。

对于团队管理来说，需要建立有效的沟通机制。以下是一些常见的步骤和建议：

1. 明确沟通的目标：首先，我们需要明确沟通的目标，这可以帮助我们确定沟通的内容和方式。比如，我们的目标是提高团队的协作效率，还是解决具体的问题，或者增强团队的凝聚力。

2. 设定沟通规则：我们需要设定明确的沟通规则，这包括沟通的时间，方式，频率，以及参与的人员。规则需要根据团队的具体情况进行设定，比如，团队成员的地理位置，时间区域，工作方式等。

3. 选择合适的沟通工具：我们需要选择合适的沟通工具，以支持我们的沟通活动。这可能包括面对面的会议，电话，电子邮件，即时消息，视频会议，项目管理工具等。我们需要根据团队成员的需求和习惯，以及沟通的内容和目标，选择最合适的工具。

4. 提供沟通培训：我们可以提供一些沟通培训，以帮助团队成员提高他们的沟通技巧。这可能包括如何清晰的表达自己的观点，如何有效的倾听他人的观点，如何解决沟通中的冲突和误解等。

5. 鼓励开放和透明的沟通：我们需要鼓励开放和透明的沟通，让团队成员感到他们的观点和感受被尊重和接纳。我们可以通过设定安全和尊重的沟通环境，以及提供反馈和建议的机会，来实现这一点。

6. 定期评估和改进沟通机制：我们需要定期评估我们的沟通机制的效果，以便进行必要的改进。我们可以通过收集和分析沟通的数据，以及听取团队成员的反馈和建议，来进行评估和改进。

通过这些步骤，我们可以建立一个支持团队目标和策略，增强团队凝聚力和协作精神，以及应对变化和冲突的沟通机制。

3.6 关系

这里的关系不是指拉帮结派，而是涉及到团队成员之间的相互作用、感情、理解和信任。这些关系能够影响团队的凝聚力、合作效率和整体的工作环境。这包括团队成员如何沟通、如何协作、如何处理冲突，以及他们对彼此的信任和尊重程度。有效的团队关系不仅涉及到个体与个体之间的关系，也涉及到个体与团队，以及团队与其他团队之间的关系。

团队关系对于有效的团队管理来说非常重要，其意义主要表现在以下几个方面：

• 提高效率：当团队成员之间的关系良好时，他们更可能愿意共享信息，协作解决问题，这可以大大提高团队的工作效率。

• 增强凝聚力：良好的团队关系可以增强团队的凝聚力，使成员感到他们是团队的一部分，愿意为团队的目标努力。

• 提高满意度：当团队成员在工作中感到被尊重和被理解时，他们的工作满意度也会提高，这对于保持团队的稳定性和吸引优秀的人才非常重要。

• 创新和解决问题：良好的关系可以促进不同观点的碰撞，从而激发创新和解决问题。

建立良好的团队关系需要投入时间和努力，以下是一些有效的策略：

• 建立信任：信任是关系的基础，需要通过遵守承诺、公平对待所有成员、开放和诚实的沟通以及接受反馈来建立。
• 提供支持：团队领导应提供必要的资源和支持，帮助团队成员成功完成任务，同时也要关注他们的职业发展。
• 鼓励开放沟通：团队领导应鼓励开放、诚实和尊重的沟通，以确保所有成员都能够表达他们的观点和感受。
• 解决冲突：团队领导需要具备解决冲突的能力，以及确保冲突的有效解决。

一旦建立了良好的关系，就需要进行维护。以下是一些有效的策略：

• 定期沟通：团队领导需要定期与团队成员进行沟通，了解他们的需求和期望，解决可能出现的问题。
• 公正和一致：团队领导需要公正地对待所有成员，确保所有的决策和行动都是公平和一致的。
• 承认和奖励：团队领导应该承认和奖励团队成员的努力和贡献，以增强他们的满意度和投入度。

建立和维护良好的团队关系需要团队领导和成员的持续努力。在遇到破坏团队信任感的人，不能留，但用人不疑，疑人不用。团队关系在团队管理中起着关键的作用。通过建立信任、提供支持、鼓励开放沟通和有效解决冲突，我们可以建立和维护良好的团队关系，从而提高团队的效率，增强凝聚力，以及提高满意度。

4 团队有效性的评估和度量

当我们做了一些手段来优化团队管理的有效性，就需要有一个评估和度量的过程。以下是一个基于各种机制的团队系统有效性评估表。其分为五个主要类别：决策与目标设定、沟通与任务分配、报酬与激励、绩效评估、人才管理和日常运营。

1. 决策与目标设定

2. 沟通与任务分配

3. 报酬与激励

4. 绩效评估

5. 人才管理和日常运营

使用此评估表时，可以为每个项目打分，比如在 1-5 的范围内，其中 1 表示不满意，5 表示非常满意。然后对所有分数进行总结，得出总体评估结果。也可以将这些分数与其他团队或行业标准进行比较，以获得更深入的洞察。

后记

花老师说：你是爱自己还是爱团队？

一言以蔽之：搭班子、定战略、带队伍。

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

”

1. 自测质量差
2. 转测 BUG 多
3. 项目延期
4. 加班赶工
5. 高强度加班后，小伙伴状态不好，导致更多的问题出现

从第 1 点状况演变成第 5 种状况，第 5 点状况继续推动第 1 种状态的持续加强，从而导致整个团队的状态极差，陷入 BUG 多 –> 延期 –> 加班 –> BUG 更多 –> 更多的延期 的死循环。

除了上面的死循环，可能还会有一些非功能性的问题，如性能、扩展性问题等等。

当团队大时，还可能遇到有小团队，各小团队各行其事，各为其主，心不往一处，力不出一孔。 这些问题让技术团队的管理者焦头烂额。

那么如何解决这些问题呢？个人认为可以从以下 4 个方面来逐一思考和优化，从而在一定程度上解决这些问题。

1. 把正确的人放到合适的岗位

所有的执行最终都是落到人身上，有了正确的人，事情会事半功倍。 说到人，我们往往会提起人的「选用育留」，这是一个很大的题目，我们不做详细的讲述，只关注选和用的一小部分。

管理上有一个在大部分场景适用的套路：选拔优先于培养。 这个套路背后有两层逻辑：

1. 改变一个人太难，比如有些人就是懒，抽一鞭子动一下；又或者家境优渥，态度佛系，无欲无求，根本就是油盐不进；又或者玻璃心，安全感差，都很难搞；
2. 成本太高，即使这个人具备可培养性，但从 0 到 1 把一个人培养起来，时间成本太高，而管理者的时间很贵，公司等不起。

所以我们这里是选人，从现有的人中找到合适的，从人才市场找到合适的，能直接用的。

本小节主要是回答两个问题：

1. 正确的人是怎样的？
2. 如何把正确的人放到合适的岗位上？

1.1 选人

在人的层面，主要包括两个部分，执行者和管理者，这里管理者包括整个团队负责人自己。 不同的部分，要求不同，选人的标准也不同。去掉专业技能部分，去掉历史经验部分，我们希望我们的伙伴是这样的：

• 喜欢和投入：对于技术热爱，对工作有投入度，能够专注于自己手上的工作，找到成就感；
• 知道自己想要什么：有一定长远的规划，知道自己走在什么样的路上，不限于一时一城之得失；
• 一路人：认同企业的价值观，价值观认同其本质上是「人以群分」；
• 宁缺毋滥：如果实在没有人，宁缺毋滥吗？这是一个好问题，严格来说是这样的，但实际中往往我们会妥协一部分。

我们选人一个常见的问题是注重人当下的表现和历史的成绩，然而我们选人是要解决未来的问题，更要关注其潜力。 那么如何看一个人的潜力呢？如果具备以下的特性，大概率是一个有潜力的人：

1. 有意愿，什么叫有意愿，就是指一个人想变好，有内在的动机去追求更高的目标；这里扩大一些，还包含积极的态度、好奇心和进取心；
2. 有静气，特别是遇大事时有静气，临危不乱；遇到繁琐的事情能一步一步慢慢做好；
3. 有度，做事有度，知道做事的边界在哪，进展有度，但是并不是事事划边界，事事划边界显得格局太小，多数事情还是从大局着眼；
4. 能扛事，遇到事情找方法，不找借口，执行力强；
5. 有所为，天赋决定了能达到的上限，努力程度决定了能达到的下限。努力去做，有所为，并且 以现在绝大多数人的努力程度之低，还远远没有达到比拼天赋的程度。 这里的有所为不仅仅是做事，更多的是学习，不停地学习，提升自己。

1.2 用人

1.2.2 人才梯队

人才梯队从时间上看分为现在和将来。 现在是指盘点现有人才情况，梳理人才结构，对团队中的人进行分层，形成「梯状」。

当前状态的人才梯队分为两个层面，一个是分层，另一个是分层后的职责。 当团队大一些后，需要明确团队的组织分层，这里可能是正式认命的 Leader，也可能是虚拟的负责人，不管是实的还是虚的，最终都会有一个层存在。

分层本质上是一个分饼的行为，什么样的人拥有什么样的资源，承担什么样的责任，行使什么样的权利。

作为一个研发团队的负责人，需要梳理这些层，确定是否有合适的人，这些层的负责人形成了我们所说的「人才梯队」。

德鲁克曾说：「一个组织应该使每个人，特别是每个管理人员和每个专业人员（但也包括每个管理单位）都理解自身的任务」。 在我们做分层的过程中，需要关注每一层的职责和其解决的问题，如我们在软件架构设计的时候一样，每一个分层都有其作用，无用的分层只会增加性能的损耗。

对于将来，未雨绸缪。

当现在的人才正在发挥作用时，培养接班人，我们经常称之为 B 角。当有人才变动时可以快速补位上去。常用的方法有内部培养，跨团队轮岗，外部招聘等。

这块特别狠的可能要算宇宙厂了，在现有人员已经能满足工作需要的同时，会继续招聘，如果更优，可能会换人。

1.2.2 艰难的决定

在我们构建人才梯队的时候，想要做到知人善任是一件很难的事情，并且让每个人的表现都达到预期水平更难。当有些人并不能胜任他当前的工作时，我们应该怎么做？这里可能有以下两种常见的方式：

1. 调岗，一般这种情况可能只是人岗不匹配，或者有些变化跟不上，但是对于人的部分能力还是比较认可。此时我们在公司内给他找一个匹配的岗位，更好地发挥其潜力。在技术团队最常见的例子是有些高 P 的技术同学，被推到管理岗，过了一段时间，发现适应不了，此时我们可以将其调到更能发挥其能力的岗位上来。又或者一些管理者因为团队扩大或者一些其它原因，管理的范围一下子增加了很多，一段时间后发现无法搞定这样的团队，此时可能将其调整到稍微低一级的职位上更合适一些。
2. 离开，尽量让对方体面的离开，公司和个人都体面的分手，该赔偿的赔偿，该理解的理解，如果在外面有合适的机会，顺手推一把，也是个不错的善缘，不枉同事一场。这里经常出现的问题是犹豫不决，最终导致大家都不开心，不欢而散。管理上常说：「心要慈,刀要快」，就是要规避这种犹豫。

1.3 管理者自己

在用人中还包括管理者自己，一个技术管理者，不仅仅要注重技术，不仅仅要设定明确的目标并排出优先顺序，跟进过程发现问题解决问题，拿到结果，还要注意另一个重要的点：业务参与者。

一个优秀的管理者和一个不那么优秀的管理者的主要差别就是他们对业务的参与程度。事实证明，对所负责业务参与的程度越深，你就越能做出更加明智的决策。

什么叫业务参与度？

我认为它不是事无巨细地了解进展，应该到一线去，怎么到一线去，去写代码，去做代码评审？

到一线去，有两个层次，一个是业务的一线，用户或产品，看用户的反馈，产品的实现，二是工作的一线，看工作流程的卡点，系统化的情况，可视化的情况。不要自己去做这些事情，主要是收集信息，决策或者发现问题解决问题，这里确定做什么的原则是： 你做的事情的价值大小，而价值大小可以从时间杠杆，团队杠杆上来指数级扩大，如果做一件事只有短期的一件事的价值，那这些事情就不是你应该做的，应该停下来去思考要做的事情。

2. 组织

说到组织，你是想要一个「令行禁止，使命必达」的组织，还是一个「简单可依赖」的组织？

组织是为实现共同目标而采取的一种分工协作体系，是人与人之间的关系，组织结构往往会随着组织的重大战略调整而调整。

而企业在商场中求生，随着外部环境的变化，行业的变化，内部环境的演进而会不断进行迭代，不断调整组织结构，因此我们经常需要重新设计组织结构。

2.1 设计组织结构

我们在设计组织结构的时候通常要思考以下五个问题：

1. 组织的目标是什么？因为组织是为了共同目标而存在的人与人的关系，目标不清楚，组织结构肯定也是不清楚的。
2. 组织由哪些层，哪些单位组成？组织是一个体系，由不同的单元组成，需要明确各层或单元分别是什么，职责是什么，其作为一个子结构需要有自己的目标和使命。
3. 组织各部分的规模和形式应该是怎样的？根据现实的情况，在设计组织结构时需要着重考虑规模和形式，多少层级？流程型？考虑管理者的有效管理幅度。
4. 组织的哪些部分应该结合在一起，哪些部分应该分开？
5. 组织内各单元之间的关系和协同应该是怎样的?

设计组织结构最难的问题可能是分和合的问题，这里有一个原则： 凡是做出同样的贡献的活动可以结合在一个部门中统一管理，不论它们的技术专业是什么。那些不是做出同样贡献的活动则一般不应合在一起。

在考虑组织结构，特别是研发团队的组织结构的时候，千万不可忽略了康威定律，甚至我们有时需要「逆康威定律」，通过适配康威定律，在明确技术架构方向的基础上，以组织结构的调整来推动技术架构的演进。

2.2 组织的形态

每家企业都有自己的文化和组织形式，抽象出来大致可以分为权力型，流程型和交易型，落到研发团队内部，一般只有前两种。

现在许多人强调去中心化、去科层化、去权力化，实际上，在大多数情形下，权力连接还是最直接、最简单、最有效的机制。权力组织讲究的是执行。

组织中的权力主要有四种。除了决策权，还有建议权、审核权和知情权。

• 决策权，对一个事情决定资源投在哪里，是不是可以做的权力；
• 建议权是提出方案、预案的权力。注意，这是一种权力：建议权拥有者如果未提出建议，上级决策者不能替代或强压；
• 审核权是对有关事项程序性、合规性的审查与核准。注意，这种权力不是对事项进行决策；只要有关事项符合程序、合乎标准和规范就予以通过放行。我们经常会看到一些企业的职能管理部门把审核权误当成了批准决定权，导致审批流程变长、决策效率降低，这是需要反思改进的。
• 知情权是信息共享权，即获取信息的权力。

以上 4 个权限很容易让我们想到项目管理里面的 RACI 矩阵：

• 谁负责：（R = Responsible），即负责执行任务的角色，他/她具体负责操控项目、解决问题。
• 谁批准：（A = Accountable，决策权），即对任务负全责的角色，只有经他/她同意或签署之后，项目才能得以进行，是整个事情的决策者；
• 咨询谁：（C = Consulted，建议权），拥有完成项目所需的信息或能力的人员，多提出建议。
• 通知谁： (I =Informed，知情权)，即应及时被通知结果的人员，却不必向他/她咨询、征求意见。

以上四种权力，决策权和建议权是权力主线，审核权和知情权是权力副线。主线是上下级逻辑，副线是平级或流程型逻辑，而我们往往理解的权力是主线权力。

在强权力主线的基础上，权力型组织的有以下 3 个缺点：

1. 唯上，组织内的成员对决定其资源或发展的上级负责；
2. 组织的发展由上级决定，当上级缺位、能力不足或脱离实际时可能会出现瞎指挥，乱指挥的情况；
3. 层级过多，导致执行和决策的效率低下。

为规避这些缺点我们需要减少层级，增加连接和协同。

如果把管理层只分为三级，我们一般称之为高层、中级和基层。这三个层要解决的问题不同。高层解决长期发展的问题，中层解决系统效率的问题，基层解决的是事情本身的问题。

比如技术管理者常规上可以分为三个大层：

• 高层管理：解决长期发展的问题，使企业/团队有前途，关注的是未来，不管是技术发展的未来，还是业务发展的未来；
• 中层管理：解决系统效率的问题，使系统更有效率，要不断强化研发流程的统一性和适应性，确定并执行好标准和规范，提升协同的效率，标准化和系统化，同时为上层的选择和决策提供依据和保障；
• 基层管理：解决事情本身的问题，而事情往往会落到一线的开发同学身上，于是经常我们基层管理者的主要工作是使一线开发同学工作有成就，培养一线开发同学，提高他们承担工作的能力和意愿，帮助他们解决问题。

我们期望是每个层能做好自己的事情，但是实际上往往是高层在做中层的事情，中层在做基层的事，基层在做一线的事情，错位了。于是，我们需要将管理层归位，各行其职，更专业的做事情。

在明确职责的基础上，尽量减少管理的层级，尽量不要出现 「副XX」 的岗位。

在协同方面我们用流程来解决协同合作的问题。流程本身的逻辑是对事情负责，对自身的任务及向下事项/环节负责。其驱动力是责任感和依赖。百度文化里面的「简单可依赖」能较好地说明流程的底层逻辑。当我们使用流程来解决协同的问题时，要经常迭代流程以优化协同的效率：

• 注意流程是为了解决过程中的问题，不是为了设置卡点，每个人都有扩大自己权力的欲望，这是我们在流程建设中要特别注意的；
• 尽量减少流程环节，聚合责任主体，我们经常遇到一个事情在某职能部门还需要经过两三道审核的情况，这种损耗可以通过聚合责任主体的方式来解决；
• 控制流程时长，这里控制流程时长还包括流程环节的前置准备，就和我们开会一样，如果开会前准备充分，会议本身的时长就有极大可能减少。

用权力解决「力出一孔」的问题，用流程解决协同合作的问题。

简单来说，在权力体系的基础上，用流程连接各环节和负责主体，现在比较常见的矩阵式组织结构基本符合这个逻辑。当然这里有一个以流程为主还是以权力为主的问题，具体是哪种，还得看公司当前组织结构的逻辑。

2.3 分工的粗和细

Adam Smith 在 1776 年的《国富论》中提出了分工，分工对于手工业生产效率有较大的提高，其总结了三个优点：

• 熟练程度的增加，当一个人专注于一块工作，不停的练习极大的增加了熟练度，熟练度的增加将导致质量和产量的增加；
• 当熟练后，人们对于重复的操作进行机械化或自动化，从而更大的提高质量和产量；
• 分工明确了输入和输出，在明确的分工下，从一个工序转为另一个工序的时长减少了。

自从分工提出来了，产生了大量的争论，有人提出了以下的一些缺点：

• 一叶障目，不见泰山，分工越细，所关注的东西都小，当人陷于某个事情越来越小的部分时，其大局观往往受限，可能会导致局部提升而全局受损的情况；
• 分工越细意味着沟通协作成本的增加，当分工获得的收益小于沟通协作的收益时，将产生极大的成本浪费；
• 分工一定关系到组织结构的分块，当沟通不畅或没有沟通时，有可能出现组织上的「孤岛」

分工落到一个研发团队，我们通常按编程语言分为 Java、PHP、C++、Javascript，或按端分为安卓端、iOS 端、前端、后端、算法、数据等，又或者大一点分为开发、测试、运维，架构师。

虽然「术业有专攻」，但多跨一步会让分工后的协同更高效一些，这里最常见的可能是测试左移和测试右移。

• 测试左移是指在研发流程中，把测试的覆盖范围从传统的测试节点中释放出来，将其向左扩展，介入代码提测之前的部分，如开发阶段阶段，需求评审阶段，让研发人员在架构设计时就考虑产品的可测试性，并尽量进行开发自测，同时评估需求的质量，比如分析需求的合理性以及完整性等。
• 测试右移是指把测试的覆盖范围从传统的测试环节中切出来，将其向右扩展，更多地融入代码部署、发布，甚至上线之后的步骤中。

更极端一些，走全栈路线，一个人从头到尾完成需求的所有工序。但是这种方式，对于人员素质的要求，对于团队组织的要求和常规不一样，且人的精力是有限的，能在每个方面都做到精通的，少之又少，除非所做的事情只需要略懂即可。

思考一下，你所在团队应该如何来做？

成本和效率？组织大小？技术发展？架构演进？

3. 机制

3.1 DRI 机制

3.1.1 DRI 的由来

DRI 是 Directly Responsible Individual 的简称，中文翻译为「直接负责人」。最开始是从苹果流传出来的内部管理概念。

DRI 不是流程、过程，也不是框架，而是一个负责人，对某部分的整体负责，小到 BUG，大到技术方向。 DRI 是为了解决责任主体的问题，其有助于避免责任分散。责任分散这个概念也被称为「旁观者效应」，也就是人们身处团队中时无法对某事负起责任，责任分散到了团队中的每个成员身上，而不是集中在真正有责任的人身上，因为每个人认为那个责任应该由其他人承担，表现得像一个旁观者。

3.1.2 DRI 的职责

• 聚焦目标；
• 督促、监督团队成员完成自己的任务；
• 清楚团队中发生的一切；
• 统筹策划，搞定所有的干系人，从头到尾负责到底，说简单点就是团队成员专注的做好手上的事儿， DRI 排除干扰，解决各种烦人的问题来，发现问题，解决问题；
• 有一定的领导责任。

简单来说，当你是某个事情的 DRI 后，这个事情就是你自己的事情。特别是当职责不清或者突发问题时，DRI 就需要发挥主人翁的精神，拉起团队成员去分析问题，解决问题。

3.1.3 什么人适合做 DRI

DRI 和工作年限无关，和是否资深无关，和技术工种无关，你想你就是。

但是在操作过程中，我们会根据实际的场景做一些偏重。如果是一个后台的活儿居多的项目，其 DRI 大概率是后台的开发同学，如果是一个质量问题较多的项目，其 DRI 大概率是一个 QA 同学。

这里我们会充分考虑同学的主观意愿，有些同学想，有些同学不愿意，只想做好手上的工作，那么他做好他手上工作的 DRI 就可以了。

DRI 无关项目大小，无关职位高低，无关所在层级，每一件大事，小事都需要有一个 DRI，且只有一个 DRI

这玩意儿换成中文其实就是我们在标语里面经常看到的「责任到人」差不多，但是更强调责任主体的唯一性。

3.2 构建良好的协同机制

公元前 221 年，秦始皇用了十年的时间，先后灭了韩、赵、魏、楚、燕、齐六国，完成了统一中国的大业。在以后，他陆续颁布了多条律法，以稳固国家的统治，包括「书同文」、「车同轨」、「度同制」等。

一个国家，一个组织，要想成为一个高效执行的团队，一定要有标准，一定要有人告诉大家怎样做是对的。 落到我们团队管理，标准，流程是必须要做的，特别是当你的团队是由若干个团队整合或融合的时候。

3.2.1 统一标准规范

当你的团队是由原来多个业务的团队融合而成，大家原来都有做一些标准，现在我们需要按统一的标准达成共识并推行下去。又或者本来标准不完善，需要系统梳理标准来达到标准的统一。

行业标准一般是为了互联互通，而对于研发团队的研发过程来说，标准主要是为了减少过程中的认知成本，提升研发的效率，比如数据库规范，大家按统一的规范来设计数据库，当有其它同学接手你负责模块的时候，能减少在基本结构的认知成本，以及在一些模块间整合或数据迁移时，对于工作会比较友好一些。

标准是什么，标准是一件行为准则，其关注的是结果。

标准和规范一般是为了告诉人们什么是好的，关注的结果，而统一标准是为了让大家互联互通。

标准不是为了成功，而是为了让整个事情不至于太坏，尽量不出现重大的问题。 具体到研发团队，我们一般需要统一如下一些标准：

• 研发过程
  • 代码风格规范
  • 数据库设计规范
  • 代码分干管理规范
  • 代码提交规范
  • 错误码规范
  • Code Review 标准
  • 代码权限管理规范
• 沟通协同
  • 架构规范
  • 技术方案规范
  • 文档规范
  • 接口规范
• 质量标准
  • 代码质量标准
  • 自动化测试标准
  • 测试质量标准
  • 线上质量标准
• 性能标准
  • 服务端性能标准
  • 客户端性能标准
  • 前端性能标准
• 安全标准
  • 信息安全标准
  • 代码安全标准
  • 数据安全标准
  • 线上安全标准

3.2.2 统一流程

流程是什么？

流程是基于时间线，有一定先后序列规则的完成一件事的过程。流程是线性的、连续的。

统一流程是什么？

统一流程就是把一些验证过的好的做事方式，好的经验通过流程的方式固化下来，防止大家重蹈覆辙，在一个坑里踩多次，并且为不熟悉的同学做好指导。

我们做任何一件事都是有流程的，有些是设计过的，有些是自然而然的，设计过的流程可能是别人的经验。并且流程需要持续迭代。

在研发管理中我们常常会构建的流程如下：

• 敏捷流程
  • 需求迭代流程
  • 紧急需求流程
  • 值班需求流程
• 研发流程
  • 代码审核流程
  • 代码发布流程
  • 紧急发布流程
• 协同
  • 对接流程
  • 资源申请流程
  • 线上问题/告警处理流程
  • 事故处理流程
  • 安全问题处理流程

3.2.3 统一工具

以上说了要统一标准，统一流程，这些第一步是要把这些标准和流程做出来，形成文档，落到知识库中。 如果只做到这一步，这些标准和流程可能就真的只是一个文档，情况好一点，有人来推进重视，可能会落实一些，但一旦这个推进人不在了，或者不再关注了，很多形式就不了了之。

要解决这个问题只能通过工具或系统，以工具或系统的形式固化标准和流程，把这此好的经验和方式以更物理的方式沉淀下来。再以这些工具或系统为杠杆，提升整体研发的效率，创造增量的价值。

4. 系统

这里的系统不仅仅是指使用某个系统，在使用系统的基础上整合，实现我们高效执行的目的。 前面我们有了机制，但是事情太多，不能让所有的事情用人来去解决，需要用系统来解决。

机制解决规模化的问题，系统解决规模固化的问题。 系统解决的问题有两个层面，一个是过程跟进，一个是结果度量。

4.1 工作流和过程跟进系统

一个研发部门可以看作一个系统，需求从一端进入，经历各种正确的工序，才能变成产品，如期从另一边离开。 当系统内部存在冲突，或者不和，或者互相针对，那么就会发生各种想象不到的问题，从而让整个系统的产出变少，甚至没有。

着眼于整个工作流，确认瓶颈点在哪，尽可能的运用各种技术和流程来确保工作在计划内有效的执行。因为我们知道：在代码投产之前，实际上并未产生任何价值，因为那只是困在系统里的半成品。

在实际中我们如何让大家更好的协同，更好的让这个工作流运转起来呢？以前可能是 Excel、Word 或者 todolist，再加上邮件或 IM 传来传去，现在更进一步有在线的表格协同，还有更完整的项目管理系统，如 Jira 、Trello、腾讯的 TAPD、阿里的 Teambition、禅道等。工具不同，但是目标是相同的，都是希望做到对项目执行的管控、对团队事务（问题）的跟踪，对需要多人协作任务的快速流转和处理。

除此之外，还需要文档管理，即过程中的物料也需要跟进起来，关联起来。至于是一个系统，还是多个系统，都是可以的。

系统虽有，但用得怎么样不好说，一个好的系统用不起来也是白搭，这里作为管理者需要推动起来的。

4.2 工作可视化

项目管理的系统用起来后，我们的工作流转就会落到系统里面，此时根据系统的数据，我们可以让工作可视化，透明化，能够清晰的观察工作流动的情况，从而发现瓶颈。发现问题是最难的，很多时候我们不知道有什么问题，包括自己。发现问题，才能解决问题，方法总是有的。 在资源有限的情况下，对非约束点的改进看起来很正确，但实质上毫无帮助，甚至会消耗宝贵资源拖累真正需要解决的问题。

我们可以构建一些看板，看一个产品从产品到设计、到研发实现，到测试完成，上线发布，再到线上问题跟进等等的情况。看效率，看一个需求从出现想法到用户看到需要多少时间，每个环节需要多少时间，哪些需求在哪些环节停留太久？不同的需求，不同的人，不同的产品做多个层次的对比，从而发现问题解决问题，让一切都在阳光下进行。

同时，我们可以让系统和数据告诉我们，整体团队的投入如何，有多少同学的工作是可以追溯的，有多少人力是隐藏在不为人知的地方的，能看到我们的时间都去哪了。

基于这样的看板，我们从两个角度优化整个系统：

• 从左到右的流动，看从产品、设计、研发到运维的工作情况。为了最大程度地优化工作流，需要将工作可视化，减小每批次大小和等待间隔，通过内建质量杜绝向下游传递缺陷，并持续地优化全局目标；
• 从右向左的反馈，每个阶段中，应用持续、快速的工作反馈机制。通过放大反馈环防止问题复发，并缩短问题发现时间，实现快速修复。通过这种方式，我们能从源头控制质量，并在流程中嵌入相关的知识。这样不仅能创造出更安全的工作系统，还可以在灾难性事故发生前就检测到并解决它。

总体来说，先透明出来，再优化，打开黑盒，问题会简单很多。

4.3 其它

以上的两个是从任务跟进和结果度量的角度，或者说从项目管理的角度来看整个团队的运转。 换一个角度，从研发同学工作本身，有没有需要系统化的地方？

代码管理是否系统化，Code Review、接口文档、接口自动化测试、Mock 数据、测试数据集管理、用户数据自动脱敏重放，代码从写完提交到代码库之后到上线，线上巡查等等这些是否有系统化？

这并不是今天我们要讲的话题，但是就系统化来说，这些都是必不可少的关键点。不管是哪方面，我们的原则是尽量减少人工介入，把人的经验变成代码和系统。

5. 后记

这篇文章务虚居多，也比较散，但是确实是技术管理者日常工作中要不停思考的点。 思考这些是用来帮助厘清思路，并不具备实操性，也就是不能实际的解决问题。 不同的公司，不同团队，问题不同，解决的方法也不同，欢迎一起探讨。

打开「黑盒」，问题会简单很多。常思考人、组织、机制和系统，这 4 个方面，发现其中的问题，并厘清解决问题的思路，一步一步，有节奏的去解决。

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