了解产品的系统结构
下午,Peter特意给关毅安排了一次关于产品技术架构的讲座,主讲人是E公司加拿大电子商务通产品组的架构师John。John的技术等级相当于全球副总裁,总之,就是传说中“牛人中的牛人”。
在E公司,管理和技术两条职业发展道路都可以走得很远,而且做技术可以像做管理一样成功。北京的E公司研发中心还很年轻,随着它的不断成长,在未来10年,也将会涌现出一批技术大牛。
John开讲了。
首先,他在白板上迅速画出了电子商务通的系统结构图(如图3-8所示)。
图3-8 电子商务通系统结构图
系统的核心是工作流引擎,相当于电子商务通的心脏,它使电子商务通的业务流程是可定制的,这一点在市场上非常有竞争力。接下来,“心脏”连接着外围系统,如销售子系统、库存子系统、监控子系统、报表系统、电子表单系统等。
John谈到电子表单系统的时候更是激情四射:“我们的表单系统可以动态地生成,完全基于XML和XForms标准,支持网络安全协议。表单是电子商务信息的重要载体。E公司的系统可以帮助客户大大减少二次开发的成本,并整合已有的业务系统。”
John接下来谈了自己对电子商务通未来发展的想法。John对Web 2.0和SOA颇有研究,打算领导研发小组从3.0版本开始逐渐把电子商务通打造成一个基于Web 2.0和SOA的新型电子商务系统,给客户带来更好的体验和更大的价值。
John说:“我们必须迅速适应市场的变化,技术也需要不断创新,否则随时都有可能死掉。”
关毅看着John潇洒的演讲,不禁陷入了无限的崇拜之中。E公司是一个以创新为核心价值理念的公司,也是技术大牛们的天堂,他们在这里释放着巨大的能量,设计着一个个超酷的技术架构,指引研发团队一步步朝着目标迈进。对他们而言,支配各种系统和代码,并不亚于指挥千军万马。
不过关毅心里一直在想,敏捷开发和传统的瀑布开发的一个重要区别在于设计环节。瀑布开发强调先由技术大牛们详细设计出要开发的功能,再由初级程序员具体实现编码,至少关毅以前工作的X公司就是这样做的。在电子商务通3.0的开发里,北京团队会全体充当初级程序员的角色吗?于是关毅问Peter:“3.0具体的开发模式会是什么样的?北京团队也会参与设计吗?”
Peter没有说话,好像在考虑什么问题。
关毅接着对Peter说:“Peter,我知道你在担心我们的能力。没关系,我们不妨按照敏捷开发的精神,最好我们也能参与设计。第一个迭代我们可以试试看,如果不行,我们再想办法,你看可以吗?”
Peter很高兴,说道:“关毅,很高兴你有这样的想法和愿望,如果北京团队能够独当一面,这是我们最高兴的。但是你们毕竟对产品不熟悉,需要有一个熟悉的过程。这样,你在这边多留几天,我愿意把我知道的都告诉你,回去之后你的担子可不轻啊!我会向项目经理汇报一下你的这个想法,而且这可能会影响产品Backlog的选取。本来3.0我们是打算主要由我们来设计,你们主要来编码的。”
听了Peter的话,关毅很高兴自己能为团队争取到一些机会。当然,这也要感谢敏捷开发的推行。
很快,项目经理同意了关毅的请求。敏捷开发强调自我管理的团队,就必须充分信任开发团队能漂亮地完成任务。