基于《项目实施管理制度》《核心岗位职责》《项目监控和操作指引》
覆盖考核三阶段所有考点，问答形式呈现
参照CMMI标准，项目划分为 七个阶段（项目计划与监控贯穿全程）：
第1步 · 项目评估
第2步 · 立项审批
第3步 · 项目启动
第1步 · 需求调研
第2步 · 功能设计
第3步 · 需求评审
第4步 · 需求录入
第1步 · 程序设计
第2步 · 设计评审（仅重难点功能）
第3步 · 用例编写（与程序设计同步，不晚于1周内）
第4步 · 程序开发
内部测试（技术组长主导）
用户测试（产品类由产品经理主导/其他项目由项目经理主导）
第1步 · 环境准备
第2步 · 部署发布
第1步 · 项目验收
第2步 · 项目结项（原则上先拿验收单再结项）
项目团队由 四个职能组 组成：
根据《软件交付部核心岗位职责》，产品经理职责分为四大块：
PMO（项目管理办公室）职责分为四大块：
需求分析流程（三步走）：
产出物清单（按责任人区分）：
| 指标项 | 格式要求 |
|---|---|
| 文档命名 | 「文档类型名称+文档版本号+项目」或「文档类型名称+文档版本号+系统名称+系统版本号+项目名称」 如：项目整体计划V1.0-江苏人社电子档案管理系统项目 |
| 版本号 | 文档版本号两位：草稿从0.1开始，每次修订增加0.1；审批通过从1.0开始，修订未审批时增加0.1，修订审核通过后增加1.0。系统版本号三位：1.0.0起 |
| 文档内容 | 首页 + 修订记录 + 目录 + 正文 |
| 章节标题 | 自动编号，按「一、」「1.1」「1.1.1」依次类推，不超5级，字体≤小四。可参照文档格式模板执行 |
| 正文 | 宋体小四、首行缩进2字符、1.5倍行距。表格内宋体五号、靠左对齐、1倍行距 |
| 段落标题层级 | 按「一、」→「（一）」→「1.」→「（1）」→「a.」顺序，可从某一级开始但不可跳级使用。可参照文档格式模板执行 |
设计开发阶段由 研发组主导，产品经理参与以下环节：
技术组长主导
产品类由产品经理主导/其他项目由项目经理主导
产品经理负责每次上线的 清单和系统配置材料：
配合项目经理：提供建议方案、参与部署方案评审。
变更审批通过后，项目经理应及时在项目管理系统上调整计划，并通知团队成员变更后的里程碑节点。
问题范围定义：项目问题包括项目需求评审完成直至项目运维的各阶段所发现的所有系统BUG、新需求，以及日常运维外的数据处理任务。
产品经理在问题处理中的职责：
🏭 产品类
公司内部、自有资金投资的产品研发/预研
🔧 实施类
根据外部客户要求开发/改造/升级信息系统
🛡️ 运维类
基础设施维护管理（收费运维/质保运维）
🤝 股份支撑类
为集团股份公司及兄弟公司提供支撑保障
📦 外包类
外包给第三方实施，公司统一管控
🚨 紧急问题处理流程
时间有限时 → 可同步开展需求分析、设计开发等工作
→ 事后在指定时间内补全过程文档
→ 如果紧急到需要立即处理和发版且连正规测试流程都来不及 → 邮件上报公司领导获得批准
→ 直接由现场实施人员验证发版
与常规流程的区别：常规流程必须按顺序走完需求→设计→测试→部署的完整流程。紧急流程允许并行推进，但必须在指定时间内补完文档。
🔴 严禁：私接设备、私改配置、装游戏、装黑客工具
🟢 日常：离席锁屏（Win+L）、下班关机关显示器
🔵 网络：IP由IT分配，严禁私改
8—3—90—5—5
8位以上 + 3种字符组合
90天更换 + 历史密码5次内不重复
5次错误锁定 + 间隔一定时间自动解锁
📛 红线：不存本地、不上传SVN、不公共社交工具传
✅ 规范：最小化原则、脱敏处理、即用即删、加密传递
🔍 自查：远望设备或python脚本自查，日志打包上传ftp
有远望设备 → 配置精细检查（勾选手机号+身份证号 + 检查压缩文件 + 检查全部 + 单个文件命中10次就上报）
无设备 → python3 + digg.py脚本自查（需先pip install xlrd==1.2.0）
发现敏感数据需立即删除，处理后重新自查一次
自查结果打包为「部门-姓名-时间.zip」，上传ftp
📍 操作路径（项目经理操作，产品经理需了解）：
🎤 内部讲解标准框架
操作路径及要点（按顺序）：
📍 入口：产品型→产品/研发需求栏；项目型→项目/研发需求栏
项目经理操作，产品经理需了解：
注意：设计评审和用例评审时间相隔不超过一周。计划制定完成并通知团队成员确认后及时在SVN中归档。
每周日之前完成填报，周一上午出监控数据，周例会通报：
| 维度 | 监控内容 | 异常判定 |
|---|---|---|
| ①计划填报 | 是否按时填报迭代计划 | 未按时/不规范填报 |
| ②里程碑 | 节点是否按时完成 | 红色预警 / 文档未归档 |
| ③功能填报 | 产品经理评审完2天内录入研发需求 | 红色预警 / 与功能清单不一致 |
| ④任务分配 | 技术组长评审完2天内拆解开发任务 | 一级任务与研发需求不对应 |
| ⑤开发进度 | 每周功能完成情况 | 产品验证未通过 / 功能延期 |
| ⑥总体成本 | 已用成本 vs 计划成本 | 已用 > 计划 |
技术组长发起 → 填写《测试申请单》
→ 发邮件给测试人员+项目经理
→ 测试人员完成测试后回复邮件
→ 附测试报告
项目经理/运维人员现场验证完成
→ 邮件带上《上线申请单》+附件
→ 发给项目经理+团队成员
→ 完成后再转发PMO+上级领导
根据《项目问题跟踪表》的检查情况汇总异常项：
🔴 高-立即处理
状态为「待任务排期」且距离提出时间 超过5天（不含5天） → 异常
🟡 中-排期处理
状态为「待任务排期」且距离提出时间 超过15天（不含15天） → 异常
产品组每周一汇总项目问题跟踪表异常，将异常数据和本周新增迭代版本提交PMO。
调整规范：
🎯 考核日现场复现 — 五步法
第1步 · 背景说明
这个功能解决什么业务问题？用户是谁？在什么场景下使用？
第2步 · 功能逻辑
功能的核心逻辑是什么？输入→处理→输出 是什么？涉及哪些业务规则/数据校验？
第3步 · 交互流程
用户操作路径：从哪进→看到什么→操作什么→到哪去。对照原型逐页讲。
第4步 · 边界情况
异常数据、权限控制、超时处理、空状态、并发冲突等边界条件怎么处理？
第5步 · 回答提问
评委（领导/同事）提问 — 回答要站在业务价值和用户体验角度
功能清单按 子系统 → 模块 → 功能点 三级结构组织：
系统名称（如：公共服务事项系统）
├── 子系统A（如：事项管理）
│ ├── 模块A.1（如：事项录入）
│ │ ├── 功能点A.1.1（如：新增事项）
│ │ ├── 功能点A.1.2（如：编辑事项）
│ │ └── 功能点A.1.3（如：删除事项）
│ └── 模块A.2（如：事项审批）
│ ├── 功能点A.2.1（如：审批流程）
│ └── 功能点A.2.2（如：审批意见）
└── 子系统B ...
标注信息：每个功能点需标注优先级、开发状态、是否涉及性能测试。
产品经理在结项中的职责：
根据附表B，产品经理（产品组）需交接的 必须材料：
| 材料 | 审核要点 |
|---|---|
| 📖 业务需求说明书 | 系统常用业务场景有对应说明，符合公司需求文档标准 |
| 📋 系统清单 | 与线上系统一致 |
| 📋 系统模块清单 | 与线上系统一致 |
| 📋 系统功能清单 | 与线上系统一致 |
| 📋 系统权限清单 | 与线上系统一致 |
| 📑 需求规格说明书 | 可选（推荐有） |
| 工具/系统 | 用途 |
|---|---|
| 🏢 北森OA | 打卡、加班、出差、请假、培训、绩效 |
| 🏢 集团OA | 报销、邮件、立项、变更、结项 |
| 📊 湖楚工作管理系统 | 日报提交、项目异常监控（每日必用） |
| 📌 禅道 | 项目过程管理、需求流转、任务管理 |
| 📁 SVN | 制度文档、过程模板、文档存档（所有规范源头） |
| ✏️ Axure | 产品原型设计 |
| 🎨 蓝湖 | 原型发布、设计稿管理 |
| 📄 金山在线文档 | 评审签字、协作编辑（评审流程核心） |
| 📄 腾讯在线文档 | 月/周任务、工作协作、问题跟踪 |
| 📈 Visio | 流程图绘制 |
| 🧠 Xmind | 思维导图、梳理产品结构 |
运维归档材料：运维服务方案、部署手册、发布程序包、运维配置项清单、巡检记录等
系统版本号为 三位：X.Y.Z
| 位 | 变化条件 | 示例 |
|---|---|---|
| X（主版本） | 系统框架重构 或 产品版本升级 | 1.0.0 → 2.0.0 |
| Y（次版本） | 新功能增加 或 原有需求调整 | 1.0.0 → 1.1.0 |
| Z（修订号） | 仅做BUG修复 | 1.0.0 → 1.0.1 |
第一版上线后为 1.0.0。