许多开发者认为只要原型系统通过评审，整个项目就不会遇到大问题了。但实际情况有时候非常复杂。因为原型系统通常只是几个人坐在一起简单展示或者试用一下，和实际使用该系统的环境有着巨大区别。所以许多问题是根本不可能在原型展示阶段暴露出来的。
做好后的系统却彻底失败
从需求文档准备好到实际开发工作进行还不到一个半月，整个系统就非常完善了。期间由于客户方负责人出差，客户企业的其他联系人要么没有决策权，要么说不知道此事（国企通病），所以我们只有在没有获得进一步反馈意见的情况下继续按照需求文档进行开发。不过完善后的系统倒是“很顺利”的通过了客户的检查，开始部署到服务器上进行试运行。
但就像火山一样，系统中存在的问题超过临界点就会爆发。短短一周以后，上门为客户提供培训的技术支持人员就带回来了一份详细的修改意见文档和反馈意见。而我仅仅看了这些文档几分钟，就明白这个项目将要进行重大修改，否则不可能投入实际应用。
修改意见文档的内容主要集中在权限系统上，具体而言就是权限系统的设计太复杂、太死板。首先，层层授权太过繁琐，有时候改变产品类别的名字也要找到上级管理员才行。其次，由于系统限定不能给一个管理人员分配多级产品分类的权限，所以必须每个产品分类层次都要设置不同的管理帐号。
客户企业有10多个大类，100多个小类，上千种型号的产品。但实际上根本没有那么多人愿意负责管理工作，最后就成了一个人用几个帐号，当初设想的严格权限管理形同虚设。而且由于使用太麻烦，实际的管理工作逐渐向少部分人集中，导致这些人怨声载道，开始对系统提出各种各样的负面看法。
在这种情况下，我公司和客户企业领导进行了多次会议，初步决定两条腿走路。一方面用最短的时间修改现有系统，保证客户企业新产品发布时，网站能够正式推出。另一方面重新做一套新系统来替换现有系统。
重新开始，该如何抉择？
对于软件公司来说，一个项目如果重做，损失和影响是非常大的。因为不但其他的开发计划要被打乱，而且公司投入的成本也要成倍增加。这个时候，如何降低损失就是最重要的事情了。好在和和客户经过进一步协商后，客户承担了一半的损失。而完全重做也改为只重做权限系统部分。
根据这个目标，我首先安排开发人员对系统进行修改。砍掉了权限系统（实际上就是这一块导致了整个系统的重做），并按照其他项目的成功经验，对多处功能进行了修改。修改完成后的系统虽然缺乏权限管理，但其他功能经过客户企业员工使用都反映良好。而且这样简化后的系统大部分功能都可以直接搬到重新开发的新系统中，最大程度的降低了成本。
同时，在我的强烈要求下，客户企业决定安排专人负责此项目。这样我才能保证新系统的开发不至于重蹈覆辙。
此文章共有4页 上一页 1 2 3 4 下一页
文章来源：中国项目管理资源网
|
Leadge.com首页 > 知识库 
