“产品汪”，“设计狮”，“程序猿”，这3个角色的故事仿佛是互联网圈内永恒的段子，看看上面我冒着生命危险放上的动图，话不多说，溜了溜了。
咳咳，回归正题，这期选的题目是产品经理如何与设计师、程序员们愉快地“玩耍”~笔者虽然从业产品经理没有几年，但在这个方面自认为有一些经验可以分享给大家。
01 具备沟通的基本条件——不太低的情商
在公司混口饭吃，情商真的很重要。这里的情商，不指大家拍马屁的能力，因为PMP这个能力需要一定的功力沉淀才能达的到。这里说的情商，泛指一些基本的沟通能力。
创业型的互联网公司有很多明显的特征，其中一点就是“沟通全靠吼”，这一例子，在需求沟通会上就体现的淋漓尽致。一名产品经理对战10名开发加测试人员的需求评审，面对一群人的炮轰，PM不吼上几嗓子仿佛真的没法继续评审了。以前在不同公司实习的时候，有的产品经理受不了他人的质疑，急眼了吵架干架的例子也见过不少。
耐心倾听，不管别人说的对不对，听完是最起码的尊重。
举个例子，我们公司有一位非常负责、热心的测试同学，每次产品经理评审需求的时候，他每次都一定会提出他的意见，并且按照第一，第二，第三，第四....的方式，从需求的出发点，到页面原型UI的设计，到逻辑的跳转，到异常情况的CASE，逐一非常有条理地给你轰炸出他觉得有问题的地方。这名测试同学在产品内部有着相当高的名声，每次评审会只要有他在，一定快不了。暂且不论他说的意见是不是一个测试同学应该考虑的，我十分尊敬他的一点是：他能忍着他的123456，直到产品经理讲完需求再提出。这其实是一个人职业素养的体现，你是否能够有足够的气度听完别人的意见，再抛出自己的见解。虽然他的很多想法，没有像一位PM一样从各种维度去想清楚需求，但每次和他的对峙过程，都能让我发现我的设计中缺乏的一些细节和一些有道理的地方，这也是我每次让自己耐心听完他说的东西之后，才能得到的收获。之前也有过几位和他合作的PM，会觉得他很无厘头，一个测试想那么多产品的东西干什么，甚至有的开发也怪他凭空又给加了几个需求点，就会在需求评审会上争论起来，不止不休，导致需求评审会不了了之。其实公司能有这样一位有想法、负责任的同事，对项目来说是极好的，如果PM说什么，技术就只做什么，那产品出来后，一定会有不少问题，只有开发环节中，每个角色的人都参与进这个项目，思前顾后，才能保证功能的完善。
站在对方的立场思考问题
换位思考，一直是处理人际关系中的一个非常有用的方法。在和设计、开发同事合作的过程中，一定更要善于换位思考，有时候理解一下他们为什么这么做，就能更顺利地推动项目的进行。往往一个设计师、一个开发不是专门只做你一个需求的，他们手里都会堆积甚至并行着很多项目，如果你只为了自己的一个需求不停地去要求、催促他们，往往是容易被“拉黑”的。有的时候，先了解一下对方目前的工作情况，再去做相应的措施。比如发现是对方的优先级排列的不正当，再通过项目经理、或者主管去沟通，将自己的项目优先级提高。比直接去要求他们做你的需求，会更高效。如果发现对方确实很忙，那么调整一下自己的项目的开发计划，报一个delay的风险评估，缓解一下他们手头的压力，可能会让他们更加感激你。毕竟由于“开发资源不足导致的项目延期”是一个常见的风险，是公司需要知道和处理的事情。
02 储备一定的“非专业”技能
这里的“非专业”，指的是“非产品”专业的技能，比如非常非常好用的PS。
越工作越发现，不会PS，没法出来混。
在公司里，设计和开发资源紧张是很常见的情况，但是项目周期又逼得很紧，怎么办呢？比如一个项目的设计稿完成了，设计师没时间切图，手头有了其他急活，开发又不愿意在没有标注切图的情况下开发。那么这种时候，只能"万金油"的产品经理出动了，这里推荐设计师同学介绍的2个很好用的PS插件：
Cutterman和Parker
Cutterman是一个一键切图工具，Parker是一个一键标注工具，非常好上手。只要懂得PS的基本操作，点一点，就可以完成设计稿的标注和切图工作。
公司里有一位能力很强的平面设计师，有时人力不足时候会让她来做一些UI的设计，但是她专攻平面设计，不太擅长切图，手头活又堆着很多。H5的开发又很傲娇不肯自己切，遇到这种情况，我都会主动承担切图的工作，其实产品经理切图有几点优势：
1.因为和开发比较熟，可以去和开发沟通好他要怎么做前端的页面，什么元素需要切出来，什么元素他自己用代码写，切什么尺寸等等。经过一番沟通之后，再去做切图工作，可以事半功倍。而如果让设计师直接切图的话，设计师并不一定懂前端H5的实现方式，会按照自己的理解去切，一般切图到了开发那里后，还需要返工。
2.在切图的过程中，对设计稿再做一遍详细的审核，发现文案不对，页面缺少什么元素之类的，及时让设计师改动，或者自己能改的就自己改了，也是能避免开发开始后，又对设计稿返工，导致项目延期。
作为一名产品经理，你自己切了图，那么等于你既给设计师卖了个人情，又给开发卖了个人情，1个活帮了2个人的忙，这样一举两得的好事干嘛不做呢~不会？摸索着学呗，产品的技能怎么学会的，这些技能也一样学。
03 遵循一定的流程
在创业公司中经常发生某个事情出了问题，大家互相甩锅，翻邮件，找罪证。经历一次两次后，慢慢发现发邮件是个很保险的事情，虽然繁琐，但是能保人身安全啊！
产品开发流程，会根据每个公司的不同情况都不一样，但这个流程相当的关键。作为产品经理，确实很多时候我们只是改一些小需求，上一个小产品，加一个小功能。但是往往积少成多，经历了一个个环节之后，越到后面，相关的人越不清楚，这种时候，大家都需要去翻需求邮件，翻PRD文档等等，如果没有，那就又只能找产品经理问了。还有测试同学会在最后忽然接到产品经理说这个项目需要测试资源，这对于测试的leader来说是最不能忍的，说明你忘了“测试”这帮辛苦的小伙伴！！没有发需求邮件提前告诉测试安排资源，没有在需求评审的时候叫上测试让他们知道这个事情，还在最后让人家帮你干活，换做是你你也不愿意干吧，但项目要上线，必须要测试，所以他们又只能怨恨着加班加点给你测试了，当然，你也就再一次“被拉黑”了。
我总结出的一些特别容易忽略又特别重要的流程：
1.需求邮件：
一个需求的提出，让需求方或者产品经理自己发一封需求邮件，后续整个开发流程的进展都在这一封邮件的基础上进行回复，保持一个thread。记得要发测试人员，需求评审的会议也要叫上测试人员！
2.产品文档：
虽然说敏捷开发，快速迭代，但是必要的文档该有的还是得有，形式不用那么固定，最起码让开发、测试有地方能看需求。这些小改动，最后还是要归纳进产品的版本管理当中。
3.埋点需求：
很多公司的产品，可能经历了几个主要的评审、设计、开发、测试、上线、回归之后就结束了，等产品发布上市了，用户使用了，想看一下数据，这时候发现“没有埋点”，是很要命的事情。建议将埋点的过程也加入在公司的开发流程里，甚至是产品的需求文档里，评审的时候也叫上数据工程师一同参与，对埋点方案进行讨论和评审。
4.总结复盘：
在创业公司，一个产品经理可能会对接多个项目线，做了很多需求，一个个接着上线了，发完上线邮件好像就是项目结束了。其实，每一个上线的产品都是产品经理的孩子，孩子出生了，不照顾可不行。对上线后的数据进行统计分析，如果开会成本太高，那就总结一封复盘的邮件，去分析总结这个项目的效果和收益，效果不好也不用担心，因为很多产品都是试错的过程，切忌不要谎报数据，真实、合理的分析比结果更加重要。
以上我总结的一些与研发、设计同学工作中处理关系的经验与技巧~欢迎各位留言讨论。
-------------
各位客官手动点一下“喜欢”，是我继续写作的动力~
