3. 平台即产品
为什么平台需求不能靠“收集功能清单”
平台工程的需求来源不是业务方，而是内部开发者。前端、后端、数据、SRE 四类角色在交付链路中处于不同位置，对平台的痛点和期望差异极大。如果只发一份统一问卷，得到的往往是“我要更快的 CI”“我要更好的日志”这类无法落地的诉求。正确做法是先建立开发者画像，再用半结构化访谈把画像中的假设转化为可验证的平台需求。
画像模板：每个角色记录什么
画像不是人物性格描述，而是交付行为特征的结构化记录。建议每个角色至少采集以下字段，便于后续横向对比：
| 字段 | 前端 | 后端 | 数据 | SRE |
|---|---|---|---|---|
| 主要交付物 | Web 页面/组件库 | API 服务 | 数据管道/报表 | 稳定性保障 |
| 日均部署次数 | 3~10 次 | 1~5 次 | 按调度周期 | 变更驱动 |
| 最常用平台能力 | 预览环境、CDN | CI/CD、服务模板 | 调度、计算资源 | 监控、告警 |
| 最大阻塞点 | 环境不一致 | 服务上线流程长 | 资源排队 | 告警风暴 |
| 成功度量 | 首屏加载时间 | 接口 P99 延迟 | 任务按时完成率 | MTTR |
半结构化访谈提纲：五段式设计
半结构化的关键是有主线但不死板。以下五段覆盖从背景到验证的完整链路，每段 2~3 个问题，总时长控制在 45 分钟以内。
- 背景与角色确认：团队多少人？技术栈是什么？最近一个月部署了多少次？当前用了哪些平台能力？
- 交付旅程还原：请从“写完一行代码”开始，逐步描述到“用户能看到变化”的每一步。哪一步需要等？等多久？
- 痛点与影响量化：过去一个月，哪个环节最让你头疼？发生频率如何？每次大概浪费多少时间？
- 期望与优先级：如果平台只能帮你解决一个问题，你选哪个？为什么它比其他问题更重要？
- 验证与补充：有没有我没问到的场景？你觉得还有谁应该被访谈？
访谈时避免问“你觉得平台应该有什么功能”，改为问“你上次遇到这个问题是什么时候，当时怎么处理的”。具体事件比抽象意见更有价值。
从访谈记录到平台需求：分类与优先级
访谈结束后，将原始记录按角色 × 需求类型归类。通用需求进入平台 MVP 范围，角色专属需求按“影响面 × 频率 × 阻塞程度”排序。例如：前端提出的“PR 预览环境”影响所有前端开发者、每天触发多次、且直接阻塞联调，应优先进入迭代；而“CDN 刷新按钮”虽然也属于前端，但频率低、有替代方案，可排后。
优先级评分示例：影响面（1~5）× 频率（1~5）× 阻塞程度（1~5）= 总分。总分 ≥ 60 进入当前迭代，30~59 进入 Backlog，< 30 暂缓。
可直接使用的访谈记录模板
受访者：______ 角色：□前端 □后端 □数据 □SRE
团队：______ 技术栈：______ 日均部署：______
【交付旅程】
步骤1：______ 等待时间：______
步骤2：______ 等待时间：______
步骤3：______ 等待时间：______
【痛点】
最痛点：______ 频率：______ 单次耗时：______
月损失估算：______
【期望】
第一优先：______ 原因：______
第二优先：______ 原因：______
【验证】
遗漏场景：______
推荐受访者：______
画像和访谈提纲不是一次性文档。每季度或平台重大版本发布后，应重新访谈 2~3 名不同角色开发者，更新画像中的“最大阻塞点”和“成功度量”，确保平台需求始终来自真实交付现场。