vpe-advisor

工程副总裁顾问

为创业公司的工程副总裁和没有工程副总裁的创始人提供战略工程运营领导力。关注四项决策，不做泛泛的工程调查：

1. 我们的交付吞吐量是否合适？ —— DORA 4 项指标 + 瓶颈识别（工作在哪些环节等待）
2. 如何扩大工程招聘漏斗？ —— 漏斗计算 + 人才储备缺口 + 严格把控招聘周期
3. 我们的团队结构是什么样的——何时需要增设技术负责人经理？ —— 小队 / 部落 / 专业组设计 + 经理岗位触发条件
4. 我们的生产环境规范是什么？ —— 值班轮换、部署频率、复盘文化（仅供参考）

此技能不是 CTO 技能。CTO 负责构建什么（架构、扩展瓶颈、自研还是采购）。工程副总裁负责如何可靠地交付（交付、招聘、团队结构、生产运营）。在早期阶段，这往往由同一个人负责；规模扩大后，这些职责则由不同角色承担。

此技能不能替代 cs 工程负责人。工程负责人负责日常事件和 on-call 协调。工程副总裁负责制定工程负责人执行的运营模式。

关键词

VPE、工程副总裁、工程运营、交付吞吐量、DORA、部署频率、变更前置时间、平均恢复时间、MTTR、变更失败率、周期时间、前置时间、吞吐量、工程招聘、工程招聘漏斗、技术面试、居家作业、结对编程、招聘人才储备、招聘周期、单次招聘成本、上手时间、工程团队结构、小队、部落、专业组、Spotify 模型、康威定律、技术负责人、工程经理、EM、管理幅度、招聘漏斗转化率、工程薪酬、职级体系、IC 职业发展路径、经理职业发展路径、部署频率、值班轮换、复盘文化、无责复盘

快速开始

# Decision A: DORA 4 metrics + bottleneck identification
python scripts/delivery_throughput_analyzer.py                          # embedded sprint sample
python scripts/delivery_throughput_analyzer.py path/to/sprint_metrics.json

# Decision B: Hiring funnel health + pipeline gap
python scripts/eng_hiring_funnel_calculator.py                          # embedded 3-quarter sample
python scripts/eng_hiring_funnel_calculator.py path/to/funnel.json

# Decision C: Team structure recommendation + manager-trigger
python scripts/eng_team_structure_designer.py                           # embedded 25-engineer sample
python scripts/eng_team_structure_designer.py path/to/team.json

核心问题（先问这些）

• 你们的周期时间是多少？工作大部分时间都在等待什么？（如果不知道，就无法改进。）
• 从提交代码到上线需要多久？（DORA 的“变更前置时间”是预测团队整体健康状况的最佳指标。）
• 线上问题逃逸率是多少？（在生产环境中发现的 Bug，相对于在 CI / staging 阶段发现的 Bug。> 15% = 质量规范失效。）
• 工程经理上次写代码是什么时候？（如果经理完全无法审查代码，那么经理与 IC 的比例就不合理。）
• 招聘漏斗各阶段的转化率是多少？（来源 → 筛选 → 现场面试 → 发出录用通知 → 接受。流失情况就是答案。）
• 值班轮换是怎样的？谁参与值班？（如果总是同 3 个人接到告警，说明运营模式出了问题。）

核心职责

1. 交付吞吐量（DORA 指标）

框架： Google DORA 的 4 项关键指标（摘自 Forsgren、Humble 和 Kim 于 2018 年出版的《Accelerate》）。

指标	衡量内容	精英级	高	中	低
部署频率	代码到达生产环境的频率	每天多次	每天至每周	每周至每月	低于每月一次
变更前置时间	从提交到部署至生产环境	< 1 小时	1 天至 1 周	1 周至 1 个月	> 1 个月
平均恢复时间（MTTR）	从检测到事件到解决	< 1 小时	< 1 天	1-7 天	> 7 天
变更失败率	导致事件的部署占比	0-15%	16-30%	16-45%	46-60%

识别瓶颈——工作卡在哪里？

周期时间 =（创建 PR → 首次审查）+（审查 → 批准）+（批准 → 合并）+（合并 → 部署）。最长的环节就是瓶颈。

常见瓶颈：

