某金融产品妹纸：四种姿势教你跪舔程序员不要不要的

放的这么开，涨姿势了…...

难道程序员和产品经理真的到了只能互相砍杀的地步了吗？在工作中，我遇到了几种不同类型程序员，他们有的让我头疼，有的也很可爱，让我们来看看如何用不同的姿势“调戏”不同的程序员？

这种类型的开发十分狡猾。遇到功能，“这个实现不了”，“为什么实现不了”，“这个要好几天，要改原来的逻辑”， ”不会啊，只是在原来的基础上面修改”，“你这个需求里面没有说”，“开会的时候说过了啊”，“你这个文档没有写”。

对于不懂技术的产品经理该怎办呢，我的方法是逼着自己去了解基本技术理论+软硬兼施，不达到目的誓不罢休。在PMCAFF社区里也有很多人问PM到底要不要懂技术，我的观点是作为PM还是要懂一些的。

比如做Android应用，要知道Android原生提供了哪些控件，有哪些基本设计规范，这样在设计方案时可以尽量使用它们。比如是在移动端上的Web产品，要知道哪些交互是在 H5 上较容易实现的，而哪些交互是实现效果非常糟糕的。如果依照在 iOS 上的动画效果来要求 H5，开发成本可能会是指数级上升的。但有一点要注意的是！千万别自己开始闷头看什么编程语言，或者买一堆21天XXX从入门到精通，除了装点书架之外没有任何的意义。不同的产品有不同的特性，也有不同的代码特点，如果你能了解你负责产品的技术背景，对付这种程序员可是手到擒来啊哈哈。

这种开发，他们的特点是没有意识培养自己的全局观，并且盲目自信，不理解业务的时候容易瞎扯。作为产品经理你要做的是什么？我认为是两点：

第一点：结合产品业务拿出整体的规划给研发

一年后产品成熟了要给用户解决怎样的问题？未来半年内产品要做成什么样子？三个月内产品应该主要提供哪些功能？ 这一个月的产品具体方案是做哪些？

如果你作为产品经理都没有规划的话，那团队基本是要完蛋的。作为产品经理你需要把这些规划想明白，并传达给研发团队，让他们在现在的代码里就给未来的功能留下空间，是最好的避免代码重写的方法。第二点：要把需求拆解的非常具体

对于需求文档来说，页面逻辑、页面布局、功能逻辑和每个功能的使用细节，都要存在。并不只是画个交互图就叫需求文档了。你给研发10个页面，做着做着研发反馈说好像缺几个子页面，你再拼拼凑凑，最后的结果是项目失败，需要推倒重来。这种开发，常常以为自己就是产品经理，自己总是喜欢站在用户角度来评论问题，一个逻辑经常会自己陷入一个死循环，没法走出来，提出各种问题，但没有一个问题是能够形成闭环解决原本问题的。要是写代码，估计会写很多个if else 来循环。

对于这样的开发我们应该怎么办？答案是产品经理和设计师主动提供设计细节，这里给大家提供一个视图设计的三要素，这三要素涉及的内容都要提供给研发噢。

第一：界面元素

比如哪里是文字，哪里是下拉框，哪里是按钮，这些属于界面元素，可以用草图，或word简单排版，但要明确界面上的元素是什么，如何展现？是静止？浮动？第二：数据逻辑

比如一个最新最热的排行列表，你要说明这个最新最热是基于怎样的数据逻辑进行排序的。再比如做推荐模块，你需要告诉你的研发，你的推荐是基于什么数据逻辑获取的。如果你不知道，你就要和技术人员一起讨论如何设计这里的数据逻辑了。第三：交互逻辑

界面上可以进行操作的有哪些元素，哪个可以点击，可以选择，操作后出现怎样的反馈，比如显示浮层？进入新页面？或者其他效果？ 这也是要在需求设计文档里说清楚的。这种开发很难去帮你想很多东西，基本上就是你说什么做什么，你不说他就不做了，基本上你要一个汉堡，他只会给你做一个烧饼，因为在他看来里面都是肉，外面都是面粉。但是你说要汉堡，我要培根，我要蔬菜，你给他后，他会立马给你改。

有的同学要问，面对这样的开发我们还有什么好办法吗？有，但没法立即见效，需要产品经理耐心培养，即鼓励研发参与到需求讨论中去，这样做的好处有什么？

一是开发的积极性强，对产品的热爱程度会提高，而不是仅仅当成一个任务

二是加深对当前需求和未来规划的理解，减少之后开发过程中的出错概率，降低改错成本

以上就是我“调戏”四位项目组的开发同事的故事啦，其实产品经理跟程序员还是应该相亲相爱的哈哈，毕竟大家的目标都是把产品做好，保持欢乐的心态，还是可以友好相处的哈。

最酷的产品经理都在读

京东业务增长10倍背后的敏捷开发秘籍【案例+分析】

那些曾刷爆朋友圈的APP，你以为全都死了？

陌陌不约炮了？

PMCAFF|盘点2016最值得突击的七大海外市场：最后一年窗口期，不出海就出局！

一个公式、五大指标帮你构建产品经理数据分析思维

前微博副总私房干货：微博平台与架构从零到IPO的打磨经验

    关注 PMCAFF产品经理社区