前端 PM 分享：PM 需要做的事情

个人经验分享

PM

PM( Project Manager )

PM( Product Manager )

一、什么情况下需要前端担任 PM？

在我之前遇到的项目中，大多数项目的 PM 是由后端/产品经理担任，但也有不少项目的 PM 是由前端担任，一般是按照以下这几种情况划分

1. 后端担任(占大多数)：

• 一般是后端工作量大，项目以后端工作为主
• 后端任务复杂，逻辑复杂
• 改动的接口较多，涉及的项目较多
• 前端对整个系统不熟悉等

2. 产品经理担任：

• 跨部门的合作，产品去协调资源
• 项目周期较长，前后端人员可能会换

3. 前端担任：

• 前端开发为主的需求
  • 插件项目
  • 编辑器项目
• 项目重构
• 运营活动需求
• 偏用户体验的项目
  • 动画
  • 3D

二、前端PM 需要做哪些事情？

1、项目规划

把控项目整体流程，从确定项目到项目立项再到项目上线复盘

1.1. 明确项目目标

• 和产品或者需求方确定是项目优先还是时间优先
• 确定项目涉及到的系统、端（ web、h5、小程序、客户端、APP）等
• 根据不同类型预估时间点和能完成的项目
• 和需求方确定项目的结果，确定做到哪一步，做成什么样

1.2. 资源规划

• 前端预估工时和开发人数
• 后端预估工时和开发人数
• 测试预估工时

1.3. 制定项目计划

2、制定项目计划

其实这一块也属于项目规划，但是很重要，就单独提出来当一个大模块

2.1. 需求评审

确保需求的质量、完整性和清晰度

2.1.1. 需求评审前的准备

• 了解此次需求，熟悉产品的需求文档
• 明确需求的优先级和重要性
• 对不清晰的需求提出自己的疑问与修改意见，确保需求点清晰
• 涉及到自己不了解的业务模块要及时找 leader 沟通
• 确定需求评审的人员，不能有遗漏，拉群
• 和产品以及对应参与人员确定评审时间
• 产品需求文档放入群公告中，并通知大家在评审时间前预览一遍

2.1.2. 需求评审

• 确认参会人员
• 评审需求的合理性，让参与人员认可
• 只评审需求，不讨论技术细节
• 标记有疑问的需求，产品可在评审时修改的就及时修改，不能及时修改的要给个时间
• 要有会议纪要，记录修改点，疑问点以及产品、运营、技术沟通后形成的共识
• 确保参与人员都理解需求
• 确定 UI 评审时间

2.1.3. 需求评审会后

• 将会议结论、问题以会议纪要发布群里，和大家同步
• 及时跟进产品在会上不能给出的需求变更，小问题改动直接群里通知大家
• 对于无法按时更新的变更，需及时上报，及时处理

2.2. UI 评审

确保 UI 设计满足要求，符合用户体验过程

2.2.1. UI 评审前的准备

• 预览设计稿，先确定设计稿颜色规范、字体规范、图标
• 核对 UI 稿上有没有遗漏需求，确定风格一致
• 确定 UI 稿和产品需求稿的差距，如果某些需求差距过大，需找产品和 UI 确认，并做标记
• 确定 UI 评审人员
• 确定评审时间
• UI 稿放入群公告

2.2.2. UI 评审

• 确认参会人员
• 和需求设计相差较大的，需要和相关方沟通确认并记录
• 设计稿交互、排版不合理或者无法实现、或者实现成本大但是业务收效低的需要提出沟通，并将最终结果记录下来
• 确保会议人员对 UI 稿整体都了解，能达到共识

2.2.3. UI 评审会后

• 将会议纪要发布群里，和大家同步
• 及时跟进对应的 UI 变更，及时通知

2.3. 技术评审

确保项目的技术方案和实施满足质量、性能和可维护性的要求

2.3.1. 技术评审前的准备

• 必须清楚对应的开发和测试人员
• 前期是否有遗留的待处理问题，需在评审前处理完成并通知大家
• 需要整体的需求和 UI 稿"了然于胸"，对需求细节和难点做到有腹稿
• 对需求模块分清主次
  • 常见的功能点是次，新的功能点是主
  • 简单的模块是次，复杂的模块是主
  • 单个开发者自给自足的模块是次，多方合作实现的模块是主
• 整个需求按模块拆分功能点，给出技术方案并预估工时

2.3.2. 技术评审

• 确认参会人员
• 按照 UI 稿，分模块进行逐步评审
• 之前未接触的功能点，需要记录技术方案
• 对于需要多方合作的模块，需要对技术方案达成共识，确定先后顺序
• 要清晰的划分清楚每个模块对应的开发者是谁
• 各模块技术方案确定之后，预估工时，协商排期
  • 后端介入开发时间
  • 后端 API 文档给出时间
  • 前端介入开发时间
  • 后端 Mock 数据提供时间
  • 后端真实/测试数据提供时间
  • 前后端联调时间
  • 提测时间
  • 验收时间
  • 上线时间
  • 项目复盘时间

2.3.3. 评审结束

• 把各个模块的开发人员整理成文档
• 把各个时间点整理成文档并通知大家

3、团队沟通与协调

所有涉及到当前项目的人员自动组成了一个小团队，会涉及到不同部门的不同人员，要及时沟通，及时协调，不欢迎私聊

3.1. 前端内部沟通

• 项目拆分和任务分配
• 前端技术方案探讨和同步
• 前端开发时间沟通确定

3.2. 前后端沟通

• 接口规范
• 接口文档字段梳理
• mock 数据时
• 联调时

3.3. 技术与产品

