vpe-review

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

/cs:vpe-review — VPE Forcing Questions

/cs:vpe-review — VPE 质询问题

Command:

/cs:vpe-review <plan>

The throughput-first VPE pressure-tests any plan touching eng operations. Six questions before any delivery commitment, eng hiring expansion, team restructure, or production-discipline change.

命令：

/cs:vpe-review <计划>

以吞吐量优先的VPE会对所有涉及工程运营的计划进行压力测试。在做出任何交付承诺、工程师招聘扩张、团队重组或生产规范变更前，需先回答以下六个问题。

When to Run

适用场景

Before quarterly delivery commitment (sprint planning, OKR review)
Before approving an eng hiring plan
Before restructuring eng teams (splitting/merging squads, adding tribes)
Before deciding whether to hire a VPE separately from CTO (or merge them)
When production incidents are increasing
When sprint velocity is dropping but everyone says "we're working hard"

季度交付承诺前（冲刺规划、OKR评审）
批准工程师招聘计划前
重组工程团队前（拆分/合并小组、增设部落）
决定是否单独聘请VPE而非由CTO兼任（或合并两者职责）前
生产事故增多时
冲刺速度下降但所有人都表示“我们在努力工作”时

The Six VPE Questions

六大VPE质询问题

1. What's the cycle time, and where does work wait?

1. 周期时长是多少？工作在哪个环节等待？

No DORA, no diagnosis.

Lead Time for Changes is the single best health metric
If you can't decompose cycle time into stages, you can't fix the bottleneck
Run
```
delivery_throughput_analyzer.py
```

没有DORA数据，就无法诊断。

变更前置时间是最能体现健康度的单一指标
若无法将周期时长分解为各个阶段，就无法解决瓶颈问题
运行
```
delivery_throughput_analyzer.py
```

2. What's the DORA performance level on all 4 metrics?

2. 四项DORA指标的表现等级如何？

One Elite metric and three Lows = bad. Four Highs = healthy.

Deployment Frequency, Lead Time, MTTR, Change Failure Rate
The worst metric defines overall level
Fix lead time first; everything else follows

一项精英级指标+三项低级指标=不健康。四项高级指标=健康。

部署频率、前置时间、平均恢复时间（MTTR）、变更失败率
最差的指标决定整体等级
优先解决前置时间问题；其他问题会随之改善

3. Where is the hiring funnel leaking?

3. 招聘漏斗的漏洞在哪里？

"Can't find good engineers" is wrong.

Specific stage is over-filtering OR top-of-funnel volume is too low OR offer-to-accept is broken
Run
```
eng_hiring_funnel_calculator.py
```
If offer-to-accept < 70%, comp is below market or close discipline is weak

“找不到优秀工程师”的说法是错误的。

要么是某个阶段筛选过于严格，要么是漏斗顶部候选人数量不足，要么是Offer接受环节出现问题
运行
```
eng_hiring_funnel_calculator.py
```
若Offer接受率<70%，则薪酬低于市场水平或Closing环节能力薄弱

4. Is the team structure healthy for the headcount?

4. 团队架构是否与人员规模匹配？

5-9 ICs per squad; 5-8 ICs per EM; 4-6 EMs per director.

Run
```
eng_team_structure_designer.py
```
Manager-trigger fires when 5+ ICs have no dedicated EM
Director-trigger fires when 3+ EMs report directly to VPE/CTO

每个小组（squad）5-9名独立贡献者（IC）；每个工程经理（EM）管理5-8名IC；每个总监管理4-6名EM。

运行
```
eng_team_structure_designer.py
```
当5名以上IC没有专属EM时，触发经理预警
当3名以上EM直接向VPE/CTO汇报时，触发总监预警

5. What's the production discipline maturity?

5. 生产规范成熟度如何？

Level 1-5; aim for Level 3 at growth stage.

On-call rotation ≥ 6 people
Severity-defined incident response with blameless postmortems
SLOs on customer-facing services (pair with
```
engineering/slo-architect/
```
)
Continuous deployment OR scheduled — not "usually one, sometimes the other"

等级1-5；成长期目标为等级3。

轮值待命人数≥6人
基于严重程度定义事故响应流程，开展无责事后复盘
面向客户的服务设置SLO（搭配
```
engineering/slo-architect/
```
使用）
要么持续部署，要么定期部署——不能“通常用一种，偶尔用另一种”

