1 网站项目管理的特点 
网站项目是以Web服务器为主体、浏览器为客户端作为基本架构的项目。这样的架构项目中包含Web服务器、浏览器和网络三个关键主体。网站项目可能是一个网站，也可能是各种Web应用程序，例如网上商店、虚拟邮局、网络办公管理系统、客户关系管理系统等等。网站项目管理就是围绕着网站项目运用知识、技术、技能、工具和方法进行组织管理。其特点表现在以下几个方面： 
1）涉及的领域很多。狭义地讲，网站项目包括了网页制作、美工设计、程序编码、系统及网络管理等专业技术，广义上又包含了企业管理、市场营销、心理学、广告学等更多领域的知识，在项目进行过程中还涉及到项目管理工具、文档和设计开发管理规范、开发及测试环境部署等特殊领域的问题。这对参与项目管理的人员提出了很高的要求。 
2）参与项目的角色很多，水平可能参差不齐。对于网站项目管理，最关键的角色是项目经理、业务流程分析师、用户界面工程师、系统分析员、编码人员（程序员）和质量控制工程师等。根据项目的规模和开发的深度，由项目经理进行角色划分。假如严格细分，一个大型项目的角色可能达到50个以上，以确保每个细节都有专业的人员进行负责和管理。其中需求分析过程中主要角色有客户代表、业务员、业务流程分析师、用户界面工程师，另外还有项目经理、数据库工程师、文档工程师等参与。 
3）网络应用的开发技术在日新月异地进步，从而使网站应用系统的开发模式具有多种选择性，达到同样的目标可以采用很多不同的方式，现代的应用系统越来越成为一个庞大的集成方案，需要考虑不同的操作平台、不同的应用服务器、不同的数据库、不同的编程语言、不同的传输介质等等，项目管理人员必须了解各种技术的利弊，帮助用户选择高效、廉价并富有前瞻性的方案。 
2 需求分析在网站项目管理中的作用及要求 
需求分析是一个项目的开端，也是项目建设的基石。由于以上提出的网站项目的特殊性和行业覆盖的广阔性，以及需求分析的高风险性，网站项目需求分析的重要性是不言而喻的，在以往建设失败的项目中，80％是由于需求分析的不明确而造成的。因此一个项目成功的关键因素之一，就是对需求分析的把握程度。 
在需求分析流程中，需要有客户代表、业务员、业务流程分析师、用户界面工程师等角色参与，业务员从客户代表那里获得需求，并形成需求报告；业务流程分析员从业务员那里获得需求报告，分析生成项目模型报告；界面工程师得到项目模型后设计制作相应的模板和用户界面原型，最终由客户代表确认。需求分析所形成的文档最终达到如下要求。 
1）正确性：每个功能必须清楚描写交付的功能。 
2）可行性：确保在当前的开发能力和系统环境下可以实现每个需求。 
3）必要性：功能是否必须交付，是否可以推迟实现，是否可以在削减开支情况发生时被“砍”掉。 
4）简明性：不要使用专业的网络术语。 
5）检测性：如果开发完毕，客户可以根据需求检测。 
3 网站项目需求分析的一般方法 
根据以往的工程经验，需求分析工作方法，应该定位在“三个阶段”（也称“三步法”）。 
第一阶段：“访谈式”。这一阶段是和具体用户方的领导层、业务层人员的访谈式沟通，主要目的是从宏观上把握用户的具体需求方向和趋势，了解现有的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体情况和客观信息，建立起良好的沟通渠道和方式。针对具体的职能部门以及各委办局，最好能指定本次项目的接口人。 
实现手段：访谈、调查表格。 
输出成果：调查报告、业务流程报告。 
第二阶段：“诱导式”。这一阶段是在承建方已经了解了具体用户方的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体实际和客观信息的基础上，结合现有的硬件、软件实现方案，做出简单的用户流程页面，同时结合以往的项目经验对用户采用诱导式、启发式的调研方法和手段，和用户一起探讨业务流程设计的合理性、准确性，界面的便易性、习惯性。用户可以操作简单演示的DEMO，来感受一下整个业务流程的设计合理性、准确性等等问题，及时地提出改进意见和改进方法。 
实现手段：拜访（诱导）、原型演示。 
输出成果：调研分析报告、原型反馈报告、业务流程报告。 
第三阶段：“确认式”。这一阶段是在上述两个阶段成果的基础上，进行具体的流程细化、数据项的确认阶段，这个阶段承建方必须提供原型系统和明确的业务流程报告、数据项表，并能清晰地向用户描述系统的业务流设计目标。用户方可以通过审查报告来提出反馈意见，并对已经可接受的报告、文档签字确认。 
实现手段：拜访（回顾、确认），提交业务流程报告、数据项表；原型演示系统。 
输出成果：需求分析报告、数据项、业务流程报告、原型系统反馈意见（后三者可以统一归入需求分析报告中，提交用户方、监理方进行确认和存档）。 
整体来讲，需求分析的三个阶段是需求调研中不可忽视的一个重要部分，三个阶段或者说三步法的实施和采用，对用户和承建方都同样提供了项目成功的保证。
4 网站项目需求分析的注意事项和技巧 
项目的整体风险往往表现在需求分析不明确、业务流程不合理，导致用户不习惯或不愿意去用承建方的软件。承建方和客户方都要重视需求分析的重要性。为更好地把握用户的需求和方向，应该采用必要的手段和方法来进行需求调研。 
4.1 挖掘用户需求 
鼓励用户将所有的想法尽可能地阐述清楚，并把所有的要求罗列出来。这时候不必担心引起客户的潜在需求而增加设计开发的工作量，应直接明白地跟客户把问题和要求一条条地列出来，把条理、归纳、分析先都放到一边，将用户最原始、最完整的要求准确地记录下来。 
很多情况下客户并非专业人士，在他们的描述中很难凸现重点和技术难关，这需要我们去为客户进行分析、归纳和整理，尤其是客户谈的不多却又是技术上实现难度和强度很高的地方特别值得注意。客户往往对需求的概念是非常模糊的，大多时候给出的需求都是笼统而且尺度难以控制的，这就要求业务人员在倾听了客户的详细说明以后，帮助客户进行整理和分析，预测客户在开发过程中变更及今后应用中可能进行修改升级的潜在需求。 
比如在为客户设计办公自动化系统的时候，也许就要为客户预留将来与他们的业务单位进行交互的通道；在设计邮件系统的时候要考虑可能会需要广告管理服务器；设计网络电子商店时需考虑今后增加库存产品进销存统计分析等等；限于时间和财力的考虑，客户通常能够接受分阶段实施的开发过程，在需求分析时，提早为客户设想到今后的需求变更除了使项目开发更加顺利以外，也为今后业务的进一步深入打下了更好的基础。 
4.2 利用自然的语言和图表描述项目模型 
在业务员与客户进行沟通和调查时撰写的需求分析，尽可能用自然语言或形式化语言来描述，还可以添加图形表述方式和模型表征方式。虽然客户的水平和资历有所不同，但是最自然的描述能够使项目开发的各个成员都能清楚地理解需求含义，不至于在理解上产生偏差。对客户而言，这样的模型描述最接近真实，容易参与修订，并能以此为测试和验收的依据。制作示意图可以有很多种方式，关键是利用示意图将客户的需求和即将开始设计的系统体现出来。在进行系统分析和程序开发之前，双方对今后要完成的产品就能够有直观的认识，换言之，就是在产品还没有真正进入开发阶段的时候，双方就对工作的结果达成统一的意见，这将大大地减轻需求变更所带来的困扰，同时客户更容易地参与到项目的开发过程中。 
4.3 需求分析要共同参与各施其职 
项目经理、系统分析员、开发经理、交互设计师、测试人员、文档人员包括客户代表都应该看需求分析，并进行共同讨论，达成一致意见。参与项目开发的人员都应该对这份需求有统一清晰的认识，并根据自己的工作对需求提出意见，通过与客户的沟通修订，最终确定项目实现的目标。这样可以尽量避免业务人员与开发人员、承建方和客户方之间发生不必要的纠纷。 
例如：项目经理通过需求分析才能组建所需要的团队包括配置工作环境，制定开发周期；开发周期的限制和功能上的要求可能会影响到程序员采用什么样的语言和工具进行编写；操作用户的技能水平将影响到交互设计师进行前台设计时做到什么样的精度；界面设计人员根据项目的性质和定位确定表现方式；测试人员了解测试环境和条件后才能对项目质量进行跟踪和检测。 
4.4 将需求变更置于可控状态 
需求的变更几乎是不可避免的，也许是出自客户的遗漏，也可能是在开发过程中被激发出来的。如何以可控的方式管理网站项目需求的变更，对于项目的顺利进行有着重要的意义。如果匆匆忙忙地完成用户调研与分析，则往往意味着不稳定的需求。所以需求管理要保证需求分析各个活动都得到了充分的执行。 
为了将变更及时反馈到项目的各个角色中，做好需求变更日志就显得非常重要。在需求分析后面附上变更日志，并将修改后的需求分析制作成新版本，保留每次更改过的版本，而不是覆盖，这样就比较容易地跟踪到需求变更过程中所带来的工作调整。在新版本的需求分析中，将变更部分用特殊方式表示出来，并在日志中记录变更明细。 
4.5 评审需求文档 
需求文档完成后，需要经过正式评审，以便作为下一阶段工作的基础。一般的评审分为用户评审和同行评审两类。用户和开发方对于软件项目内容的描述，是以需求规格说明书作为基础的；用户验收的标准则是依据需求规格说明书中的内容来制订，所以评审需求文档时用户的意见是第一位的。而同行评审的目的，是在软件项目初期发现那些潜在的缺陷或错误，避免这些错误和缺陷遗漏到项目的后续阶段。 
5 总结 
随着互联网的飞速发展，Web技术应用日益广泛，网站的规模和复杂性不断增加，网站项目的设计和开发进入了需要强调流程和分工的时代，软件工程方法将越来越多地介入到网站项目的设计和开发中。建立规范的、有效的、健壮的开发机制，特别是打好网站项目管理的基石，强化项目的需求分析，将有利于高效、高速、高质量地完成开发任务。