1998年，互联网火了，新鲜出炉的网虫在网上发邮件、上BBS，立刻成了新潮一派；
1999年，个人主页火了，啃几行HTML、扒弄点图片，捣鼓出个人站点就成“大虾”了；
2000年，Dotcom火了，门户、聊天、游戏、社区花样百出，混个斑竹网管当当，顿时风光无限；
2001年，网络应用火了，买卖东西、拉拉客户、管管财务，有点技术的家伙开始牛啦；
现在该怎么干？？？
A镜头：你被老板安排负责信息化建设，是不是像老虎咬刺猬一样无从下口？
B镜头：你希望请别人设计一个网站，他们是不是会敷衍了事，蒙你一把？
C镜头：有一个诱人的项目摆在面前，到最后是不是搞得一团糟，反而倒贴老本？
到底该怎么办？？？
从现在开始，一起出发去找我们的新奶酪吧。这个奶酪的名字叫“网站项目管理”。
网站项目：即以Web服务器为主体、浏览器为客户端作为基本架构的项目。这样的架构项目中包含Web 服务器、浏览器和网络三个关键主体。网站项目可能是一个网站，也可能是各种Web应用程序，例如网上商店、虚拟邮局、网络办公管理系统、客户关系管理系统等等。
网站项目管理：是围绕着网站项目运用知识、技术、技能、工具和方法进行组织管理。其共同特征是：
● 管理由人实现，而非机器；
● 项目具有时间周期，包括启动时间和结束时间；
● 项目受资源限制，包括人员、资金、场地、设备等；
● 需要计划、实施和控制；
文章开头的A镜头、B镜头和C镜头，都可以纳入网站项目管理的范畴。以下是网站项目管理的几个重要概念：
（1）角色：是指项目人员在管理过程中，在特定环境下参与设计的行为代表。
例如项目经理、数据库工程师、界面设计师、文档工程师等等。对于网站项目管理，最关键的角色是：项目经理，业务流程分析师，用户界面工程师，系统分析员，编码人员（程序员），质量控制工程师。根据项目的规模和开发的深度，由项目经理进行角色划分。假如严格细分，一个大型项目的角色可能达到50个以上，以确保每个细节都有专业的人员进行负责和管理。
需要注意的是：角色不等于人。一个人可能充当多个角色，一个角色也可能由许多人组成。比如既是系统分析员，也是测试工程师，或者既是用户界面工程师，又担任文档编写和管理，一个项目管理小组可能只有三五个人，也可能三五百号人，项目组可大可小，但是项目管理流程需要细致的角色分工。
（2） 流程：在项目过程中执行的工作序列。
每个角色在流程中获得和输出相应的工作结果。例如在需求分析流程中，需要有客户代表、业务员、业务流程分析师、用户界面工程师等角色参与，业务员从客户代表那里获得需求，并形成需求报告；业务流程分析员从业务员那里获得需求报告，分析生成项目模型报告；界面工程师得到项目模型后设计制作相应的模板和用户界面原型，最终由客户代表确认。
（3）业务主角：指与系统交互的各种不同角色。
例如一个网上商店系统，业务主角有普通访客、下定单会员、管理会员及定单的业务员、网站的商品信息发布人员、商品供应厂家的业务管理人员，物流配送管理员等等。
不管面对多么复杂的网站项目，当我们开始接手时，都可以按照一定的规范和流程进行展开。
网站项目涉及的领域很多，狭义地讲包括了网页制作、美工设计、程序编码、系统及网络管理等专业技术，广义上又包含了企业管理、市场营销、心理学、广告学等更多领域的知识，在项目进行过程中还涉及到项目管理工具、文档和设计开发管理规范、开发及测试环境部署等特殊领域的问题，这对一个项目经理和小组来说是个严峻的考验。
网站设计发展经历了静态网站、交互式网站、商业应用、特殊应用的过程，随着企业对网络应用的理解和认识，对网站的功能要求越来越复杂，如今网站项目的设计已经不能再仅仅简单地利用静态Html文件来实现，与前几年网站设计由一两名网页设计师自由的创作相比，网站项目的设计和开发越来越像一个软件工程，越来越复杂，网站项目的设计和开发进入了需要强调流程和分工的时代，建立规范的、有效的、健壮的开发机制，才能适应用户不断变化的需要，“网站即软件！”，借鉴软件工程的思想并可从中寻找出网站项目管理的规律和方法。
网站项目管理分成以下六个阶段进行：
一) 需求分析及变更管理；
二) 项目模型及业务流程分析；
三) 系统分析及软件建模；
四) 界面设计、交互设计及程序开发；
五) 系统测试、部署和文档编写；
六) 客户培训、技术支持和售后服务。
在每个阶段，都必须建立“里程碑”，代表当前工作的阶段性成果，并以此作为进入下一阶段的标准，实现对项目质量的控制和管理。
第一阶段：需求分析及变更管理
假如病人上医院看病，医生需要“望、闻、问、切”，耐心仔细地了解完情况后，确定病因后才敢开药方。而我们在接手一个网站项目的时候，是否真的弄清楚客户的“病因”？又有多少回等到项目做到一半的时候才发现客户的需求根本不是这样的？！
项目本来是为满足客户需求目标而进行的，然而结果往往并非如此，因为：“客户也不知道自己的需求是什么！”在所有不成功的案例中，这句话也许是我们听的最多的。事实的确如此，这很令人沮丧。庆幸的是网站项目和建筑工程最大的区别在于：大楼建到一半的时候，不可能重新浇注地基，只好推倒重来，但网站项目却经常在页面制作、交互设计已经完成的时候还可以更改核心，甚至重新架构。
做好需求分析并建立变更管理机制是保证项目顺利完成的原始基础。
● 重要角色：项目经理，业务员，客户代表。
● 获取文档：通过与客户的讨论等各种渠道获得需求。
● 里 程 碑：《需求分析报告》
● 注意事项：
☆ 技术是为客户服务的，采用对用户最有效和经济的设计方法才是最好的，而非采用了最好的技术和配置就能设计出最好的方案。所谓最好的技术附带的潜台词往往就是高昂的成本、漫长的开发周期和潜在的不稳定，切忌将客户当作技术的试验田。
☆ 记住“需求是一定会变的”，同时不要害怕客户提需求。如果因为害怕看见大象的全貌而只摸摸大象的腿，怎么也不可能设计出客户所需要的系统。
☆ 锁定需求，学会放弃。对超出计划和目标的需求可以通过制定升级计划或二期工程，从当前的项目中转移出去，否则系统可能永远都在设计开发中，不断修改和增加，则始终没有可以发布的版本。
☆ 《需求分析报告》应得到客户和全体项目小组的共同认同，切忌公说公的理，婆说婆的理，只有所有成员都对目标有清晰一致的认知后，才能最大地提高工作效率。
● 技巧和方法：
☆ 仔细聆听，罗列客户的所有要求；
☆ 将需求进行分析，确认可操作的系统模型；
☆ 利用最自然的语言对系统进行描述，使每个开发人员不会产生歧义；
☆ 迅速确定系统的业务主角；
☆ 分析确定每个角色的权限及可操作的功能；
☆ 制作流程图和示意图将需求表现出来；
☆ 让客户参与到示意图的设计中，及时正确地反应出需求变更；
☆ 制作需求变更日志，保留升级版本，通过版本控制进行需求管理；
☆ 通过《需求分析报告》使每个参与人员看到共同的努力目标。
在这个阶段，我们通过需求分析对项目得到一个初步的认识，并通过编写《需求分析报告》得到一份客观的可参照的重要文档，这是个很好的起点。
客户的需求基本清楚了，但是客户并没有教我们该怎么做。当客户把球抛给了项目小组，看你如何把球接起来呢。
好吧，下面让我们继续……
第二阶段：项目模型及业务流程分析
我们需要业务流程分析人员将客户需求分解和优化，网络技术的应用所产生的电子流程工作方式既不能彻底更改传统的工作流程，也不是对传统工作流程的简单复制，而是需要对传统的工作流程进行合理的优化、改进和重组。
用户提出的需求通常是凌乱的、不完整的，甚至是不正确的，而且，更准确更精细的需求经常是在项目开发进行中才被挖掘发现的。缺乏经验的项目人员往往在接受任务后迫不及待地进行系统分析和开发，而不愿意多一点时间在和客户反复推敲项目需求和模型，开发过程中想当然地凭空为客户做很多假想，只能是费了九牛二虎之力之后吃力不讨好。
业务流程分析员重点需要协助客户将需求进行归纳分析，查找出所有的业务主角，确定业务主角后，将每个主角的相关活动及流程清晰地制定出来，最终设计出业务逻辑图。
为了使用户更好地理解系统设计方案，在时间条件许可的情况下，为系统制作用户界面原型图是非常有效的办法。在尚未进行开发之前，客户就能对今后要完成的系统能够直观地看到效果，并能根据需要进行调整，将大大提高项目成功的可能性，同时可减设计过程中的更改工作量。
● 重要角色：业务流程分析师，用户界面工程师，系统分析师。
● 获取文档：《需求分析报告》。
● 里 程 碑：《项目模型报告》、《用户界面原型》、《设计开发计划书》。
● 注意事项：
☆ 业务流程应符合客户偏好和习惯，以客户的环境和技能水平设计系统，切忌以项目小组的喜好随意设计；
☆ 请客户和用户模拟操作，找出盲点和分歧点，问题越早发现越容易处理，损失越小；
☆ 制定性能和功能指标，作为下一阶段测试工程师的工作依据。客户对功能的需求相对来说比较敏感和直观，但是对性能的需求很难提出具体的要求，这就需要系统分析师在这个阶段进行明确，并作为系统设计的依据之一。
文章来源于领测软件测试网 https://www.ltesting.net/