6. Are we adding a VPE separately, or is CTO doing both?

6. 我们是单独聘请VPE，还是由CTO兼任？

If CTO is spending > 50% on management vs strategy, VPE is needed.

Or: VPE complement when CTO is co-founder more comfortable with strategy
VPE owns operating model; CTO owns architecture
At small scale (< 20 eng), one person can do both

若CTO在管理工作上花费的时间超过战略工作的50%，则需要聘请VPE。

或者：当CTO作为联合创始人更擅长战略时，VPE可作为补充
VPE负责运营模式；CTO负责架构
规模较小时（<20名工程师），一人可兼任两者职责

Workflow

工作流程

bash

undefined

bash

undefined

1. Delivery throughput

1. 交付吞吐量

python ../../../skills/vpe-advisor/scripts/delivery_throughput_analyzer.py sprint_metrics.json

2. Hiring funnel

2. 招聘漏斗

python ../../../skills/vpe-advisor/scripts/eng_hiring_funnel_calculator.py funnel.json

3. Team structure

3. 团队架构

python ../../../skills/vpe-advisor/scripts/eng_team_structure_designer.py team.json

undefined

python ../../../skills/vpe-advisor/scripts/eng_team_structure_designer.py team.json

undefined

Output Format

输出格式

markdown

undefined

markdown

undefined

VPE Review: <plan>

VPE 审查：<计划>

Date: YYYY-MM-DD

日期： YYYY-MM-DD

The Decision Being Made

待决策事项

[throughput | hiring | structure | production | VPE-vs-CTO]

[吞吐量 | 招聘 | 架构 | 生产 | VPE与CTO职责划分]

Delivery Throughput (if applicable)

交付吞吐量（如适用）

DORA overall: Elite / High / Medium / Low
Worst metric: <DF | LT | MTTR | FR>
Bottleneck: <stage> (X% of cycle time)
Top fix: <action + owner>

DORA整体等级：精英级 / 高级 / 中级 / 低级
最差指标：<DF | LT | MTTR | FR>
瓶颈：<阶段>（占周期时长的X%）
首要解决方案：<行动 + 负责人>

Hiring Funnel (if applicable)

招聘漏斗（如适用）

End-to-end conversion: X%
Weakest stage: <stage>
Pipeline gap: +N candidates needed
Top fix: <specific action>

端到端转化率：X%
最弱环节：<阶段>
缺口：需补充N名候选人
首要解决方案：<具体行动>

Team Structure (if applicable)

团队架构（如适用）

Recommended: <informal pods / squads / tribes>
Manager trigger fired: yes/no
Director trigger fired: yes/no
Action: <hire EM | hire director | split squad>

推荐架构：<非正式小组 / 正式小组 / 部落>
触发经理预警：是/否
触发总监预警：是/否
行动：<聘请EM | 聘请总监 | 拆分小组>

Production Discipline (if applicable)

生产规范（如适用）

Current maturity level: 1-5
Next practice to add: <specific>
SLO coverage: X / Y services

当前成熟度等级：1-5
下一步需添加的实践：<具体内容>
SLO覆盖范围：Y个服务中的X个

Verdict

结论

🟢 SHIP | 🟡 SHARPEN | 🔴 BLOCK

🟢 执行 | 🟡 优化 | 🔴 暂缓

Next Steps

后续步骤

[3 concrete actions]

undefined

[3项具体行动]

undefined

Routing

关联路由

```
/cs:cto-review
```
— for architectural causes of throughput problems
```
/cs:chro-review
```
— for hiring funnel comp/leveling issues
```
/cs:cfo-review
```
— for cost-per-hire envelope and eng budget
```
/cs:ciso-review
```
— for production discipline + compliance overlap
```
/cs:decide
```
— log the verdict
```
/cs:freeze 30
```
— on multi-year hiring commitments

```
/cs:cto-review
```
— 针对导致吞吐量问题的架构原因
```
/cs:chro-review
```
— 针对招聘漏斗中的薪酬/职级问题
```
/cs:cfo-review
```
— 针对招聘成本范围及工程预算
```
/cs:ciso-review
```
— 针对生产规范与合规的重叠部分
```
/cs:decide
```
— 记录结论
```
/cs:freeze 30
```
— 针对多年期招聘承诺