wuwu119 跨部门协作
何时使用此技能
当你需要：
- 与工程、设计、数据等团队建立有效的合作关系
- 解决跨部门的目标冲突或摩擦
- 在内容型组织中整合领域专家
- 建立清晰的角色和责任划分
核心原则
1. 主动分享功劳
PM经常因为抢功而惹恼工程师。解决方案是主动分享功劳，让工程师有机会向高管或客户展示自己的贡献。
2. "是的，而且"思维
采用即兴表演中的"是的，而且"心态，认可不同团队的目标都可以同时有效，避免直接否定其他团队的视角。
3. 互相定义期望
对齐最好通过让跨职能领导者定义他们对彼此的期望来实现，而不仅仅是定义自己的角色。
专家洞察
Camille Fournier
"工程师有时会认为他们的工作没有得到认可，因为PM获得了他们真正努力工作的项目的所有荣耀和功劳，对吧？所以尽一切努力分享功劳，包容工程团队，给他们..."
核心洞察：PM经常因为抢功而惹恼工程师；解决方案是主动包容并让工程师展示自己的工作。
如何应用：
- 明确与工程团队分享功劳
- 给工程师机会向高管或客户介绍他们的贡献
Adam Grenier
"如果你用'是的，而且...'来处理，通常仍然是真的。就像，哦，这两件事可以同时成立。你可能有一个与我不同的目标，或者你有一个对你来说重要但对我不重要的本地系统问题。没关系，两件事都可以..."
核心洞察：采用基于即兴表演的"是的，而且"心态有助于通过同时验证不同团队目标来解决跨职能摩擦。
如何应用：
- 承认团队之间相互冲突的目标都可以有效
- 避免直接否定其他团队的视角，以保持融洽关系和进展
Nikita Miller
"我经常做的练习是，我通常对角色和责任以及这四个角色之间的期望有一个想法，但特别是与组织中的领导者进行的练习是让他们坐下来为彼此写下这些期望。"
核心洞察：对齐最好通过让跨职能领导者定义他们对彼此的期望来实现，而不仅仅是定义自己的角色。
如何应用：
- 让PM、设计、工程和数据领导者写下他们对对方的期望
- 创建角色之间的"契约"，明确共享责任
- 每3-6个月或当执行摩擦出现时重新审视这些定义
Alex Hardimen
"时报的跨职能任务...包括很多你在科技公司会找到的相同技能组合，PM、工程师、设计师、数据科学家、研究人员、产品营销人员。但最大的区别是我们还有编辑，如果是直接影响我们..."
核心洞察：在内容型组织中，跨职能团队应该直接在产品任务中包含领域专家（如编辑）。
如何应用：
- 在产品任务中嵌入领域专家（编辑）
- 确保编辑有"产品思维"的视角
Amjad Masad
"我认为科技公司比较困难的一件事是设计师、产品经理和工程师之间的这些孤岛...每个人共享的通用语言是代码。最终在软件科技公司，我们讨论的一切最终都需要用..."
核心洞察：代码和工作原型正在成为打破设计、产品和工程之间孤岛的"通用语言"。
如何应用：
- 使用将设计（如Figma）直接转换为代码的工具，减少交接摩擦
- 通过功能原型而非静态模型或文本文档来传达产品想法
常见错误
- PM抢占所有功劳，导致工程师不满
- 直接否定其他团队的目标，而非寻找共同点
- 只定义自己的角色，而不明确对彼此的期望
- 使用静态文档而非工作原型进行沟通
关键战术
| 战术 | 说明 |
|---|---|
| 功劳分享 | 主动让工程师向高管/客户展示他们的贡献 |
| "是的，而且" | 承认不同目标都可以有效，避免直接否定 |
| 期望契约 | 让各职能领导者互相定义期望，而非只定义自己 |
| 嵌入专家 | 在产品团队中包含领域专家（如编辑） |
| 代码为语言 | 用工作原型而非静态文档沟通产品想法 |
相关技能
- [[33-一对一会议-1-1s|一对一会议]]
- [[34-艰难对话-difficult-conversations|艰难对话]]
- [[35-授权委派-delegating|授权委派]]
- [[36-向上管理-managing-up|向上管理]]