前端 PM(Project Manager) 分享

发布时间:2024年01月08日

个人经验分享

PM

PM( Project Manager )

PM( Product Manager )

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

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

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

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

2. 产品经理担任:

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

3. 前端担任:

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

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

1、项目规划

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

1.1. 明确项目目标
  • 和产品或者需求方确定是项目优先还是时间优先
  • 确定项目涉及到的系统、端( webh5、小程序、客户端、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

文章来源:https://blog.csdn.net/guoqiankunmiss/article/details/135455090
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。