在关系与规则之间：怎样在不完善的组织里做成事

你可能遇到过这样的项目：目标已经确定，计划也写得很完整，所有人都在工作，项目却突然推不动了。例如：

• 一个政府部门正在推动跨部门数据共享。数据提供方愿意合作，使用方也有明确需求，但数据权限、隐私评估、项目预算和结果责任分别掌握在不同单位手中。各部门都在履行自己的法定职责，项目却要等它们重新达成协议，才能继续推进。
• 一所大学正在建设统一的科研管理平台。中央技术团队负责系统，院系掌握实际流程，科研和财务部门制定管理规则。项目负责人可以组织会议和更新计划，却不能单独改变业务流程，也无法要求院系调配人员。试点已经启动，系统仍可能因为决策分散而停在半路。
• 一家零售企业正在开发需求预测平台。试点模型已经完成，产品负责人却在组织重组中离任。新的负责人可以管理产品待办事项，却不能代表补货部门接受库存风险；关键工程资源也被调往其他项目。模型还能继续优化，但谁决定上线范围、谁提供生产资源，已经没人能够一次说清。

这三个场景不是对某家组织的完整复述，而是跨部门项目中反复出现的组合情境。组织并没有失去制度，但具体项目的决策链可能因为人员调整、职责分割和资源变化而断开。

如果你是工程师，继续优化技术未必有用；如果你是项目负责人，继续开会也未必能解决问题。你需要找到真正有权作出取舍的人，同时避免替组织承担一份没有边界的责任。

那么，怎样借助具体人物的支持把事情启动起来，又怎样用明确的边界保护自己？这要从组织实际的决策链说起。

一、组织有制度，项目为什么还会卡住？ #

组织结构图告诉人们谁担任什么职位，却不一定说明在一项具体任务里，谁能调整范围、谁掌握关键资源、谁能协调不同部门，以及谁有权决定组织承担多大风险。

我在《人身依附和角色责任：从前现代到现代管理》中讨论过，前现代管理更多依赖对具体人物的忠诚，现代管理则试图把责任放进角色、流程和可以交接的制度中。现实组织往往同时包含这两种机制。社会学家马克·格兰诺维特（Mark Granovetter）指出，经济行动嵌入具体的社会关系网络[1]。正式制度不会让关系消失，它更重要的作用，是降低合作对私人关系的依赖。

很多跨部门项目真正失效的，不是制度本身，而是制度之间的接口。

人员调整或任务跨越部门边界以后，责任、权限和协调能力没有重新组成一条完整的决策链。各部门仍然按照自己的制度运行，跨部门任务却失去了能够作出整体取舍的人。

这时，项目负责人不能只看会议开了多少次、计划写得多完整，还要判断几个更实际的问题：坏消息能否传到真正有权决定的人那里？范围、资源和风险归属能否留下稳定记录？部门发生冲突时，究竟由谁作出取舍？

社会文化也会影响组织怎样填补这些制度缺口。有些环境更习惯等待上级表态、依靠熟人协调或避免公开冲突；另一些环境更强调合同、角色和专业判断。跨文化领导力研究表明，不同社会对权力距离以及理想领导方式存在不同期待[2]。不过，文化可以帮助人们理解组织成员为什么会作出某种反应，却不能替责任模糊和授权缺失提供合理化解释。

企业管理者可以在权限范围内调整预算和人员；政府项目受到法律、预算和行政程序约束；学校还需要考虑学术自治、专业判断和校内治理。具体人物的支持不能替代这些制度，也不能让越权决定变得合理。这种支持真正有价值的地方，是帮助项目找到有权决定的人，补上暂时断裂的协作接口。

找到真正的决策链，只说明事情有可能继续推进。执行者还要判断：这个没人负责的问题，究竟是机会，还是组织正在向下转移风险？

二、没人负责的问题，都值得接吗？ #

未必。

没有明确负责人的问题，既可能让一个人建立影响力，也可能成为组织向下转移风险的方式。判断的关键不在于大家是否经常抱怨，而在于这个问题是否真正限制了整个系统的产出。

一个报表界面不好用，可能让很多人不满意，却未必影响最终结果。一个数据口径长期无人确认，看起来只是小事，却可能让模型训练、实验分析和绩效评价失去共同基础。解决后一类问题，不只是完成一项任务，还能让许多人的后续工作顺利进行。

但“无人负责”的问题至少有两种。

一种横跨多个部门，组织确实希望解决，只是缺少协调者。另一种则没有预算、没有授权、没有稳定支持，组织又不愿承认现有条件不足。前一种可能是机会；后一种往往意味着组织需要一个人替系统性的缺口承担责任。

