最近因为接近年关，为了能够提(达)升(成)活(K)跃(P)度(I)，公司打算搞一个抽奖活动。当然，活动年年搞，但作为有追求的公司，我们还是希望每一次的活动都能做出新意，而不仅仅只是达成这项任务。
为此，我们产品人员也是绞尽脑汁地去思考这个抽奖活动，如何将其与自家产品结合起来，又不至于显得那么俗套，如何防止恶意刷奖的行为，又不至于将活动门槛拉得太高。当将这些东西都考虑到之后，产品的逻辑就会显得非常复杂，这个时候，如何沟通与传达这个逻辑，就会显得非常重要。产品、开发、测试，任何一方对逻辑的理解出了偏差，就会导致最终的产品和大家的预期不一致。
那么我们应该如何来保证各方对产品逻辑的理解尽可能保持一致呢？
首先，产品的逻辑应该是多方讨论之后产出的，如果只是产品人员闭门造车，最终难免错漏百出。
多方坐在一起，讨论了许久之后，活动方案逐渐清晰了，各种问题也逐渐明晰了，这个时候，产品经理再梳理一下逻辑，发出来，开始设计、开发、测试，然后产品上线，多么美好的一件事情！
然而真正在推进项目的过程中，你发现根本就不是这么一回事，虽然大家讨论得都很清楚了，但会议一过，大家对于讨论的细节就忘得差不多了。这个时候，再看着产品经理梳理出来的文档，每个人又开始有了自己不同的理解，整个项目过程根本不是那么美好。
在我看来，逻辑是抽象的，每个人的理解不可能完全一致，尤其是在涉及到一些边界情况的时候，所以除了抽象的逻辑之外，还得有针对不同case的解释。
在之前的项目中，为了说清楚分页的逻辑，我除了将逻辑写出来，还将不同case下的不同示例给列了出来，以为将这些工作大包大揽之后，就万事大吉了。但实际上，真的这么写出来之后，文档非常的冗长，给开发人员的阅读和理解带来了很大的困难。如果开发人员没能完全理解产品所要的逻辑，然后按照文档中对不同case的解释来做了，那么会造成其代码的逻辑却非常繁琐，非常不利于维护。此外，如果产品未将全部的边界情况考虑进去，那么最终在这些边界情况下，就会出现各种诡异的Bug。
事实证明，详尽的文档不一定能够将问题表述清楚，因为阅读和理解成本太高了。
有了这次经验教训之后，我觉得工作中沟通的方法需要进行优化。
就逻辑和case来说，开发和测试两方都需要了解，但开发侧重于逻辑，而测试更加侧重于case。至于逻辑本身，应该在全面的同时，尽可能地做到简单。
- 产品需要梳理出简单可理解的逻辑，并和开发测试两方进行沟通，确保双方能够理解这个逻辑。在沟通的过程中，可以根据各种情况进行拓展，但这种拓展是为了帮助各方理解逻辑，而并不是需求本身。
如果有某些场景未能被现有规则逻辑覆盖到，那么就需要再新增其他逻辑规则，直至逻辑本身能解释各种可能出现的场景。 - 逻辑确定之后，由测试人员负责去罗列所有可能出现的case（测试用例），然后由开发人员去去完善这些测试用例——在各种case中，产品应该是什么样子的。
- 最终，再由产品和开发一并沟通这份完善过的测试用例，如果没问题，则说明开发已经理解了产品的需求。
这种方式虽然冗长，但是能确保各方都能参与进来，而且能将一些结论落实到纸上，可以为后续的开发流程提供参考。
当然，这种方法仅适用于逻辑较复杂的情况，如果逻辑简单到几句话就能说明白，那么完全没必要去浪费这些时间。
唉，想想自己，也还真是挺累的！
