创建一个典型的企业网站项目

　　简介：这是一个真实的故事。故事中，我作为一个项目的负责人，因为初期过于迎合客户，而放弃了对一些基本原则的坚持，最终导致项目进行中被迫进行大改动。而改动过程中，通过引入敏捷开发而将损失降到了最低。

　　项目背景

　　年初，一位客户联系我的公司，希望能够为其企业创建一个企业网站项目。根据客户的简单描述，这个项目本质上就是一个内容管理系统，并集成了论坛、FTP和电子邮件等功能，因此不算复杂。按照以往的经验估计，最多一个月就可以完成这个简单的项目。

　　需求分析

　　大体而言，该项目的主要功能包括新闻和文章发布、产品发布以及后台的用户管理和权限设置，还有外围的论坛、FTP和电子邮件系统。应该是一个很简单的Web应用程序，通常情况下写一个简单的概要性文档，就可以安排开发人员进行实际编码了。

　　但这个客户是国有企业，所以简单的概要性文档是显然不可能通过领导审核的。为此，我和客户一起，将网站所有的功能整理成了列表，并标记出各个功能之间的关联关系。功能和内在逻辑关系整理完毕后，客户还和设计师一起将所有网页的布局也画成了图表。最终，需求文档多达50页。

　　在整理需求文档的过程中，我发现项目并不像客户最开始描述的那样简单。因为客户所在的企业有一百多个部门、车间，所以客户要求按照部门和车间对网站的用户进行管理。同时，权限管理是层层授权的。简单来说就是上级部门可以，也只能给直接下级部门授权，而不能越级授权。获得授权的用户可以创建一个产品子类别。然后给子类别指定一个下级部门的管理员，然后再由该下级部门的管理员来创建更深层次的子类别或管理产品信息。

　　从表面上看，这种设计没什么问题。但在实际操作中，这种设计要求对每一个部门的相关员工都进行培训，让其掌握系统的使用，增大了项目的应用成本。同时，由于繁琐的授权模式，最终负责产品管理的人员反倒没有充分的权力使用系统。

　　所以我对这些不合理的地方提出了自己的看法，希望采取更灵活更实用的设计方案。不幸的是，我没能说服客户接受我的意见。毕竟这是个金额较大的项目，客户方负责人坚持己见，我也无可奈何。

　　虽然按照需求文档，我把项目开发时间定为两个月，但事实证明两个月的时限过于乐观。

　　原型系统开发和初步评审

　　文档准备完毕后，我安排了开发人员和设计师进行此项目。而开发人员不到20天，就拿出了一个原型系统，虽然细节上还有不少需要完善的地方，但主要功能都已经具备了。原型系统开发完毕后，我们和客户一起进行了初步评审。评审结果双方都比较满意，所以准备在余下来的时间中完善细节。

　　但我发现这个原型系统中权限部分实用性非常差，因此再次提出了修改意见。不过客户显然对于我这种“怀疑”他的做法很不愉快，最后用一句“这是我们行业特点决定的”来结束了讨论。虽然我早已知道决定项目成败的，“人”才是关键因素，但迫于客户的压力，我再次选择了妥协。

　　许多开发者认为只要原型系统通过评审，整个项目就不会遇到大问题了。但实际情况有时候非常复杂。因为原型系统通常只是几个人坐在一起简单展示或者试用一下，和实际使用该系统的环境有着巨大区别。所以许多问题是根本不可能在原型展示阶段暴露出来的。

　　做好后的系统却彻底失败

　　从需求文档准备好到实际开发工作进行还不到一个半月，整个系统就非常完善了。期间由于客户方负责人出差，客户企业的其他联系人要么没有决策权，要么说不知道此事（国企通病），所以我们只有在没有获得进一步反馈意见的情况下继续按照需求文档进行开发。不过完善后的系统倒是“很顺利”的通过了客户的检查，开始部署到服务器上进行试运行。

　　但就像火山一样，系统中存在的问题超过临界点就会爆发。短短一周以后，上门为客户提供培训的技术支持人员就带回来了一份详细的修改意见文档和反馈意见。而我仅仅看了这些文档几分钟，就明白这个项目将要进行重大修改，否则不可能投入实际应用。

　　修改意见文档的内容主要集中在权限系统上，具体而言就是权限系统的设计太复杂、太死板。首先，层层授权太过繁琐，有时候改变产品类别的名字也要找到上级管理员才行。其次，由于系统限定不能给一个管理人员分配多级产品分类的权限，所以必须每个产品分类层次都要设置不同的管理帐号。

　　客户企业有10多个大类，100多个小类，上千种型号的产品。但实际上根本没有那么多人愿意负责管理工作，最后就成了一个人用几个帐号，当初设想的严格权限管理形同虚设。而且由于使用太麻烦，实际的管理工作逐渐向少部分人集中，导致这些人怨声载道，开始对系统提出各种各样的负面看法。

　　在这种情况下，我公司和客户企业领导进行了多次会议，初步决定两条腿走路。一方面用最短的时间修改现有