接下任务之前，你需要弄清楚几件事：组织是否真的希望解决这个问题，谁定义结果并负责验收，哪些部门必须配合，以及资源和优先级发生冲突时由谁处理。更重要的是，当前提条件发生变化时，谁有权暂停任务、缩小范围或重新谈判承诺。

还有一个更敏感的问题：如果项目失败，组织会回头检查前提条件和既有决定，还是只寻找一个承担责任的人？

这些问题往往比职位名称更能说明机会是否真实。

一项任务只有同时具备相称的责任、权限和资源，才更可能成为真正的机会。如果组织只下放责任，却没有提供必要的权限和资源，就要警惕风险正在向下转移。

即使组织愿意提供支持，执行者仍然面对一个更敏感的问题：可以借谁的力，又应该为这份支持承担多少责任？

三、可以借领导的力，但要承担多少责任？ #

复杂工作经常需要一位有能力提供支持的项目支持者（Sponsor）。这个人可能是企业高层、政府主管负责人、项目委员会成员，也可能是学校或院系负责人。他能够确认优先级、协调资源，并在项目遇到跨部门冲突时推动必要的取舍。

完全拒绝这种人格化的支持，项目可能无法启动；得到某个人的支持，也不等于必须成为“他的人”。

为了描述两者之间的状态，本文暂且把它称为**“有限依附”**：在明确边界内借助具体人物的信任和权力完成一项工作，但不因此进行私人效忠，也不放弃专业和制度边界。个人借的是完成任务所需要的支持，而不是把自己的身份和长期前途绑定在某个人身上。

接受任务时，可以依次确认几个问题：

1. 定义结果： 项目解决什么问题，结果由谁验收；
2. 理顺依赖： 需要哪些数据、系统和部门配合；
3. 确认权责： 自己能决定什么，谁提供资源，谁接受结果风险；
4. 承诺进度： 前置条件满足以后，再给出可靠的时间表。

在开头那类情境中，合格的项目支持者无须接管日常工作。他真正需要做的，是确认项目范围，协调必要资源，明确由谁接受业务风险，并为跨部门冲突提供升级路径。项目负责人把这些决定转化为行动，专业人员则判断方案在技术和专业上是否可靠。

项目负责人不能凭职位创造授权，专业人员也不应替业务部门或管理层接受组织风险。

职位名称本身也不会自动带来完成任务所需要的权力。如果一个人需要为交付负责，却不能影响范围和优先级，无权协调资源，也无法把冲突升级给真正的决策者，各部门就会继续保留各自的决定权，跨部门失败却可能集中到这个人身上。

口头支持因此还需要转化为组织承诺。会议纪要、决策日志和书面确认更重要的作用，是让团队对范围、依赖和风险形成共同版本，并为后来的调整和交接保留背景。这样，即使时间、人员和利益发生变化，项目也不必反复争论当初作出了什么决定。

授权是否可靠，还可以看支持者怎样对待坏消息。艾米·埃德蒙森（Amy Edmondson）对一家制造企业 51 个工作团队的研究发现，团队心理安全（psychological safety）与学习行为相关[3]。这项研究不能直接证明所有组织都会出现相同结果，但它提示了一个重要机制：如果成员担心提出问题会招致人际惩罚，团队就更难及时发现和纠正错误。

如果一位支持者要求忠诚，却始终不明确权限；或者一面要求团队承担结果，一面惩罚报告风险的人，这种支持就更接近责任转移，而不是有边界的授权。

因此，关系可以帮助项目获得授权，记录可以固定授权，结果则检验这份授权是否真正有效。

有了这些边界，执行者才有条件推进工作。但知识型项目还有另一层困难：任务本身往往并不清楚。技术人员接下来要解决的，是怎样把一句模糊要求变成组织真正可以作出的决定。

四、技术人员怎样把模糊要求变成可以决定的问题？ #

很多知识工作在开始时都不是定义清楚的任务。

需求方可能说“做个模型提高转化率”“把这些数据打通”或者“建立一个跨部门平台”，却没有说明谁定义指标、谁提供条件、谁使用结果，以及谁承担错误成本。

执行者如果直接把这些要求变成排期，就会在没有决策边界的情况下提前承诺结果。

面对“把预测做得更准”这样的要求，技术人员可以先不讨论模型和上线日期，而是问几个更基本的问题：更准确的预测将支持什么决定？门店怎样使用结果？高估和低估分别会造成什么成本？谁有权接受这些误差？

这些问题有了答案，模型指标才开始具有组织意义。

技术人员随后需要把已经确认的事实、仍待验证的假设以及模型的适用边界分开说明。如果存在多个方案，就写清每个方案需要的资源、可能产生的影响和无法消除的风险，再请真正有权的人作出取舍。

