网站建设能有多大访问量,下载百度导航app,福田公司全称,营销成功案例个人经验分享 PM
PM( Project Manager )
PM( Product Manager )
一、什么情况下需要前端担任 PM#xff1f;
在我之前遇到的项目中#xff0c;大多数项目的 PM 是由后端/产品经理担任#xff0c;但也有不少项目的 PM 是由前端担任#xff0c;一般是按照以下这几种情况划… 个人经验分享 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
