字数统计：4746字 预计阅读时间：约10分钟
在制造企业的研发项目中，我们经常看到一种现象：团队里的每个人能力都不差，设计、工艺、质量、采购和项目管理人员也都很努力，但项目运行仍然不顺畅。
设计认为工艺介入太晚，工艺认为设计方案不具备制造可行性；质量不断提出风险，研发却认为质量只会增加流程；采购希望尽早锁定供应商，项目团队又认为技术方案尚未成熟。项目延期以后，大家都很忙，却很难说清楚问题究竟出在哪里。
企业于是开始考虑：是不是缺少更优秀的人？是不是需要换一位更强势的项目经理？是不是团队执行力不够？
但从第三方管理咨询的角度看，团队能力并不是把一群优秀的人放在一起之后自然产生的。一支真正强大的研发团队，需要经历形成、冲突、磨合和成熟的过程，也需要清楚的目标、角色边界、决策机制以及与其能力相匹配的授权。
团队建设不是安排一次拓展活动，也不是要求大家“加强沟通”。它本质上是一项组织能力建设。
塔克曼团队发展模型把团队成长分为五个阶段：形成期、冲突期、规范期、高效期和收尾期。
这个模型的重要价值，不是给团队贴标签，而是提醒管理者：不同阶段的问题不同，领导方式也不能完全相同。
1.形成期：大家都很客气，但真正的问题还没有出现
一个新项目刚启动时，团队成员通常比较积极，也比较礼貌。会议看起来很顺利，很少有人公开反对，但这种“和谐”并不一定代表团队已经达成共识。
很多人实际上还没有完全理解项目目标，也不清楚自己应该承担什么责任，更不知道哪些问题需要自己决策，哪些问题需要升级。
在这一阶段，领导者最重要的任务不是立即要求团队提高绩效，而是帮助团队回答几个基础问题：
项目最终要解决什么问题？成功的标准是什么？每个角色负责什么？不同部门之间如何衔接？出现争议时由谁决策？
如果这些问题没有在项目早期说清楚，表面的和谐很容易在后续转化为责任争议。
2.冲突期：问题开始暴露，团队才真正开始形成
项目进入实质阶段以后，团队成员开始提出不同意见。
设计希望保持技术方案的完整性，制造部门关注能否稳定生产；质量关注风险，项目经理关注节点；采购关注成本与交期，售后则更关心未来的维修便利性。
此时，团队成员还可能争夺话语权，质疑他人的专业判断，甚至挑战项目负责人的决策。很多管理者会把这种状态视为团队失控，希望尽快压制争论。
但冲突并不一定是坏事。它往往意味着团队开始触碰真正的问题。
管理者此时需要做的，不是简单要求大家“顾全大局”，而是建立基本的讨论与决策机制：哪些问题由专业负责人决定，哪些问题需要跨部门评审，什么情况必须升级，最终决策依据是什么。
没有经历过有效冲突的团队，很难真正形成共同的工作方式。
3.规范期：团队开始形成自己的运行规则
当团队成员逐渐了解彼此的专业特点、工作方式和责任边界后，合作会变得更加顺畅。
设计人员开始主动邀请工艺人员参与早期方案讨论；质量人员不再只在评审会上指出问题，而是提前参与风险分析；采购也能够根据项目成熟度，分阶段推动供应商参与。
此时，团队不再依赖项目经理解决每一个问题，而是逐渐形成共同的规则和判断方式。
需要注意的是，团队发展并不是一条只能向前的直线。新成员加入、项目目标调整、关键技术变化或者组织关系变化，都可能让团队重新回到冲突期。
因此，团队成熟并不意味着从此没有问题，而是出现问题以后，能够更快地重新形成共识。
4.高效期：领导者不再需要介入每一个细节
进入高效期以后，团队已经具备较强的自主性。成员能够围绕共同目标进行协作，主动识别风险，也能够对不合理的目标和资源安排提出专业意见。
此时，领导者不应继续控制每一个动作，而应把更多精力放在方向、资源、人才发展和跨组织协调上。
真正成熟的团队，不是从不向领导提出异议，而是能够基于事实、风险和项目目标，提出有依据的不同意见。
5.收尾期：项目结束不等于团队经验自动留下
项目结束、成员调动或者团队解散时，企业常常只关注交付结果，却忽视了经验沉淀。
哪些决策是正确的？哪些问题原本可以更早发现？哪些跨部门协作方式值得保留？哪些临时解决方案不能被误认为标准做法？
如果没有项目复盘，团队积累的经验很容易随着人员调整而消失。下一次新项目启动时，组织又会重新经历同样的问题。
因此，项目结束以后，应当对团队成果进行认可，同时将关键经验转化为流程、标准、检查清单和案例知识。
很多企业选择研发团队成员时，首先关注专业能力和工作经验。这当然重要，但并不足够。
一个技术能力很强的人，不一定适合所有团队。企业还需要考虑，他是否能够理解产品目标，是否愿意与其他专业协作，是否能够接受需求变化，以及是否真正理解自己的工作对下游环节产生什么影响。
例如，一位设计人员可能非常擅长某项技术，但如果他始终认为制造、质量和采购只是负责执行，那么跨部门协作就会非常困难。另一个人可能专业能力不是最突出，却能够理解系统目标、主动暴露风险，并推动不同岗位共同解决问题，他对团队的价值可能更大。
在组建研发团队时，企业至少需要确认四个方面。
第一，项目需要哪些角色，而不是现有组织中有哪些人。
第二，每个角色对最终结果承担什么责任，而不是只完成哪些任务。
第三，不同角色之间的接口和决策权限是什么。
第四，团队对“完成”的定义是否一致。
对设计人员而言，“完成”可能意味着图纸发布；对工艺人员而言，可能意味着过程能够稳定实现；对质量人员而言，还需要风险得到控制、验证证据充分；对项目负责人而言，则意味着产品能够按要求交付。
如果团队对“完成”的理解不同，即使每个人都完成了自己的任务，项目仍然可能没有真正完成。
组建团队的重点，不只是把岗位填满，而是形成一套能够共同对产品结果负责的角色组合。
项目开始时，管理者经常强调目标一致，但真正的目标一致，不只是大家都知道交付日期和销售目标。
团队成员需要知道，项目为什么重要，客户真正需要什么，当前最大的风险在哪里，以及自己的工作如何影响最终结果。
同时，团队也需要明确工作边界。其他职能可以对专业方案提出意见，但意见如何进入决策，最终由谁承担专业责任，需要有清楚的机制。
例如，质量部门可以提出风险，但不能只用“质量不接受”代替风险说明；设计部门拥有技术决策权，也不能以专业自主为由拒绝制造可行性和历史问题的输入。
透明同样不意味着把所有信息毫无选择地发送给所有人。如果领导层只公布某项经营指标，却不解释背景和影响，团队可能产生不必要的焦虑，甚至作出错误反应。
真正有效的透明，应当包括必要的信息、适当的背景以及清楚的行动要求。
团队需要的不是信息越多越好，而是能够依据共同事实作出正确判断。
冲突处理没有一种方法适用于所有情况。Thomas-Kilmann冲突模型提出了竞争、迁就、回避、妥协和合作五种基本方式。
这些方式本身没有绝对好坏，关键在于是否适合当时的情境。
当出现安全风险、重大质量问题或必须立即控制的紧急情况时，领导者需要快速作出决定，不能为了追求所有人满意而无限讨论。
当问题影响较小，而另一方拥有更充分的信息和专业判断时，适度迁就可能更加有效。
当情绪过于激烈、信息明显不足，或者当前还有更紧急的问题需要处理时，暂时回避、等待条件成熟，也可能是合理选择。但回避不能变成永远不处理。
当时间有限、双方都有合理诉求时，可以先形成阶段性妥协方案，但需要清楚妥协带来的风险和后续安排。
对于影响产品方向、关键技术和长期合作关系的问题，则应尽可能采用合作方式，充分理解各方关切，寻找更完整的解决方案。
企业最需要避免的，不是团队成员意见不同，而是所有冲突都采用同一种方式处理。
有些管理者习惯依靠职位强行决定，久而久之，团队只会等待指令；有些管理者追求所有人都满意，导致重要决策长期拖延；还有一些团队表面上没有冲突，实际上所有真实意见都转移到了会议之外。
有效解决冲突，需要团队做到三件事：先理解对方真正表达的内容，再确认事实和假设，最后共同讨论可以实施的方案。
讨论的目标不是证明谁更正确，而是找到对项目和组织更有利的决定。
很多企业都在谈授权，但实际做法往往走向两个极端。
一种是领导者决定所有细节，团队只负责执行；另一种是领导者提出一个模糊目标，然后要求团队自行解决所有问题。
真正的赋能，需要同时具备目标、边界、资源和责任。
领导者可以不直接规定解决方案，但需要明确问题是什么、必须达到什么结果、哪些条件不能突破，以及团队能够使用哪些资源。
例如，与其要求团队“按照某一种结构设计”，不如提出问题：“在满足安全、成本、交期和维护要求的前提下，如何实现这个功能？”团队可以选择具体方案，但必须对方案的结果负责。
被赋能的团队，不只是拥有更多自由，还需要承担更完整的责任。企业也不应只追究某一个人的失误，而要关注团队是否建立了必要的评审、验证和风险控制机制。
同时，真正的授权还意味着团队可以对不合理目标提出异议。如果团队只能接受任务，不能讨论资源、风险和实现条件，那么所谓授权只是把压力向下转移。
赋能的核心，不是减少领导者的工作，而是提高团队解决问题和承担结果的能力。
并非所有问题都适合使用相同的管理方式。
对于目标清楚、方法成熟、结果相对确定的工作，可以通过标准流程、明确分工和较强的进度控制推进。
对于技术复杂但能够分析的问题，需要依靠专业人员、数据和跨部门评审作出判断。
对于高度不确定、需要探索的新技术和新产品，则更适合采用短周期试验、快速反馈和逐步验证的方式。领导者需要提供方向和资源，而不是过早规定唯一答案。
当企业面对重大事故、严重质量风险或项目失控时，领导者则需要先快速稳定局面，明确指挥关系，控制风险，再恢复正常的团队协作和复盘机制。
团队成员对问题性质的判断，也可能与领导者不同。领导者认为情况紧急，需要快速决策；团队成员却可能认为还有充分时间进行分析。如果不解释决策背景，管理方式的变化就容易被理解为突然干预或不信任。
因此，在调整流程和领导方式时，需要向团队说明为什么改变、改变什么，以及恢复正常机制的条件是什么。
随着团队成员和利益相关者增加，沟通关系也会迅速增长。一个由十个人组成的团队，潜在的双向沟通关系已经达到45组。此时，单纯依靠增加会议和抄送邮件，很难保证信息一致。
领导者更重要的工作，是建立统一的信息来源、决策记录、接口机制和升级路径，让团队不必依赖个人转述来获得关键信息。
优秀的领导，不是始终站在团队前面发号施令，也不是完全隐身，而是在团队需要方向时给方向，需要资源时给资源，需要成长时给空间。
真正强大的研发团队，不是因为成员之间从不发生冲突，也不是因为每个人都拥有相同的工作方式。
它能够在目标、角色和方法尚不清楚时逐步形成共识；能够在出现分歧时围绕事实和风险进行讨论；能够在规则建立后实现自主协作，也能够在项目结束以后把经验留给组织。
因此，团队建设不能只依靠个人魅力，也不能只依靠一次培训。它需要与产品开发流程、角色责任、决策机制、项目管理和人才培养结合起来。
团队能力的本质，不是几个优秀的人能够解决多少问题，而是组织能否让更多人持续、稳定地共同解决问题。
带好团队，不只是分配任务、跟踪进度，更需要管理者在团队形成时明确方向，在出现分歧时推动有效讨论，在团队成熟后给予恰当授权。从“自己把事情做好”，走向“带领团队共同把事情做好”，是管理者需要持续修炼的能力。TPP将于12月举办公开课《管理者思维——管理者五项全能修炼》，欢迎希望提升团队管理能力的管理者参与学习与交流，结合实际管理困境，重新审视自己的角色与工作方式，让团队少一些对个人救火的依赖，多一些自主协作、共同承担结果的能力。