本文抛开各种产品经理能力模型，仅聊聊在设计师眼中，一位“靠谱”的产品经理画像是什么样子的。
入行设计接近4载，感觉和自己对接的人员对自己的评价中，最喜欢的一个词就是：靠谱。
没错，很中性的一个词，但是去而包含和别人对你的极大肯定，不需要多于的美化，也不需要过多的捧杀。
转回正题，随着对接不同的项目，接触到了形形色色的产品经理，有刚入职的菜鸟，也有混迹多年的老油条。仅从设计师眼中看来，一个“靠谱”的产品经理，不仅可以提升整体项目流程的效率，同时也可以让设计、开发、测试人员都处在一种十分融洽的氛围中共同完成目标。
接下来的正文，就抛开各种产品经理能力模型，仅聊聊在设计师眼中，一位“靠谱”的产品经理画像是什么样子的。
1、产品思维
众所周知，PM往往需要多样化的学历、工作背景，以适应不同的互联网产品，这是他们自身的优势，但是背景多样化带来的负面效应就是互联网产品思维的不平衡。一位具有较好产品思维，或者学习能力强，能够快速塑造自身产品思维的PM，在对接过程中会很顺利。设计师提出的体验优化点或者方案，产品能够快速响应并从产品角度给出调整方案，从而将需求细节打磨更加精致。
但是产品思维不强的PM，设计师在对接需求的时候往往会感到心里很累。在需求提出开始就会很无语，漏洞百出的方案描述，或者只有一句话来描述“增加XXX功能”。看到这样的需求，任何一个设计师心里估计都要奔溃一阵子。
度过了需求提出的难关，在做需求的过程中，设计师会根据实际体验和视觉效果进行微调，调整内容需要跟PM沟通确认。本来这是一个很正常的流程，但是笔者就不幸遇到过一个“相对”比较“缺失”产品思维的PM，给出N种优化方案，并附上优势和劣势点说明。
但是PM的回复是：
“我觉得你的方案和我给的差不多啊~”
“吧啦吧啦吧啦吧啦吧啦吧啦”
……
然后，就没有然后了。
刚开始笔者以为可能是我的方案不清晰？所以还会去认真“撕X”一下，但是后来发现，情况不对啊！
可能不是我方案的问题，而是发现，笔者说的一些优势和劣势的问题，对方好像根本没有意识到，并且自动过滤掉了。他的眼中只有他自己最原始那个漏洞百出，从多个竞品里抄来拼凑的图啊。
对于设计师自己负责的项目，面对这样的情况，设还是需要坚持自己的立场并寻求圆满解决方案的，但是具体手法，这里就不赘述了。
2、对项目的整体规划能力
任何产品不是一蹴而就的，在敏捷开发的指导下，需要多个小版本的快速迭代上线，从而实现互联网产品的速度优势。因此，无论是从0到1的产品，还是线上产品的功能优化，都需要多个小版本快速叠加起来的。
版本一多，势必会拉长整个流程周期，每个周期内需要完成版本的哪个功能，就是PM需要从一开始就要意识到的（这里需要排除BOSS主导的一些项目，毕竟很多时候，老板的也就是一句话的事，但是影响到执行层就是天壤之别了），这样PM对产品每个阶段的目标有明确的认识，具体反映在每一版本的需求都是层层递进关系，就算有迭代或者回滚现象发生，也能够做好风险规避，避免设计和开发重复的工作量。
还是说一下反面例子，如果产品对项目整体缺少规划能力时，就会出现以下的现象：
- 纵向上进行功能优化时，每个版本缺少衔接性和递进，导致每一版本中出现重复设计，或者由于是断层式需求，所以体验或者视觉样式上不一致问题；
- 横向上功能重构或者新项目启动过程中，各个功能模块之间的逻辑关系不清晰，不同功能模块之间的跳转逻辑和复用关系混乱，后期需要耗费很大工作量去排查。
3、节点把控能力
PM要有主人翁意识，对产品的上线效果负责，所以要把控产品流程的每个节点，以及各个环节之间的配合效果。因为有些项目可能不会专门配置项目经理来把控项目进度和流程，这就要求产品能够从宏观大局上出发，在流程与时间上找到平衡点，保质保量完成任务。
同时对于开发调整需要及时与设计、测试同步，避免项目流程阻塞，很多内容需要当事人重新确认，从而耗费工作量。
这里的节点主要指时间节点，毕竟很多设计和开发手中的项目是并行开发的，每个项目需要给出合理排期，一个版本内相对完整的项目时间流程如下图：
前期PM提出需求并进行评审，包括内审、设计评审、开发评审等，在这个过程中交互设计需要设计结束，同时启动视觉设计。需求确定并收集截止后，后端优先启动开发，随后前端开始开发，随后就是进行测试和设计验收，待BUG修复完成后，可进行Android灰度测试或者iOS版本的内测，随后就是提交应用商店等待上线。
所以从流程中中可看到，设计、开发、测试的工作都是紧密配合并且有重叠的，所以需要做好时间规划，把控每个节点的启动和结束时间，同时为每个流程都需要预留可浮动的天数减少项目风险。
4、品德与责任感
无论产品是否做得好，但是要先学会做人。为人处事要正直端正，唯唯诺诺或者趋利避害的性格是无法胜任的。PM是项目的牵头人，如果头部出现问题，那身体的其他部分就太容易失控了。
曾经参与过一个项目就遇到了一个缺乏责任感的PM，相比与缺少产品思维或者其他靠谱能力而言，对于团队的伤害更大，主要表现在：
（1）不愿担责任
项目出问题需要讨论确定时，本着多一事不如少一事的态度，任由事态发展或者当事人自己解决，不主动去把控问题解决进度和结果。
（2）处事不端正
内部合作出现问题，总是想着息事宁人，维护表面的和谐。面对强势的对接人员就容易妥协，面对性格温和的对接人员就满不在乎，内心缺少公平公正感。
（3）甩锅
项目delay，PM本身对于关键问题不敲定，不发出邮件确认和明确，这样就会很容易让项目组内部关系一团糟，问题出现时难免会出现互相甩锅的现象，结果项目内部需要花费很多时间和精力来追责而不是完成项目进度。
在设计师眼中，“靠谱”的PM既懂得产品，又懂体验，同时还有一些美学知识，当然他是一个品行正直有责任感的人……如此看来，作为一个“靠谱”的PM也是不容易啊。
本文为@运营喵原创，运营喵专栏作者。