CPM (Channel Performance Management) 项目的经验总结：

1．  需求说明书的重要性：

a>     由进行系统开发的人员来进行需求调研并写出用户需求。让用户确认需求之前应该由团队的项目成员来集体审阅。最好开会逐句进行审核，要求成员真正用心地去读需求说明书。如果对一些需求描述有任何不清楚的地方，一定要马上指出。不能放过任何有疑问的地方。对于每次修改的部分必须特别提醒用户复审，以免跨部门用户没有跟进在同一层面

b>     写需求说明书通常需要经历几次反复的过程, 做到详细并可衡量化,减少歧义.

c>     用客户的语言进行书写，并保证说明书足够清晰，完整。以便日后加入到团队中的人也能够完全知道需要做什么

d>     特别要检查有无概念不清楚的地方，特别是像一些如：某些，大部分的字眼。一定要明确到底是什么数值或者是在某些数值范围变化之内。

e>     要明确哪些数值在未来可能发生变化。像CPM项目中每财年SBU的数值都会发生变化。这种变化的频率和变化的趋势也要记录下来。

f>      不能仓促完成计划书，也不能为了让说明书得到认可而言过其实。如果存在什么困难或者争论一定要公开出来并在项目正式开始之前积极地解决掉。

2．系统结构

a> 系统结构需要及早确立。使用什么样的操作系统，数据库，第三方软件等等。特别是要符合目前公司的标准。比如说一开始vendor提出要用.net开发，但是公司标准是Java.这种组织政策的制约对项目的开发构成了很大的影响；因为非常有可能公司规定的开发语言或者数据库的版本就不支持某些需求的开发。

b> 一旦确立下来系统架构，就要考虑目前公司里面是否已经有这些数据库或者应用软件，License问题，权限问题。列出问题的清单以及负责人。往往是越是公司内部涉及到什么采购等等的问题花费的时间最长并且耽误项目进度。

c> 不一定是越复杂的系统架构就越好。曾经看到过其它一个项目的系统架构图表，非常简单的业务流程数据竟然被分置在包括DB2,Oracle,SQL Server的3台数据库服务器上。这些服务器数据之间要进行数据的交换。其实只要用一个数据库服务器就完全可以满足所有的系统需求。其实从用户的角度出发他们所关心的就是系统功能运行的可靠性，速度性。像CPM系统，用户要得到的是包含原始数据的excel图形。不管是用Java还是.net技术开发出来的excel图形都不如直接在excel表格上做出来的图形漂亮而且直观。而且这种经过后台处理过的数据总是让用户觉得不太放心，他们总想要从后台业务系统直接倒出来的数据而不是报表中直接显示出来的数据。那么其实完全可以不用搞这些复杂的技术，直接将后台数据导入到excel表格中然后用excel自己的图形功能其实是更为方便和可靠的，而且系统运行的速度也会有很大的提高。

3．  详细计划

不能屈服于压力而缩短计划-必须牢记这点。因为如果屈服于压力而做了一个不切实际的计划，那么结果就是和所有团队成员一起去打一场败仗。在某些情况下，可以将项目分为几个不同的阶段。

对于压缩计划时间, 可以另外一个形式争取不同方的意见,比如压缩时间,可能需要增加人手, 成本也会相应增加,也有一些新的风险,需要评估.这样让对方认识到压缩时间需要另外的代价以及风险.

4．  接口问题

对系统之间的接口标准要做出接口说明书；尤其是如果是两家外包商做同一个项目碰到接口问题的时候，一定要明确这种数据格式是什么，接口标准是什么。什么时候进行接口数据的测试，如何测试。

5．  质量控制

对软件代码进行全面审核，看是否符合公司所要求的代码规范和准则。不能过分相信所谓的大的外包公司.因为不管公司规模的大小，最终进行项目开发的都是软件人员而且不一定所有最优秀的人才都来进行软件开发工作。而实际上大部分都是刚刚毕业1至2年的新人来进行程序开发。项目经理可以要求从内部增派一名作技术的同事来负责查看外包公司的代码。特别是注意是否有使用了一些硬代码。这种类似的问题在进行系统测试的时候可能不能被发现，但是一旦环境发生了变化比如说系统实施后就非常有可能出现这种错误。

一定要明确谁是最终用户。谁能进行测试。谁能进行最终数据的验证。对于CPM系统，最终系统用户和进行数据验证的用户不是同一个人。报表数据被生成后其实还是要发到各个国家负责商业的同事那里进行数据的校验。每个国家进行数据校验的方法手段都不同造成了用户测试时间的延长。