昨天中午，徐大师做了一场针对BA（业务分析师）的关于p2p，产品化交付的session。由于徐大师讲的东西都很有营养，所以我得赶紧把听到的东西记下来，早晚能用上。
这几年P2P很火，我们公司也有很多新项目是关于P2P的。关于P2P的定义的漏听了，只记得大概，可能不对：大意是说，由于国家对于金融的管制，银行或者支付宝这样帐上有很多钱的公司，为了防止卷款跑路，或者自己用掉，必须要在国家的某个机构存放相应的保证金。在某些时候（好像是银根紧缩），银行的钱就不够放货款了，公司想借钱就非常难，利息也非常高。而民间有些人有钱，有些人缺钱，但他们之间却没法安全的互相借。于是几年前，平安银行就开通了一项服务（名字忘了），在互联网上搭了一个平台，帮助这样的人交易，同时收取一些手续费。这个平台后来被人们认为是国内第一个P2P服务。恰好这个平台是我们公司做的，所以后来我司因此获得了很多P2P的项目。
我们公司有一些团队正在做这样的项目，在开发过程中，发现了这种类型的项目与我们之前所做的企业定制的项目，有很大的不同。
对于企业定制，不同的企业拥有非常不同的业务，我们所做的每一个项目几乎都是非常特化的，所以基本上不考虑业务层面的重用性。一个需求来了，对于我们来说就是一张或者几张卡，做完了就算交付成功。我们做的都是“项目”，而不是“产品”。
但是对于P2P来说，我们是把它当作产品来做的。因为如果我们还是像企业定制那样，每次都新做，进度实在太慢。但如果能把它做成一个足够通用的产品，将会大大减轻后续开发的工作量。
这就意味着，对于任何一个新来的需求，都将不可避免地被拆分为两部分：“通用”与“特化”
“通用”的部分，就像一个框架，是对某个领域进行很抽象的建模，而不是针对某家或某几家公司。比如P2P，考虑的就是P2P这种业务，在比较高的层面是，是怎么样的。每一家做P2P的公司，在这方面都是相同或非常相似的。
而“特化”的部分，则是针对具体的公司。同样的业务在不同的公司里，在细节上都会有很大的不同，甚至是特有的。
“足够通用”是很难达到的，就算是同一个行业，就算各家公司提供给最终用户的服务看起来是差不多的（比如“存钱”，每家银行都有这样的服务），但是内部的流程就有可能有很大的不同。如果抽象层次不够高，则会发现为某几家公司设计的“通用”部分，完全无法适用于其它公司。
拿我们熟悉的技术类比，“通用”部分就像是SpringMVC/Rails这些Web框架。对于web开发来说，它们是非常通用的框架，我们却可以用它来开发各种各样不同的网站。
在“特化”的部分中，我们的原则是“代码改动越少越好”，所以依次是：
只有经过深思熟虑之后，才能把某些部分放入到“通用”部分。
（记得“通用”部分是用Core来表示，“特化”部分是Implementation, Configuration，另外两个忘了）
对于“特化”部分，实现的方式越简单，对于实施团队来说，也就越容易，越难出错。
从上面可以看出，这样的项目对于BA的要求更高了。当用户提出一个需求之后，需要在极短的时间（可能几秒钟），就能清楚地把它拆分并归类于不同的部分，然后才能平等地与客户进行后续的交流。
（如果判断出错，后期修改的成本会很高，特别是把一个特化的部分放到了通用中，以后又想把它移除）
所以BA要对业务、行业非常熟悉，拥有较高的业务抽象能力。
在听徐大师讲到产品化交付的方式时，我突然想起了教主，他的做法岂不正是这种“产品化交付”吗？教主开了一家专为中小企业提供OA服务的公司，其中有一个重点功能是报表。由于每家公司都会有各式各样不同的报表，很难做出一个通用的，所以他也是把功能分成了两种，“通用”和“特化”，并且提供了一堆Javascript接口，可以让实施人员去公司现场，当场用JavaScript实现出一个复杂的报表出来。
由于他设计出来的Js接口很好用，并且提供了非常方便的调试、预览功能，一般一个人到一个公司两天时间，就能帮客户设计出一堆报表，效率非常高。教主曾经给我演示过，的确非常方便。我当时觉得教主太聪明了，居然能想出这么好的办法。
现在看来，教主的确很牛，一个人就在几年前做出了跟我们现在谈到的“产品化交付”一样的思路。
会后跟徐大师确认了一下，他说这种开发方式跟他讲的，是一样的。