PM喜欢的开发，或者说PM眼里的自己

开发眼里的产品，是什么样子的，我不清楚，我也没做过开发（初期的时候肯定觉得这PM就是一傻逼）。但接触过一些开发人员，发现了一些优秀开发人员的共同品质，反过来，或许开发也希望产品人员具有同样的品质吧~

优秀的专业技能

这个是最基本的。每个人的编程水平有高有低，你不能奢望每次跟你合作的程序员都是只手遮天的牛人。当然了，一般情况下，就你那点破需求，开发都能搞定。所以，这里的专业技能，是指另一个层面的问题：对对方方案的评估。

产品人员，应该能虚心提取多方的建议：来自用户的、来自运营的、来自开发的、甚至来自老板的圣旨……但是，好的产品决不能随便认同别人的建议！哪怕他当时跟你说的多么激动人心、多么在理、甚至数据显得多么充盈。工作快两年了，深有感触的一点：千万不能被小部分别有用心的“用户”给带沟里！产品人员需要先接下需求，再仔细斟酌。你会发现，当初一听就头脑发热的idea，其实后来90%都会被证实不靠谱、自欺欺人。产品在工作的时候，也要听取开发的意见，并且由衷地期望开发多给出意见，特别是反对的意见（至少我是这么希望的）。你的头脑发热，就需要有人向你泼冷水。谁来泼？最好是技术同事。本着对工作负责的态度，冷水泼的越多，产品人员越清醒、受到的打击越大，脸皮也越厚……(*^__^*)

具体一点：一般开发都会对阈值很敏感，特别是超出范围的情况。而产品的一般思维，都会忽视那些“小概率”事件。因为在产品看来，小概率事件，都是极小部分闲的蛋疼的用户才会触发的事件。照顾好大多数人就行了。但是开发的思维：代码又不知道谁小谁大，到时候溢出了报错，怎么解决？……我在工作的初期，经常会被开发问住：如果就是有用户手贱，愿意触发按钮100次，那我们设计的上限是100，那么101怎么办？

那时我的心态：What a fu*k!&%……#&%%

不过我还是很感谢开发提的质疑。因为强逻辑性的思维，是很多产品人员都欠缺的。

能协助产品拆解方案——因为谁也不知道，这个需求承接下来，未来将是怎样一个个的深坑……

多久能上线？到底改完了没有？改改改，还上不上了……这事产品也没多大辙。有时候为了追求视觉的“炫酷”，有时候为了迎合老板的需求，不得不把需求改了又改（话说这事大家都不愿意，但个人认为，产品不应该是提出需求的，因为那会夹杂太多个人主观的东西，而是应该做到处理需求和拒绝需求的）。开发要知道，不是产品跑过来说要实现这实现那的，好的产品应该说服开发一起去实现市场认可的需求——让正确的事情正确地发生。

说到实现、上线，产品希望开发给出一个合理的预估值。大家都要避免：你把效果图给我，我就能做；或者只要技术能实现，剩下用户的事情就交给我……好吧，大家都碰到过这种事：看起来实现很简单，但实际做起来，发现一堆问题要解决：旧的用户怎么办？旧的程序还要不要沿用？（你说不要旧的，那当初谁TM让我做这个的？！）关键的字段表里竟然没有做记录，追踪不到结果……有时候，产品真的需要开发协助，拆解方案。有时候，产品问你还要多久才能完成，并不是在催你，而是他又准备提新的需求了o(╯□╰)o

还是那个老生常谈的槽点——产品需要感性，思维有时候会绕过现有的框架；开发需要理性，程序不报错不代表不会有问题……

无论是PM还是RD，都想对对方说一句：I need U~~~~（相爱相杀）

对产品负责的态度——这里的产品不是人，而是大家共同做的事情。

我作为产品狗，迄今为止加班最多一次8个小时，到夜里快2点才走。也没啥大事，就是明天要交付给客户的东西开发还没做完，陪着他们一起，顺带测试什么的。我知道，这个加班时长，对各位程序员同志，可能根本不算啥。但起码想表明一个态度：咱是一条战壕里的。

我不知道开发看见，每次下班，提需求的产品拍屁股走人，是什么心情；至少我每次走的时候，看到开发还在为产品需求加班加点，心理挺过意不去的。产品和开发，都应该对自己做的事情负责。这件事往小了说对产品本身，往大了说，不忘初心吧。反正鸡汤啥的人卑地微资历浅就不灌了。我相信开发对产品的专注，并不比PM差。

总之，产品希望开发具备什么样的职业素养，反过来，也是希望自己今后在产品工作上，能有所追求有所作为吧~~
大家小年快乐！