产品汪和程序猿的相处之道

2016年1月20日 10:34 阅读 414

今天这篇文章是关于产品经理话题的第三篇，专门谈谈产品经理和程序员怎样建立良好的工作配合。前面两篇分别是「人人都能做产品经理吗？」，「产品经理究竟是做什么的？」。

如今的互联网有个传说中很神奇的职位，叫做「程序猿鼓励师」，据说都是童颜巨X的妹子；今天看到一个文章，某公司程序猿过生日，请了好几个身穿比基尼的俄罗斯外模（如下图所示）；更不用说某互联网公司年会请岛国女优的事情了。

好像程序员给业界的印象通常都是：死宅，萝莉控，难以沟通，通常非常难以合作。特别是对于产品经理来说，好像必须哄着程序员干活，得用尽各种办法哄，否则程序员不配合。我其实一直很奇怪，程序员群体究竟怎样被妖魔化成这样的。

前几天carol写了一篇非常棒的文章：「技术人员愿意亲吻怎样的运营？」，这篇文章从运营人员角度去谈怎样和程序员合作，我也推荐给产品经理看，因为道理都是一样的。我就从产品经理角度再补充一些建议：

产品经理和研发共同参与产品设计

一般的产品流程都是从产品需求搜集，到产品原型设计，这个阶段都是产品经理来执行，然后产品经理把原型交给视觉设计，视觉设计出高保真的设计稿，最后交给程序员开发。

在这个产品经理，视觉设计，程序员共同参与的产品生产过程中，程序员是最后的环节，当程序员在代码实现的过程中发现了产品逻辑的错误，或者产品设计的问题，是非常被动的。这个时候程序员再要求产品经理更改设计，修正产品交互逻辑，产品经理通常的反应就是：「程序员又和我讨价还价，产品deadline又要延后了」，跟着双方就开始剑拔弩张的对峙。

我在带团队做产品的时候，从产品立项一开始，就召集产品经理、视觉设计、研发负责人、运营负责人、运维工程师一起参与，把产品的目标定下来，然后让大家各自从自己工作分工的角度去讨论产品需求，产品功能，产品应该采取什么视觉风格，产品实现是否有难点，产品部署需要预先考虑些什么等等。之后每周产品例会都会召集大家一些开会讨论产品进度。

尽管产品立项之后，是由产品经理负责搜集和定义产品需求，整理产品逻辑规则，设计产品原型稿和交互，这个阶段并不需要程序员开始写代码，但是从一开始就让程序员，运营，甚至运维工程师都参与进来，是非常有益的：

程序员从一开始就了解了产品的来龙去脉，对产品需求和产品要达到的目标非常清楚，这样在和产品经理的配合中，就非常容易理解产品经理提出的很多功能要求，沟通起来非常顺畅；
程序员从一开始就参与，并且持续参与产品设计的过程，最大的好处在于从一开始就可以纠正可能出现的产品设计逻辑错误，以及评估技术难以实现的产品功能。这样等到真正进入开发阶段，研发周期是非常可控的，基本不会出现延误。
一些有良好产品意识的程序员，可以帮助产品经理从一开始就完善产品逻辑，从实现上修正产品可能遇到的问题，让产品开发过程变得更加有保障。

很多产品经理犯的一个重大错误就是：直到原型稿交互稿定稿之后，才交给程序员，之前全无沟通，然后逼着程序员立刻评估一个精确的开发周期。

这个时候程序员内心是非常抗拒的。一来我完全不了解这个产品，不知道做这个产品是干啥的？能够解决什么问题？是否有更好的替代解决方案；二来我也不清楚这个产品逻辑是否有需要调整和修正的地方，以及有些技术上需要投入很多资源但是不划算的功能。

所以程序员通常只能硬着头皮估一个时间，然后实现过程当中一旦出问题，就是双方互相扯皮，互相推卸责任。

产品不是产品经理的，而是大家的

