实在是不想写开篇语了...
算了，还是写吧，要不显得文章没头没尾很敷衍...
思考中：怎么写能吸引引起大家的兴趣，是大家读下去呢...
算了，不玩套路了，直接来：产品和开发的日常撕逼，看似正常，其实可以避免，之前老K一直强调沟通能力的重要性，其实，最最根本的，是产品经理要有基本的自我修养。
下面，论产品经理的自我修养：
别YY需求
产品经理提出任何需求，原因一定不是，不是，不是：老板想要、运营需求、竞品已有等等这类**的理由（老K曾在产品经理7神器——说服程序猿一文提出过说服程序猿的法宝，这明显是用来搞笑的，聪明如你们，一定懂得吧）。任何需求，都要从产品目标&用户需求两个层面去考虑，首先找到充足的理由说服自己，然后再去说服技术。
举个例子：比如理财产品都涉及绑定银行卡这样的功能，一般需要手动去输入银行卡号，体验很差。所以PM提出优化方案：用拍照识别银行卡来代替手动输入。这个需求，从产品目标上讲：符合产品科技金融的定位&简化操作可以提高转化和留存；从用户需求上讲，极大的优化了体验，用的爽！
做好信息共享
很多PM在需求评审时只告知要做什么，而不说明为什么要做。是啊，程序猿负责实现功能就好了，说其他的有什么用？然，这种想法是绝对错误的，大家同属一个Team，一定要让每一个人都明确目标，同时也明确自己的努力可以向目标迈进一步。
而且，经验丰富的程序猿会想到功能可能的延伸方向，提前做好可扩展性。
不要强行评估工作量
即使是技术出身的PM，也不要强行去评估工作量并确定工期。切记，专业的事儿交给专业的人去做。
尽量别改需求
对产品来说，改需求是一句话的事儿；对技术来说，改需求可能意味着代码废弃、框架重构...简单说来就是通宵两天写的几千行代码没用。。
所以，承接第1条，别YY需求，所有的需求都从产品目标&用户需求的两个层面去考虑周全，避免在开发的过程中改需求。
及时反馈结果
功能上线后，达成的效果要及时反馈给程序猿（挑好的说），虽然大部分程序猿并不关心运营指标，但自己的努力取得了很好的效果，他们还是很高兴的。同时，也会建立程序猿对PM的信心，信任PM的眼光，由此形成良性循环，沟通上会更加顺畅。
把握好"度"
前段时间看《我的前半生》，其中贺函对唐晶的一句话让我印象很深刻：你学会了我的所有技能，唯独欠缺的是把握一个"度"（具体台词忘了，大概这个意思...）。
其实很多同学都缺乏这个，怎么讲呢，举个简单的例子：需求会后定好了上线时间，但是在测试过程中发现一个BUG影响很大，难以解决，怎么办？逼开发通宵加班解决BUG？讲道理你没错，确定好了时间就一定按照时间节点走，但这类难以预见的问题影响开发进度，该怎么办呢？
所谓的把握好"度"，所谓的人情世故，大概这样吧...
文章转自产品经理日记微信公众号，转载文章仅供学习，感谢产品经理日记的分享。
