前端 PM（Project Manager）分享

个人经验分享

`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 进行验收
- 需求样式问题：修复并发布
测试通过、问题修复、验收通过，发布完成
发送项目发布成功邮件
对应的文档更新