如何在阿里作一个靠谱的前端 PM

本文来自飞猪前端@九屻同窗（也叫狗哥），深刻业务侧开发多年，在项目中有深厚PM的经验，给飞猪新同窗梳理了这篇《前端PM手册》,借飞猪前端团队微信公众号分享给前端的开发同窗，期待能够给大伙一些阿里项目开发管控过程当中的一些输入，欢迎一块儿交流！

前端PM防diss指南

从开始作飞猪前端导购业务项目至今已有一年多时间，在大大小小的需求洗礼下自认为对前端需求的掌控度尚可，可是在接到个别需求时仍是会有一些不在掌控、千头万绪的感受，会怕遗漏一些应该作的对接或者评审，也会遇到一些情况外的问题，更是会遇到“模棱两可”的选择题，尤为是我这种比较纠结类型的人，好比：

• 这种相似的场景见得太多了，看一下就直接跳过吧？
• 需求评审时已经说清楚了，需求也不大，技术评审还要作吗，是否是能够直接拉排期了？
• 技术评审某个同窗没参加会议，我也不直接依赖他，是否是不来也不要紧？
• 这个功能点到预约时间了还没完成，钉钉催下进度就行了？
• 要发项目周报吗，好像不发也能够？
• ......

当由于生怕遗漏而焦虑时，是否有一个能够check的“应作事项list”？当遇到情况外的问题时，是否有“指南”能够学习？当面对上面的选择题时，是否有前人的经验能够帮助决策？哪些是不变的定论，又有哪些是须要因地制宜的思考，这个准绳是什么？其实目前现有的技术PM定义里面已经包含了答案：

• 技术：提供技术方案,解决产品可用性、易用性问题，同时确保技术上的健壮性和系统性，对用户体验和有效的实施过程负责。
• PM：确保成员对Task理解清晰，边界清楚，对工期预期一致，组织推进落地，调动资源，化解风险，对交付物质量负责

可是“定义”，通常都是抽象的，具象到现实的导购场景上时咱们该怎么作，哪里能有一个清晰的答案，哪怕是经验？
为了防止本身后续再陷入这些问题，根据我以往作前端PM的经验和教训，基于现有阿里业务项目总结出一份《前端PM手册》，若是你是其余业务线的小伙伴，可将本身的业务以及工具代入阅读。但愿这份手册能对我和其余同窗在以后的工做中有一些帮助，也但愿能对其余业务线的同窗有些启发，欢迎你们批评指正。

需求评审

评审前的准备

能力准备

• 熟悉对应业务，对业务有本身的体感，清晰业务范围和边界
• 熟练业务经常使用工具：好比依赖的搭建平台、业务逻辑处理的工具（圈特定的人、选择合适的商品）、模版搭建工具；算法规则配置等等
• 熟悉项目平常工具：需求周期管理平台、数据埋点平台、ABTest工具、玩法活动平台等等

和PD事先沟通产品意图（通常发起评审前会PD先找主要开发者沟通）

• 对不是通用能力解决的场景，态度明确的提出意见，建议PD从新审视需求和资源
• 对不熟悉当前业务运营工具、实现流程的，须要科普
• 对不熟悉项目历史（指已有项目作更新迭代）的PD，须要科普并提供本身的看法
• 对重复实验性改动（既以前作过相似改动可是效果并不理想）提出意见，尤为是背景和目标无太大区别时态度要坚定
• 要充分倾听PD的改动背景、设计思路、产品预期，能据此提出的意图给出本身的建议或意见（技术上或者业务上），能对PD和业务有必定的输入
• 对PD不熟悉须要涉及资源的状况，要及时给出负责人或者范围或者方向，让PD有大体的体感

沟通后的工做

• 仔细阅读PRD，须要对每一个模块用到哪些能力有清晰的体感
• 需求的业务目标必须清晰合理，投入产出太低、目标模糊的须要反馈给PD从新审视
• 涉及到本身不熟悉的领域要及时补足信息

  • 例如：这个活动页面须要用到秒杀功能，秒杀功能对应的活动玩法体系本身是否了解？
  • 例如：本次有招商的商品进入，招商的流程、招商商品和普通商品的差别本身是否了解？
• 不涵盖在本身理解的业务范围内需求，要及时和老板沟通业务范围和边界，而后反馈给PD
• 功能改动涉及到开发人员不清楚的话，及时咨询，防止评审时漏人
• 有新技术、新工具挑战，要及时作好技术储备

需求评审邀请