互联网公司通常是产品经理负责制，产品经理往往认为我是这个产品的owner，你们其他人都是配合我工作的。但其实除了创业者CEO自己就是产品经理之外，通常大公司的产品经理并不真的是产品的owner，不具有对产品最终负责的权利。这个时候就产生了认知的错位和工作对抗：

产品经理认为：你们都应该听我的指挥，我是产品的owner，你们都要配合我的工作。但是程序员会想：我凭什么听你指挥？我还有我的上级领导呢。我和你就是平级关系而已，我又不是向你汇报，你凭什么对我颐指气使？

在这种情况下，产品经理应该传递一个信息：产品是大家的，需要大家共同合作，一起努力把产品做好，无论是产品，视觉，研发，还是运营，大家都是为了一个共同的目标而努力。我作为产品经理并不天然具有命令大家的权力，如果大家愿意听从我的意见，那也是因为我更加努力，更加专业，做出的贡献能够得到大家的认可。

你真的需要这个功能吗？

产品经理面临最大的自我拷问就是：「你确定你真的需要这个功能吗？」。产品经理提出一个功能需求是很容易的事情，不浪费什么资源，可是一个功能一旦确定需要做，后面跟着的就是大量的设计，开发，测试，以及产品上线无休无止的维护工作。

另外一个特别常见的现象就是一个功能开发出来以后，很快又抛弃掉了，改过来改回去。而产品经理通常又不需要为此决定而买单，擦屁股的都是程序员，所以这也是非常招人恨的原因之一。

好的产品经理总是在思考应该再去掉哪些功能，而不是毫无节制的添加产品功能。即使添加一个功能，也要再三拷问自己，真的需求吗？真的必不可少吗？

不需要懂技术，但是逻辑要严谨

其实产品经理并不需要懂技术，很多优秀的产品经理也并非技术出身，但是产品经理必不可少的一项基本功就是：逻辑要严谨。因为一旦产品经理思考不周全，或者产品逻辑出现了自我矛盾，最终都是程序员要为此买单，要么产品功能实现不下去，要么到处都是漏洞，程序员变成了救火队长。

产品经理犯的错误，最后买单的都是程序员，这也是为什么一个差的产品经理通常很招程序员恨的主要原因

关于产品经理的基本修养，请看公众号前面的文章「人人都能做产品经理吗？」（回复消息022）

以身作则，以德服人

产品经理可以是很忙碌的，也可以是很清闲的。

什么叫做清闲的产品经理：等着用户（或者客户）反馈bug和问题，整理到工作任务列表，指派给程序员，然后定期监督程序员工作完成状态。新的产品立项，画个简单的原型线框图交给视觉，然后催着程序员定deadline。

什么叫做忙碌的产品经理：主动找用户（或者客户）做访谈，搜集产品反馈，根据产品反馈，思考产品未来的改进方向；将用户的反馈和自己的产品规划定期和程序员沟通，大家一起商量制定产品迭代改进的roadmap；仔细钻研产品界面的每个元素，动手画出高保真的产品原型和交互，罗列产品每个分支逻辑，以及异常处理流程；整理产品的所有功能点，设计完备的测试用例，并且在产品的每个发布点做详细的完备的测试验收工作；和程序员每周定期沟通，互通有无，推进产品开发进度。

如果你是一个清闲的产品经理，只是动动嘴皮，敲敲键盘，那么你的价值在哪里？你怎么可能取得程序员的信任？如果你是一个忙碌的产品经理，你承担了产品大量的工作，成为一个产品事实上的灵魂，程序员怎么会不喜欢不配合你呢？

一个产品经理如果能够做到以上几点，我相信一定能够成为程序员非常喜欢的产品经理。其实程序员这个群体和任何其他群体没有什么特别的不同，也不是真的需要什么程序猿鼓励师，需要产品经理哄着才能干活。说到底其实就是一条：踏踏实实做好自己的本职工作，才能赢得程序员的尊重。