• 需求确定
• 需求变更
• 需求 delay
• 验收和上线

3.4. 技术和 UI

• UI 稿确定
• icon 和图片资源
• 验收和上线

4、项目进度跟踪

4.1. 项目启动

• 创建对应的项目 aone
• 各个模块创建对应的 aone
• 各个开发创建对应 aone
• 需求邮件发送
  • 项目背景、项目目标、项目节奏、项目成员、项目资料
  • 人员不能遗漏，涉及到的所有人以及对应的 leader
  • 开发内容以此邮件中的需求范围为准
  • 验收/上线/变更需求都以此邮件为主

4.2. 项目周报、日报

PM 一定要写周报，既是记录又是备份

4.2.1. 是否需要周报、日报

• 建议周报一定要有
• 项目提测、验收、以及 delay 的时候要有日报

4.2.2. 周报内容

• 本周工作进度：具体到每个模块的进度以及对应开发的进度
• 总体进度：写清楚进度百分比，概述目前完成的功能
• 问题&风险
  • 问题：本周发现的问题，是否已经解决，未解决但已有解决方案的，以及还没解决方案的，需要谁来帮忙，是否影响进度
  • 风险：是否有可能影响项目进度的问题，需要写清楚原因
• 下周工作安排：具体到每个模块以及对应开发

4.2.3. 日报内容

提测日报，只是写个日报标记下，不属于提测邮件

• 工作进度：具体到每个模块的进度以及对应开发的进度
• 完成项目：完成了哪些模块
• 模块负责人：标清楚前后端人员
• 测试链接：测试链接给出
• 测试方案：一些项目测试时需要技术支持

4.3. 项目风险&延期

发现风险一定要第一时间同步产品和 leader，风险是否会涉及到延期也需要预估并同步

• 确定风险来源，是开发问题、还是需求问题
• 拉动产品与相关开发人员进行沟通
• 开发问题：
  • 是否是项目预估出现了严重偏差
  • 是否是技术方案上出现了问题
  • 是否可以通过补充人力来解决
  • 是否因为第三方原因导致的问题
• 需求问题：
  • 是否是 UI 稿实现起来太麻烦
  • 是否因为需求变更导致的
  • 是否因为资源没给到导致的
  • 部分不紧急但麻烦的需求是否可以放到二期
• 确定是否会延期
  • 延期需要和产品、测试、开发达成一致，并邮件以及群内通知所有人，发送延期通知

5、变更管理

在有效管理项目范围内的任何变更，确保变更的影响得到适当评估，最终以受控的方式实施

5.1. 变更分类

5.1.1. 需求变更

这种需求变更在开发中一般是最多的，断断续续的需求变更，这个时候就需要 PM 对项目整体进度以及需求变更的优先级以及影响范围进行评估，来确定是否接受这次变更

5.1.2. UI 变更

UI 变更也会经常发生，一个颜色、一个字体等，小的变更可以直接通知，但是有的变更比较大，就需要 PM 进行评估

5.1.3. 延期变更

延期也是一种变更，一般是由开发人员导致的，需要和产品、测试、开发同步

5.2. 变更请求记录

对在邮件发送之后的任何变更都需要有记录，记录内容包括变更的性质、原因、提出者、提出时间等信息

5.3. 变更影响确认

• 变更对开发的影响
  • 开发时间
  • 技术方案
  • 是否有新的技术难点
  • 联调时间
• 变更对测试的影响
  • 测试内容
  • 测试方案
  • 单元测试 case
  • 测试时间
• 变更对 UI 的影响
  • 是否需要 UI 稿的更改
• 变更对时间的影响
  • 开发时间
  • 联调时间
  • 提测时间
  • 上线时间

5.4. 变更预估

PM 需要先自己预估下此次变更的影响，需要和产品、测试、UI、开发、leader 等同步，确定完成之后是同意变更还是放到二期等

6、项目提测

所有项目在提测时需要 PM 发布提测邮件

6.1. 提测前准备

• 测试环境准备，和后端/运维等确保测试环境正常
• 完成自测、联调、单元测试 case 走通
• 测试数据
• 提测文档

6.2. 提测邮件

• 提测项目：提测项目名称
• 完成项目：完成了哪些模块
• 是否自测：是否自测、联调
• 模块负责人：标清楚前后端人员
• 测试链接：给出测试链接/测试包/测试二维码
• 测试方案：一些项目测试时需要技术支持
• 需求/实现对比图：需求截图和实现截图
• 需求变更：需求变更点以及影响点

7、项目发布

项目最后一哆嗦，很多时候在这卡壳

7.1. 发布前提

• 必须测试通过
• 必须业务方和 UI 验收通过
• 必须做到可回滚
• 域名解析

7.2. 发布安排

• 按照各个项目顺序发布
• 发布后立刻组织测试进行线上验证
  • 用户无感知并可快速修复：修复并发布
  • 用户无感知但无法快速修复：PM 标注，和产品沟通是否需要二期
  • 用户有感知并可快速修复：先回滚再修复
  • 用户有感知但无法快速修复：先回滚，和产品等沟通是否归类风险&延期
• 产品 UI 进行验收
  • 需求样式问题：修复并发布
• 测试通过、问题修复、验收通过，发布完成
• 发送项目发布成功邮件
• 对应文档更新

8、项目复盘

是否需要复盘，要看项目大小、是否有延期、与项目预期对比等来判定

• 复盘人员：涉及到产品、技术、运营等
• 复盘目标：项目成功的因素、发现问题和改进点
• 经验教训分享
• 项目成果分享
• 项目改进/优化提案

END