• 需求评审会议邀请由PD发出，PM须要检查与会人员是否涵盖全部必要人员以及必要人员是否能准时参加
• PD没有项目钉钉群的，须要拉钉钉群，由PD负责阐述需求背景等，需求PRD地址须要放入群公告
• PD没有提早沟通需求的，仔细阅读PRD后若是有疑问，根据对项目的影响决定是否马上须要找PD沟通

  • 对于业务边界、资源优先级等 直接影响项目开展的问题，须要马上找PD沟通，须要PD理清边界、协调资源
  • 部分模块技术上不可行、目前工具没法承接等问题，能够在评审时抛出讨论

评审

需求评审会议

• 确认必要人员所有到场
• 需求的业务目标必须清晰合理，有量化可追踪

  • 例如：本期重点关注的指标是点击率，须要明确点击率在多久内达到多少，对比哪一个时期提高多少
• 需求评审的重点是评审需求的合理性，以各需求相关方承认为准，没必要在技术细节上过多讨论，此类问题可记录后在技术评审上肯定

  • 例如：某个商品字段可否取到这种问题，只要不是本期特别关注的字段能够先记录下来，由于有可能交互稿也只是示意图，能够在UI评审时确认，技术评审时肯定
• 需求点必须作到彻底清晰，不可想固然如此，必需要各方肯定方案，而且要确认方案的可行性
• 需求使用交互稿评审的，须要关注前端的交互问题，在需求评审时就抛出，防止拖慢UED进度
• **有讨论后确认的模块的需求，或者特殊的模块需求，须要有文字记录 **

  • 例如：秒杀模块倒计时需求，是运营填写倒计时的时间点仍是读取活动的接口，倒计时结束后模块更新成什么内容，异常兜底怎么处理。这种产品、运营、技术沟通后造成的共识，必定要记录下来
• 对于须要会后确认的点，要记录清楚问题、指定到人以及要肯定在什么时间能够确认好，确认好以后要有反馈（在UI评审上或者群里给到回复）
• 肯定后续UI评审的时间，资源不肯定的状况下除外

需求评审会议结束后

• 将记录的结论、问题以会议纪要的邮件形式发出同时同步到钉钉群和PRD的评论中，要求有疑问立马反馈。对于肯定到某我的的某个时间点必须给出结论的事项，必定要标注清楚问题、人和时间
• 到了肯定的deadline无进度回复的，须要联系问题的负责人肯定进度，并将进度周知各方

UI评审

评审前的准备

预览设计稿

• 预览一遍设计稿，设计稿主要关注常见的问题点

  • titlebar是常态的仍是异形的，目前是否支持
  • 当前技术栈下是否与特殊排版没法实现
  • 每一个卡片字段取值来源
• 模块和需求设计相差较大的，须要记录并在评审时提出

UI评审邀请

• 需求评审会议邀请由PD或UED发出，PM须要检查与会人员是否涵盖全部必要人员以及必要人员是否能准时参加
• UI稿地址须要放入项目群公告

评审

UI评审会议

• 确认必要人员所有到场
• 需求评审待确认事项同步

  • 全部关于需求的待定事项必须此时完成确认
• 模块和需求设计相差较大的，须要和PD、相关方沟通确认并记录
• 设计稿交互、排版不合理或者没法实现，或者实现成本大可是业务收效低的须要提出沟通，并将最终结果记录下来
• UI稿的评审要精确到商品或内容的字段，尤为是牵涉到不常见字段时必定要重点关注，须要和服务端同窗一块儿在会上沟通肯定可否拿到，不肯定的须要将该问题跟进的负责人和时间点记录下来
• 须要能掌握每一个模块对应的先后端、算法等开发者是谁，开发者的依赖方不在场的须要记录下来，以确保技术评审无遗漏相关方
• 会上除了没法确认的纯交互、排版外，其余事项须要所有肯定下来，单纯的UI问题须要具体到人到什么时间确认，确认时间须要在技术评审以前，将负责人和时间点记录下来

UI评审会议结束后

• 将记录的结论、问题以会议纪要的邮件形式发出同时同步到钉钉群和PRD的评论中，要求有疑问立马反馈。对于肯定到某我的的某个时间点必须给出结论的事项，必定要标注清楚问题、人和时间
• 到了肯定的deadline无进度回复的，须要联系问题的负责人肯定进度，并将进度周知各方

技术评审

评审前的准备

心理准备

