简介：这是一个真实的故事。故事中，我作为一个项目的负责人，因为初期过于迎合客户，而放弃了对一些基本原则的坚持，最终导致项目进行中被迫进行大改动。而改动过程中，通过引入敏捷开发而将损失降到了最低。
项目背景
2006年年初，一位客户联系我的公司，希望能够为其企业创建一个企业网站项目。根据客户的简单描述，这个项目本质上就是一个内容管理系统，并集成了论坛、FTP和电子邮件等功能，因此不算复杂。按照以往的经验估计，最多一个月就可以完成这个简单的项目。
需求分析
大体而言，该项目的主要功能包括新闻和文章发布、产品发布以及后台的用户管理和权限设置，还有外围的论坛、FTP和电子邮件系统。应该是一个很简单的Web应用程序，通常情况下写一个简单的概要性文档，就可以安排开发人员进行实际编码了。
但这个客户是国有企业，所以简单的概要性文档是显然不可能通过领导审核的。为此，我和客户一起，将网站所有的功能整理成了列表，并标记出各个功能之间的关联关系。功能和内在逻辑关系整理完毕后，客户还和设计师一起将所有网页的布局也画成了图表。最终，需求文档多达50页。
在整理需求文档的过程中，我发现项目并不像客户最开始描述的那样简单。因为客户所在的企业有一百多个部门、车间，所以客户要求按照部门和车间对网站的用户进行管理。同时，权限管理是层层授权的。简单来说就是上级部门可以，也只能给直接下级部门授权，而不能越级授权。获得授权的用户可以创建一个产品子类别。然后给子类别指定一个下级部门的管理员，然后再由该下级部门的管理员来创建更深层次的子类别或管理产品信息。
从表面上看，这种设计没什么问题。但在实际操作中，这种设计要求对每一个部门的相关员工都进行培训，让其掌握系统的使用，增大了项目的应用成本。同时，由于繁琐的授权模式，最终负责产品管理的人员反倒没有充分的权力使用系统。
所以我对这些不合理的地方提出了自己的看法，希望采取更灵活更实用的设计方案。不幸的是，我没能说服客户接受我的意见。毕竟这是个金额较大的项目，客户方负责人坚持己见，我也无可奈何。
虽然按照需求文档，我把项目开发时间定为两个月，但事实证明两个月的时限过于乐观。
原型系统开发和初步评审
文档准备完毕后，我安排了开发人员和设计师进行此项目。而开发人员不到20天，就拿出了一个原型系统，虽然细节上还有不少需要完善的地方，但主要功能都已经具备了。原型系统开发完毕后，我们和客户一起进行了初步评审。评审结果双方都比较满意，所以准备在余下来的时间中完善细节。
但我发现这个原型系统中权限部分实用性非常差，因此再次提出了修改意见。不过客户显然对于我这种“怀疑”他的做法很不愉快，最后用一句“这是我们行业特点决定的”来结束了讨论。虽然我早已知道决定项目成败的，“人”才是关键因素，但迫于客户的压力，我再次选择了妥协。
此文章共有4页 1 2 3 4 下一页
文章来源：中国项目管理资源网
|
Leadge.com首页 > 知识库 
