|
来新司三个月，也许是团队协作与流程上仍有许多待提升的地方，比较注重项目上的复盘与反思；同时作为产品经理，从专业角度，与之前的工作内容相比，有了新的提升与挑战。因此定期的思考与总结，便十分重要。不过周报本就有个人思考部分，估计老板也只会注意这部分的内容，来判断当周你的工作价值。毕竟细节也很重要，但老板不关心，做好本就是基本要求。反而是从中是否有所思考与提升，才证明了你能否承担更重要的工作。
-
开发最讨厌的PM特征
-
评审上来就讲怎么做，实现逻辑及细节。被问到为什么要这么做？回答不出来，“老板的要求”，或“运营提出的，业务上的需要”。成为了需求的传话筒，自己也不清楚，需求的真正价值
-
PRD没想清楚功能细节，评审时被技术问到细节问题，卡住了，完全没有想过，或者明显是现场现想的。还有中情况是接的上一个同学的需求，只知道落地填坑，不去追溯需求最开始的背景与目的
-
帮技术评估工作量
-
逼着技术给出承诺。只盯着技术给出timeline，给完就啥也不管了，最后只等着要结果。若有延期就指责是开发的责任
-
开发过程中改需求。由于客观原因导致方案变更，都可以理解。无法忍受的是由于PM没有想清楚，或之前与业务关于需求没有确认清楚、沟通有歧义导致的方案变更，在开发看来这就是把开发不当人看的态度，认为开发人力的浪费完全不所谓。
-
无节奏感。做完一个需求，再开始考虑下一个需求方案，导致技术为了赶绩效，开发时疯狂赶工，上线后一段时间又闲着
-
优柔寡断。讨论完之后，等着PM拍板的时候，决不能再说各种方案各有利弊，大家看还有什么好的想法。
-
把开发只当成了一种资源。没有及时反馈除了开发外的其他信息，或同步产品的相关数据
-
即使接到了明确的改动项，例如只是更改前端界面的一个button的跳转链接。也需要多问一个为什么。为什么要这么修改？原来的链接为何不能用了？也可以跟相关PM沟通，目的不是从成本角度（因为本身effort也很小），而是从业务角度，是否有更优的方案？
-
UAT的bug，dev碰到难题，较长时间未定位到原因、或找到好的解决方法，说明给再长时间也不会有进展了，受限于dev本身的能力或信息不足，应立刻同步给他的leader，共同解决
-
问题，从你的角度，或你的团队开发人员角度，很难解决，或毫无思路；多咨询相关PM，或拉相关方讨论，也许从别人视角，是很容易能解决的事情
-
Timeline变更，需及时与相关方沟通，目的在于对齐所有相关方的理解及预期
-
UAT或线上bug，PM都需关注。先分析问题，问题是否包含需求，可能需要迭代去解决。或方案设计本身如此。
-
多方有歧义项，及时组织会议使大家align，否则群聊半天也较难达成结论
-
PRD设计方案时，应考虑UAT适配策略。
可能为了更好支持业务进行UAT，需要设计特殊的临时功能。
对于灰度发布、期初数据处理逻辑，也应考虑周全
-
根据团队协作安排，提前设定好各任务截止点。例如下一版本需求，一般提前三天需UAT sign off，进入staging状态；初评需提前一周预约，否则本周没找到合适时间，需求评审延误一周
-
终评把控方案介绍的节奏，业务背景及目的，一定要讲透。实现方案细节上，把控讲解的颗粒度。
-
制定Timeline应根据模块大小及复杂度给出客观排期，既要考虑Ops，对于上线时间的要求，也要考虑开发测试把控质量的要求。前期排计划时应注重准确性，不能为了满足进度要求仓促评估，给出并不实际的排期。基于过往经验，及与Dev充分沟通复杂的逻辑，从而保证排期的质量。同时也要与Ops充分沟通，若上线时间是优先级更高的要求，那可以对需求拆解，识别核心功能与后期优化需求，调整当期项目范围。
-
线上问题，应第一时间响应，起码要告知相关方该问题正在解决。尽量当日反馈，问题原因及建议举措。
-
需注重开发阶段的项目管理工作，跟进开发与测试进度。在开发过程中，dev会从系统实现角度，发现一些逻辑细节上的待确认项，或之前考虑不够周全的场景，或者可能发现在之前评审时对于需求理解不一致的地方，造成进度delay。需保持跟进，有模糊处及时澄清，有待讨论项尽早拉会确认，不影响后续任务项。
-
需
关注版本规划，特别下半年，提前考虑code freeze约束，来安排UAT及Live时间。
-
B端产品，或后台产品，输出的PRD。对于FE，因会有UI设计稿，较容易理解。但对于BE，需注重梳理UML或图表示意，否则较难完全理解后台设计逻辑，状态流转，数据操作及流向。
-
对于Closed的Bug，PM也应关注。目的在于，一是Dev修复的可能只是表象原因，没有找到Root cause；二是可能供产品后续优化借鉴。
-
针对开发中的需求，应每日关注团队sub task状态，有延迟尽快了解具体情况，评估如何处理；同时按项目计划，转入UAT时间点的前三天开始，与相关方保持进度共享，有UAT或Live延期风险提前告知，管理预期。
-
提前了解下一Q需求大致背景，对优先级及复杂程度先有初步判断，合理动态安排每一版本的需求量，避免出现前松后紧的情况。
-
涉及数据操作的产品，设计方案时需要考虑数据同步的问题。特别涉及到多处写入，或依赖多个上游系统。
-
针对新产品，处于不稳定状态，任何新增逻辑，无论大小，若涉及到后端，需从底层状态及数据流上梳理，是否会遗漏场景？或产生逻辑bug？否则可能会出现，需求很小、开发上代码改动量也很小，但出现问题产生了不小的影响
-
作为PM，注重利用碎片化思考，及调研、收集资料。PM方案设计的质量，看重日常思考的积累，但其工作特点导致很难有大块的固定时间。
-
影响到上下游数据的新功能，可以区分
-
主动暴露的接口，方案设计时PM需要梳理有哪些消费方在调用
-
主动提供出去，可以在技术层面把控
-
业务分享PPT
-
产品的价值，拆开不同用户分析
-
先Overview架构
-
注重相应的业务场景及数据指标，截取前端更加直观
-
跳过逻辑细节，没有人感兴趣，感兴趣也听不懂，听懂了很快就忘了
- 能力模型
- 需求把控（方案合理、没有漏洞；汇报评审时，值得challenge；能谈出价值）
- 用户体验把控
- 项目管理把控
- 上线质量把控
- 数据分析及迭代优化
| 
转播
