Art
一·互联网公司的鄙视链
在互联网公司，开发同学总会或多或少鄙视产品同学：“什么都不懂，就会瞎BB”。即使很多时候没有这么表达，有时候也在内心里这么想着，想着……
先来看一个段子：
开发哥哥的计数器
那么，问题来了：
产品经理怎样才能得到开发同学发自内心的尊敬呢？
第一，要对自己的产品业务逻辑足够熟悉。
第二，多一点技术思维。
二·产品经理需要对自己的业务内容足够熟悉
对于产品经理或者项目经理来说，如果能够对自己负责的产品业务足够熟悉，甚至比开发同学还要熟悉，那么就会得到开发同学的足够尊敬。
举一个我身边的例子：我的一个师兄在某证券公司做项目经理，根据师兄的描述，他会利用下班时间，周末时间学习金融领域的各种知识，对自己负责的业务非常熟悉，相比之下，很多开发同事对于一些业务不熟悉或者只熟悉自己负责的那一块。这样一来，开发同学对这位师兄尊敬有加，自然而然，师兄开展工作就得心应手了！
这位师兄是所有同届员工中发展晋级最快的。
因此，产品经理需要对自己负责的产品或者业务足够的熟悉，这样在跟开发哥哥对需求的时候才不至于出现理解偏差。同时，自己提出的需求也是基于自己的业务逻辑的，有理有据，让开发同学信服。
三·产品经理需要学习一些技术思维
对于优秀的开发同学，他们在开发过程中，会有一套严谨的逻辑体系，他们会关注边界情况，他们会熟练使用状态跳转图，他们会有许多编程技巧。
上面说的是优秀的开发者具备的特点，如果产品经理也能了解这些方法，对工作将会有极大的好处。这些方法属于方法论层面的东西，而不涉及任何技术细节，产品经理也都应该学习。
下面详细来说：
第一，拥有严谨、清晰、全面的逻辑
以设计一个邮件箱的翻页功能为例。
邮件列表功能
简单一想，很简单：就是加一个上一页、下一页的按钮，再加几个页码数字，供用户点击跳转就可以了！
但再深入思考，有那么简单吗？
比如：
@邮件有0封应该怎么设计？
@如果邮件每一屏要显示10封，有8封时候应该怎么显示？
@有两页时候应该怎么显示？有8页时候应该怎么显示？
@有100页时候应该怎么显示？要不要有邮件删除功能？
@删除功能要不要弹窗进行确认？
评论功能
再举一个经典的例子：论坛帖子的回帖功能。
简单一想，很简单：你发了帖子，我的评论就在下面显示就完了。
但再仔细想想，真的那么简单吗？
比如：
@评论的这条内容要不要显示时间？
@有多条评论的时候，是按时间从前往后显示，显示从后往前显示？
@评论还可以被继续评论吗？
@评论和子评论的展示UI需要有差异吗？
@评论可以被点赞吗？
@点赞之后可以取消吗？
@点赞之后要显示点赞人吗？要显示的话按照什么顺序显示呢？
所以。我们看，一个小小的功能就会有非常多的可能性，产品经理必须能够对逻辑有非常全面的理解，然后根据自己产品的调性，经营决策取舍。
这样一来，当开发同学来挑战你的时候，你都是经过严密思考的，开发同学会佩服你的。
第二，考虑清楚边界条件
以上面的邮件箱功能为例：
邮件数量是0的时候应该怎么做，是100的时候应该怎么做。都要考虑清楚。
以评论功能为例：
每条评论最多显示多少字？一共可以显示多少条评论？如果有1000条评论怎么办？都要考虑清楚，并给出方案。
第三，熟练使用状态跳转图
@记得以前学习“马尔科夫链” 的时候，就经常画逻辑跳转图。
@再到学习《编译原理》的时候，有状态机的概念，也要使用状态跳转图。
@再到学习操作系统的进程调度，也是通过状态机来呈现。
所以说，开发同学在以前的知识架构过程中，已经熟练掌握了状态跳转的使用，这是保证逻辑性的关键。
对于产品经理在策划产品时候，业务逻辑免不了状态变化，不同状态如何跳转，除了初始状态之外，一个状态不可能无缘无故来，也不可能无缘无故消失。
所以，对于产品经理来说，首先要把状态跳转关系整理清楚，画出来。其次，要把每一种状态下对应的情况内容，整理清楚。
第四，学习一个软删除的技巧
首先，这个技巧非常有用。其次，软删除是一个技术概念，指的是用户在删除的时候，只是表面上看起来没有了，其实在数据库中还有保留。
对于产品策划功能时候，有时候在用户删除一个重要信息之后，我们还需要看原始记录，怎么办？这时候就采用软删除的技巧，用状态位标记。状态位是1的时候就显示，用户删除后，我们把状态位置为0就好了。
四·总结
道理很简单：
对于产品经理而言，技术思维用的好，才不会被技术同学喷，反而会比开发同学想地更全面，从而真正得到开发同学的信服。
xander / 2017/ 08
网友评论