关于 working-with-architects
面向工程经理与架构师及其他资深技术伙伴协作的指导技能,帮助厘清责任、准备明确的协作请求,并说明如何在不同架构团队模式下尽早沟通。
主要功能
- 01厘清经理与架构师的职责
- 02组织技术意见请求
- 03说明集中式与分散式模式
- 04指导准备工作与尽早沟通
适用场景
- 01准备就复杂项目咨询架构师
- 02争取架构师投入时间
- 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。不同组织使用的职称可能不同。
默认回复结构
在协助处理与架构师或高级技术伙伴相关的问题时,请明确职责归属:
- 情境: 建议、评审、决策、项目受阻,或申请架构师投入时间。
- EM 的职责: 经理在寻求帮助之前必须负责完成的事项。
- 向架构师提出的请求: 所需的具体意见、决策、评审或升级处理。
- 准备工作: 背景信息、限制条件、备选方案和决策截止时间。
- 关系维护: 致谢、后续跟进或重申预期。
除非架构师明确负责交付,否则不要将 EM 的项目描述成由架构师负责。
做好自己该做的事
不要拖延他们的请求
当架构师需要你做某件事时——例如安全更新、共享服务重构或新的测试方法——请尽快完成。这些事情几乎从来都不是真的紧急,因此很容易让人想慢慢来。不要这样做。
这样做还有一个很大的附带好处:率先实施此类举措的团队,会得到架构师更多的帮助和指导。他们会在推进共享工作的团队身上投入更多。
主动征求他们的意见
遇到复杂的技术难题时,应在做决定之前征求他们的意见——即使问题比通常需要他们参与的事情更小。越早让他们了解情况,他们在后续阶段提供帮助的可能性就越大。
致谢
长期项目很容易在完成时忘记那些让项目得以推进的早期帮助。到了最后,我们往往记不起项目初期架构师提供的重要指导。
介绍一项功能时,要提及他们的帮助,并亲自向他们致谢。如果他们的工作格外出色,也要让他们的经理知道。
合作的另一方
这是你的项目——别忘了
在复杂项目中,架构师可能会编写初始基础设施或示例来指明方向。完成初始阶段后,项目就完全由你负责。他们的职责是帮助你以最佳方式完成工作,而不是在出问题时与你共同承担责任。
不要把事故或错误推给他们参与编写的内容。这是你的项目。
不要犹豫,主动争取他们的时间
架构师的时间不会自动分配给你的团队。清楚地提出诉求,才能获得帮助。
请求他们参与时:
- 明确说明你需要哪些帮助
- 解释为什么需要帮助,以及这能为组织带来什么好处(时间紧迫的项目、对其他团队有用的新技术,或错误代价高昂的代码库敏感区域)
- 据理力争
更资深的团队负责人能获得更多资源,是因为他们更善于陈述理由。熟能生巧。
不要把琐事推给他们
一旦你确切知道该做什么以及如何去做,就不再需要他们了。让他们投入下一个重要项目。滥用这项便利会损害关系,也会浪费本应用于解决更棘手问题的时间。
咨询他们之前
先收集背景信息。架构师着手架构工作时,首先会问:
- 你对这个问题了解多少?
- 为什么业务需要解决这个问题?
- 什么时候需要解决?
准备好这三个问题的答案。
两种架构团队模式
集中式: 架构师负责所有架构决策。你是领域专家——他们会咨询你以了解问题领域,然后设计解决方案。这要求你与架构师之间保持紧密、持续的沟通。
分散式: 架构师帮助你为团队设计解决方案。他们制定原则和技术雷达。只要你遵循指导方针,决策权就归你。沟通较少,但你需要推动事情进展并主动联系他们。
无论采用哪种模式:都要尽早参与。参与得太晚是最大的错误。如果已经完成了太多工作,改变方向可能需要大量返工,甚至无法实现。
深入了解
如果用户询问某个框架的来源,或想了解此技能中任何主题的更多背景信息,请阅读 references/sources.md。
相关技能
delegation— 与架构师合作是外部协作中影响力最大的方式之一influence— 为争取架构师时间据理力争,需要运用与影响更广泛的利益相关者相同的技能managing-high-performers— 如果架构师向你汇报,那就属于另一种关系,有着不同的互动方式