|
项目启动以后，双方应当就项目执行的规范和约束达成共识，包括双方的沟通和交流机制、必须交付哪些文档，哪些文档必须确认，确认以什么形式等等都应描述清楚，通常这份文档的名称是《项目章程》，A公司的IT信息主管刘一民出身技术，对选择哪种开发语言有自己的判断，却不清楚实施一个项目，做为甲方，最主要应当对乙方提出什么样的要求。项目管理者联盟
如果说，SOW和《项目章程》的缺失，反映出双方尤其是B公司的项目流程不正规，为项目带来了很大的风险，但接下来的需求调研和分析如果做好了，还是有可能不让这些风险“落实”成问题的。因为项目成功的因素是很多的。项目管理者联盟
不幸的是，从案例中我们看到，最关键的环节，项目的需求调研和分析工作似乎进行得非常简单，A将心目中理想的各功能模块原型网站提供给B，自认为需求很“明了”了，而B公司没有将客户提供的需求进行系统分析、综合归纳，理顺逻辑关系等工作，并形成《需求说明书》之类文档， 至少从案例描述中没有看到这部分工作，即使做了，只怕也没经过认真的评审和签字确认，否则，就不会出现现在这样的结果。项目管理者联盟
等到B将第一个“失败的版本”拿出，虽说A方刘一民很意外，但其实太正常了。那么多应该做的事情都没好好做，凭什么做出来的东西就该符合他心目中的设想呢?项目管理者联盟
第一个版本错误太多，但是绝对不能客户提出一个错误就修改一个。因为做为一个系统，功能模块、功能点之间都是有关联的，修改一个错误可能会带出一堆新错误，这是最常见的现象，所以有经验的项目组都知道如何将错误控制在一定范围，如何将哪些错误放到下一个版本。B公司却恰恰这样做了，使得错误没完没了，而且他们修复错误的效率还很低，逼得着急的A公司也安排人加入了测试工作，这样又冒出了新的需求，项目越发结束不了了。这个过程中看不到B公司的“缺陷处理流程”，“需求变更控制流程”……。项目管理者联盟
这个项目可谓是一步错，步步错，可吸取的教训太多了。项目管理者联盟 项目管理者联盟
本文为项目管理者联盟联盟会员原创文章，授权发布，非经同意不得转载！
|