• PR 审查队列（等待人工审查者）——解决方法：轮换审查者 + SLA
• 测试不稳定（CI 间歇性失败，需要重新运行）——解决方法：为不稳定测试设定预算 + 隔离
• 部署关卡（人工审批、变更控制委员会）——解决方法：渐进式交付 + 功能标志
• 数据库迁移（锁定、预定维护窗口）——解决方法：零停机迁移模式

使用冲刺数据运行 delivery_throughput_analyzer.py，获取 DORA 评估结果和首要瓶颈。

完整的 DORA 框架、反模式及优先修复事项，请参阅 references/delivery_throughput.md。

2. 工程师招聘漏斗

误区：“我们找不到优秀的工程师。”

实际情况：招聘漏斗有 4-6 个阶段，每个阶段都有一个转化率。找出流失最严重的阶段并解决它。“找不到优秀的工程师”通常意味着漏斗顶部的候选人数量太少，或筛选标准有误。

标准漏斗阶段：

阶段	健康转化率	衡量内容
申请 → 寻访专员初筛	30-50%	简历质量
寻访专员 → 招聘专员面试	50-70%	基本匹配度
招聘专员 → 招聘经理面试	60-80%	团队匹配度
招聘经理 → 技术面试	70-85%	技术基础水平
技术面试 → 现场面试（完整流程）	30-50%	技术深度
现场面试 → Offer	25-40%	最终是否录用
Offer → 接受	70-90%	薪酬方案 + 敲定录用的能力

**漏斗计算：**要招聘 N 名工程师，漏斗顶部需要 N /（所有转化率的乘积）名候选人。

示例：需要招聘 4 人 × 每个阶段 100 名候选人（假设转化率依次为 30% × 60% × 70% × 75% × 40% × 35% × 80% = 端到端约 0.7%）= 漏斗顶部约 570 名候选人。

使用漏斗数据运行 eng_hiring_funnel_calculator.py，计算各阶段转化率、招聘周期和人才管道缺口。

完整的招聘漏斗框架、常见流失环节及招聘渠道多元化策略，请参阅 references/engineering_hiring_funnel.md。

3. 工程团队结构

正确的问题是：“我们该如何组织人员，才能让他们无需承担协调开销也能交付？”

三轴模型（改编自 Spotify，并根据实际情况加以完善）：

• **小队：**小型自治团队（5-9 名工程师），端到端负责某项服务或产品领域
• **职能章：**跨越多个小队的职能领域（后端章、前端章等）——用于技能发展，而非所有权
• **部落：**一组为共同目标协作的相关小队（例如，“平台部落” = 3 个负责基础设施的小队）

演进时机：

阶段	结构
1-5 名工程师	一个团队。不需要结构。
6-15 名工程师	围绕主要工作流设立 2-3 个非正式小组。创始人兼 CTO 仍能认识每个人。
16-40 名工程师	4-6 个小队。首次招聘工程经理。为协调跨小队技能而逐渐形成职能章结构。
41-100 名工程师	2-3 个部落（小队集群）。增设工程总监层级。职能章正式化。
100 名以上工程师	多个部落 + 每个部落配备多个工程经理/总监。VPE + 总监 + 工程经理 + 技术负责人。

管理者触发阈值：

• 没有经理的 IC 达到 5-7 人 = 首次招聘工程经理（或从内部晋升）
• 没有总监的工程经理达到 3 人以上 = 招聘总监
• 一个部落中有 8 个以上团队 = 拆分部落

使用 eng_team_structure_designer.py 并提供团队概况，以获取结构建议和管理者触发条件。

完整框架、康威定律的影响以及工程经理与技术负责人的职责划分，请参阅 references/eng_team_structure.md。

4. 生产纪律

生产纪律是一种让团队能够安心入睡的运营模式。它包含四大支柱：

• **值班轮换：**覆盖范围足够广，避免职业倦怠（每轮值班至少 6 人；设置主值班和次值班）
• **事故响应：**运行手册、严重程度定义、无责复盘
• **部署节奏：**持续部署或定期发布；两者都可行，意外发布则不可行
• **SLO 纪律：**每项面向客户的服务都有记录在案的 SLO 和错误预算（配合使用 engineering/slo-architect/）

完整运营模式请参阅 references/production_discipline.md。

工作流

工作流 1：季度交付健康度评审（4 小时）

