软件中的八二原则（二）

 

软件中的八二原则（二）

1. 八二原则（80/20）本身

    1.1. 八二原则错吗？ 没错。

    1.2. 八二原则在软件领域不适用了吗？适用。很多理论，比如八二原则、长尾理论、摩尔定律等，它们是大道，而非仅适狭窄局部的小规律。（当然，它们也有其范围和范畴，没有老子的“道可道”的道那么大。老子到底有多大，我也不知道。）

    1.3. 那么，为什么那些八二的公司会被fucked？ 因为他们一刀切的，武断的在运用这个规律。没用对地方。

2. 支持Joel的个案

    Joel简单的说到了他的观点，很多话我想他没有讲。（多半并非他不知，而是没说到那里去，省略了很多。）

    如果简单的枚举几个例子，试图通过此来证明Joel是错的话，那么我也能举出一些反面的例子，是否能证明Joel是对的呢？其实都不能，因为都是“以偏概全”。但提到这些例子还是有必要，比如其中两个：

    2.1. 我的经历——在LIMS、LIS、ERP等领域的情况

     我在LIMS（实验室）和HIS（医疗）领域有很多实践，有大量这样的案例。当一个具有20%功能（它能满足80%需求）的软件卖到客户手中，客户会提出一些“个性化的需求”，绝对在20%非常规需求之列，那些往往是很个性的，有时甚至很无厘头。你能够拿着仅有20%的东西向客户收钱吗？你也可以很个性，坚持自己的原则。但是结果是剩余的尾款20万你就甭要了。你是要保持个性还是那10万、20万？事情还不仅如此，当这样的客户出现几个，你就会出现一些“烂尾楼工程”，接下来你的口碑就坏了，那么在这个市场上你就甭做了。那么，为何不与客户讲道理呢？也许客户无知？他们不知道八二原则？你去给那些高学历并老江湖的所长院长们讲讲看，教教他们什么是八二原则，然后争取让他们在某些功能得不到满足的情况下付出那20万的尾款。如果你能做到，那么恭喜你，你可以比肩乔布斯，他能创造需求进而获取财富，你能在不满足需求的情况创造财富。

     结论是：那是不现实的。我碰到过很多很多次，憋着开发商为了某个个性化需求做定制开发。（虽然通过一些工作，比如客户洗脑（ERP的惯例），勾兑（返点、波推打炮之类的手段，中国商业的惯例）可以在局部的点上好办些，但那不是道。）在LIMS、ERP、OA、HIS、LIS等领域，指望“我只提供20%，然后卖拷贝争取占有80%的市场”是真的在做梦。

    2.2. 小众软件和仇富型愤青

          “善用佳软”和“小众软件”两个网站都不错，我常看。其中很多“小众产品”精致小巧，介绍的文章都会说这儿不错那儿不错。但有个问题，既然都不错，那为什么它们没有获得市场的成功？为什么没有把这种不错变成纳斯达克坚挺的股票指数？因为还不够。要么只是在某些局部的点上不错，要么本身客户对象就是小众的，要么就是只20%了。

        相反，国内和国际有个反微软阵营，包括我所在的公司也有个这方面的积极分子。典型特征是凡微软必骂，只要微软的产品能不用尽量不用。但微软是最赚钱的公司之一，产品是他赚钱的来源。那么，为何不借鉴一下微软的思路呢？我称那些反对者为“仇富型愤青”，情绪让他们偏执了。举个例子：wps和office。很多人在替wps唱赞歌，如何如何好之类的。抛开爱国情结不说，wps真的比office好？ 对只需要一个办公软件的个体来说可以选择wps，但对于开发商就不能这么想了。这是角度的不同。wps可能只是20%，其实也不止20%了，而office则是典型的超20%。（除了wps，国内还有永中office，以及国际上还有很多类似的，包括sun公司有款不错的，我一时忘记名字了）。他们为什么失败？在对office一片骂声中，为什么它鹤立鸡群？我们看到的office和常用的office功能一般就够了，但那只是冰山一角。我们曾在1999年时试图解决客户千变万化的报告问题，怎么处理那些报告呢？最终采用了集成office的方式。我们可以对office再编程，并使之与我们的程序无缝集成，进而满足客户该需求。如果没有用它会怎样呢？会导致开发量、开发难度、开发周期大为增加。wps能做到吗？做不到。其实那个时候，wps还是完全有机会的。一个开发商集成了office，卖出几百上千套产品，那么无形中office就被部署到了客户中，每个客户再有几十个终端，那么几千上万套office就被实际用户在用。逐渐它成势了。 我知道office的成功，当然不只是这么简单。但这里想强调的是，面对同样的客户群体和80%的共性需求以及20%千奇百怪的个性需求，office的做法是值得借鉴的。office也不能满足100%，但它的20%比wps等的20%大的多，并且它的20%是随着时间和版本的升级在不断的放大。

 

3. 20%和80%指的是什么？

     就像经纬度一样，我认为80/20应该从两个方面来看: 经度的功能（为了满足某项需求），维度的功能（满足该项需求的程度）。 对于此，有个不错的诠释是正航ERP中的T357系列。在ERP领域，客户的共性是有的，但个性化更多，怎么应对这么局面呢？ 有个原型版本做定制开发是可以，但那样的结果是当你的客户多了时，产品（版本）管理以及部署实施会有一连串的麻烦。对此，SAP有其办法，但SAP的高度不是随便哪个公司都能效仿的到的。简单点，正航T357系列的做法值得借鉴。

     简单的说明：订单、客户、库存、财务、计划，这算几个功能，那么还有其它的吗？当然有，比如某客户需要其ERP系统与设备进行数据采集，或需要与另外的系统进行数据交互（比如lims）。后两者可以被看做个性化的需求，一般的ERP标配中未必含有这功能。这只是一个层面，功能的经度。再来看常规的“功能”中，订单、客户、库存等功能，，它们有什么不同吗？当然有，而且区别很大。同样是实现“客户管理”的功能，可以简单到只有一个客户列表，能支撑系统其它模块跑起来就行，也可以复杂到时一个价值几百万的全面的CRM系统。这像是从一个极端走向另外一个极端，在这两头就会有很多“点”，，这些“点”决定了你这个部分实现的怎么样。我把这叫做“维度的功能”。再进一步，在同样的维度上，还涉及UCD（客户体验如何）。这里把安全性等性能问题先放到一边。 当这种“经度+维度+UCD”的功能综合起来，决定了一个产品的品质，它是参与市场竞争的手中的牌。

      这就是经纬度的问题。很多时候，把某项“维度的功能”往前提升一步，会比多增加两个“经度的功能”要难很多。

       Joel在他的帖子中，主要指的是经度方面的功能，，但这里其实也会包括维度方面的功能问题。

 

（未完，待继，敬请关注下一节）