13 产品经理实战：PM 角色与方法论

这是关于你自己的角色的文件。“IT 专家转 PM/BA”是你的优势，理解自己的定位和方法论至关重要。

---

一、角色定位

你在组织中的位置

flowchart LR
    Biz[业务部门<br/>Sales/Trading/Risk/Ops] -->|需求| PM[产品经理 / BA]
    PM -->|问题| IT[IT 开发团队]
    PM -.->|约束| Comp[合规/财务/运营]
    PM -->|交付| Biz

你的核心价值

1. 翻译官：把业务需求翻译成技术规格（PRD/FSD）
2. 粘合剂：连接业务、技术、合规、运营
3. 体验官：确保系统好用、高效
4. 质量门：确保交付的系统满足需求

IT 背景转 PM 的优势

优势	应用场景
理解系统架构	更好地评估技术方案可行性
能与开发深入沟通	减少沟通损失、提高 PRD 质量
理解数据流	设计更有逻辑的系统
了解技术边界	设定合理期望
项目管理经验	推动需求落地

IT 转 PM 的挑战

挑战	应对
业务知识不足	学习文档、跟交易台交流
术语不熟	积累 glossary、不懂就问
对业务紧迫感理解不足	体验交易员的工作节奏
过度技术化沟通	用业务语言表达

---

二、核心方法论

需求管理

需求来源：

• 销售/交易员提出（最频繁）
• 风控/合规要求（最紧迫）
• 监管变化（不可推迟）
• 运营反馈（体验优化）
• 自己发现（主动优化）

优先级排序（MoSCoW 法则）：

Must Have（必须有）→ 合规要求、基本的交易功能
Should Have（应该有）→ 效率提升功能
Could Have（可以有）→ 体验优化
Won't Have（暂不有）→ 低优先级需求

文档撰写

PRD（Product Requirements Document）核心结构：

1. 背景与目标（为什么要做）
2. 业务规则（怎么做）
3. 功能规格（具体功能）
4. 界面说明（UI/交互）
5. 数据要求（输入/输出）
6. 非功能要求（性能、安全）
7. 验收标准（如何算完成）

项目管理

需求 → 评估 → 排序 → Sprint Planning → 开发 → 测试 → 验收 → 上线

Sprint 节奏（通常 2 周）：

周一：需求澄清、Sprint Planning
周二-周四：开发、每日站会
周五：测试验收、Demo
下周一：上线

---

三、关键沟通方与沟通方式

沟通对象	沟通频率	沟通内容	沟通方式
销售/交易员	每日	痛点、需求、改进	面谈/IM
开发团队	每日（站会）	进度、问题、澄清	站会/文档
风控/合规	每周	合规需求、规则变更	会议
运营	每周	流程优化、bug 报告	会议/工单
管理层	每月	项目进展、KPI	邮件/简报
供应商	按需	系统集成、支持	电话/邮件

---

四、系统验收（UAT）

UAT 流程

开发完成 → 内部测试 → UAT 计划 → 业务用户测试 → 验收签收 → 上线

UAT Checklist：

• 功能是否符合 PRD
• 业务流程是否顺畅
• 异常处理是否完善
• 性能是否可接受
• 审批流程是否正常
• 数据是否正确
• 审计日志是否完整

---

五、第一天上班检查清单

• 认识所有关键干系人（销售、交易、风控、运营、合规）
• 熟悉现有系统（登录、走一遍业务流程）
• 了解你的产品线（哪些产品、哪些客户）
• 收集正在进行的项目列表
• 了解近期要交付的需求
• 熟悉文档流程（PRD 模板、发布流程）
• 加入所有相关群组和邮件列表

---

下一步：14-Systems-and-Data.md 深入系统架构