工作那么多年，合作过的产品经理有很多，但是被我和工程师团队认为靠谱的产品经理却不多，工程师也经常吐槽产品经理不靠谱（貌似，我们之前合作过靠谱的产品经理女性居多，也不知道是什么原因……）。
产品汪和程序猿之间的现状
我们去通过Google或Baidu搜索关键词 “产品经理 程序员”，也经常出现如下的内容。
比如，想不通的……
比如，比较暴力的……
或者，如此求解的……
感觉整个互联网行业，甚至IT圈都在上演产品经理和程序员的“恩怨情仇”，堪比各大影院前段时间上映的迪斯尼大片《Zootopia》（疯狂动物城）。
矛盾如何产生？
很多产品汪都经常会碰到这样的场景：
一个非常复杂的产品设计终于加班加点的完成了，你满心欢喜的召集程序猿们开产品讨论会，但是过程中却备受打击，经常会碰到如下问题，而你还回答不出来：
- 是否要搜索？模糊搜索还是精确搜索？
- 是否有翻页，每页显示多少条数据？
- 能不能输入小数点、负数、字母？
- 公式怎么算的？
- 各种状态如何定义？如何转换状态？
- ……
很郁闷的是上述问题，你在产品设计过程中，你根本没有考虑过这些问题，你一直在考虑如何来创建订单，应该让用户更简单的使用。而这些问题，你认为都是小问题，还需要我来考虑吗？
这个会议的效果可想而知。
程序猿们会认为这么长的时间了，你产品经理在想什么，这些都没有想明白，没干活啊！
产品汪们会非常委屈，觉得程序猿是有意刁难自己。要么觉得这些问题难道不是应该程序猿考虑的吗？要么觉得，这些问题复杂想不清楚。
最后会议草草收场，团队之间出现嫌隙。
当产品汪把上述问题的答案整理完之后，再次召集程序猿们开产品讨论会，发现貌似还是会有类似的问题。
哲人发出如此的感叹:
慢慢的，产品汪和程序猿之间的情绪就越来越对立，对这个产品的热情也慢慢下降，更多的精力和时间都放在两边对耗上了，产品推行的非常之慢。
直到Boos来过问产品的状况，只有互相推诿和指责。
回顾矛盾的产生
其实矛盾产生的根源在于我们在产品讨论会上碰到哪些可能答不出来的问题。
那么，这些问题需要产品经理考虑吗？答案是显而易见的，产品经理必须要考虑这些问题、
因为这些最基本的问题会影响到系统的设计，没有考虑到，意味着产品经理对于规划的产品可以做什么？如何做？能做到什么程度？没有概念，规划产品的可行性就会大打折扣。
一般产品研发的上下游基本上下图，程序猿处于产品汪的下游。
一个没有概念，规划的产品设计，你让一个思维严谨的程序猿如何能接受？他们只会认为，产品经理不靠谱，这种不靠谱的需求只会导致如下情况：
如果让这个产品通过了产品讨论阶段，那么他们只能为这个不靠谱的产品设计和产品经理买单，程序猿们会产生这样的想法： 我TMD就是那个“接盘侠”。
** 产品汪们，你们也想想，你们愿意当这个接盘侠吗？ **
解决矛盾的办法
那么我们怎么来解决这些矛盾呢？
产品如同人一样，有样貌、皮肤等外在结构，也有筋骨、神经网络等内在体系。在产品设计及规划中，产品汪除了要对UI、UE等外在负责以外，还需要对产品的筋骨、神经网络负责。
产品的筋骨、神经网络就是产品隐含的逻辑规则，才是产品运转正常的保证。
我们推出一个产品，一般要解决两类问题：
- 人的问题，业务的问题
- 计算机的问题，也就是技术的问题
那我们设计一个产品，不管我们想的如何天马行空，如何炫酷，也一定要通过一整套的IT系统来支撑。而IT系统本质上就是对数据的各种处理，各种状态流转，使用了各种形态来展示这些数据和状态流转。
而产品汪一般的产品设计思路都是按照人的思维模式来进行设计的，但是人本身就是一种适配功能很强的“适配器”，人可以对模糊的信息做出自己的补充，完善自己对这个模糊的信息补充，并作出自己的反应。
但是计算机并非如此，比如，我们进出地铁，站在扶梯上，会有语音提示“上下楼梯，请握紧扶手”。我们很容易理解这个句话，并作出自己适当的反应，来握紧扶手。
但是计算机如何来理解？用手施加10牛顿的力吗？
那产品汪在做产品设计时，是否要考虑到如何来定义这个“紧”？！
那很多产品汪就非常郁闷的说，这么多的问题，怎么样才能够都考虑到呢？
那怎么办呢？我们是不是需要进修一下呢？比如学星爷研读的秘籍《产品狗的自我修养》。
其实，我们并不需要研读那么深刻的著作，其实我们只要掌握了产品设计的七字真言，基本上也程序猿的在产品讨论会上碰到的问题就能解决的差不多了。
七字真言
很多人看到“七字真言”的第一反应可能是这样的。
其实产品设计的七字真言就是增 、删、改、查、显、算、 传
所有的产品设计，本质上都是对于一些数据、内容、结构层、信息做一些交互，这是产品的本质。
增
- 增加按钮的样式、位置
- 增加按钮的文案：添加、创建、新建？
- 增加内容的字段
- 字段的必填非必填说明
- 字段的验证、提示说明
- 界面排列的说明
- 弹窗还是当前页跳转？
- ……
删
- 删除按钮的样式、位置
- 删除案例的文案： 删除
- 删除时是否要确认？确认窗口的样式
- 删除完以后界面布局的变化
- 逻辑删除
- 物理删除
- 删除之后是否会影响到其他的功能模块？
- …….
改
- 编辑按钮的样式、位置
- 编辑按钮的文案： 修改、编辑？
- 弹窗还是当前页面跳转？
- 可以修改与不可修改的说明
- 更改数据之后，对其他功能模块的影响
- ……
查
- 按照哪些字段进行排序？
- 搜索框：需要对哪些进行搜索？是否可以组合搜索？搜索后的界面如何程序？模糊搜索还是精确搜索？
- 搜索结果的展示如何？是否和搜索条件有关系？
- 搜索条件之间是否有冲突？
- 查不到数据该如何？
- 需要查看哪些数据？
- ……
一般来说，产品经理做到以上四点就能把原型做的非常完善，例如数据做成了列表样式，是否考虑了分页？是否需要排序？排序的话按什么条件进行？排序满足不了需求的话是否需要搜索框？查询框？查看详细列表的打开方式是怎么样的？本页操作还是新窗口操作？跳转之后需不需要跳回来？选择数据支持单选还是多选？单选的话是用下拉还是radio？如此等等
细节交代的越清楚，和程序猿的沟通成本就越小
显
- 页面内容的布局
- 每页多少条数据、数据的排序？
- 是否有翻页、翻页样式如何？
- 是否提供查看详情，如何查看？
- 查看是弹窗还是当前页打开，还是新页面？
- 如何从各个操作页面跳转回原页面的方法？
- 跳转回来的页面如何显示？
- 不同权限用户的数据展示是否有不同？展现规则是怎么样的？
- ……
算
- 计算规则
- 页面公式、特定指标的计算规则
- 数据背后的逻辑
- ……
传
- 不同用户之间、不同操作之间传递哪些数据？哪些字段？
- 需要提供哪些API的接口？整合其他第三方系统时，他们提供的API是否能够满足我们现有需求？
- 数据的流向规则
- ……
每当我们在做产品设计的时候，都在心里默念着七个字，基本上设计出来的产品功能点就都覆盖到了，省去了产品讨论和产品研发过程中很多不必要的沟通、交流和冲突。
有一个比喻非常好，“产品是孩子，开发是妈妈，产品经理是爸爸，测试时医生”，We are 伐木累！，产品汪，你们觉得呢？
最后说一句，不管怎么样，各位产品汪们，需要对产品经理本身的职责要搞清楚，如果你短时间内不能达到产品经理本身应该具备的素质，那你就应该努力提高自己对产品设计和产品经理职责的理解，good good study,day day up！并且，要发挥自己的亲和力将整个团队的各个成员的长处组合起来，一起完成一个满意的产品。
另外，程序猿们也不要太过难为产品汪，大家都是在一个团队工作，为了同一个目标而努力，能够互相支持，互相补位的就多多支持和补位。毕竟大家也都是在同一个马勺里喝水。