• 须要到场的相关方是否都已清楚、明确
• PM必须清楚各位开发和业务方站位

  • 例如：一个典型的促销活动页面，商品池是谁提供（算法仍是运营），商品字段由谁来补充（服务端取值仍是算法计算产出），投放的方式是怎么样的（运营配置入口仍是个性化算法），生产的方式是怎么样的（算法仍是运营配置），入口有哪些case，每种入口展现须要哪些字段
• 需求和UI是否已经了然于胸，每一个模块须要沟通的功能点是否已经心中有腹稿
• 前期遗留的待定事项是否都已有确切结果
• 哪些是重点问题，哪些是一带而过的点，要分清主次

  • 常见的功能点是次，新的功能点是主
  • 简单的模块是次，复杂的模块是主
  • 单个开发者自给自足的模块是次，多方合做实现的模块是主
• 技术评审的主要目的不是为了拉排期，而是为了信息互通、肯定技术方案、理清各开发者边界和合做方式

技术评审邀请

• 需求评审会议邀请由技术PM发出，PM须要检查与会人员是否涵盖全部必要人员以及必要人员是否能准时参加

评审

• 全部开发人员&测试人员&PD必须所有到场，若是须要运营配合的，运营同窗也必须到场
• 评审参照UI视觉稿逐模块进行
• 每一个模块的每一个字段由谁提供、怎么实现要沟通清楚

  • 对于某些特殊字段，须要文案记录取值逻辑，谁来实现，怎么实现都要记清楚
• 对于以前未接触过的功能点，须要文案记录技术方案
• 对于须要多方合做完成的模块

  • 须要各方对技术方案达成共识，要探讨到具体的实现流程，不能有含糊的想固然

    • 例如：某个数据谁来给数据依赖方，数据从哪里来又将经过什么方式给到依赖方，是事件通知、sql仍是离线表，这个数据实时性的要求如何，稳定性的要求如何
  • 须要清晰到每一个开发者负责哪些、提供哪些、上游下游是谁
• 对于各方难以抉择的边界问题，及时拉上相关方主管确认边界划分
• 各个模块的方案沟通清楚后，协商排期

  • 通常的需求，须要后端提供功能联调的，须要确认的时间点按照时间线正序：

    • Kickoff时间
    • 先后端数据协议约定
    • 后端mock数据提供
    • 后端真实数据提供
    • 先后端联调时间
    • 提测时间
    • 验收时间
    • 上线时间
  • 通常的搭建需求，须要确认的时间点按照时间线正序：

    • Kickoff时间
    • 前端建立完成模块时间
    • 运营同窗商品池建立完成时间
    • 运营同窗数据投放平台配置完成事件
    • 提测时间
    • 验收时间
    • 上线时间
  • 后端也有依赖改动的，除通常需求的必须时间点外，须要清晰到各个被依赖方能提供出数据或能力的时间点，必需要知足依赖方的开发工期
• 会议结束后须要有一个明确的开发排期

项目进度跟踪

项目启动

是否须要Kickoff邮件

• 除平常迭代外全部项目均须要Kickoff邮件

Kickoff邮件内容

• 基本要素：项目背景、项目目标、项目节奏、项目成员、项目资料
• 明确阐述项目范围和开发内容，后续开发范围以此为准，不在该范围内的变更均算需求变动
• 邮件接收人为全体项目成员，抄送主要相关方（PD、运营、UED、先后端、算法、测试）主管 + 本身所在团队项目成员，重要项目须要抄送到推动此事各团队或BU负责人

项目周报、日报

是否须要项目周报或日报

• 原则上鼓励项目周报
• 重要或特殊项目（如：涉及相关方多且跨团队甚至跨BU的项目；相关方多，信息难以同步的项目），必须有日报周知
• 开发工期在两周内的平常迭代项目，能够没有项目周报或者日报，但须要天天要关注各个开发者的进度
• 开发工期在两周内的平常迭代项目，因非资源问题开发进度受阻未按时提测的，须要有项目日报周知进度
• 除以上类型外的项目须要有项目周报

项目周报、日报内容

• 本周/日工做进度：具体到每一个事项以及事项对应的负责人
• 整体进度：明确进度百分比，概述目前完成的功能
• 问题&风险

  • 问题：本周/日发现未解决但已有解决方案的
  • 风险：有可能影响项目内容或进度的事项，须要标红警示
  • 不可控风险：基本肯定影响项目内容或进度的事项，置顶标红警示
• 下周/明日工做安排：具体到每一个事项以及事项对应的负责人

风险&延期

