2. 平台产品思维
内部开发者平台（IDP）最常见的失败模式，不是技术选型错误，而是把它当成一个“基础设施项目”来交付：由平台团队闭门设计、按季度上线功能、以“我们提供了什么能力”为验收标准。结果往往是平台功能齐全，但开发者仍然绕过它，继续用脚本、工单和口头约定完成交付。要避免这一点，必须把 IDP 当作一个有用户、有场景、有生命周期、有取舍的产品来经营。
一、从“项目思维”切换到“产品思维”
项目思维关注的是范围、工期和一次性交付；产品思维关注的是用户、价值、采用率和持续迭代。两者在 IDP 上的差异可以具体化为几个可观察的指标：项目思维会问“这个季度我们上线了几个自助服务能力”，产品思维会问“开发者从提交代码到获得可用环境的中位时间是否下降”“有多少团队在无人工干预下完成了首次部署”。
产品思维要求平台团队明确三件事：谁是用户、他们现在如何完成工作、平台在哪个环节能显著降低他们的认知负荷或等待时间。这三件事无法靠会议室讨论得出，必须通过用户画像和需求调研获得。
二、识别内部开发者用户画像
“开发者”不是一个同质群体。在 IDP 语境下，至少可以区分出四类典型画像，他们的目标、痛点和成功标准差异很大：
- 应用开发者（App Dev）：日常写业务代码，关心的是“我能不能快速拿到一个和线上一致的环境”“部署是否可预测”。他们对 Kubernetes、Terraform 等底层细节通常不感兴趣，甚至视为干扰。
- 平台/SRE 工程师：负责平台本身的稳定性和可扩展性，关心的是“如何用一套标准模板覆盖 80% 的服务”“如何在不牺牲安全的前提下减少审批”。他们既是平台的构建者，也是早期用户。
- 数据/ML 工程师：工作负载与常规微服务不同，需要 GPU、大数据作业、模型训练流水线。他们关心的是资源调度、实验可复现性和数据访问权限。
- 新入职开发者：入职前两周的体验最能暴露平台问题。他们关心的是“我能不能在第一天跑通一个服务并提交一次变更”，任何需要找人问、找文档翻的环节都是摩擦点。
画像不是贴标签，而是用来做优先级判断。例如，如果平台团队只有 5 个人，同时服务 200 名应用开发者和 15 名数据工程师，那么第一版自助服务能力应优先覆盖应用开发者的“创建服务 + 部署到测试环境”路径，而不是先做 GPU 调度。
三、痛点识别：从“他们说什么”到“他们做什么”
开发者反馈常常是失真的。直接问“你需要什么功能”，得到的往往是“我想要一个更快的 CI”这类模糊诉求。更有效的方式是观察实际工作流中的等待、切换和重复劳动。常见的痛点信号包括：
- 同一个操作在多个工具间重复输入（如先在 Jira 建单，再到 Jenkins 建流水线，再到 ArgoCD 建应用）；
- 环境申请平均等待超过半天，且状态不可见；
- 新服务上线需要 3 个以上不同团队审批；
- 文档分散在 Confluence、README、聊天记录中，且互相矛盾；
- 开发者自己写脚本绕过平台，说明平台路径比绕行路径更慢或更不可靠。
这些信号比问卷更能说明问题。平台团队应建立一条从开发者行为到平台改进项的映射链：观察到绕行行为 → 定位绕行原因 → 判断是能力缺失、体验问题还是信任问题 → 形成可验证的改进假设。
四、需求调研方法：轻量、持续、可验证
IDP 的需求调研不应是一次性的大型问卷，而应嵌入平台团队的日常节奏。以下方法按投入从低到高排列，可组合使用：
- 行为埋点与漏斗分析：在平台关键路径上埋点，例如“创建服务 → 配置流水线 → 首次部署成功”。观察每一步的转化率和耗时，找出流失最严重的环节。这是最客观的数据来源。
- 开发者体验走查（DevEx Walkthrough）：平台团队成员以新开发者身份，从零开始完成一次真实任务，记录每一步的等待、报错和需要求助的地方。走查产生的摩擦清单往往比访谈更具体。
- 短周期深访：每次选 5 位不同画像的开发者，围绕最近一次真实交付经历提问，而不是问“你想要什么”。例如：“上一次你上线一个新服务，从开始到成功用了多久？中间卡在哪里？”
- 平台使用数据与绕行检测：对比平台路径与绕行路径的使用量。如果某个团队持续用自定义脚本部署，说明平台路径存在未满足的需求或信任缺口。
- 需求假设卡片：把每个需求写成“我们相信 [某类用户] 在 [某场景] 下遇到 [某问题]，如果我们 [某改进]，则 [某指标] 会改善”。这张卡片直接对应验证闭环中的指标。
五、从画像到优先级：一个可操作的判断示例
假设平台团队收到两类需求：应用开发者希望“一键创建带数据库的服务”，数据工程师希望“支持 GPU 队列的作业提交”。两者都合理，但资源有限。此时可以用画像覆盖度、痛点强度和验证成本三个维度做判断：
| 需求 | 覆盖画像 | 当前痛点信号 | 验证成本 | 建议优先级 |
|---|---|---|---|---|
| 一键创建带数据库的服务 | 应用开发者（约 200 人） | 环境申请等待中位 6 小时，绕行率 35% | 低：可复用现有模板与 Operator | 高 |
| GPU 队列作业提交 | 数据/ML 工程师（约 15 人） | 当前用邮件申请，等待 1～2 天 | 中：需对接调度器与配额系统 | 中 |
这个判断不是永久的。当应用开发者的环境申请中位时间降到 30 分钟以内、绕行率降到 10% 以下后，GPU 队列的优先级就应上升。产品思维的核心不是一次做对所有事，而是持续用证据调整优先级。
六、把产品思维落到平台团队的日常
要让产品思维真正生效，平台团队需要建立几个固定动作：每个迭代周期开始时，用画像和痛点数据确认本周期要解决的一个核心问题；迭代结束时，用埋点数据回答“目标指标是否改善”；每季度回顾一次画像是否仍然准确，因为组织架构、技术栈和业务重点都会变化。
此外，平台团队应指定一名“产品负责人”角色，不一定是专职产品经理，但必须有人对“开发者采用率”和“端到端体验”负责，而不是只对“平台可用性”负责。这个角色的关键产出不是功能列表，而是一份持续更新的开发者体验基线：当前各画像的关键路径耗时、绕行率、主要摩擦点和正在验证的假设。
当平台团队能够用画像解释“为什么做这个功能”、用痛点数据解释“为什么现在做”、用验证指标解释“做完之后是否真的有用”，IDP 才真正从基础设施项目转变为内部产品。