一 引子
永远忘不昨晚那一幕：一向不苟言笑的老总居然一边和助理开着玩笑，一边吹着口哨巡视一圈开发大厅，然后哼着小曲蹩进了洗手间——千年难遇啊！
我知道，这一切都是因为一个项目的缘故……
二 外包
我是一家软件公司的项目经理，我们企业管理系统开发为主要业务。在许多项目中，我们自己开发基础数据库和应用平台，具体的业务系统则外包出去以节约成本。
随着公司业务的发展，分包这种开发形式也逐渐暴露出许多问题来：
一方面，接包的开发者素质参差不齐，一些小型软件公司还有一些流程上的管理，而那些带着研究生开发的大学导师、社会上的小型SOHO开发团队，则很难有良好的项目管理。于是项目质量、成本和交付都难以控制，造成许多项目难以达成验收，少数项目甚至被迫宣布核销——谁都知道核销两个字背后的意义。
另一方面，由于我们是业务系统外包，外包方可以直接和客户沟通需求，也顺带做一些客户关系。长期下来，一些做得好的外包商在把握好了客户关系和业务需求后，居然对我们进行信息屏蔽，客户认他们反而不认我们了，例如江西有一个项目我们升级平台，客户居然要外包商签字批准了才允许升级，搞得公司极其尴尬。
为了进一步拓展业务，公司在通过ISO9001质量体系认证后，又在着手策划进行CMMI3级的推进，在此之前，公司领导决定先要对外包型项目进行整顿。
“如果说每一个分包项目，是一块积木的话，我们就是那个用积木搭建埃菲尔的人，我们既要保证每一块积木的质量，还要保证整个工程的质量。分包项目，既要做到质量进度可控，更要做到对业务的控制！”
公司总经理在经营业务会议上的一席话，把沉甸甸的压力加到了我们项目管理者的肩上。
是啊，既要QCD可控，又要把握好业务，还要配合CMMI的推进，怎么做呢……
三 SPP
我是去年知道M项目的，那个时候，项目还在售前阶段。随着项目一步步走向确定，公司在积极策划投标的同时，也赋予了这个项目另一个意义：外包整顿的试点项目。
在投标前一个月，我被任命为这个项目的预备项目经理，并着手进行项目策划。
一个合理的方法论和一个合适的项目管理工具是很重要的，我希望的是一个简明的开发流程和相应的工具，而这个工具能够很好的支持对虚拟团队，也就是外包开发团队的管理。
在工具的选择上我最早考虑的是Rational的套件，但一方面由于太贵，另一方面Rational过程过于重型，90万的项目有些大材小用了；后来有人推荐SourceForge.net，感觉功能比较完善，但是因为是英文版的东西，用起来总感觉比较生涩，毕竟我们总是偏向母语的，用英文写Bug报告，也太……麻烦了。
SPP方法论就是在这个时候让我有了眼睛一亮的感觉：把项目过程简化为“启动”、“执行”和“收尾”，去除了大型方法论的项目策划和项目监控过程；采用迭代的开发模型，能够灵活的进行版本控制；对团队成员的职责进行明确定义，这样可以比较好的管理外包团队……
后来发现SPP方法论是上海贝尔的林锐博士提出的，相应的管理软件是上海漫索的RDMS平台。我是看着林锐博士的《高质量程序设计指南—C++/C语言》做第一个项目的，出于对林锐的信任，我和几位SPEG的兄弟试用了一下RDMS平台。
这个平台虽然在功能上不如SourceForge完善，但是能看出平台在配置管理上下了功夫，把DocCenter文档管理系统、Future 4.1项目管理系统结合起来，能够比较好的管理外包团队，控制产品的质量、成本和进度。这正是我们想要的。
四 RDMS
SPP支持对过程的灵活裁减，让我们能够对分包商管理提出比较可行的方案，结合RDMS平台，我们提出了具体的项目管理方案：
1 RDMS平台采用B/S架构，我们在公司总部服务器上部署了一个RDMS平台，分包商可以远程登陆这个系统来进行相关的操作。
2 使用Future 4.1研发项目管理系统，我们把本公司项目组和每一个分包商都作为一个部门来对待，相应的分包项目就建立在这个部门下，并赋予外包商负责人项目经理的权限。
3 总体项目的项目经理，赋予的是所项目相关部门的领导权限，这样，我可以通过系统，协调跨分包商任务的执行。
随着项目的进行，RDMS平台的优势也逐渐发挥出来。
SPP的理念是简化项目策划和监控的过程，体现在RDMS平台上，就是对这两个过程的高度自动化。在需求分析阶段，我们能够很好的对需求进行审批和跟踪，并清楚地掌握每一个分包系统的业务逻辑；而作为分包商，不需要再撰写冗长的需求分析报告，也让他们不大不小的松了口气。
SPP强调进行迭代开发，体现在RDMS平台上，就是完善的版本控制和缺陷跟踪功能，由于系统能够清晰的显示各个版本的需求规格，节约了测试人员了解系统的时间，这也使得我们的测试人员能够在关键阶段参与分包系统的测试，这样，分包项目的质量控制成为了现实。
DocCenter文档管理系统在项目进行过程中派上了用场，许多会议纪要、沟通记录和邮件记录在项目过程中产生，我们为每个分包商的每一个项目，都建立了相应的文件夹，并要求他们及时把文档上传到系统中，DocCenter自身具备良好的版本管理功能，所以文档名后面不需要添加日期编号，这也给我们带来了小小的方便。
不得不提的是，系统之外我们也采取了许多辅助措施。比如，我们和商务部门确定了一个流程，就是分包商提交的付款通知单上，必须有我方项目经理的签字，财务才能通过审批，走付款流程。换句话说，只要我们的项目经理不批，那么分包商就拿不到钱。
与此类似的，我们还定期到分包商的开发现场去进行巡检，了解实际的开发状态；不定期和各个的业务系统的客户进行沟通，了解他们对系统的看法……
事实证明，这类“盘外招”能很有效的控制分包商，让他们切实在内部推进RDMS平台，提升自身的管理能力。
五 尾声
持续上升的客户满意度让销售的工作越来越好做，迭代开发让客户对我们解决问题的能力越来越有信心，由于紧密的管理模式，公司与分包的合作过程越来越可控……所有一切，都预示着一个好结局的到来：
昨天，M项目的甲方负责人，爽快的在终验证书上签了字——此时距离我们最后一个版本的完成还有3周——提前验收！这是公司前所未有的事情！与此同时，二期项目的合同也已经开始起草，客户希望在M项目最后一个版本Release的同时，M项目二期也开始实施。
双喜临门，于是就有了文章开头的一幕。
如果说，M项目是我们用积木成功搭出的一座埃菲尔铁塔，那么这座塔绝不代表着公司拥有了比原来更强的整体能力，我们还要搭出更多的埃菲尔铁塔，甚至金字塔，用这一切来证明M项目的成功绝不是偶然！
目前，公司已开始在多个项目中推广SPP方法论和RDMS项目管理平台，由于这套方法是基于CMMI3级的，因此我们把两个重点项目列为了CMMI3级的建设项目。
一切都在往好的方向发展，这给了我们信心，让我们看到了一条通往成熟的道路。在我们心中，还有一个愿望，那就是能够亲自拜访林锐博士，感谢他提出的SPP方法论，我们要用经验与他交流，进一步完善SPP方法论，让更多人从RDMS项目管理平台中受益。
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1233412