• 发现风险必定要第一时间同步PD
• 对于不可控风险，马上拉动PD和相关开发者会议沟通解决方案
• 资源投入问题

  • 投入产出较低的功能点，优先考虑是否有替代方案甚至去除该功能（例如：商品卡片的某个字段取值逻辑问题，按照既定逻辑须要涉及多方改动，是否可使用现有的其余取值代替），须要和PD、开发、测试达成一致，发送需求改动通知报
  • 能经过补充人力来解决的

    • PM动员协调项目成员，组织加班，加班须要有加班邮件，邮件内容如日报
    • 若是相关开发人员团队有富余人力可由开发者在团队内沟通协调
    • 没法协调的，由PD出面协调人力资源
  • 不能解决的，再考虑需求是否有替代方案，须要和PD、开发、测试达成一致，发送需求改动通知
  • 可能因一个功能延期可是该功能优先级并不高的状况，考虑需求是否能够分拆到二期进行，须要和PD、开发、测试达成一致，发送需求改动通知
  • 以上都不可行，考虑项目延期，延期须要和PD、开发、测试达成一致，发送项目延期通知
• 功能实现问题

  • 投入产出较低的功能点，优先考虑是否有替代方案甚至忽略该功能，须要和PD、开发、测试达成一致，发送需求改动通知
  • 技术上有实现方案，不过须要既定成员外同窗参与实现的，PM与PD一道协调人力或由PD指定子需求，PM和相关开发同窗确认技术方案可行
  • 不能解决的，再考虑需求是否有替代方案，须要和PD、开发、测试达成一致，发送需求改动通知
  • 无替代方案且没法实现，考虑去除该功能，须要和PD、开发、测试达成一致，发送需求改动通知

需求改动&延期通知

• 非重大项目需求改动：钉钉群周知而且在PRD中备注，项目周/日报中体现
• 重大项目需求改动 或者 任何项目延期：除钉钉群周知而且在PRD中备注，项目周/日报中体现外，须要邮件周知Kickoff邮件的收件人

提测规范

是否须要提测邮件

全部项目均需有提测邮件

提测邮件内容

• 基本要素：功能完成度、是否完成自测、测试包（若是须要）、离线包（若是须要）、页面地址、二维码、项目资料
• 中间有需求变动的，须要在提测邮件中着重提醒
• 对测试内容有特殊要求的，须要在提测邮件中代表
• 对测试方法有特殊要求的，须要在提测邮件中标明测试方法文档地址

发布

发布前提

• 必须测试经过
• 必须业务方验收经过

发布安排

• 发布严格遵循当时实行的变动红线，必须作到有灰度、有监控、可回滚
• 按照各方依赖顺序发布

  • 通常被依赖方先发布
  • 若是有影响线上的改动，不兼容旧版一方后发布
• 发布后要马上组织测试和业务方进行线上验收
• 测试和业务方验收经过后，发布正式完成
• 验收发现线上问题

  • 用户无感知并可快速修复：修复并发布
  • 用户无感知但没法快速修复：和PD沟通是否走平常迭代
  • 用户有感知并可快速修复：先回滚再修复
  • 用户有感知但没法快速修复：参考风险&延期中的指导

发布后要作的事情

问题记录

• 养成线上问题排查过程和分析记录的良好习惯

监控&性能

• 关注监控平台各项稳定性指标
• 关注是否有舆情反馈
• 采集性能数据，有新旧版本的须要对比先后性能变化

业务数据

• 关注线上业务数据表现，业务目标在预期时间内是否达成
• 分析业务数据：找出表现好和很差的数据维度并分析缘由

是否须要Release邮件

• 有Kickoff的项目，都须要有Release

Release邮件内容

• 业务目标完成状况，分析业务数据阐述本身的理解

  • 例如：某个模块点击率提高显著，分析是曝光下降致使仍是真实的点击率提高
• 线上成果展现

  • 线上页面展现
  • 改版项目，对比新旧版本页面
• 技术成果总结
• 邮件接收人为Kickoff邮件接收人

Last but not least

以上即《前端PM防diss指南》所有内容，也是飞猪这边项目开发过程当中的一个缩影，若是没有说明白的地方，欢迎评论交流，也欢迎指出不对的地方~

飞猪正在招聘前端，目前咱们在 Serverless 、微前端运营工做台、端渲染、互动营销、招选投搭、智能化、体验技术、数据度量有很多建设，欢迎有能力同窗进来落地技术产生业务价值，想带人同窗过来直接带一个方向也是能够的，欢迎关注微信公众号来联系！

本文使用 mdnice 排版