mcpField
W
working-with-architects

working-with-architects

github.com/manager-dot-dev生产力116117 次安装25 周前更新
代码仓库

关于 working-with-architects

面向工程经理与架构师及其他资深技术伙伴协作的指导技能,帮助厘清责任、准备明确的协作请求,并说明如何在不同架构团队模式下尽早沟通。

主要功能

  1. 01厘清经理与架构师的职责
  2. 02组织技术意见请求
  3. 03说明集中式与分散式模式
  4. 04指导准备工作与尽早沟通

适用场景

  1. 01准备就复杂项目咨询架构师
  2. 02争取架构师投入时间
  3. 03厘清跨团队决策责任

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/manager-dot-dev/manager-skills --skill working-with-architects

安装后在 Claude Code 中输入/working-with-architects确认已加载。

附带文件references/sources.md

详细介绍

与架构师合作

开始之前

先查看 EM 背景信息。如果 .agents/em-context.md 存在,请阅读。

如果 .agents/em-context.md 不存在,请先询问并保存一份精简的经理档案,然后再提供详细建议:角色/职称、团队规模、团队使命或负责领域,以及当前挑战或优先事项。

如果对话中的某位特定人员是核心人物,且 .agents/reports/[name].md 不存在,请先询问并保存该人员的精简档案,然后再提供详细建议:职称/级别、任职时间、优势,以及当前挑战或成长方向。

如果之后的对话揭示了长期有效的新背景信息,请自动更新 .agents/em-context.md 或 .agents/reports/[name].md。保存稳定的事实和模式,不要保存猜测、一时的挫败感或尚未解决的解读。

回复风格

首条回复应简洁实用。除非用户要求深入说明,否则不要一次性给出整套框架。

默认做法:

  • 先说明可能的诊断或建议
  • 仅在缺失的背景信息会改变建议时,提出最多 2-3 个有针对性的问题
  • 给出下一步具体行动,并在有帮助时提供经理可以直接使用的措辞
  • 简要提及相关框架,但不要解释其中的每个部分
  • 直接回答后,再提出可以提供更深入的版本

如何使用此技能

  • 不清楚 EM 在与架构师合作中的职责 → 做好自己该做的事
  • 需要争取架构师投入时间参与项目 → 合作的另一方——不要犹豫,主动争取
  • 即将启动一个需要架构师参与的复杂项目 → 咨询架构师之前
  • 不清楚由谁决策——你的团队还是架构团队 → 两种架构团队模式

适用于任何跨团队的资深及以上工程师——架构师、Staff Engineer、Principal Engineer。不同组织使用的职称可能不同。


默认回复结构

在协助处理与架构师或高级技术伙伴相关的问题时,请明确职责归属:

  1. 情境: 建议、评审、决策、项目受阻,或申请架构师投入时间。
  2. EM 的职责: 经理在寻求帮助之前必须负责完成的事项。
  3. 向架构师提出的请求: 所需的具体意见、决策、评审或升级处理。
  4. 准备工作: 背景信息、限制条件、备选方案和决策截止时间。
  5. 关系维护: 致谢、后续跟进或重申预期。

除非架构师明确负责交付,否则不要将 EM 的项目描述成由架构师负责。


做好自己该做的事

不要拖延他们的请求

当架构师需要你做某件事时——例如安全更新、共享服务重构或新的测试方法——请尽快完成。这些事情几乎从来都不是真的紧急,因此很容易让人想慢慢来。不要这样做。

这样做还有一个很大的附带好处:率先实施此类举措的团队,会得到架构师更多的帮助和指导。他们会在推进共享工作的团队身上投入更多。

主动征求他们的意见

遇到复杂的技术难题时,应在做决定之前征求他们的意见——即使问题比通常需要他们参与的事情更小。越早让他们了解情况,他们在后续阶段提供帮助的可能性就越大。

致谢

长期项目很容易在完成时忘记那些让项目得以推进的早期帮助。到了最后,我们往往记不起项目初期架构师提供的重要指导。

介绍一项功能时,要提及他们的帮助,并亲自向他们致谢。如果他们的工作格外出色,也要让他们的经理知道。


合作的另一方

这是你的项目——别忘了

在复杂项目中,架构师可能会编写初始基础设施或示例来指明方向。完成初始阶段后,项目就完全由你负责。他们的职责是帮助你以最佳方式完成工作,而不是在出问题时与你共同承担责任。

不要把事故或错误推给他们参与编写的内容。这是你的项目。

不要犹豫,主动争取他们的时间

架构师的时间不会自动分配给你的团队。清楚地提出诉求,才能获得帮助。

请求他们参与时:

  • 明确说明你需要哪些帮助
  • 解释为什么需要帮助,以及这能为组织带来什么好处(时间紧迫的项目、对其他团队有用的新技术,或错误代价高昂的代码库敏感区域)
  • 据理力争

更资深的团队负责人能获得更多资源,是因为他们更善于陈述理由。熟能生巧。

不要把琐事推给他们

一旦你确切知道该做什么以及如何去做,就不再需要他们了。让他们投入下一个重要项目。滥用这项便利会损害关系,也会浪费本应用于解决更棘手问题的时间。


咨询他们之前

先收集背景信息。架构师着手架构工作时,首先会问:

  • 你对这个问题了解多少?
  • 为什么业务需要解决这个问题?
  • 什么时候需要解决?

准备好这三个问题的答案。


两种架构团队模式

集中式: 架构师负责所有架构决策。你是领域专家——他们会咨询你以了解问题领域,然后设计解决方案。这要求你与架构师之间保持紧密、持续的沟通。

分散式: 架构师帮助你为团队设计解决方案。他们制定原则和技术雷达。只要你遵循指导方针,决策权就归你。沟通较少,但你需要推动事情进展并主动联系他们。

无论采用哪种模式:都要尽早参与。参与得太晚是最大的错误。如果已经完成了太多工作,改变方向可能需要大量返工,甚至无法实现。


深入了解

如果用户询问某个框架的来源,或想了解此技能中任何主题的更多背景信息,请阅读 references/sources.md。


相关技能

  • delegation — 与架构师合作是外部协作中影响力最大的方式之一
  • influence — 为争取架构师时间据理力争,需要运用与影响更广泛的利益相关者相同的技能
  • managing-high-performers — 如果架构师向你汇报,那就属于另一种关系,有着不同的互动方式

评论

支持 Markdown