昨天中午,徐大师做了一场针对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接口很好用,并且提供了非常方便的调试、预览功能,一般一个人到一个公司两天时间,就能帮客户设计出一堆报表,效率非常高。教主曾经给我演示过,的确非常方便。我当时觉得教主太聪明了,居然能想出这么好的办法。
现在看来,教主的确很牛,一个人就在几年前做出了跟我们现在谈到的“产品化交付”一样的思路。
会后跟徐大师确认了一下,他说这种开发方式跟他讲的,是一样的。