认识达内从这里开始

成都达内：程序员该多向产品经理学习!

程序员和产品经理之间的故事大家听的足够多了。本文达妹为大家理智的分析一下，程序员应该向产品经理学习什么。。

最近几年要说哪个领域最火，无疑是互联网领域，而随着互联网的火热，伴随而来的也是相应的互联网职位的火热，比如炙手可热的程序员和产品经理(或者叫程序猿和产品汪)。

我也是一个刚入行不到三年的菜鸟程序员一枚，大学学了四年计算机，毕业以后就一直在写程序。就像很多人说的那样，大部分时间似乎是在为了实现产品经理的需求而写程序，于是程序猿和产品汪之间那些相爱相杀的事情，我也基本都能体会一二。

如果按照主流的做法，作为程序猿王国里的一猿，我应该挥舞起长矛大刀对产品经理口诛笔伐一番，但是这里我却丝毫不想去为了黑而黑，而是一反常态，从自己的角度来谈谈，作为程序员，我们应该从产品经理那里学到些什么能力，而这些能力，程序员往往做得不够好甚至可能是欠缺的。

01

文案能力

对的，没错，就是文案能力。程序员最擅长的是写代码，用文字符号来清晰地表达程序的运行逻辑，简简单单的if...else、for就能表达很多复杂的运行逻辑，时间久了，对于母语的表达能力渐渐下降，写个注释往往都能词不达意。更何况现在代码风格指南都在强调好的代码不需要注释，于是程序员越来越少写自然语言了。

于是就经常出现一种场景，产品设计了一个静态页面，上面全是产品说明、用户指南等等，程序员觉得这个太简单了，复制粘贴，就一段HTML，嗖的一下就上线了。但这只是开始，你会发现产品经常时不时地修改文案，换掉图片，于是你不停地修改，不停地再上线…

除了静态页面这种大面积的文案时不时地修改，弹窗提醒这种犄角旮旯的文案也不说是写好一次就能一劳永逸的，总之文案这种在程序员看起来不起眼的东西，在产品经理那里就会非常被重视。

不重视文案的后果，就是程序员有时候自己写的文案往往让人感到可怕。比如，直接给用户来个“500内部错误”，此时的用户估计也是一脸懵逼：错误就错误，啥是内部错误?内部错误就内部错误，500又是什么鬼，玛雅人的神秘符号?

程序员自己都明白，500是个HTTP状态码，内部错误指的就是Internal Server Error，但是用户不知道啊程序员大哥!

那我们再来看看，如果是产品经理，会怎么提示用户出现错误的?列举几个我看到的：“主人，服务器开小差了，请等会再试试吧!”，“服务器提了一个问题，我们正在紧张地撰写答案”，等等。这些文案是不是看起来要比“500内部错误”好很多呢?是不是有点俏皮与严谨的同时，又能给用户一个心理安慰呢?

当然，我说的是面向用户，如果你是程序员，可能会觉得真磨叽啊，直接告诉我错了不就行了嘛!但是，如果你正在使用别人家的app，不是你自己在调试程序，想想看别人家的app给你突然弹个窗“500内部错误”，你还不是一样爆个粗口，大呼“卧槽”!

02

沟通能力

据我的观察，画原型图只占据了产品经理工作时间很短的一部分，剩余的大部分时间是在和老板、开发、设计、测试沟通，推进产品的一次次迭代。

所以，在一个程序员眼里，产品经理是要协调各方一起推进产品上线的角色，如果有人对需求产生了认知上的偏差，产品经理是要负很大一部分责任的，至少说明产品经理的沟通没做到位，而这样的产品经理大部分都被辞退了，因为出现沟通问题最严重的后果就是上线延期甚至产品失败，一个产品的失败是对产品经理最大的否定。

总之，产品经理绝不是埋头苦干的原型画家，要去关注外界、关注他人，平衡各方利益并且化解冲突。沟通，本质上也是权衡与妥协的艺术。我看到的和遇到的产品经理，沟通能力普遍都是很好的，至少大部分都不输于程序员。

如果你是是经常埋头写代码的程序员，那我真要建议你抬起头来，向产品经理学习，比如学会主动和领导沟通进度、和同事沟通想法。确实存在这样的一些观点，程序员写好代码就行了，不用想其他的。

我是不太赞同这种观点的，如果自己仅仅埋头写代码，不和同事相互Review，不去探讨更好的做法，不去学习他人优秀的命名方式或者另辟蹊径的算法，是不大可能写出好代码的(除非你是Linus这样的天才)。

在很多人看来程序员属于闷骚型群体，不擅长与人沟通，但其实在我看来，程序员是一种对沟通能力要求一点也不低的职业，至少我身边的程序员同事沟通能力都不差。

比如在接口定义、排查错误这些需要和其他程序员和测试沟通的场景中，如果程序员过于闷骚和不知变通，多半是要出现相互甩锅和争吵的场景的。

03

整体思维

现在稍微有点规模的互联网公司都会把各个业务或者功能进行细分，很多程序员往往会专注于自己的业务和细分领域。精细化分工，是现代社会发展出来的一个高效率生产方式，对提高公司的竞争力是大有好处的。

但是这有一个负面的影响是，很多程序员往往过于专注自己的一亩三分地，不太关心甚至忽略了整体的存在。

曾经听到过一个产品经理这样对开发人员实现的结果表达不满：我们做的是产品，不是功能!这句话深深触动了我，因为我以前很长一段时间总是关注在能不能实现这个功能，很少考虑这个功能之外的东西。

比如只管实现这个需求，而不管到底为啥要这么做，这么做的坏处是什么，所以实际上背后的实现逻辑最后越来越复杂，结果导致实现的东西不仅没有产生理想的效果，反而做了很多的无用功。

产品经理思考的出发点往往会从整个产品本身出发，某个功能点只是产品整个价值体现的一部分，做产品不只是做功能，还要思考这个功能背后到底解决了用户什么样的痛点，是不是会伤害用户体验，是不是会产生运营上的问题，等等。

思考到这一点，也许程序员最后发现能找到其他的解决方案来实现最本质的需求，而很可能比最开始的解决方案更加完美。

像产品经理一样，从整个产品的角度思考问题，而不是只局限于某个细节，适当地跳出框架，从更宏观的角度看待系统、业务、公司，程序员也能更好地理解我们的系统为什么这么做，代码为什么这样写，从而帮助公司实现整体意义上的产品价值。

04

总结

一个好的产品经理其实绝不止这些能力，而文案、沟通、整体思维这些能力是我所观察到的作为产品经理最容易被放大和辨识到的能力，也是多数比较容易被程序员忽视的能力，程序员学习到产品经理身上这些最容易被观察到的特质，对程序员本身来说是一个非常好的进步的过程。

所以，程序员，请多看看产品经理发给你的文案，是不是比你自己写的更友好，逼格更高?多观察产品经理是怎么说服大家接受需求变动的，如果换作是你，你能安抚大家的小情绪吗?多体会产品经理对产品设计和预期的宏观描述，再简单的功能也有它背后的逻辑和存在的意义。

成都达内培训，成都达内，达内培训