这样做不是把技术问题推给管理者，而是把技术选择中本来就存在的取舍说清楚，再把超出专业权限的决定交给真正有权的人。

数据和人工智能项目尤其需要这种边界。技术团队可以设计指标、比较方案、选择阈值，也应当对实现质量、数据处理和已知技术风险负责。但技术团队不能因为掌握技术，就默认获得决定业务目标、合规边界和风险分配的权力。技术人员可以设计方案，却不能替组织决定谁承担后果。 美国计算机协会（Association for Computing Machinery，ACM）的职业伦理准则要求从业者诚实说明系统能力、局限和潜在问题[4]；美国国家标准与技术研究院（National Institute of Standards and Technology，NIST）发布的人工智能风险管理框架，也强调人工智能系统整个生命周期中的治理、角色和问责[5]。

刚参加工作的人不必立即看懂整张权力网络，也无须刻意经营所谓“人脉”。更实际的起点，是把需求问清楚，把假设写下来，及时报告风险，只承诺自己有条件兑现的结果。

一个人最初建立的组织信用，通常不是因为“做过大项目”，而是同事逐渐确认：这个人提供的信息可靠，遇到问题不会隐瞒，答应的事情能够得到明确结果。

不过，完成项目只是建立信用的开始。项目结束以后，组织怎样解释这次成功，决定了这份信用究竟依附于某段关系，还是逐渐属于你本人。

五、做成一件事以后，组织记住了什么？ #

项目完成以后，组织可能形成两种完全不同的认识：

“这个人认识某位领导，所以能够调动资源。”

或者：

“这个人能够判断问题、组织协作、及时暴露风险，并交付可以验证的结果。”

前一种认识依赖私人关系。支持者一旦离开，个人影响力也可能随之消失。后一种认识更接近一种可以迁移的组织信用：即使更换团队、项目或领导，其他人仍然愿意相信这个人的判断和承诺。

这种信用不能只靠当事人自己讲述，需要留下第三方可以验证的证据。

决策记录说明项目解决什么问题、为什么选择这个范围、谁接受了哪些风险；交付结果说明哪些指标得到改善、结论能否复核、失败又带来了什么认识；协作记录则说明谁作出了贡献、风险是否得到及时暴露，以及团队怎样处理问题。

这些记录也会慢慢改变组织记忆。别人记住的不再只是“你认识谁”，而是你怎样判断问题、组织协作和兑现承诺。与此同时，需求记录、决策日志和复盘还会给下一次同类工作留下更好的起点。

负责人应当让参与者获得与贡献相称的认可，在出现问题时也应主动承担解释责任。不过，解释责任并不意味着吸收全部系统责任。如果失败来自授权不足、资源缺失或者更高层级已经作出的决定，负责人就不应该用“担当”掩盖真实原因。

在政府和学校等组织中，预算、机会和利益的分配还必须遵守公开程序与利益冲突规则。个人关系可以帮助沟通，却不能成为私下处置公共资源的理由。

组织信用让别人愿意再次把事情交给你。但如果每一次成功都进一步增加组织对你的个人依赖，这份信用还没有真正转化成组织能力。

六、当你不在场，事情还能继续吗？ #

“组织离不开我”在短期内可以带来位置和谈判筹码，也可能慢慢把人锁在原来的角色里。

所有问题都来找同一个人，团队无法独立判断，组织既依赖他，又担心关键资源被他控制。不可替代可以是建立信用过程中的一个阶段，却不适合作为最终目标。

更成熟的做法，是把个人积累的资源转化成可以复用的组织能力。

负责人可以把私人建立的外部联系变成稳定接口，把经验变成可以检验的方法，把临时协调沉淀为明确的决策和升级路径。对数据与人工智能团队来说，版本控制、自动化测试、数据血缘、运行手册和交接文档，都是把个人知识写进系统的具体方式。

对项目负责人来说，真正的成功也不是所有项目以后都必须由自己协调，而是团队逐渐能够独立处理反复出现的依赖、决策和风险。

判断一次成功有没有真正改善组织，可以问几个简单的问题：

结果能否由别人验证？
方法能否由别人复用？
自己不在场时，事情能否继续运行？
再次遇到同类问题时，组织是否拥有比上一次更好的起点？

如果这些问题大多得到否定答案，所谓“不可替代”很可能只是关键信息仍然集中在个人手中。如果每个项目都需要同一位领导重新拍板、同一个人重新协调，组织就没有真正积累能力。

一个人即使摆脱了对上级的依附，也可能正在建立一套要求同事和下属依附自己的新结构。

并不是所有组织都欢迎这种转换。有些领导愿意明确授权、保留记录，并把有效做法变成团队机制；另一些领导更需要一个随时待命的“自己人”。

