产品经理自处的不二法则逻辑业务

　　今天是上班的最后一天，划了一下水（老板，请你假装看不到这几个字好么），逛社区的时候看到有个问题是酱紫的：
　　标题：后台产品经理和前台产品相比，是否发展更受限制？
　　提问：后台产品只要对公司业务了解，熟悉业务流程好像谁人都能做，后台的一些系统对设计以及交互的要求也不高，使用对象要不是公司内部的人要不是合作商，用户量也不会更大，所以在犹豫要不要转前台？
　　谁说对业务了解谁都能做的！
　　谁说熟悉业务流程谁都能做的！
　　谁说复杂逻辑的梳理谁都能做的！
　　你你你，你给我站出来，看我不打shi你！
　　打shi是开玩笑的，毕竟怎么说，伦家也算是软妹纸啦（旁边扶墙呕吐~~），当然可以发现，其实题主最大的需求是希望自己做的产品有更多的人用。
　　But，看到前半段的描述，略感慨。针对这个问题，特别想甩个自己的总体观点：
　　没有后台产品和前台产品谁更厉害，谁发展更好的问题。不过硬要说，应该从整个产品生涯来看待。
　　目前来说我自己认为是：后台产品-前台产品-产品运营。（产品运营这个在这里不具体展开）
　　后台产品：提高业务深入、逻辑梳理的能力，作为基础；
　　前台产品：提高交互、设计的能力，作为纵向扩充；
　　产品运营：提高推广、用户认知、市场认知、整体产品认知的能力，作为更大范围的扩充；
　　通俗来讲，就是要知道怎么做出来、卖出去；
　　在这个问题上，其实有个东西是必须先要明确的，那就是＂前台产品＂、＂后台产品＂的定义：
　　1、这个＂产品＂是真的产品，而不是产品汪
　　那么，前台产品就是普通用户用的、后台产品就是非普通用户（运维、运营、管理人员）用的。
　　例如：选股宝App是一般用户用的，选股宝管理后台是选股宝的管理人员和编辑用的；
　　那么，题主对于前半段的描述还是挺离谱的（题主我不是故意对你开枪的，真的是凑巧）。从产品这个岗位来说，两者差别在于用户群的不同而引起的业务理解、需求分析、逻辑梳理、交互设计的不同，哪样都不轻松。而普遍意义上，给用户用的产品相对来说是比较简单的，后台产品是前台产品的支撑，例如内容发布系统、广告系统、推送系统等等都是后台来做的，对应的，前台是显示内容、显示/不显示广告、收到/收不到推送等等。后台业务更深入、逻辑更复杂，挑战更大。
　　2、这个＂产品＂是产品汪，而不是产品——引申的定义
　　现在产品经理虚多的情况下，把原本的产品工作也做了更多细分：产品的前端产品经理、产品的后端产品经理，其中前端产品经理更注重交互和设计，后端产品经理更注重逻辑和业务理解。 （虽然我觉得这是略奇葩的分法…）
　　两种定义，其实都不妨碍哪个更重要以及如何对自己更好的理解。
　　这个时候，上盘例子什么的比较通俗易懂：（该例子针对第一种定义）#不做电商，为啥要举电商例子我也是迷迷迷惑的
　　用户行为的流程：用户逛来逛去挑选商品->一件件放入购物车->支付->购买成功；
　　针对这个流程，后台、前台、运营分别大概要做的是：
　　后台：货品管理系统、订单管理系统、结算管理系统，每个系统都有各自非常复杂的判断条件以及边界条件，同时一个系统和另一个系统或者另两个系统发生关系时的判断和边界条件更加复杂。
　　这里举个曲折小例子接地气的感受下麻烦程度：
　　小瑶子是个非常犹豫的人，逛了半小时，在店A选了一个尺码为M、有高级会员优惠，同时享受了店铺节日优惠的连衣裙，放进购物车，继续逛了一会，觉得可能M太大了，想去，换成S，结果尺码S么有了，怒了，决定不买这个连衣裙了。过了一会儿在店B买了两双同款不同色的尖头高跟鞋分别是暗红和黑，要付款了，发现店B的黑色高跟鞋木有惹，心好累，付钱付钱，先用信用卡付钱，发现木有开通网上支付，然后用借记卡A付钱，发现里面居然木有钱了，再用支付宝，发现特喵喵的不够，最后支付宝扣除后连同绑定的借记卡B付完了钱。
　　有木有绕晕？
　　前台：首页怎么展示、具体货品页怎么展示、订单页面怎么展示、判断以及边界条件、支付页面流程怎么展示、判断以及边界条件、页面相互之间怎么跳转等；
　　运营：首页展示什么、具体货品展示什么、订单管理时展示什么；
　　这三者其实都是相辅相成的：
　　运营：各种方法吸引用户买买买；
　　前台：各种方法方便用户买买买；
　　后台：各种方法保证用户买买买；
　　吸引到用户买买买了，用户不能成功下单、支付也死活不行，狗带！
　　系统做的棒棒的，各种方便哟，然而用户揍是不喜欢在你这儿买东西，狗带！
　　所以这里，并没有岗位谁比谁更好的问题，而是什么作为自己的基本功更好的问题。对于这个也是比较主观的看法，每个人想法不同。撇除运营，讨论前台和后台产品：
　　我认为先做后台产品来加强逻辑和业务基础，再去做前台产品对自己更加好。
　　这里再端盘例子上来：（该例子针对第二种定义） #终于是自己行业的惹
　　玩股票的人们，都是要看K线图、注重自己收益的吧？我们在做＂选股宝＂App的时候，策略内容中，对于单只推荐的股票有个＂至今收益＂的概念。从前台来看，用户看到的只是一个至今收益的数据显示而已。然而对于后台算法来说，大概酱紫：
　　1、明确计算的是涨跌，而不是模拟盘的收益；（策略性质决定不是组合概念）
　　2、提出被推荐股票的生命周期：推荐->暂停推荐->再推荐->….->终止推荐，其中只计算推荐时候的累计涨跌；
　　3、基本公式=（现价-创建价）/ 创建价 * 100%（基本公式真是简单的太无耻了）
　　①根据推荐/重启推荐的时刻不同，会影响到创建价的记录；（5个时段）
　　②根据暂停推荐/终止推荐的时刻不同，会影响到现价的记录；（5个时段）
　　以为这样就好了吗？还有诸多条件要考虑：
　　1、股票停牌怎么办？
　　2、股票发生除权除息怎么办？
　　3、基金发生下折上折怎么办？
　　4、处于节假日、周六日怎么办？
　　5、中途又推荐其他的股票怎么办？
　　等等…..
　　这些判断条件，需是要对业务了解的人，也就是所谓的＂业务专家＂才可以，不然就算逻辑能力牛逼，但是不清楚有这种情况的发生，也是白搭。
　　同时也要逻辑清楚，不然这么多种情况叠加，懵圈了就。
　　举个程序中会遇到的情况（虽然分析师们多出于长期看好某股票作为推荐的，但是程序上是要考虑的嘛对不对）：在1.1在开盘前的8：00，推荐了股票A、B，写了自己的推荐理由，恰好此时股票A停牌，在开盘后的14:00又新增推荐了股票C，第二天A复牌了。第三天，B股票除权了，在13:00暂停推荐了A股票，14:00暂停了B股票，同时新增推荐了股票D，并且修改了自己的推荐理由。这种情况下，到第三天收盘后，各股票的涨跌怎么样？总体涨跌如何计算？历史更新如何算？页面如何展示？
　　这里的判断并不是简单的1+2+3+4=10，而是1*2*3*4*….*n的问题。
　　可见，逻辑思维和业务理解作为基本功和习惯，是非常重要的。而这种基本功，也会在之后做的纵向提升上有很大的帮助，无论是交互、设计、推广、广告等，会使你考虑问题会更周全。