大家好，最近非常得忙，也好久没有更新博客了，过年期间忙里偷闲写一下这段时间的心得。
2015年下半年，我离开了挖财的PD岗位，以一个合伙人的身份加入了一家创业公司，也算开始了创业之旅。
创业项目是一个任务类平台产品，平台型产品的特点就是需要兼顾“Platform/Business/Customer”3方需求，逻辑方面会比较复杂，也算是产品中最考验产品经理业务能力的类型了。所以我欣然接手这个项目，并视之为挑战。
刚接手这个平台时我发现，因为之前没有产品经理管这个项目，需求全部由业务方直接提出，所以平台的业务逻辑非常混乱：资金流系统接近崩溃，代码信任度极低；多个功能卡到爆炸，用户体验等于零；功能方面为了实现而实现，完全不顾及性能和可维护性。
但总得来说，该平台潜力巨大，且方向绝对没错。最好的证明是：在产品如此混乱的情况下，业务成绩却非常不俗，月流水超过了百万（此为银行流水，系统流水此时已崩溃，无法展示精确数值）。
而这个平台之所以会是那样，原因就是程序员思维，陷入了复杂陷阱中。
何谓程序员思维？就是当一个需求出现，他就用逻辑A去解决；另一个需求出现，则用逻辑B去解决；而当逻辑A与逻辑B产生了冲突，他就会去添加逻辑C去解释A与B的冲突。一两层逻辑的情况下倒也还好，当逻辑的堆叠到达4、5层时，维护成本就会变得异常夸张。而在平台型产品上，要考虑3方需求，这种情况显然会被放大1.5倍以上。
而我对这个平台进行功能整理时，就发现了一个陷入复杂陷阱中比较典型的例子：
首先，我们先来介绍一下之前的逻辑：当一个任务被Business创建完成，任务则会生成多个子任务让Customer来完成。当Customer因为觉得子任务麻烦而不想做了，则有3种理由撤销子任务：不想做了/任务过于复杂/任务无法完成。
当然，子任务被撤销的同时，Customer也将受到惩罚：佣金-1.
而当一个任务有3个子任务因为Customer使用“任务无法完成”来撤销时，那么我们就开始怀疑Business放出的任务是否能被完成，所以任务将被暂时冻结，Platform方将重新审核此任务，以确认是Business的问题还是Customer的问题：
- 如果任务确实无法被完成，则会被删除，撤销子任务的Customer们被扣除的1元佣金也将被返还；
- 如果任务可以被完成，Customer只是不想做了而已，那么任务将被重新放出，撤销子任务的Customer们将无法再接这个任务了。
看到这个逻辑我相信所有产品经理的内心都会崩溃，因为他的逻辑远远超过了2层。我想，这繁杂的逻辑一定不是一次性提出的需求，而是由需求方和程序员在混乱中所制作出来的奇怪功能。
然而它确确实实存在了这个世界上，存在于程序员逻辑的复杂陷阱之中。
那么，我也给出了自己的解决方案：
- 取消3种撤销子任务的理由。
- 修改撤销子任务立即佣金-1的惩罚：改为一个Customer一天只能取消3次子任务，超过3次子任务后，每次撤销子任务开始扣除1元佣金。
- 取消任务的冻结状态与Platform审核。
完成后，这个业务的逻辑立刻变得清晰、简单和单向，逻辑也控制在了2层之内。
Platform/Business/Customer三方的职责也立刻明确了：
Customer：我不需要知道Customer撤销子任务的原因，我可以容忍Customer一天撤销3次子任务，超过3次，那么，就一定是Customer本人的问题。
Business：如果他的子任务一直处于“被接/撤销”状态下，那么Business自然会开始怀疑自己所放的任务是否有问题，从而重新设计任务。
Platform：无需再维护任务的“冻结”状态，节省了开发维护成本，提高了服务器性能。也不需要客服不断地去重复审核任务，也节省了客服维护的成本。
至此，这个进入复杂陷阱之中的功能得到了拯救。
避免陷入这样的复杂陷阱，是身为产品经理的职责，我们必须在每一个新增需求、新增功能点上保持谨慎。而我给自己的目标是：不能让任何业务的逻辑超过2层。说白了，就是做减法。给技术提需求时，也必须明确这点。
把整个平台从复杂陷阱中拯救出来，也成为我和我的团队接下来的主要工作。
