吉宁博士观点
随着国内互联网的发展，网站项目管理越来越多。一方面由于网站项目管理却没有成熟的规范和标准，大部分项目靠人为主观控制，出现了多多少少的问题，比如：不能按期完工，质量不满意，费用超出预算等等。
另一方面，在网站项目管理思想上，国内还处在一个刚起步的阶段，很多公司都处于封闭状态，自己制定独立规范和开发自用软件，进步缓慢；而国外则已经发展有开放的，系统的网站管理理论和先进的网站管理工具。这方面的差距是我们现在同国外的主要差距。
随着技术的不断发展和用户对网站功能性的需求不断提升，如今网站项目管理的设计已经不能再仅仅简单地利用静态Html文件来实现，与前几年网站设计由一两名网页设计师自由的创作相比，网站项目管理的设计和开发越来越像一个软件工程，也越来越复杂，网站项目管理的设计和开发进入了需要强调流程和分工的时代，建立规范的、有效的、健壮的开发机制，才能适应用户不断变化的需要，达到预期的计划目标。
网站项目管理的含义为以Web应用程序为主要表现方式的架构来进行的项目设计及网站管理，这样的架构中包含了浏览器、网络和Web服务器等关键主体，主要体现在网站设计、以浏览器为客户端的Web应用程序开发（例如信息类网站、网上商店、虚拟邮局、客户关系管理）等网站项目管理中。
在本文中，作者将网站项目管理与软件工程的统一过程网站管理进行参照比较，并结合实际工作经验，力求将网站工程管理的角色、分工、流程进行完整的阐述，使网站项目管理逐渐走向规范化。
一、网站项目管理可以分为以下七个阶段进行控制：
1、需求分析及变更管理
2、项目模型及业务流程分析
3、系统分析及软件建模
4、界面设计、交互设计及程序开发
5、系统测试和文档编写
6、客户培训、技术支持和售后服务
需要说明的是，这些阶段虽然具有一定的延续性，但是并非完全隔断的，例如需求变更管理和测试工作、文档编写都是贯穿整个网站项目管理过程的，许多工作时交叉进行或同时进行的。
二、网站项目管理需求分析及变更管理
业务员与客户进行的沟通，撰写需求分析报告是项目展开的基础。项目是以客户的需求为中心，而不是为技术而迁就需求。
2.1让客户畅所欲言，罗列出所有的需求
让用户将所有的想法尽可能的阐述清楚，并把所有的要求罗列出来，不要遗漏。这时候不应该害怕”勾引”起客户的潜在需求而增加设计开发的工作量，从而被今后客户无止境的变更拖入泥潭，直接明白地跟客户把问题和要求一条条地列出来，把条理、归纳、分析先都扔到一边去，将用户最原始、最完整的要求准确地记录下来就完成了第一步的工作。
很明显，假如客户的需求做的都不完整，随时可能会产生意想之外的变更，甚至这个变更会破坏已经做的模型及结构，那么这个项目从开始就注定了会失败。比如站点所有的功能都实现了，本地测试起来也没有什么问题了，但是你却不知道客户的系统是要承受每天100万独立IP的访问，而你原来想当然的以为了不起就是1万独立IP访问的访问流量，稍微有经验的开发人员都会明白这样的设计是个灾难，无论是应用服务器、数据库还是程序全部要重新开发！
2.2透过现象分析潜在的需求
很多情况下客户并非专业人士，在他们滔滔不绝的描述中不能指望他们帮助我们整理出重点和技术难关，这需要我们去为客户进行分析、归纳和整理，尤其是客户谈的不多却又是技术上实现难度和强度很高的地方特别值得注意。
客户往往对需求的概念是非常模糊的，大多时候给出的需求都是笼统而且尺度难以控制的，这就要求业务人员在倾听了客户的详细说明以后，帮助客户进行整理和分析，同时预测客户在开发过程中变更及今后应用中可能进行修改升级的潜在需求。
比如在为客户设计办公自动化系统的时候，也许就要为客户预留将来与他们的业务单位进行交互的通道；在设计邮件系统的时候要考虑可能会需要广告管理服务器；设计网络电子商店时今后增加库存产品进销存统计分析等等；限于时间财力的考虑，客户通常能够接受分阶段实施的开发过程，在需求分析时，提早为客户设想到今后的需求变更除了使项目开发更加顺利以外，也为今后业务的进一步深入打下了更好的基础。
我曾负责一个大型新闻网站管理的设计，当客户拿着将近五十页厚的一本设计要求报告时，我发现有四十页的内容对程序开发来说都是重复的，而在其中一页的角落却画了个”搜索其他网站相关新闻”的按钮，并且没有做任何说明，仅仅这10个字所完成的工作量完全顶的上其他整整四十页重复赘述所做的工作，客户完全不知道这个要求引发的问题实际就是一个搜索引擎的开发，通过协商，客人同意了修改成站内搜索的引擎。
2.3利用自然的语言描述项目模型
在业务员与客户进行沟通和调查时撰写的需求分析，尽可能用自然的语言进行描述，虽然客户的水平和资历有所不同，但是最自然的描述能够使项目开发的各个成员都能清楚地理解需求含义，不至于在理解上产生偏差。对客户而言，这样的模型描述最接近真实，容易参与修订，并能以此为测试和验收的依据。
比较以下两份关于需求的描述：
”用户在访问首页的时候可以在点击客户通道按钮，弹出填写用户名和密码的窗口，输入正确后在新窗口打开客户通道的首页，在该页显示所有可操作的功能的导航条和最新的导读新闻链接列表”
”站点分为公开和加密两种状态，通过身份验证机制使特有的用户可以访问到加密信息，并提供不同于普通用户的功能。”
前段描述我们就很容易想象的出来设计完成的网站管理是什么样子，而后一段的描述可能会做出无数不同的版本，造成对需求理解的歧意。
2.4利用示意图和图表将用户的需求表现出来
需求分析无论文字上怎么样表述都还是抽象的，对客户而言理解毕竟是困难的，将基本确定的需求制作出示意图是最直观有效的。
制作网站项目管理示意图可以有很多种方式，用PowerPoint制作流程示意或用Html文档制作界面示意都是可行的，最简单利用画图和Word表格方式也完全可以，关键是利用示意图将客户的需求和即将开始设计的系统体现起来，在进行系统分析和程序开发之前，双方对今后要完成的产品就能够有直观的认识，换言之，就是在产品还没有真正进入开发阶段的时候，双方就对工作的结果达成统一的意见，这将大大地减轻需求变更所带来的困扰，同时客户更容易地参与到项目的开发过程，保证项目往正确的方向进行。
在RUP中有这样的描述：”利用电影、卡通、图片、表格和动画片等制作示意图开始，告诉我们用户是谁，要发生什么事情，如何发生。
简单地说，制作网站项目管理示意图就是使用工具向用户(主角)说明（有时是动画演示）系统如何适应组织的需要，并表明系统将如何运转，协调员将初始示意板展示给小组，小组成员提供意见之后，在举办研讨班期间，示意板也进行”实时”演进。所以，需要一种可以轻松更改示意板的画图工具。为了避免分散注意力，一般最好使用简单的工具，比如图表、白板或PowerPoint。
2.5什么人要看需求分析报告
项目经理、系统分析员、开发经理、交互设计师、测试人员、文档人员包括客户代表都应该看需求分析，并进行共同的讨论，达成一致的意见。
我们经常会遇到业务人员辛辛苦苦谈下来的项目，对开发人员来说却是难以实现的，而技术人员设计的产品却常常得不到客户的认可，甚至发生纠纷，因此参与项目开发的人员都应该对这份需求有统一清晰的认识，并根据自己的工作对需求提出意见，通过与客户的沟通修订，最终确定网站项目管理实现的目标。
例如：
项目经理通过需求分析才能组建所需要的团队包括配置工作环境，制定开发周期；
开发周期的限制和功能的要求可能会影响到程序员采用什么样的语言和工具进行编写；
操作用户的技能水平将影响到交互设计师进行前台设计时做到什么样的精度；
界面设计人员根据项目的性质和定位确定表现方式；
测试人员了解测试环境和条件后才能对项目质量进行跟踪和检测；
通过下表，我们可以看的出不同角色根据需求的变更所进行的网站管理工作流程：
2.6建立需求变更日志，制作新版本的需求分析报告
尽管我们费了许多功夫在需求分析进行了最大可能的努力，但几乎可以肯定的是，这份需求分析在开发过程中一定会发生变化，也许是出自客户的遗漏，也可能是在开发过程中被激发出来的，这种变更有时是如此的频繁和琐碎，以至于往往不能将变更及时反馈到项目的各个角色中，那么做好需求变更日志就显得非常重要。
在需求分析后面附上变更日志，并将修改后的需求分析制作成新版本，保留每次更改过的版本，而不是覆盖，这样就比较容易地跟踪到需求变更过程中所带来的工作调整。
网站项目管理在新版本的需求分析中，将变更多部分用特殊方式表明出来，并在日志中记录变更多重的明细。
关于需求分析和变更网站管理可以参照下图示意：
2.7本阶段重点工作角色
在需求分析和变更管理的过程中，工作量最大的角色为客户代表、业务员和项目经理。
客户代表提出需求，业务员帮助整理和分析，项目经理对整个项目进行评估。
在实际工作中，很多项目失败的起因都和需求分析有关。客户代表和业务员通常并非从事技术开发的专业人员，在讨论需求的时候往往对项目的技术难度、工作量、时间进度把握不准确，这时候需要项目经理或技术人员进行参谋。
为了降低网站项目管理的风险，提升工作效率，有必要设计规范的需求管理计划书，帮助客户代表和业务员更好的完成任务。
不论是功能网站管理设计，还是基于B/S架构的MIS系统，都需要有一套合理的网站管理方案来保证项目的正常运转。去年为企业部门做了一个基于B/S的MIS系统，项目不大，总共三人——数据库设计人员、程序开发人员（我）和一个测试人员，做完之后有两个体会：一是包揽网站管理的前后台设计使得自己要面临的问题很繁杂，二是给企业部门做事效率太低，客户的支持不够。不管怎么样，项目总算是做完了，可以交付使用，但中间存在的问题只有我们自己知道，我们想解决问题，但不是我们开发人员说的算。中国这种项目多了，拿出来讲总有讨论不完的话题，并且没有什么意义，这里只想站在项目管理的角度，总结一下网站项目管理中的过程实践，在今后的项目中能做的更好一些。
网站界面
对于程序员来说，网站管理界面设计相对于后台程序设计并不那么起眼，因为按照我们的理解，客户需要的是能够使用的程序，这是基础，而不是漂亮的应用界面，如果两者能同时满足当然最好，但在我参与的那个项目中可没有这么好的“待遇”。在实际中，太花哨的网站管理界面的确很难得到用户的垂青，特别是专业的MIS网站管理系统更是如此，因此，在这个过程中如何讲程序的核心功能展现在用户面前是最关键的问题，而不仅仅是按钮工具条如何摆放，核心的模块确定之后，其他的功能和修饰就能很快决定出来。以后应用中，使用AJAX是一种增强用户体验的方法，也是当前的流行趋势，但一切还是以实用、简洁、易用为目的。说到这里，这一切还是必须要以完善的需求分析为基础，只有了解到用户需求的核心所在，才能将需求变为程序。
项目进度
把握好项目进度不是一件容易的事，首先要充分考虑环境因素，如自己的团队怎么样，更重要的是客户的支持与配合。企业部门的项目如果得到领导的充分重视，并且有良好的工作流程和明确的业务关系，项目实施将会非常便利，像银行、电信等部门的项目就相对好做，因为他们的业务需求非常明确，银行的利率计算方法就是明确的，审批流程也是通用的，提取款方式也是规定好了的，后台规则都是不容许轻易改动的等等。但是其他大多数的项目中，开发人员就没有这么好的“待遇”了，一是业务规则经常会出现小的变动，二是有的环节领导还需要一定的“灵活性”，更难受的是，得不到领导的重视，这个项目做的过程难受，做完了以后可能根本不会用，这样虽然可以应付交差，但对开发人员来讲没什么意思，如果可以选择还不如不做。因此，这个环节最重要的是项目需求的精细程度、客户的支持程度和自身的开发实力，这样才能评估出一个较好的项目进度方案，并且项目进行过程中给予控制。
人力资源
可能在一些大公司情况会好一些，在我参与的这个项目中，自己要负责Web的前后台所有应用，从视图层到控制层到业务逻辑层，从更细的层面上说，数据持久化需要自己做，公共类需要自己开发，分页要自己设计，还有各种VO/BO，Action等等，更头痛的还要设计页面的编排，CSS控制，起初真的是折腾了我一阵子，现在想想对个人也是一个锻炼，但对于项目而言，应该有充分的人力资源来支撑项目的顺利进行。一般的小项目，需要需求定义人员一名，页面设计美工一名，业务程序开发一到两名，数据库设计人员一名，还需要一位测试人员，这样说的比较狭隘，但至少分工细一点对整个项目的正常运转是有好处的。
团队氛围
团队氛围直接影响团队所有成员的精神状态，只有大家精神状态良好，才能保证工作的积极性与上进心，主动与同事、项目经理沟通。在团队中，大家最开始就应该有一个共同的目标，这个目标的形成，需要项目经理在领导、客户和项目团队成员之间寻求最佳点，深入需求分析，争得大家一致同意后确定每个步骤环节的目标，包括美工、开发、测试、试运行等等。这样可以保证在项目进行过程中避免不必要的分歧和争论，影响项目质量和进度。闲暇之余，团队里的成员可以在一起运动一下，如打乒乓球、羽毛球等体育运动，或联机游戏，但个人觉得还是体育运动比较好。
项目文档
这两天已经看到几位老大对它的讨论了，如庄兄的《代码质量与文档质量》和Ghawk的《UP&XP之争，意义何在？》。我还不能站在一个高的角度上来评论这些，只是按照自己的一点点经验和思考来理解。其实对待项目文档，最简单的处理态度是适中，不要一味追求文档，但少了也肯定不行。文档是软件生命周期必不可少的东西，它的主要作用是规范统一的行为和风格，让大家有章可循，避免在开发过程中走弯路，并且文档要是可行的，这样可以降低项目的风险。当然，使用文档的目的是服务网站项目管理的，要能够为项目带来效益，所以没有必要一味的去要求书本中所提及的完整的文档，那样只会给自己带来时间的浪费和额外的成本，总之，适合项目的就是最好的。
其他要求
网站管理软件开发中，版本控制几乎是每个程序员都会碰到的，流行的习惯用CVS作为版本控制，在上传代码时需要注释以便查询。程序的代码需要符合统一的规范，每个程序员都有自己的代码风格，即使是有注释，也会给他人阅读带来不便，因此强制执行规范的代码风格是必要的，在我参与的网络MIS系统中没有这个问题，因为所有的开发代码由自己一个人完成，但是良好的代码结构仍然对自己今后阅读，及他人维护带来很多便利。最后是测试的重要性，优秀的测试人员能够给项目把住最后的一道关，保证项目的质量，有时候测试人员的作用是决定性的，测试过程中的疏漏往往会直接给项目组带来时间和经济上的损失。
