关于 cross-functional-collaboration
面向跨职能团队的协作指导 Skill，适用于产品经理、设计师、工程师等角色。它借鉴产品负责人的经验，帮助明确职责、改善沟通并建立更稳固的合作关系。
主要功能
- 01诊断协作摩擦
- 02明确不同角色的预期
- 03建议团队结构与会议节奏
- 04推动利益相关方与工程师直接沟通
- 05用原型减少交接摩擦
适用场景
- 01明确 PM、设计、工程与数据团队的共同职责
- 02让工程师参与客户探索
- 03在产品三人组中解决分歧
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/cross-functional-collaboration确认已加载。
附带文件references/guest-insights.md
详细介绍
跨职能协作
借助 57 位产品领导者总结的框架，帮助用户高效开展跨职能协作。这些领导者曾在 Linear 到 Airbnb 等公司打造高绩效跨职能团队。
如何提供帮助
用户寻求跨职能协作方面的帮助时：
- 诊断摩擦点 - 判断问题出在职责不清、沟通模式还是组织结构
- 明确预期 - 帮助定义各职能对彼此的期望
- 设计合适的结构 - 建议团队组成和会议节奏
- 建立关系 - 强调协作顺利开展所需的人际因素
核心原则
慷慨分享功劳
Camille Fournier：“工程师有时会觉得自己的工作没有得到认可，因为 PM 抢走了所有功劳。因此，应尽一切努力分享功劳，并让工程团队参与其中。”让工程师向高管和客户展示自己的工作。
采用“是的，而且”的思维方式
Adam Grenier：“如果你用‘是的，而且’的思路去看，通常两种说法都成立。这两件事可以同时为真。你的目标可以和我的不同。”同时认可不同团队的目标，而不是制造虚假的二选一。
写下彼此的期望
Nikita Miller：“让 PM、设计、工程和数据负责人写下对各自合作伙伴的期望。为不同角色建立一份‘契约’，明确共同承担的责任。”每 3-6 个月重新审视这些定义。
让工程师参与探索
Christine Itwaru：“早期，我们开始越来越多地邀请工程师参加客户会议。开始这么做后，工程团队的反响非常好。”直接接触客户有助于培养技术共情。
不要当传声筒
Camille Fournier：“如果你让自己处于中间位置，在利益相关者和工程师之间传话，那会非常烦人，也会浪费所有人的时间。”需要深入讨论技术问题时，直接让利益相关者与工程师沟通。
每天直接与工程师合作
Marty Cagan：“如果你没有每天和一组工程师一起解决问题，那你就不是产品经理。”去掉充当协调人的“产品负责人”等中间角色。
建立真正的关系
Ebi Atawodi：“你知道工程经理的生日吗？知道他们的入职纪念日吗？知道他们为什么做现在这份工作吗？”牢固的合作关系建立在人与人之间真实的联结之上。
代码是共同语言
Amjad Masad：“大家共享的共同语言是代码。如果这种语言真正变成可运行的原型和应用，会怎么样？”使用可运行的原型，而不是静态模型，以减少交接摩擦。
拥抱“产品三人组”
Teresa Torres：“三人组由产品经理、设计师和软件工程师组成。如果你从未在一个运作良好的三人组中工作过，这会颠覆你的认知。”出现分歧时，应寻求更多数据或更好的方案，而不是仗势压人。
可用于帮助用户的问题
- “各职能对彼此有什么期望——你们写下来了吗？”
- “工程师会参与客户探索，还是只会收到规格说明？”
- “发生冲突时，谁来拍板？他们能多快采取行动？”
- “你了解工程和设计合作伙伴的个人职业目标吗？”
- “你是在充当翻译，还是在让利益相关者直接与工程师沟通？”
需要指出的常见错误
- 独占功劳 - PM 将工程师完成的工作归功于自己
- 传声筒 - 在利益相关方和工程师之间充当不必要的中间人
- 将工程师排除在构思之外 - 把他们当作资源，而非创意伙伴
- 职责边界不清 - 未明确各自负责的事项，导致所有事情都落到 PM 身上
- 忽视人的因素 - 良好的协作需要把合作伙伴当作真实的人来了解
深入了解
查看 references/guest-insights.md，了解 57 位嘉宾分享的全部 72 条见解
相关技能
- 开展高效的一对一沟通
- 进行艰难的对话
- 委派工作
- 向上管理