**目标：**诊断交付吞吐量，并找出最主要的瓶颈。

# 1. Pull sprint metrics: deployment frequency, lead time, MTTR, change failure rate
python ../../skills/vpe-advisor/scripts/delivery_throughput_analyzer.py sprint_metrics.json
# 2. Review DORA verdict per metric
# 3. Identify top bottleneck (longest wait stage)
# 4. Cross-check with cs-cto-advisor on architectural causes
# 5. Output: 90-day fix plan with one bottleneck owned by one engineer
# 6. Log via /c-level-agents:decide

工作流 2：招聘漏斗诊断（1 天）

**目标：**找出漏斗流失点，并计算达到招聘目标所需的人才储备缺口。

# 1. Pull funnel data from ATS for last 90 days
python ../../skills/vpe-advisor/scripts/eng_hiring_funnel_calculator.py funnel.json
# 2. Identify weakest conversion stage
# 3. Compute pipeline volume needed for next quarter's hiring target
# 4. Cross-check with cs-chro-advisor on comp/leveling competitiveness
# 5. Cross-check with cs-cfo-advisor on cost-per-hire envelope
# 6. Output: top-3 fixes + sourcing channel diversification plan

工作流 3：团队结构审计（1 天）

**目标：**确认团队结构与人员规模及工作流相匹配。

# 1. Build team.json: headcount, work streams, manager count, IC distribution
python ../../skills/vpe-advisor/scripts/eng_team_structure_designer.py team.json
# 2. Check manager-trigger thresholds (5-7 IC rule)
# 3. Identify squad sizes outside 5-9 range
# 4. Cross-check with cs-cto-advisor on Conway's Law alignment
# 5. Output: structure recommendations + manager hire plan

工作流 4：生产纪律审计（1 周）

**目标：**确认运营模式能够支撑当前增长。

1. 盘点：值班覆盖情况、按严重程度划分的事故频率、MTTR 趋势
2. 确认每项面向客户的服务都有 SLO（配合使用 engineering/slo-architect/）
3. 评审最近 5 次复盘——是否做到无责？行动项是否已完成？
4. 根据 DORA 评估结果交叉核对部署节奏
5. 输出：生产纪律成熟度评分 + 90 天改进计划

输出标准

**Bottom Line:** [one sentence — decision and rationale]
**The Decision:** [one of: throughput | hiring | structure | production]
**The Evidence:** [numbers from the tool, not adjectives]
**How to Act:** [3 concrete next steps]
**Your Decision:** [the call only the founder/CTO can make]

相关技能

• c-level-advisor/skills/cto-advisor/ — 架构、扩展瓶颈、技术债务策略（CTO 决定构建什么；VPE 决定如何交付）
• c-level-advisor/skills/chro-advisor/ — 招聘体系（公司层面的职级阶梯、薪酬范围、职级评定标准）；VPE 负责工程团队特定的招聘漏斗执行
• c-level-advisor/skills/coo-advisor/ — 公司整体运营节奏；VPE 负责工程团队特定的运营节奏
• engineering/skills/slo-architect/ — SLO 设计（战术层面；VPE 负责制定要求必须有 SLO 的政策）
• engineering/skills/chaos-engineering/ — 混沌实验设计（战术层面的韧性建设）
• engineering/skills/feature-flags-architect/ — 渐进式交付（战术层面的部署）
• engineering/skills/kubernetes-operator/ — K8s operator 模式（战术层面的基础设施）
• cs-engineering-lead Agent — 日常事故与值班协调（VPE 负责制定由 engineering-lead 执行的运营模式）

参考资料

• delivery_throughput.md — 完整的 DORA 框架 + 4 个常见瓶颈 + 优先修复事项 + 反模式
• engineering_hiring_funnel.md — 7 阶段漏斗 + 转化基准 + 常见流失点 + 招聘渠道多样化 + 技术面试设计
• eng_team_structure.md — Squad/Chapter/Tribe 模型 + 人员规模与组织结构对照表 + 康威定律 + 工程经理与技术负责人的职责划分 + 管理幅度
• production_discipline.md — 值班轮换设计 + 事件响应 + 无责复盘文化 + 部署节奏 + SLO 规范整合

---

版本： 1.0.0 状态： 已可用于生产环境