旧文整理一下重发：

最近跟我一起合作了一段时间的PM（产品经理）离职了，她的工作能力有口皆碑，大家都很喜欢和她一起合作，今天在和接任她的PM的一对一会议上，新PM问我：“你觉得她哪些方面做的好？这样我能向她学习，争取也能像她一样优秀！”

这其实也是我一直在思考的问题：怎么从优秀的PM身上找出他们的闪光点，如何向他们学习。 我尝试着给新PM总结了一下：

首先是她的产品设计基本功不错，能在短时间内熟悉我们的产品功能，并对我们的产品功能做出了不少优秀的改良，对于产品相关的问题，能做出专业的解答。

产品设计是对一个PM最基本的要求。以前有同事问过前PM她都是怎么学习的这些产品知识，她说是通过看Youtube视频学习的。也是，现在想学东西资源有很多，想学总能找到这些资源。

然后她对于需求的优先级处理的挺好。我们团队经常会收到很多其他部门发来的需求，尤其是法务部门，总是催的急，很难拒绝，而她总是处理的不错，一般不会在当前Sprint给我们临时加需求，总能想办法给我们排到后续的Sprint，所以团队总是在按计划有序的在工作，不需要临时处理各种加塞。

在处理需求优先级上其实我做的不够好，所以我曾专门请教过她如何排好需求的优先级，她告诉我她通常需求分成三个级别：

1. 最高优先级是严重影响用户使用的问题，以及对时间要求紧急的法务上的需求。这类需求会尽量在第一时间处理，哪怕有时候需要打补丁。
   
   
2. 普通的功能性需求，比如产品新需求，对现有产品的修改等等，默认放在后续的Sprint，这类需求通常占大多数。但是和提需求的人做好沟通很重要，比如要让他们清楚我们日常版本发布的流程，以及可能造成的影响。由于我们每两周发布一次版本，所以最多也就等两周左右，基本上都还能接受。
   
   
3. 技术相关的，例如技术债务、性能优化这些，优先级通常要低一些。这种技术相关的虽然优先级相对低一些，但是我们每个Sprint在做计划时，通常会安排20%～40%比例的技术任务，所以总体来说并没有欠什么技术债务。 按照这样三个优先级别来排任务，大部分任务都可以按照优先级排到对应的Sprint中。
   
   但是也有例外情况，就是大领导（CXO/VP）直接要求的紧急任务会相对比较麻烦，她的建议是：
   
   
   • 要先搞清楚他们紧急加需求的原因是什么？ 然后要让领导们清楚这样临时加塞所造成的影响是什么，比如会让系统不稳定，会影响其他正在进行中的计划，或者其他影响。
     
   • 最后如果领导坚持要加塞，没必要正面对抗，可以找PM或者其他领导一起协商，实在不行就给加塞上。
     
     再有就是这个PM对于新产品功能，有很好的计划性，能提前协调好资源，在将需求交给开发时，UI/UX设计、后端API这些都已经准备好了，各种细节也通过文档和多次会议反复确认完成，开发人员只要按照产品设计文档、UI设计文档、API文档去开发就可以，不需要开发自己去反复确认。
     
     这种项目的计划和资源的协调通常是项目经理来做的事情，但是她作为产品经理，自然而然将项目管理的工作也一起做了，最终团队也受益。 所以我经常建议大家学习软件工程和项目管理，不管是你做开发还是做产品设计还是其他工作，工作中融入这些项目管理技能会让你事半功倍！
     
     最后还有一点就是她对日常工作中的问题能做到及时有效的反馈，真正做到了“件件有着落，事事有回音”！
     
     作为产品经理，日常除了要做产品设计，还有就是要经常和开发确认各种产品细节、任务优先级。无论团队中谁通过何种方式问她问题，比如ticket的评论、Slack的消息、会议上的问题，她都会尽可能第一时间回复，哪怕她当时不能马上给出答复的，她都想办法去确认清楚，然后第一时间给出答复。
     
     这种“件件有着落，事事有回音”本职是一种职业素质的体现，当我们和这样的同事合作，他们总能让你放心，问他们一件事情有答案，交代一件事情有结果和及时的反馈，所以我们都喜欢和这样的同事一起共事。
     
     如果简要总结一下我的前任产品经理为什么受欢迎？
     
     首先她作为一个产品经理，最基础的产品设计能力是不错的；在专业能力之上她有良好的项目管理能力，可以妥善处理好需求的优先级，可以有计划有步骤的推进项目，协调好资源；最上面是她的职业素质，“件件有着落，事事有回音”，让她成为团队中一个靠谱的不可或缺的存在，大家都乐于跟她一起共事！