如何在研发项目中提高RDC的研发能力

如何在研发项目中提高RDC的研发能力

ISMP项目的感受

在谈这个话题的时候，我先需要说说对目前ISMP项目的感受。ISMP项目，是我所参加过最为“大型”的项目，整个项目组超过50人，这个在我以前是从来没有遇到过的。之所以加引号，是因为类似的项目，如果放在我原来的公司进行进行研发，我想项目组人员不会超过10个人（所以不是真正的大型项目），象 ISMAP Server，目前ISMP项目组有7、8个人，要做至少三个月，如果是以前我的公司，工作量也就是一个人做两个月。

为什么同一个项目，所需要开发资源有这么大的差异呢？并不是说我原来公司人员水平比现在的公司高，而是我们RDC没有任何积累，我们没有通信系统软件的编程框架、没有专门的计费系统、没有PORTAL框架、没有工作流，但所有这些，在我原来的公司，全部都具备，因此需要做的开发工作量少很多。没有积累，意味着需要耗费更多的资源，意味着时间和成本的提升。

以ISMP为例，如果公司要同时实施五个省的ISMP系统，意味着我们研发中心面临着五个省的项目和客户，尽管中国电信定义了许多标准和规范，但是落实到各个省的实际项目中，实际客户的需求都不尽相同，比如计费的需求，比如PORTAL，比如报表，诸如此类，再加上中国电信ISMAP规范的升级，同时项目实施的周期也很长，一般要持续0.5-2年才能完成从项目实施到终验，对人员资源占用很大。

因此，如果研发中心定位在一个Service Offered Center，那么如何提高研发的效率，降低研发成本，是一件非常重要的事情，因为研发中心面向的项目会非常多，来自客户需求会非常多，面向中国这样一个客户需要快速响应的市场，如果不能建立一套优良的软件程序框架，未来面向实际的商用项目，我们很难担负起更多重任。

软件的复用

在我原来的公司，有个笑话，说有N个开发人员，在开发过程中需要使用一个list类（那个时候没有STL），都觉得别人写的类不好，结果就是各自开发了N 个列表list类，结果十个都有BUG。其实每个开发人员都自己从头开始开发软件，效率和质量都是很低的，但是如果N个开发人员，都去使用并且共同完善这个list类，情况会如何呢？哪怕这个类一开始是很糟糕的，但是通过不断的应用，这个list类一定会得到完善和改进的。（这其实也类似现在Open Source的理念，用的人多了，不完善也会变得完善）

list类是公用代码的例子，再举个公用模块的例子，今后很多项目都会应用到短信发送和接收功能，因此我们需要实现各种短消息协议比如SMPP、 SMGP、CMPP等等，目前ISMP的项目开发出了SMPP Control和SMGP Control，但是在下一个其他项目，如果需要应用到这些SMS协议，目前的这些Control是否能够使用？还是需要重新开发？如果要重新开发，其实还是和前面举的的那个列表类一样，就是没有积累，未来开发人员就需要为不同的项目，维护N个不同的SMS Control类。

很多软件开发的书籍都强调代码复用，我认为，这个思想，不仅仅是对个人软件编程的要求，而且是对RDC的开发理念的要求。有公用的模块，才有积累，有积累，才有效率和质量，我认为这是一个Solution Development Center很重要的能力。

公用软件体系框架

RDC的研发能力，我个人认为包括两部分，一部分是人员的研发能力，另一部分是RDC的公用模块和公用软件体系框架。人员的研发能力是通过项目和培训不断提高的，和个人水平和进取心也有关系，这里不详谈。公用模块的好处上面我也谈过了，我主要谈谈公用软件体系框架。

以通信软件框架为例，目前我们应用ACE构建了ISMAP Server，这是一个好的开始，但是我们还需要做的更好，下次做SAG的时候，ISMAP Server是否留下了一个可复用的体系框架？我这里指复用，不是简单的COPY代码，而是要在ACE上通过不断实践，构建一个良好的通信软件框架（选择合适的Thread Mode，选择合适的TCP Server和TCP Client设计结构，实现高性能的分布式架构），这个框架是可以通过项目不断提升和完善，使得开发人员无需关心通信软件的通信控制部分，而更加专注于软件的业务逻辑处理。有了这样框架，在开发通信软件的时候，才能够更好的提升软件开发的效率和质量，做到事半功倍。

类似的软件体系框架还包括数据库统一接口（不需要每次都让开发人员去熟悉OCI的开发接口）、计费系统（如何应用EMM到中国市场？还是自己开发一个 ISMP计费系统？）、报表模块（运营商最关心的功能之一）、Workflow模块（我知道BEA的Portal很贵，实际项目是否采用BEA的产品，值得考虑）等等。

我举的例子，并不是说我们研发中心都要做，有些可以应用公司已有的产品，有些可以应用第三方的软件，但是我们需要深入考虑有那些软件框架是研发中心未来几年中要使用到的，并且是需要自己开发的软件框架。

行进中开火，过程中沉淀

我们研发中心成立的时间很短，面临的项目任务很多，实际上是没有任何时间来专门开发我上面所说的软件体系框架和公用模块的，但是，借助于项目过程来开发这些体系框架和公用模块，是完全有可能的，而一个体系框架，也不是凭空想象出来的，而是在项目的实际开发应用中产生和完善。

这里用一句话小结：

行进中开火，过程中沉淀。