因此，衡量一个组织是否值得长期投入，不能只看它给个人多少机会。还可以观察：每次成功以后，角色是否变得更清楚，规则是否变得更稳定，其他人是否获得了独立做事的能力？

如果一次次成功只换来更深的私人绑定，那么离开有时比继续证明自己更理性。

总结：关系只能是起点 #

在不完善的组织里，人们无法等到所有制度完善以后再行动。具体人物的支持有时确实能够补上暂时断裂的决策链，让跨部门工作重新开始。

但这种支持只有在边界清楚时才值得接受。执行者需要先定义结果和依赖，再确认权限、资源与风险归属，最后才承诺进度。工作开始以后，用记录固定授权，如实报告风险，用结果建立信用，再把一次成功沉淀为别人可以验证、复用和接手的能力。

对刚进入组织的人来说，耐心不是消极等待，而是先观察事情实际上怎样发生。 不必急于通过承担所有问题来证明自己，也不必因为一两次受挫，就把所有协作都理解成权力游戏。可以先看看不同角色真正关心什么，哪些承诺最终会兑现，组织怎样对待犯错和提出异议的人，再决定自己愿意投入多少。

对已经工作多年的员工，以及负责工程或管理的人来说，经验的价值不只是更快找到办法，也包括知道哪些办法虽然短期有效，却会损害长期信用。“这里一直如此”解释得了某些做法为什么存在，却不能让隐瞒问题、扭曲数据、绕过专业判断或把责任转给新人变得合理。

局面越混乱，越需要把已知和未知说清楚，尊重事实，也尊重同事的专业判断和人格。这些做法未必让事情立刻变快，却决定了一个人最终会留下怎样的职业信用。

关系可以启动事情，却不应成为责任的最终基础。真正值得积累的，是一种能够离开具体人物继续运行的组织能力，而不是谁对谁的私人依赖。

附录：为什么跨职能团队更容易出现权责错位？ #

技术企业经常把完成一项业务目标所需要的不同角色组成跨职能小组（cross-functional team）。一些公司把这种团队称为 Squad。数据与人工智能小组可能包含以下成员，但不同公司的角色组合和命名并没有统一标准：

业务域技术负责人（Pillar Tech Lead）可能统筹多个小组的技术方向和工程标准；跨小组领域专家（cross-squad Subject Matter Expert，SME）则按需提供安全、隐私、平台或业务支持。架构师和其他专家既可能长期属于一个小组，也可能同时支持多个小组。

Spotify 在 2012 年发表的一篇文章推动了 Squad、Tribe、Chapter 和 Guild 等术语的传播。不过，Spotify 并没有发明跨职能团队。原文也明确说明，这只是 Spotify 当时工作方式的一张“快照”，而不是一套已经完成、可以照搬的标准模型[6]。

矩阵式组织（matrix organization）的历史则更早。随着大型复杂工程和项目管理的发展，组织逐渐需要同时保留项目目标与专业职能两条管理维度：项目线关注目标、进度和整体集成，职能线则负责专业能力、人员发展和工程标准[7]。

跨职能小组并不一定采用矩阵管理。只有当成员同时受到项目线和职能线的权责影响时，组织才具有比较典型的矩阵特征。

政府和学校未必使用 Squad、Chapter 这些名称，却同样可能存在类似结构。专项工作组、项目办公室或者跨学科团队负责完成某项任务，成员的任用、专业标准和长期发展仍由原部门或院系负责。

真正重要的从来不是复制哪一套称呼，而是弄清楚：任务线与职能线分别决定什么，两者发生冲突时又由谁裁决。

参考文献 #

[1] Granovetter, M. “Economic Action and Social Structure: The Problem of Embeddedness.” American Journal of Sociology, 91(3), 1985, pp. 481–510. https://doi.org/10.1086/228311

[2] House, R. J., Hanges, P. J., Javidan, M., Dorfman, P. W., and Gupta, V., eds. Culture, Leadership, and Organizations: The GLOBE Study of 62 Societies. Sage Publications, 2004.

[3] Edmondson, A. “Psychological Safety and Learning Behavior in Work Teams.” Administrative Science Quarterly, 44(2), 1999, pp. 350–383. https://doi.org/10.2307/2666999

[4] Association for Computing Machinery. “ACM Code of Ethics and Professional Conduct.” 2018. https://www.acm.org/code-of-ethics

[5] National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1, 2023. https://doi.org/10.6028/NIST.AI.100-1

[6] Kniberg, H., and Ivarsson, A. Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds. 2012. https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf

[7] Stuckenbruck, L. C. “The Matrix Organization.” Project Management Quarterly, 10(3), 1979, pp. 21–33. https://www.pmi.org/learning/library/matrix-organization-structure-reason-evolution-1837