很早之前写过一个《B端如何做好一个产品功能》，现在看，感觉之前写的还是浅了一些，今天根据真实案例，举例说一下，产品想要做好一个功能，还需要思考什么？
现在还有多少的产品会自己画类图？会和技术谈论技术实现方案？会考虑产品功能的可扩展性？会思考功能实现的影响范围？
上面说的几个问题，有幸上周都遇到了。一个一个的给大家列出来。
1、那一刻，我意识到了类图的重要性
背景：在教育机构，存在学员、班级、老师角色，学员有正常学习和休学的状态，老师有绩效核算。一个业务前置条件，当一个学员休学后，所做的动作，还算到最近学员待过班级的绩效。
需求：学员休学后的处理。
争论点：学员休学后要不要离班？
思考：学员离班和不离班有什么区别？怎么才算离班？
学员离班和不离班的区别是什么？1、如果不离班，每次以班级维度做动作的时候，都需要把休学的学员特殊处理；2、如果离班老师如何更好的给学员提供服务？
怎么才算是离班？如果我们没有类图，没有技术思维，这个问题其实不好回答。但是如果你有类图，有技术思维。然后分析如果A休学，要把A从我的班级里面清理出去，如何才算清理出去？现在是A身上关联了班级id吗？是要把这个id去掉吗？如果去掉，那么没办法做绩效。如果不是，是有一个班级ID，然后班级ID里面关联着所有的学员，是通过班级ID找学员，那么如果我们去掉了这个关联，然后我们在做数据统计的时候，我们是拿班然后去找这个班级的同学，然后再去看同学的各种数据，然后有了一个数据结果。但是我们在做绩效的时候怎么办呢？绩效是以班级为单位的，我通过班级关联找用户找不到了，我只能再去所有用户筛选一遍，找到这个班级之前休学的同学，然后把这个同学加进来，然后在和班级里面能关联上的学员，一起计算。计算后的结果还和班级非绩效计算的结果不一致。
通过分析我们明白：这个不是一个离班不离班的问题，而是一个在老师的后台系统显不显示这个学员，在前端显不显示你归属的班级，至于休学需要谁服务，和离班不离班没关系，是你休学了谁服务你，不是你离班了谁服务你。
所以再以班级为单位的做动作的时候，系统自动把休学的学员处理掉就好，不需要老师特殊处理即可。至于谁服务用户，用户权益，是不是和状态挂钩，有几个用户状态确定用户有什么权益。订单正常，订单退费，服务正常，服务过期，正常学习，休学，重修，按照不同纬度的状态来区分权益
2、考虑技术的实现方案？
背景：直播中台之前的样式配置和鉴权是一个接口，现在随着样式越来越多，接口越来越大，撑不住了，所以需要把健全接口和样式接口分开，影响所有业务线。
为什么要考虑技术方案呢？因为很多时候，技术并不知道我们的长期规划，很多时候技术只是针对当前需求去设计技术实现方案，导致技术目前设计的技术方案并不能适配到我们长期的规划，在我们后期再做功能的时候，就需要重构之前的技术方案，如果没办法向下兼容，只能全部修改，则成本居高。
所以我们再给技术将需求的时候，如果我们对我们的功能未来有预期，则可以同步给技术，未来，我可能要做成什么什么样，让技术老师做技术方案的时候，考虑之后的版本。然后技术在做技术外审的时候，产品一定要参加，认真听，考虑其技术方案是否合理。
3、产品的可扩展性和未来规划
之前有一个模块化设计讲的很好的一个文章《模块化产品设计》。以电商商品举例。
以添加商品为例：要新建一个商品，必不可少的有商品基本信息、商品类目、商品属性信息等等。
如果想简单点设计：1、点击添加商品按钮，进入添加商品页面。2、在固定表单中，填写商品所有信息。3、点击保存按钮。
添加商品，本就不是很复杂的事，此简单的方案不是不可行。只是不利于系统的可扩展性和灵活性。
为什么？在固定的表单中填写商品所有信息，你就能保证所有的商品都是一样的业务逻辑，一样的商品信息吗？根本保证不了，那么一旦做成固定模板，系统后期就要不断的根据新的业务逻辑和商品去不断的改代码来实现业务方的需求。
那么，有没有更好的方案？模块化设计。
回到问题本质：想成功添加一个商品到商品库。
方案：将商品信息打散，将其拆分为三大类信息组合：商品共性信息（所有的商品都有的属性）、商品类目、动态属性（区分商品唯一性的属性）。
理清父子关联关系
既然要模块化，那么肯定就会出现一层又一层的父子关联关系。
说明：要想成功添加A商品，必须关联某个A商品类目。A商品类目必须关联某个A模板，A模板必须关联对应属性。
属性管理：管理了商品的所有类别的属性信息，一定要做好分类。比如：关键属性、规格属性、非关键属性等等。
模板管理：不同的商品，可能由不同的属性构成。那么我将属性形成一个又一个模板，就可以灵活的去满足各种类别的商品。
商品类目：商品的分类管理。所有的商品，肯定有自己的分类，也就是商品类目。同一类商品归为一类，便于商品的维护和管理。
商品管理：所有商品的管理。现在要添加一个商品，通过模板化设计，就变得非常灵活。要想添加商品：1、点击添加按钮。2、选择A商品类目。3、填写A类目关联的模板A中对应的属性信息。4、保存。
模板设计的好处就是，我可以随时更换关联关系，也可以随时在下一层关联关系中做任何CRUD操作却不影响当前层级新的数据。
模块化设计的底层思维，其实还有一个未来规划的影子，就是我们在做第一版本的功能时，就已经有了一个完整功能的大概样子，有了这个样子，指导我们设计第一版本，防止未来无法扩展，不能做到我们规划的理想中的样子。
举例：在给直播中台设计一个“引导用户关注公众号”的需求，我们采用的是，教师端发起二维码，则用户端中间弹出二维码，用户可以扫描二维码，也可以点击关闭按钮，收成1个ICON放在页面的右下角。做这个需求我们要思考？以后中间弹框弹出图片的还有其他场景吗？图片和ICON是不是可以随意配置。收起来的ICON会不会有多个同时展示的情况，这种时候ICON怎么展示，ICON一个个关闭/新增的时候如何交互。
4、会思考功能实现的影响范围？
技术在做功能的时候，因为没做过其他的功能模块或者其他的系统，并没有一个全局的视角，不知道做这个功能是否对其他的功能模块、甚至其他的系统产生影响，所以就只有产品设计的时候，写需求的时候，列出来所有的影响范围。
那我们应该如何思考，我们修改的功能的影响范围呢？看你设计的功能，新增了哪些实体类？关联了那些实体类？那些角色会用到新增的实体类和关联的实体类？关联的实体类和角色是否还会使用其他的系统。比如我们修改了课程退款的逻辑。没有新增实体类，但是关联了退款进度实体类，这个实体类客服、老师、财务、学员都在用，客服用在什么地方，老师用在什么地方、财务用在什么地方、学员用在什么地方。
总结：我们在做功能设计的时候，切记不要埋头就干，先思考，再动手，动手之后再思考。
