原则系列：怎样保证B端产品的简洁.docxVIP

原则系列：怎样保证B端产品的简洁 笔者曾经将做C端产品比喻过建大平房，B端管理软件产品类似于建小高楼，占地面积是用户的量，楼的高度是业务的复杂度；C端产品重定位以及交互能力，B端产品重架构以及抽象能力。 实际上将产品比喻为建筑物也是有不合适的地方，建筑物在建造之前一般都有了很精确的设计图纸；但是作为软件产品来说，很多时候是没有精确的图纸的，除非已经很成熟的赛道，很多场景下面它更像一个相对未知的生物体、生命体；它是不断在生长的，在产品生长的过程中，产品很容易变得臃肿不堪，最后很难维护以及扩展，用户也很难使用。 即使SAP、Workday、Salesforce这样优秀的软件也难逃其命运；不过这些软件都是21世纪初或者20世纪的产物，随着移动互联网的发展，B端软件产品设计的理念正在发生很大的变化。 那么怎样保证产品在长期错综复杂的发展过程中，保持其简洁性；笔者提供一些小的原则建议： 一、确定产品形态 努力想清楚产品最终的大致形态，以及用户在哪些场景，用什么样的方式来使用我们的产品，做好取舍。 产品的发展是基于公司的战略以及愿景，在想清楚产品的最终形态之前，需要想清楚公司的战略以及愿景；基于公司服务的人群，以及提供的服务，确定产品的最终形态。 基于战略对于哪些功能需要做，哪些不要做有一定的准则，否则陷入撒都要做的境地。 另外，笔者经常看到一种境况，创业公司有时候产品定位不准确，切入的是用户痒点的需求，很多时候产品供应商没有察觉到；反而觉得是功能不够多，不断的去迭代更多的痒点功能，实际上痒点＋痒点不等于痛点，再多的痒点功能的叠加也是不可能形成客户对产品的依赖的。 二、产品线定位 做好每条产品线的定位，避免定位的混乱后，产品走向不明，不同产品线之间重复交叉在一起。 产品的使用一般有多个角色，使用的场景也不尽相同，很多时候我们都会有面向客户的移动端、web端，也会有公司内部的运营端，每条产品线的定位需要想的非常清楚，避免交叉。 这里我们经常看到的误区有如下几个： 不同的角色用不同的产品线来支持。 笔者经常看到一些公司，不同角色因为功能有所区分，就用不同的产品线、不同的APP来支持；实际上一般来说随着产品的发展，不同角色重叠的功能会越来越多；实际上只需要统一成一条产品线，通过权限来区分不同角色的使用功能就足够了。 滥用移动端，什么功能都往移动端来走。 作为移动端，一些经常需要在移动端使用的功能，协同功能以及高频需要查看的数据可以放在移动端；但是移动端不适合做一些输入工作太重的功能，也不适合做的很重，太重了就不适合“移动”了。 三、主线功能 优先做好主线功能，也要保证极端低频事件有路可走。 对产品发展的过程当中，需求优先级的控制极其重要；低频事件，特别是一些逆主流程的功能实际上的工作量是极大的；比如说流程走的好好的，用户需要支持逆向的操作，如果这种业务流程中有大量的逻辑——这种逆向操作的代价是巨大的。 这里的一个原则就是对于低频极端事件，不一定要完全线上支持，很多时候可以采用线上＋线下的支持方式，保证客户在低端情况发生的时候，系统不至于无路可走就行。 打一个比方，在ERP的上下游结算，或者薪酬的薪资计算的时候，总是会有一些费用是很难标准化的，或者计算方式是很难抽象的；这种时候可以考虑开一个口子支持这种费用项目，但是这种费用项目的完整管理不要线上化，让客户通过线下的计算，然后有入口进行输入或者调整就好了。 四、每个迭代把握做小、做少、做精的原则 每个迭代把握做小、做少、做精的原则；做加法很容易，做减法很难。 将一个产品做复杂很容易，但是复杂之后，要变简单非常难，无论是前端，还是后端的数据库以及逻辑层；做加法都是容易的，但是做减法都是极难的。 所以在产品的把控上面，采用线做小、做少、做精的克制原则是非常重要；否则，产品发展2，3年之后，就复杂到客户很难使用，维护成本很高，扩展难度很大的积重难返的地步。 五、合并同类项，减少复杂度 前面说过笔者有一个看法是产品是不断在生长的，无论是大的功能，还是小的逻辑分支；这些分支随着产品的发展会不断生长出新的分支，这样不断的裂变，会导致产品复杂度不断上升；所以需求控制、产品设计、逻辑实现上面，需要尽量抽象、合并同类项，尽量减少分支是在产品落地层面的最重要的技巧。 所以在设计以及研发这个层面，核心工程师的抽象能力也是非常重要的，需要找一些逻辑思维能力强，追求最佳实现路径的工程师来承担一些核心的功能。 六、基于场景来进行设计，避免过度设计 过度设计是经常发生的现象，简单如一般的搜索，笔者看到大量客户不会用到的检索条件罗列放在上面；客户在用这个功能的时候希望看到哪些信息，可能会怎样进行检索，一定要了解客户使用的场景之后再去做设计。 当然一些通用软件，因为使用场景很难预测，将场景进行放大也是可以理解的；只是无论通用场景还