Ｂ端产品如何做好从1到10的架构搭建？
上一篇文章，我写了《Saas产品如何做好从0到1的架构搭建？》。
今天这篇文章，不聊从0到1。
我想拓宽思路聊一聊Ｂ端产品如何做好从1到10的架构搭建。
一款从1—10的Ｂ端产品，产品经理在推进需求落地的过程中，会遇到各种大大小小的需求，围绕需求，如何做好架构搭建？
是我们这篇文章要聊的重点。
我把平时遇到的各种需求分为3大类，一个又一个的小需求；一个又一个模块性的中等需求；想解决一个新业务问题的大需求。
不同类别的需求，对应着不同的架构思考，分别为：
1.小需求，用产品模块内可配置思考方法；
2.中等需求，用高内聚、低耦合思考方法；
3.大需求，重启产品线思考方法；
4.平衡的艺术（这是个补充）。
接下来，
我一个一个的讲。
01
小需求
用可配置思考法
作为一个Ｂ端产品经理，我们经常或主动或被动的接收到一个又一个的小需求。
如果是一个Ｂ端小白产品经理，
第一反应就是，那就把需求落地成功能，画出需求相关的原型图，交给技术开发。
结果就是产品里不断的堆砌功能，以至于产品越来越复杂，越来越难用。
但如果是一个Ｂ端资深产品经理，
面对一个又一个的需求时，会先站在整个系统架构来看这一个又一个的小需求，把需求归类到属于它的模块，然后尽量的用一个功能模块来满足多个类似的需求。
也就是，一个Ｂ端资深的产品经理，在面对一个一个小需求时，懂的在整体中来理解部分。
在整体中理解部分有多么重要，这里讲一个经典的小故事：
有一天有三个石匠在打石头。有个路人经过，问他们在做什么。第一个石匠说：“我在打石头，养家糊口。”第二个石匠说：“我在做全国最好的石匠活。”第三个石匠抬起头说：“我在建造一座大教堂。”
现在，假设你是这三个石匠的领导，那么请问，哪一个石匠最让你放心？
正确的答案是：第三个石匠最让人放心，因为他知道整体系统的目标是什么，是建造一座大教堂，尽管他只是整体系统中的一部分，但是他把整体的目标放在心中。
他从整体系统中来更高、更深的理解自己局部工作。
作为产品经理也一样，不从产品整体架构中来理解，永远不会成为领导放心的好帮手，领导会担心，因为产品经理整体性思考的不够，在解决一个一个的小需求过程中，功能模块越堆越多，最终会导致产品越来越不好用。
这里我还是以上一篇文章聊到的景区智慧营销Saas系统为例，讲一讲面对一个又一个的小需求时如何思考并落地。
首先，先介绍一下智慧景区Saas系统目前的现状，目前模块现状是：一级模块“商品管理”里包含了“门票（此时的门票是指付费门票）、特产”两个二级模块。
还有其它如，订单管理、店铺管理、数据管理等一级模块。
大概的架构如下面这样：
然后现在遇到了以下3个最终确定有价值的需求：
1.景区想提供给游客免费门票，但需游客提前预约；
2.某景区入园时需要出示身份证；
3.某景区每日游客入园数有限制。
这时需要把产品落地成功能，开发出来，然后提供给景区使用。
如果是一个小白产品经理，那么可能的思路是：
1.景区想要上传免费门票，那就在商品管理模块里增加一个免费门票上传管理的二级模块；
2.游客入园时要出示身份证，那就找一个在店铺管理里面或者是什么位置，加一个提示游客需要出示身份证的功能按钮。
如上面这样，Ｂ端小白产品经理基本上就是属于遇到问题解决问题，尽量把问题解决好，但基本上没有从整体架构、未来产品的可拓展性角度上来思考。
而如果是一个资深的Ｂ端产品经理，那么可能的思路是：
1.景区想提供给游客免费门票，但需游客提前预约。
首先这业务需求肯定要归类到商品管理里面的门票管理模块里面去，通过梳理发现，免费门票和付费门票的业务逻辑，在整个后台景区工作人员的工作流里，基本上是一致的，不同点就是有的景区门票收费，有的免费。
这时只需要在门票管理模块里配置一个是否要收费的功能，就能把这这个问题解决了。
如果不需要收费的门票，工作人员选择了不需要按钮，图片中的市场价和销售价框就会被置灰，不能操作。
2.某景区入园时需要出示身份证。进入场景思考，景区在软件的什么地方放这句话，游客会百分百的看到这句话，买票的时候，对，就是买票的时候，因此景区可以在上传门票的时候添加这样的字段。
但这里又引来了一个新问题，入园时不需要门票的景区此时怎么办？
这时也简单，在门票管理模块里配置一个“景区可选择取票时是否需要出示身份证按钮可供选择”就能解决问题了。
以上就是遇到一个又一个小需求时，产品经理可以用可配置思考法来解决问题。
02
中等需求
用高内聚，低耦合思考法
在工作过程中，我们除了会遇到一个又一个的小需求，我们也会遇到一些比较大的模块性的需求需要落地。
比如：
现在你接手到了要增加一个“大转盘抽奖”功能，这个功能要解决的问题是，景区想用大转盘抽奖功能来和游客现场互动，游客通过抽奖可以抽到优惠券奖品。
接下来需要把这个需求落地，设计出来。
像面对这样的中等需求，如何落地推进，这个时候就要用到高内聚，低耦合思考法了。
高内聚的意思是指，产品结构中单个模块内各个元素联系紧密，也就是一个模块内的代码只完成一个任务。
低耦合的意思是指，产品结构内不同模块间的联系弱，关系简单，修改一个模块则不会影响另一个模块。
产品通过低耦合、高内聚的思想来设计，会给产品未来带来更好的可扩展性和灵活性，避免了后期产品的难以迭代，需要重构。
回到大转盘抽奖活动功能模块，我们看看整个活动落地的一个思考过程。
这里我简单做了一个大转盘抽奖活动的业务流程图（流程图做的不详细，仅供参考，不具有实用价值）。
这张流程图里有3个关键点，创建大转盘活动时，需要添加优惠券，而添加优惠券的时候要添加商品。
资深的Ｂ端产品经理这时会知道，产品设计要低耦合，让功能模块更聚焦。
不能把大转盘、优惠券聚集在一起。大转盘模块解决大转盘的问题，优惠券模块解决优惠券问题，优惠券属于和大转盘同一层级的另一个模块，商品则又属于另一个模块，大转盘和优惠券之间的关系则是调用关系。
大转盘功能带着这样的思想去设计，就做到了低耦合，会大大降低未来产品的迭代成本。
如果是一个Ｂ端小白产品经理，在设计大转盘活动时，就可能会把大转盘和优惠券给聚合在一起，这会导致，任何一个模块要做修改和迭代时，都会最大程度的影响另一个模块，导致后期的迭代成本非常高，甚至会导致产品需要重构。
以上就是遇到一个又一个中等需求时，产品经理可以用高内聚，低耦合思考法来解决问题。
03
大需求
重启产品线思考方法
一家公司，或者一家公司的某条产品线。
在往前发展的过程中，可能会遇到以下这么几种情况：
1.产品本身没有突破从0到1的破局点，无边界的在找各种需求（或者说有一定的边界，但边界已远远超出产品从0到1架构的边界），一直在做各种尝试；
2.本来公司业务是解决营销问题的，因为客户的需要，或者是老板发现了新机会，想在目前的产品基础上增加人力资源管理的功能模块；
3.原本是一款Saas产品，在发展的过程中，有了一定的客户量，公司领导想在Saas产品的基础上增加行业信息化解决方案；
4.等等。
反正，用一句话来总结就是：
公司有了新需求，且这个需求已经远远超过了产品从0到1的架构边界。
甚至这个需求是不是真需求？这个需求有没有价值？能不能规模化发展？等等都是一个未知。
这时最好的解决方案就是重新启动一个独立的新产品来解决这个问题，千万不要把新需求聚合在老产品里。
不然会让产品越来越不好用，影响了老业务的发展，得不偿失。
04
平衡的艺术
当然我上面讲的也没那么绝对，它只是一种思考方法。
比如，我文章中提到的：要把需求对应的功能设计在符合业务属性的模块内？
实际工作中，也不一定非要这样做。
实际情况还是要根据产品经理对业务的理解，客户的理解，公司现状、目标的理解综合考虑之后，才能给出一个更优的解决方案。
这里举个例子，
现在有一个需求：文章提到的景区智慧营销Saas要给不等等级的会员设置权益，权益是不同等级的会员买商品时可以有不同的折扣价。
理论上来讲，这个需求搭架构时的业务思考逻辑是这样的：
不过由于景区业务低频，权益管理并不复杂，所以思考逻辑有所简化，如下：
从客户管理这个模块来讲，把“调用商品，添加折扣数”这个需求，放在权益管理这个二级模块里，可能是最优解，但它对整体来讲不是最优解。
对产品整体来讲，由于景区商品品类少，产品设计和开发成本、对客户的影响范围等综合考虑之下，设计思路可以如下（这样会降低成本）：
这里把不同等级会员设置不同的商品折扣这个需求，放在客户模块里。
调用商品，添加折扣数这个需求，直接在添加商品的业务流程里配置了一个“可以启用会员价”功能的这么一个小按钮。
而不需要在客户模块里面“调用商品，添加折扣数”，就把问题解决了，同时也不影响未来产品的可拓展性。
所以，
产品架构设计没有什么非黑即白的准则，它是一个平衡的艺术。
需要你在各种要素之间进行判断、取舍和平衡。