为啥程序人员总和产品人员吵架，或许是天生的吧。
或许程序人员是理性的，产品人员是感性的。
但是作为把生活提取出来成为产品的第一步，产品人员也应该具有理性思维。
此文我主要想说离散数学在整个产品开发中的重要性，主要是离散数学的归纳和总结。
离散数学是什么，我们先举些例子吧。
场景.
要做一个聊天室，聊天室主要内容有，谁说话，谁送礼，谁对谁说话送礼，某人进来了、出去了，发送了一个超大叫喊（就是展示的很大的字）；权限，谁把谁禁言了，踢出去了，还有等级，谁说话多了，等级会提升，什么开玩笑等级，魅力等级等。
最后可能获取到的最简单的原子操作是这样的（用最小的表示方法代表所有内容）：
A 说话：blabla
A对B说话：blabla
A 对B 超大叫喊：blabla
A大声叫喊：blabla
A送B礼物：X
A把B 禁言了
A把B 踢出去了
A的玩笑等级提升到 ：4
A的魅力等级提升到 ： 4
看到这里大家觉得怎么样，如果在添加新的功能，比如A对B 换个动作（啥都可以），又得出来一大堆不同的，而且整个看起来很乱，包括添加新协议的时候扫描（bianli）以前有没有都很复杂，可能1-9的数字是打乱的，更复杂。这个对于开发、后期维护，包括测试进行测试都极其复杂。
总结以上的逻辑，其实完全可以把以上的逻辑进行划分，如 说话，送礼，权限操作，升级 4个点
于是就有了这样的表格：
| 干啥 | 类型 | 属性 |
|---|---|---|
| 1（说话） | 1说话 | 内容 |
| 2大声叫喊 | 内容 | |
| 2（送礼） | 1 送礼 | 礼物名 |
| 3（权限） | 1 禁言 | 操作还是反操作 |
| 2 踢出 | 操作还是反操作 | |
| 4（升级） | 1玩笑 | 等级 |
| 2 魅力 | 等级 |
所有协议里面包括操作和被操作者，如果被操作人没有，即空。
对产品来说：
比如要添加其他的等级升级，产品人员仅需要在4号里面查看喝添加就行，而且其他特性都保留，比人的各种属性，比如登记啊，穿的衣服啊。这方面一般不会动，而且产品也不用特意说这个任务要哪些属性。。。。。（何须一张张的美术UI画面，一个数字总结表即可）。
同时产品在项目数值上面也更加清晰内容，更易于别人接手。
对程序来说：
表整洁，一系列的switch case出来，代码清晰。修改说话公共 部分，全部都改了。bug避免非常多。就说这么多，开发猿自己体会。
对测试来说：
整体性测试和分类也做完了，相关测试要点在心里一目了然。
其他......
其实这个工作也不一定全由产品做，开发也可以做或fix，最后反馈给产品到整个项目。
总结：
这里其实就是用到了离散数学中的归纳的思维，将面或线性的生活数据，转换成点（软件可处理的数据）。这个过程其实越早做愈好。当然这个例子仅是展现的归纳的一部分（归纳的数据模型），其他还有逻辑范式，统计模型等等。
如果对此文有疑义，请直接在评论中留言和讨论。
