商业网站建设规划分析
越来越花哨的个人网站容易让人产生网站很容易做的误解。阅读完本文，你才会知道建设一个商业网站的艰苦卓绝。个人网站像儿童的画板，商业网站是一套软件。个人网站很容易绚丽多彩，因为它不必考虑目的性、完整性、扩展性以及负荷，它更多地只是一时兴起；商业网站是工作的平台，它关乎未来工作的效率、连续性、安全性，不容失败。
如果你是一家中小企业，你恰好要建一个基于工作的网站，如果你真正想将工作架在互联网上，而不是一时新奇，那么，你仔细读读这篇文章，能消灭很多错误的观念。读完本文，如果你觉得做一个商业网站太麻烦了，你不做了，那也是一种收获。现在，很多“商业”网站形同虚设，最重要一个原因，建立者建立之时，就根本没有将它当作商业网站做。
1998年，互联网火了，新鲜出炉的网虫在网上发邮件、上BBS，立刻成了新潮一派；
1999年，个人主页火了，啃几行HTML、扒弄点图片，捣鼓出个人站点就成“大虾”了；
2000年，Dotcom火了，门户、聊天、游戏、社区花样百出，混个斑竹网管当当，顿时风光无限；
2001年，网络应用火了，买卖东西、拉拉客户、管管财务，有点技术的家伙开始牛啦；
2002年，企业应用解决方案，.net平台看起来又要火了…
A镜头：你被老板安排负责信息化建设，是不是像老虎咬刺猬一样无从下口？
B镜头：你希望请别人设计一个网站，他们是不是会敷衍了事，蒙你一把？
C镜头：有一个诱人的项目摆在面前，到最后是不是搞得一团糟，反而倒贴老本？
到底该怎么办？？？
从现在开始，一起出发去找我们的新奶酪吧。这个奶酪的名字叫“网站项目管理”。
网站项目：即以Web服务器为主体、浏览器为客户端作为基本架构的项目。这样的架构项目中包含Web 服务器、浏览器和网络三个关键主体。网站项目可能是一个网站，也可能是各种Web应用程序，例如网上商店、虚拟邮局、网络办公管理系统、客户关系管理系统等等。
网站项目管理：是围绕着网站项目运用知识、技术、技能、工具和方法进行组织管理。其共同特征是：
● 管理由人实现，而非机器；
● 项目具有时间周期，包括启动时间和结束时间；
● 项目受资源限制，包括人员、资金、场地、设备等；
● 需要计划、实施和控制；
文章开头的A镜头、B镜头和C镜头，都可以纳入网站项目管理的范畴。以下是网站项目管理的几个重要概念：
（1）角色：是指项目人员在管理过程中，在特定环境下参与设计的行为代表。
例如项目经理、数据库工程师、界面设计师、文档工程师等等。对于网站项目管理，最关键的角色是：项目经理，业务流程分析师，用户界面工程师，系统分析员，编码人员（程序员），质量控制工程师。根据项目的规模和开发的深度，由项目经理进行角色划分。假如严格细分，一个大型项目的角色可能达到50个以上，以确保每个细节都有专业的人员进行负责和管理。
需要注意的是：角色不等于人。一个人可能充当多个角色，一个角色也可能由许多人组成。比如既是系统分析员，也是测试工程师，或者既是用户界面工程师，又担任文档编写和管理，一个项目管理小组可能只有三五个人，也可能三五百号人，项目组可大可小，但是项目管理流程需要细致的角色分工。
（2） 流程：在项目过程中执行的工作序列。
每个角色在流程中获得和输出相应的工作结果。例如在需求分析流程中，需要有客户代表、业务员、业务流程分析师、用户界面工程师等角色参与，业务员从客户代表那里获得需求，并形成需求报告；业务流程分析员从业务员那里获得需求报告，分析生成项目模型报告；界面工程师得到项目模型后设计制作相应的模板和用户界面原型，最终由客户代表确认。
（3）业务主角：指与系统交互的各种不同角色。
例如一个网上商店系统，业务主角有普通访客、下定单会员、管理会员及定单的业务员、网站的商品信息发布人员、商品供应厂家的业务管理人员，物流配送管理员等等。
不管面对多么复杂的网站项目，当我们开始接手时，都可以按照一定的规范和流程进行展开。
网站项目涉及的领域很多，狭义地讲包括了网页制作、美工设计、程序编码、系统及网络管理等专业技术，广义上又包含了企业管理、市场营销、心理学、广告学等更多领域的知识，在项目进行过程中还涉及到项目管理工具、文档和设计开发管理规范、开发及测试环境部署等特殊领域的问题，这对一个项目经理和小组来说是个严峻的考验。
网站设计发展经历了静态网站、交互式网站、商业应用、特殊应用的过程，随着企业对网络应用的理解和认识，对网站的功能要求越来越复杂，如今网站项目的设计已经不能再仅仅简单地利用静态Html文件来实现，与前几年网站设计由一两名网页设计师自由的创作相比，网站项目的设计和开发越来越像一个软件工程，越来越复杂，网站项目的设计和开发进入了需要强调流程和分工的时代，建立规范的、有效的、健壮的开发机制，才能适应用户不断变化的需要，“网站即软件！”，借鉴软件工程的思想并可从中寻找出网站项目管理的规律和方法。
网站项目管理分成以下六个阶段进行：
一) 需求分析及变更管理；
二) 项目模型及业务流程分析；
三) 系统分析及软件建模；
四) 界面设计、交互设计及程序开发；
五) 系统测试、部署和文档编写；
六) 客户培训、技术支持和售后服务。
在每个阶段，都必须建立“里程碑”，代表当前工作的阶段性成果，并以此作为进入下一阶段的标准，实现对项目质量的控制和管理。
第一阶段：需求分析及变更管理
假如病人上医院看病，医生需要“望、闻、问、切”，耐心仔细地了解完情况后，确定病因后才敢开药方。而我们在接手一个网站项目的时候，是否真的弄清楚客户的“病因”？又有多少回等到项目做到一半的时候才发现客户的需求根本不是这样的？！
项目本来是为满足客户需求目标而进行的，然而结果往往并非如此，因为：“客户也不知道自己的需求是什么！”在所有不成功的案例中，这句话也许是我们听的最多的。事实的确如此，这很令人沮丧。庆幸的是网站项目和建筑工程最大的区别在于：大楼建到一半的时候，不可能重新浇注地基，只好推倒重来，但网站项目却经常在页面制作、交互设计已经完成的时候还可以更改核心，甚至重新架构。
做好需求分析并建立变更管理机制是保证项目顺利完成的原始基础。
● 重要角色：项目经理，业务员，客户代表。
● 获取文档：通过与客户的讨论等各种渠道获得需求。
● 里 程 碑：《需求分析报告》
● 注意事项：
☆ 技术是为客户服务的，采用对用户最有效和经济的设计方法才是最好的，而非采用了最好的技术和配置就能设计出最好的方案。所谓最好的技术附带的潜台词往往就是高昂的成本、漫长的开发周期和潜在的不稳定，切忌将客户当作技术的试验田。
☆ 记住“需求是一定会变的”，同时不要害怕客户提需求。如果因为害怕看见大象的全貌而只摸摸大象的腿，怎么也不可能设计出客户所需要的系统。
☆ 锁定需求，学会放弃。对超出计划和目标的需求可以通过制定升级计划或二期工程，从当前的项目中转移出去，否则系统可能永远都在设计开发中，不断修改和增加，则始终没有可以发布的版本。
☆ 《需求分析报告》应得到客户和全体项目小组的共同认同，切忌公说公的理，婆说婆的理，只有所有成员都对目标有清晰一致的认知后，才能最大地提高工作效率。
● 技巧和方法：
☆ 仔细聆听，罗列客户的所有要求；
☆ 将需求进行分析，确认可操作的系统模型；
☆ 利用最自然的语言对系统进行描述，使每个开发人员不会产生歧义；
☆ 迅速确定系统的业务主角；
☆ 分析确定每个角色的权限及可操作的功能；
☆ 制作流程图和示意图将需求表现出来；
☆ 让客户参与到示意图的设计中，及时正确地反应出需求变更；
☆ 制作需求变更日志，保留升级版本，通过版本控制进行需求管理；
☆ 通过《需求分析报告》使每个参与人员看到共同的努力目标。
在这个阶段，我们通过需求分析对项目得到一个初步的认识，并通过编写《需求分析报告》得到一份客观的可参照的重要文档，这是个很好的起点。
客户的需求基本清楚了，但是客户并没有教我们该怎么做。当客户把球抛给了项目小组，看你如何把球接起来呢。
好吧，下面让我们继续……
第二阶段：项目模型及业务流程分析
我们需要业务流程分析人员将客户需求分解和优化，网络技术的应用所产生的电子流程工作方式既不能彻底更改传统的工作流程，也不是对传统工作流程的简单复制，而是需要对传统的工作流程进行合理的优化、改进和重组。
用户提出的需求通常是凌乱的、不完整的，甚至是不正确的，而且，更准确更精细的需求经常是在项目开发进行中才被挖掘发现的。缺乏经验的项目人员往往在接受任务后迫不及待地进行系统分析和开发，而不愿意多一点时间在和客户反复推敲项目需求和模型，开发过程中想当然地凭空为客户做很多假想，只能是费了九牛二虎之力之后吃力不讨好。
业务流程分析员重点需要协助客户将需求进行归纳分析，查找出所有的业务主角，确定业务主角后，将每个主角的相关活动及流程清晰地制定出来，最终设计出业务逻辑图。
为了使用户更好地理解系统设计方案，在时间条件许可的情况下，为系统制作用户界面原型图是非常有效的办法。在尚未进行开发之前，客户就能对今后要完成的系统能够直观地看到效果，并能根据需要进行调整，将大大提高项目成功的可能性，同时可减设计过程中的更改工作量。
● 重要角色：业务流程分析师，用户界面工程师，系统分析师。
● 获取文档：《需求分析报告》。
● 里 程 碑：《项目模型报告》、《用户界面原型》、《设计开发计划书》。
● 注意事项：
☆ 业务流程应符合客户偏好和习惯，以客户的环境和技能水平设计系统，切忌以项目小组的喜好随意设计；
☆ 请客户和用户模拟操作，找出盲点和分歧点，问题越早发现越容易处理，损失越小；
☆ 制定性能和功能指标，作为下一阶段测试工程师的工作依据。客户对功能的需求相对来说比较敏感和直观，但是对性能的需求很难提出具体的要求，这就需要系统分析师在这个阶段进行明确，并作为系统设计的依据之一。
● 技巧方法：
☆ 真正以用户为中心的设计，到客户的实际工作环境中观察和记录；
☆ 仔细查找各种业务主角，并描述不同主角的各种操作流程与步骤；
☆ 简化需求，将客户的需求归纳整理，抓住核心问题；
☆ 细化需求，针对核心问题，模拟用户角色，进一步确认流程和规范；
☆ 认真制定设计计划书，为下阶段的工作打好基础；
在这个阶段，我们将客户的需求转换成一个切实可行的设计方案，并为客户重新进行业务优化和组合，定出项目目标。
现在我们总算找到方向了，剩下的就是开始攻坚。向下一个阶段进发……
第三阶段：系统分析及软件建模
如果说前面两个阶段是设计大楼蓝图，那么，我们现在要开始打地基了。
系统分析和建模是项目开发的核心工作，对于一个有经验的开发人员来说，客户的需求有很多方式可以实现，但是不同的构架对系统今后的维护、升级和扩展具有天差地别的影响，一个不合理的结构用不了多久就得完全抛弃，重新开发。
如果眼光仅仅放在满足客户眼下的需求，当问题出现时再不断修补，头痛医头，脚痛医脚，甚至系统构架需要不断调整或重新设计，那么，很快就会陷入代码泥潭或坠入系统重复开发的无底深渊，项目完成时的成就感将被无止境的沮丧所代替。系统分析决定系统开发的成败，软件建模使系统开发走向成熟。
客户的需求一定会变，服务器和客户端环境也不断在变，考虑到不同的操作平台、不同的应用服务器、不同的数据库、不同的编程语言、不同的传输介质等等所带来的影响，系统分析员面临着艰难的选择，任何人都不可能掌握甚至说精通全部的技术，孰优孰劣，何去何从？我们仿佛走到了迷宫的中央，四处都是通道，却不知道哪里才是最快的出口。
“采用面向对象的开发模式并使用UML（统一建模语言）对系统建模！”，网站即软件，软件开发方法同样适用于网站项目开发，这给系统分析员指出了方向。
建模并不等同于程序编码，利用同样的UML模型可以生成不同语言的框架代码，而且可以通过反向生成，在编写代码过程中及时更新UML模型，这对系统分析员和项目管理人员来说是梦寐以求的。只要能够仔细地把握客户的需求，不断改进软件模型，那么采用什么样的语言开发已经成了次要，大量的需求积累和分析工作能在客户需求变化时得到高度的复用，即使系统采用新的语言重新开发，需要的也仅仅是编码部分的工作。
● 重要角色：系统分析师，构架设计师，数据库工程师，业务流程分析师。
● 获取文档：《需求分析报告》、《项目模型报告》、《用户界面原型》、《设计开发计划书》。
● 里 程 碑：《系统分析报告》、《设计及编码规范》、《系统模型工件》。
● 注意事项：
☆ 客户比较关注的是功能实现，但是不意味着客户不在乎系统的性能，成功的项目开发不会仅仅为表面上达到客户的需求而忽视系统的缺陷和瑕疵，网站项目同样需要有”精品”意识，树立一个品牌将为自己赢得更多的机会和更丰厚的回报。
☆ 客户的初期需求或许很简单，但开发人员不能不为客户潜在的巨大需求打下坚实的基础。
☆ 也许是因为项目周期过短、开发人员技能达不到等因素，在小型项目开发中难以采用进行规范的系统分析设计和建模，此时，应尽可能采用模块化设计、争取代码最大限度的复用。
● 技巧方法：
☆ 补充完善上一阶段可能欠缺的系统性能需求；
☆ 系统分析员需要站在全局出发，设计合理可行的系统方案；
☆ 在需求不明的情况下设计多种解决方案，供客户选择；
☆ 使用UML建模方式，将客户变化的需求映射到模型中，大大提高系统的扩展性和开发效率。
走到这一步，最难的骨头被啃了下来，当一个合理可靠的系统核心被设计出来时，客户会很诧异地问他为什么看不到一行的代码，但成熟的系统分析员已经成竹在胸。
下面让我们一起看看整个系统是如何构建起来的……
第四阶段：界面设计、交互设计及程序开发
在网站项目开发过程中，这个阶段也叫做构建阶段，是工作量最大、最艰苦、最难以控制的阶段。不管一座大楼蓝图设计得多宏伟，若没有管道工、泥瓦匠、水电工等各种工匠一砖一瓦地艰辛积累，密切协作，这座大楼始终是空中楼阁、海市蜃楼。
如果客户此时参观项目小组的工作，他可以看到：
● 美工设计师在根据用户界面原型进行美工设计，准确地将系统的形象进行定位；
● 交互设计师将美工的作品根据业务流程进行网页的编辑，为用户体贴地设计着交互程序；
● 程序员根据系统分析员分配的模块编写代码，一行行代码将系统浇注起来，一个个模块开始活起来；
● 测试工程师不断地检验着每个人的工作，单元测试、集成测试、负荷测试；
● 文档工程师开始收集、管理各种开发文档，每天检查更新记录和随时保证重要文档处于最新版本；
● 系统管理员为每个开发人员部署开发环境，并保证着最佳的工作状态；
项目小组在项目经理的带领下紧张而有序地进行着，全速开动。系统构建阶段，控制开发质量，保证进度是项目经理最关注的焦点，通过合理地分配资源和任务、建立小组成员间的有效沟通和采用相关管理软件控制能够有效地提高开发质量和进度。
● 重要角色：美工分析师、交互设计师、程序员、测试工程师、文档工程师。
● 获取文档：《需求分析报告》、《项目模型报告》、《用户界面原型》、《设计开发计划书》、《系统分析报告》、《设计及编码规范》、《系统模型工件》。
● 里 程 碑：《程序模块》、《开发文档》、《按客户需求开发完成的系统》。
● 注意事项：
☆ 人不是机器。当人成为项目开发流程中一个链条的时候，谁也保证不了人可以像机器一样精确而不知疲倦地工作，因此，项目管理人员要保障小组成员之间有效地沟通和协作。在划艇比赛中，不是人数越多就划的越快，当有人喊着号子，大家齐心协力协调行动时，这艘皮艇才能快速地向目标驶近。
☆ 测试是保证质量最直接最有效的方式，只有不断地测试、测试、再测试，才能使系统达到满意的质量。把BUG消除在萌芽状态是最理想的，遗憾的是老虎也有打盹的时候，何况人还会偷懒？系统构建进度最快的时候通常就是BUG产生最多的时候，只有进行反复交叉的测试才能确保质量。
☆ 交互设计师是系统和用户之间的桥梁，真正从用户的方便和习惯上下功夫，无论是一个弹出窗口还是站点的导航设计，甚至意外出错的提示等等，都需要精心设计，反复雕琢。交互设计如果能解除新用户对系统的恐惧，将会赢得意想不到的奇效。
☆ 程序员在编码过程中需要和系统分析员保持密切的协作和沟通，在规范的系统开发过程中，随意的个性化是极其有害的，任何一个自定义函数或字段都可能造成系统崩溃。构建一个系统好比将1000块砖头垒成一叠，程序员再往上加一个模块上去的时候都得想想摆正了没有，否则垒不到几十块的时候，系统就轰然倒塌了。系统就是这么一回事，一点也不好笑。
● 技巧方法：
☆ 利用项目管理工具对项目进行管理，无论是Project还是Starteam，或是其他工具都行；
☆ 建立文档管理规范，采用相应的文档管理工具对版本进行控制，PVCS或VSS都是可选择的工具；
☆ 创建团队的沟通环境和渠道，利用邮件或者论坛，开会或者递纸条，一切有利于交流的方式都可以，以保证协作成员之间迅速绕过障碍，奔向目标，人力资源经理的忠告是：沟通是提高团队凝聚力最有效的办法；
☆ 建立BUG汇报及处理系统。只要是软件，就一定有BUG，虽然这是个灰色笑话，但捕捉和消灭BUG是开发人员的天生义务，建立BUG管理系统可以争取使同样的错误不再犯第二次，当系统日渐完善的时候，那长长的BUG消灭清单就像工程师们的累累战果。
系统的全貌终于露了出来，客户的心这时候总算踏实了些。
不过这时候可不是结束的时候，在软件开发过程中，剩下的10%工作量都可能会拖延占用项目的90%时间。
第五阶段：系统测试、部署和文档编写
意外在网站项目管理中不是个新鲜词，最大的意外就是没有意外。
系统开发完成后，虽然经过了一次又一次的测试，但是在部署过程中仍然随时存在着意外。此时，最常听到开发人员说的一句话就是：“奇怪？！怎么在我这里好好的，放到别人那里就不行了？”
● 测试工程师根据《系统分析报告》和《项目模型报告》模拟测试环境，按照测试指标对系统的功能和性能进行全面的测试，编写测试报告，并通知项目成员进行修正。
● 部署工程师会同客户代表进行安排配置和调试，直至正式发布启用。
● 文档工程师撰写各种文档，包括系统白皮书，用户使用手册，管理员手册，客户培训文档，用户帮助等等，并总结设计和开发文档，进行项目总结。
中国有句古话：“善始善终。”项目小组协助客户快速部署并提供相应文档，不但能为售后服务节省大量精力和成本，同时能够大幅度提高客户满意度。
● 重要角色：测试工程师、文档工程师、部署工程师、客户代表。
● 获取文档：《需求分析报告》、《项目模型报告》、《用户界面原型》、《设计开发计划书》、《系统分析报告》。
● 里 程 碑：《测试报告》、《技术白皮书》、《用户使用手册》、《客户培训文档》、《用户帮助》。
● 注意事项：
☆ 测试不单包括功能测试，特别需要注意到性能测试和兼容性测试，应尽可能创建不同的模拟环境，取得完整的测试数据，针对测试结果对系统进行改进。
☆ 开发环境和部署环境不同造成实施过程出现“意外”一点也不意外，只有到客户能够良好地驾驭系统才算达成目标。
☆ 对照前两个阶段所做的《需求分析报告》和《项目模型报告》，检查目标是否都已经实现了？马虎的项目小组也许经过长时间的开发，已经忘记了最早的项目目标，而需求计划在开发过程中也许经过了大量改动，事实也许就是这样，等做完了，客户和你才找到了真正需要的东西。
● 技巧方法：
☆ 根据系统的特性，采用专用测试软件或编写测试工具，有助于提高测试的效率、准确性和完整性。
☆ 选择对系统完全陌生的典型用户模拟操作，能够发现大量系统缺陷。
☆ 无论是网页模板还是程序模块，养成在源代码中写注释的良好习惯，对开发过程中任务交接、纠错或今后二次开发都非常重要。
☆ 交给客户的文档越规范详尽，后期的成本越节省。
当系统终于如期运转的时候，该好好祝贺你了，系统开发完毕，对于项目小组来说接近了终点，但是对于客户来说才是一个起点，项目进入收尾阶段就是从客户培训开始的。
最后让我们来交钥匙去吧……
第六阶段：客户培训、技术支持和售后服务
开发一个老客户的成本远远低于拓展一个新客户，网站项目作为一个特殊产品，对客户的培训及技术支持尤其重要，而对于客户来说，一旦失去了技术保障，系统出现问题或需要扩展和升级的时候，将面临着怎样的困境？！
因此，为客户建立售后支持快速反应体系，不但可能会赢得更多的业务，也能消除客户的后顾之忧虑。至于客服支持的费用，总能找到双方可接受的条件。
● 重要角色：培训工程师、客户支持工程师、业务员。
● 获取文档：《需求分析报告》、《测试报告》、《技术白皮书》、《用户使用手册》、《客户培训文档》、《用户帮助》。
● 里 程 碑：《培训手册》、《客户服务记录》。
● 注意事项：
☆ 客户培训不仅仅是本期项目的一个终点，同时也是开启新项目的最好契机，认真做好培训文档，把接力棒顺利交接过去，今后会受益无穷。
☆ 技术支持和服务是网站项目非常重要的环节，它保持双方的联系和业务往来，合理控制服务成本，可以增加客户的忠诚度。
● 技巧方法：
☆ 电话、邮件、网站都是建立客户支持的良好手段，将相应文档发布在网站上对客户来说有时更加方便。
☆ 可按照客户情况的紧急度确定客户支持的反应时间和方式，使客户支持工作更有效率。
☆ 建立客户服务纪录，跟踪客户运行状况和变更记录，为下次的合作建立密切的联系。
历经千辛万苦到达这里的时候,好好庆祝吧,将成功的喜悦和经验仔细回味……
理想和现实总是有距离的，当我们真正开始实施网站项目的时候，却发现：
☆ 项目的周期太短，写代码还来不及，哪有那么多时间写文档！
☆ 人员有限，一个项目只有两三人干，经验又不足！
☆ 掌握项目管理软件和相应工具的学习成本太高，一个临时的队伍没有培训时间！
☆ 项目小组分散在各地，无法集中，进度质量控制不住！
☆ 没有人会测试方法，没有人会建模，没有人会……怎么办？
对网站项目来说，存在着各种各样的问题，本文探讨的是一般方法，不是形式，其目标是为将网站项目分阶段、分角色进行有效地组织和管理，从而完成网站项目的要求。虽说不管黑猫白猫，能抓老鼠的猫就是好猫，但毕竟会放捕鼠夹的猫更可能会成为一只最出色的猫。
最后让我们来看看网站项目管理成功和失败的典型特征：
失败网站项目总有这样那样的原因：
● 始终弄不清楚客户的需求，丢三拉四，尤其对变更无法管理；
● 总期望奇迹发生，有英雄出世去完成不可能的任务；
● 谁也说不清楚究竟哪一天能把项目做的完；
● 没有测试报告和性能分析；
● 程序员成为项目的主宰，万一程序员走了，项目就无法进行下去；
如果你是一家中小企业，你恰好要建一个基于工作的网站，如果你真正想将工作架在互联网上，而不是一时新奇，那么，你仔细读读这篇文章，能消灭很多错误的观念。读完本文，如果你觉得做一个商业网站太麻烦了，你不做了，那也是一种收获。现在，很多“商业”网站形同虚设，最重要一个原因，建立者建立之时，就根本没有将它当作商业网站做。
1998年，互联网火了，新鲜出炉的网虫在网上发邮件、上BBS，立刻成了新潮一派；
1999年，个人主页火了，啃几行HTML、扒弄点图片，捣鼓出个人站点就成“大虾”了；
2000年，Dotcom火了，门户、聊天、游戏、社区花样百出，混个斑竹网管当当，顿时风光无限；
2001年，网络应用火了，买卖东西、拉拉客户、管管财务，有点技术的家伙开始牛啦；
2002年，企业应用解决方案，.net平台看起来又要火了…
A镜头：你被老板安排负责信息化建设，是不是像老虎咬刺猬一样无从下口？
B镜头：你希望请别人设计一个网站，他们是不是会敷衍了事，蒙你一把？
C镜头：有一个诱人的项目摆在面前，到最后是不是搞得一团糟，反而倒贴老本？
到底该怎么办？？？
从现在开始，一起出发去找我们的新奶酪吧。这个奶酪的名字叫“网站项目管理”。
网站项目：即以Web服务器为主体、浏览器为客户端作为基本架构的项目。这样的架构项目中包含Web 服务器、浏览器和网络三个关键主体。网站项目可能是一个网站，也可能是各种Web应用程序，例如网上商店、虚拟邮局、网络办公管理系统、客户关系管理系统等等。
网站项目管理：是围绕着网站项目运用知识、技术、技能、工具和方法进行组织管理。其共同特征是：
● 管理由人实现，而非机器；
● 项目具有时间周期，包括启动时间和结束时间；
● 项目受资源限制，包括人员、资金、场地、设备等；
● 需要计划、实施和控制；
文章开头的A镜头、B镜头和C镜头，都可以纳入网站项目管理的范畴。以下是网站项目管理的几个重要概念：
（1）角色：是指项目人员在管理过程中，在特定环境下参与设计的行为代表。
例如项目经理、数据库工程师、界面设计师、文档工程师等等。对于网站项目管理，最关键的角色是：项目经理，业务流程分析师，用户界面工程师，系统分析员，编码人员（程序员），质量控制工程师。根据项目的规模和开发的深度，由项目经理进行角色划分。假如严格细分，一个大型项目的角色可能达到50个以上，以确保每个细节都有专业的人员进行负责和管理。
需要注意的是：角色不等于人。一个人可能充当多个角色，一个角色也可能由许多人组成。比如既是系统分析员，也是测试工程师，或者既是用户界面工程师，又担任文档编写和管理，一个项目管理小组可能只有三五个人，也可能三五百号人，项目组可大可小，但是项目管理流程需要细致的角色分工。
（2） 流程：在项目过程中执行的工作序列。
每个角色在流程中获得和输出相应的工作结果。例如在需求分析流程中，需要有客户代表、业务员、业务流程分析师、用户界面工程师等角色参与，业务员从客户代表那里获得需求，并形成需求报告；业务流程分析员从业务员那里获得需求报告，分析生成项目模型报告；界面工程师得到项目模型后设计制作相应的模板和用户界面原型，最终由客户代表确认。
（3）业务主角：指与系统交互的各种不同角色。
例如一个网上商店系统，业务主角有普通访客、下定单会员、管理会员及定单的业务员、网站的商品信息发布人员、商品供应厂家的业务管理人员，物流配送管理员等等。
不管面对多么复杂的网站项目，当我们开始接手时，都可以按照一定的规范和流程进行展开。
网站项目涉及的领域很多，狭义地讲包括了网页制作、美工设计、程序编码、系统及网络管理等专业技术，广义上又包含了企业管理、市场营销、心理学、广告学等更多领域的知识，在项目进行过程中还涉及到项目管理工具、文档和设计开发管理规范、开发及测试环境部署等特殊领域的问题，这对一个项目经理和小组来说是个严峻的考验。
网站设计发展经历了静态网站、交互式网站、商业应用、特殊应用的过程，随着企业对网络应用的理解和认识，对网站的功能要求越来越复杂，如今网站项目的设计已经不能再仅仅简单地利用静态Html文件来实现，与前几年网站设计由一两名网页设计师自由的创作相比，网站项目的设计和开发越来越像一个软件工程，越来越复杂，网站项目的设计和开发进入了需要强调流程和分工的时代，建立规范的、有效的、健壮的开发机制，才能适应用户不断变化的需要，“网站即软件！”，借鉴软件工程的思想并可从中寻找出网站项目管理的规律和方法。
网站项目管理分成以下六个阶段进行：
一) 需求分析及变更管理；
二) 项目模型及业务流程分析；
三) 系统分析及软件建模；
四) 界面设计、交互设计及程序开发；
五) 系统测试、部署和文档编写；
六) 客户培训、技术支持和售后服务。
在每个阶段，都必须建立“里程碑”，代表当前工作的阶段性成果，并以此作为进入下一阶段的标准，实现对项目质量的控制和管理。
第一阶段：需求分析及变更管理
假如病人上医院看病，医生需要“望、闻、问、切”，耐心仔细地了解完情况后，确定病因后才敢开药方。而我们在接手一个网站项目的时候，是否真的弄清楚客户的“病因”？又有多少回等到项目做到一半的时候才发现客户的需求根本不是这样的？！
项目本来是为满足客户需求目标而进行的，然而结果往往并非如此，因为：“客户也不知道自己的需求是什么！”在所有不成功的案例中，这句话也许是我们听的最多的。事实的确如此，这很令人沮丧。庆幸的是网站项目和建筑工程最大的区别在于：大楼建到一半的时候，不可能重新浇注地基，只好推倒重来，但网站项目却经常在页面制作、交互设计已经完成的时候还可以更改核心，甚至重新架构。
做好需求分析并建立变更管理机制是保证项目顺利完成的原始基础。
● 重要角色：项目经理，业务员，客户代表。
● 获取文档：通过与客户的讨论等各种渠道获得需求。
● 里 程 碑：《需求分析报告》
● 注意事项：
☆ 技术是为客户服务的，采用对用户最有效和经济的设计方法才是最好的，而非采用了最好的技术和配置就能设计出最好的方案。所谓最好的技术附带的潜台词往往就是高昂的成本、漫长的开发周期和潜在的不稳定，切忌将客户当作技术的试验田。
☆ 记住“需求是一定会变的”，同时不要害怕客户提需求。如果因为害怕看见大象的全貌而只摸摸大象的腿，怎么也不可能设计出客户所需要的系统。
☆ 锁定需求，学会放弃。对超出计划和目标的需求可以通过制定升级计划或二期工程，从当前的项目中转移出去，否则系统可能永远都在设计开发中，不断修改和增加，则始终没有可以发布的版本。
☆ 《需求分析报告》应得到客户和全体项目小组的共同认同，切忌公说公的理，婆说婆的理，只有所有成员都对目标有清晰一致的认知后，才能最大地提高工作效率。
● 技巧和方法：
☆ 仔细聆听，罗列客户的所有要求；
☆ 将需求进行分析，确认可操作的系统模型；
☆ 利用最自然的语言对系统进行描述，使每个开发人员不会产生歧义；
☆ 迅速确定系统的业务主角；
☆ 分析确定每个角色的权限及可操作的功能；
☆ 制作流程图和示意图将需求表现出来；
☆ 让客户参与到示意图的设计中，及时正确地反应出需求变更；
☆ 制作需求变更日志，保留升级版本，通过版本控制进行需求管理；
☆ 通过《需求分析报告》使每个参与人员看到共同的努力目标。
在这个阶段，我们通过需求分析对项目得到一个初步的认识，并通过编写《需求分析报告》得到一份客观的可参照的重要文档，这是个很好的起点。
客户的需求基本清楚了，但是客户并没有教我们该怎么做。当客户把球抛给了项目小组，看你如何把球接起来呢。
好吧，下面让我们继续……
第二阶段：项目模型及业务流程分析
我们需要业务流程分析人员将客户需求分解和优化，网络技术的应用所产生的电子流程工作方式既不能彻底更改传统的工作流程，也不是对传统工作流程的简单复制，而是需要对传统的工作流程进行合理的优化、改进和重组。
用户提出的需求通常是凌乱的、不完整的，甚至是不正确的，而且，更准确更精细的需求经常是在项目开发进行中才被挖掘发现的。缺乏经验的项目人员往往在接受任务后迫不及待地进行系统分析和开发，而不愿意多一点时间在和客户反复推敲项目需求和模型，开发过程中想当然地凭空为客户做很多假想，只能是费了九牛二虎之力之后吃力不讨好。
业务流程分析员重点需要协助客户将需求进行归纳分析，查找出所有的业务主角，确定业务主角后，将每个主角的相关活动及流程清晰地制定出来，最终设计出业务逻辑图。
为了使用户更好地理解系统设计方案，在时间条件许可的情况下，为系统制作用户界面原型图是非常有效的办法。在尚未进行开发之前，客户就能对今后要完成的系统能够直观地看到效果，并能根据需要进行调整，将大大提高项目成功的可能性，同时可减设计过程中的更改工作量。
● 重要角色：业务流程分析师，用户界面工程师，系统分析师。
● 获取文档：《需求分析报告》。
● 里 程 碑：《项目模型报告》、《用户界面原型》、《设计开发计划书》。
● 注意事项：
☆ 业务流程应符合客户偏好和习惯，以客户的环境和技能水平设计系统，切忌以项目小组的喜好随意设计；
☆ 请客户和用户模拟操作，找出盲点和分歧点，问题越早发现越容易处理，损失越小；
☆ 制定性能和功能指标，作为下一阶段测试工程师的工作依据。客户对功能的需求相对来说比较敏感和直观，但是对性能的需求很难提出具体的要求，这就需要系统分析师在这个阶段进行明确，并作为系统设计的依据之一。
● 技巧方法：
☆ 真正以用户为中心的设计，到客户的实际工作环境中观察和记录；
☆ 仔细查找各种业务主角，并描述不同主角的各种操作流程与步骤；
☆ 简化需求，将客户的需求归纳整理，抓住核心问题；
☆ 细化需求，针对核心问题，模拟用户角色，进一步确认流程和规范；
☆ 认真制定设计计划书，为下阶段的工作打好基础；
在这个阶段，我们将客户的需求转换成一个切实可行的设计方案，并为客户重新进行业务优化和组合，定出项目目标。
现在我们总算找到方向了，剩下的就是开始攻坚。向下一个阶段进发……
第三阶段：系统分析及软件建模
如果说前面两个阶段是设计大楼蓝图，那么，我们现在要开始打地基了。
系统分析和建模是项目开发的核心工作，对于一个有经验的开发人员来说，客户的需求有很多方式可以实现，但是不同的构架对系统今后的维护、升级和扩展具有天差地别的影响，一个不合理的结构用不了多久就得完全抛弃，重新开发。
如果眼光仅仅放在满足客户眼下的需求，当问题出现时再不断修补，头痛医头，脚痛医脚，甚至系统构架需要不断调整或重新设计，那么，很快就会陷入代码泥潭或坠入系统重复开发的无底深渊，项目完成时的成就感将被无止境的沮丧所代替。系统分析决定系统开发的成败，软件建模使系统开发走向成熟。
客户的需求一定会变，服务器和客户端环境也不断在变，考虑到不同的操作平台、不同的应用服务器、不同的数据库、不同的编程语言、不同的传输介质等等所带来的影响，系统分析员面临着艰难的选择，任何人都不可能掌握甚至说精通全部的技术，孰优孰劣，何去何从？我们仿佛走到了迷宫的中央，四处都是通道，却不知道哪里才是最快的出口。
“采用面向对象的开发模式并使用UML（统一建模语言）对系统建模！”，网站即软件，软件开发方法同样适用于网站项目开发，这给系统分析员指出了方向。
建模并不等同于程序编码，利用同样的UML模型可以生成不同语言的框架代码，而且可以通过反向生成，在编写代码过程中及时更新UML模型，这对系统分析员和项目管理人员来说是梦寐以求的。只要能够仔细地把握客户的需求，不断改进软件模型，那么采用什么样的语言开发已经成了次要，大量的需求积累和分析工作能在客户需求变化时得到高度的复用，即使系统采用新的语言重新开发，需要的也仅仅是编码部分的工作。
● 重要角色：系统分析师，构架设计师，数据库工程师，业务流程分析师。
● 获取文档：《需求分析报告》、《项目模型报告》、《用户界面原型》、《设计开发计划书》。
● 里 程 碑：《系统分析报告》、《设计及编码规范》、《系统模型工件》。
● 注意事项：
☆ 客户比较关注的是功能实现，但是不意味着客户不在乎系统的性能，成功的项目开发不会仅仅为表面上达到客户的需求而忽视系统的缺陷和瑕疵，网站项目同样需要有”精品”意识，树立一个品牌将为自己赢得更多的机会和更丰厚的回报。
☆ 客户的初期需求或许很简单，但开发人员不能不为客户潜在的巨大需求打下坚实的基础。
☆ 也许是因为项目周期过短、开发人员技能达不到等因素，在小型项目开发中难以采用进行规范的系统分析设计和建模，此时，应尽可能采用模块化设计、争取代码最大限度的复用。
● 技巧方法：
☆ 补充完善上一阶段可能欠缺的系统性能需求；
☆ 系统分析员需要站在全局出发，设计合理可行的系统方案；
☆ 在需求不明的情况下设计多种解决方案，供客户选择；
☆ 使用UML建模方式，将客户变化的需求映射到模型中，大大提高系统的扩展性和开发效率。
走到这一步，最难的骨头被啃了下来，当一个合理可靠的系统核心被设计出来时，客户会很诧异地问他为什么看不到一行的代码，但成熟的系统分析员已经成竹在胸。
下面让我们一起看看整个系统是如何构建起来的……
第四阶段：界面设计、交互设计及程序开发
在网站项目开发过程中，这个阶段也叫做构建阶段，是工作量最大、最艰苦、最难以控制的阶段。不管一座大楼蓝图设计得多宏伟，若没有管道工、泥瓦匠、水电工等各种工匠一砖一瓦地艰辛积累，密切协作，这座大楼始终是空中楼阁、海市蜃楼。
如果客户此时参观项目小组的工作，他可以看到：
● 美工设计师在根据用户界面原型进行美工设计，准确地将系统的形象进行定位；
● 交互设计师将美工的作品根据业务流程进行网页的编辑，为用户体贴地设计着交互程序；
● 程序员根据系统分析员分配的模块编写代码，一行行代码将系统浇注起来，一个个模块开始活起来；
● 测试工程师不断地检验着每个人的工作，单元测试、集成测试、负荷测试；
● 文档工程师开始收集、管理各种开发文档，每天检查更新记录和随时保证重要文档处于最新版本；
● 系统管理员为每个开发人员部署开发环境，并保证着最佳的工作状态；
项目小组在项目经理的带领下紧张而有序地进行着，全速开动。系统构建阶段，控制开发质量，保证进度是项目经理最关注的焦点，通过合理地分配资源和任务、建立小组成员间的有效沟通和采用相关管理软件控制能够有效地提高开发质量和进度。
● 重要角色：美工分析师、交互设计师、程序员、测试工程师、文档工程师。
● 获取文档：《需求分析报告》、《项目模型报告》、《用户界面原型》、《设计开发计划书》、《系统分析报告》、《设计及编码规范》、《系统模型工件》。
● 里 程 碑：《程序模块》、《开发文档》、《按客户需求开发完成的系统》。
● 注意事项：
☆ 人不是机器。当人成为项目开发流程中一个链条的时候，谁也保证不了人可以像机器一样精确而不知疲倦地工作，因此，项目管理人员要保障小组成员之间有效地沟通和协作。在划艇比赛中，不是人数越多就划的越快，当有人喊着号子，大家齐心协力协调行动时，这艘皮艇才能快速地向目标驶近。
☆ 测试是保证质量最直接最有效的方式，只有不断地测试、测试、再测试，才能使系统达到满意的质量。把BUG消除在萌芽状态是最理想的，遗憾的是老虎也有打盹的时候，何况人还会偷懒？系统构建进度最快的时候通常就是BUG产生最多的时候，只有进行反复交叉的测试才能确保质量。
☆ 交互设计师是系统和用户之间的桥梁，真正从用户的方便和习惯上下功夫，无论是一个弹出窗口还是站点的导航设计，甚至意外出错的提示等等，都需要精心设计，反复雕琢。交互设计如果能解除新用户对系统的恐惧，将会赢得意想不到的奇效。
☆ 程序员在编码过程中需要和系统分析员保持密切的协作和沟通，在规范的系统开发过程中，随意的个性化是极其有害的，任何一个自定义函数或字段都可能造成系统崩溃。构建一个系统好比将1000块砖头垒成一叠，程序员再往上加一个模块上去的时候都得想想摆正了没有，否则垒不到几十块的时候，系统就轰然倒塌了。系统就是这么一回事，一点也不好笑。
● 技巧方法：
☆ 利用项目管理工具对项目进行管理，无论是Project还是Starteam，或是其他工具都行；
☆ 建立文档管理规范，采用相应的文档管理工具对版本进行控制，PVCS或VSS都是可选择的工具；
☆ 创建团队的沟通环境和渠道，利用邮件或者论坛，开会或者递纸条，一切有利于交流的方式都可以，以保证协作成员之间迅速绕过障碍，奔向目标，人力资源经理的忠告是：沟通是提高团队凝聚力最有效的办法；
☆ 建立BUG汇报及处理系统。只要是软件，就一定有BUG，虽然这是个灰色笑话，但捕捉和消灭BUG是开发人员的天生义务，建立BUG管理系统可以争取使同样的错误不再犯第二次，当系统日渐完善的时候，那长长的BUG消灭清单就像工程师们的累累战果。
系统的全貌终于露了出来，客户的心这时候总算踏实了些。
不过这时候可不是结束的时候，在软件开发过程中，剩下的10%工作量都可能会拖延占用项目的90%时间。
第五阶段：系统测试、部署和文档编写
意外在网站项目管理中不是个新鲜词，最大的意外就是没有意外。
系统开发完成后，虽然经过了一次又一次的测试，但是在部署过程中仍然随时存在着意外。此时，最常听到开发人员说的一句话就是：“奇怪？！怎么在我这里好好的，放到别人那里就不行了？”
● 测试工程师根据《系统分析报告》和《项目模型报告》模拟测试环境，按照测试指标对系统的功能和性能进行全面的测试，编写测试报告，并通知项目成员进行修正。
● 部署工程师会同客户代表进行安排配置和调试，直至正式发布启用。
● 文档工程师撰写各种文档，包括系统白皮书，用户使用手册，管理员手册，客户培训文档，用户帮助等等，并总结设计和开发文档，进行项目总结。
中国有句古话：“善始善终。”项目小组协助客户快速部署并提供相应文档，不但能为售后服务节省大量精力和成本，同时能够大幅度提高客户满意度。
● 重要角色：测试工程师、文档工程师、部署工程师、客户代表。
● 获取文档：《需求分析报告》、《项目模型报告》、《用户界面原型》、《设计开发计划书》、《系统分析报告》。
● 里 程 碑：《测试报告》、《技术白皮书》、《用户使用手册》、《客户培训文档》、《用户帮助》。
● 注意事项：
☆ 测试不单包括功能测试，特别需要注意到性能测试和兼容性测试，应尽可能创建不同的模拟环境，取得完整的测试数据，针对测试结果对系统进行改进。
☆ 开发环境和部署环境不同造成实施过程出现“意外”一点也不意外，只有到客户能够良好地驾驭系统才算达成目标。
☆ 对照前两个阶段所做的《需求分析报告》和《项目模型报告》，检查目标是否都已经实现了？马虎的项目小组也许经过长时间的开发，已经忘记了最早的项目目标，而需求计划在开发过程中也许经过了大量改动，事实也许就是这样，等做完了，客户和你才找到了真正需要的东西。
● 技巧方法：
☆ 根据系统的特性，采用专用测试软件或编写测试工具，有助于提高测试的效率、准确性和完整性。
☆ 选择对系统完全陌生的典型用户模拟操作，能够发现大量系统缺陷。
☆ 无论是网页模板还是程序模块，养成在源代码中写注释的良好习惯，对开发过程中任务交接、纠错或今后二次开发都非常重要。
☆ 交给客户的文档越规范详尽，后期的成本越节省。
当系统终于如期运转的时候，该好好祝贺你了，系统开发完毕，对于项目小组来说接近了终点，但是对于客户来说才是一个起点，项目进入收尾阶段就是从客户培训开始的。
最后让我们来交钥匙去吧……
第六阶段：客户培训、技术支持和售后服务
开发一个老客户的成本远远低于拓展一个新客户，网站项目作为一个特殊产品，对客户的培训及技术支持尤其重要，而对于客户来说，一旦失去了技术保障，系统出现问题或需要扩展和升级的时候，将面临着怎样的困境？！
因此，为客户建立售后支持快速反应体系，不但可能会赢得更多的业务，也能消除客户的后顾之忧虑。至于客服支持的费用，总能找到双方可接受的条件。
● 重要角色：培训工程师、客户支持工程师、业务员。
● 获取文档：《需求分析报告》、《测试报告》、《技术白皮书》、《用户使用手册》、《客户培训文档》、《用户帮助》。
● 里 程 碑：《培训手册》、《客户服务记录》。
● 注意事项：
☆ 客户培训不仅仅是本期项目的一个终点，同时也是开启新项目的最好契机，认真做好培训文档，把接力棒顺利交接过去，今后会受益无穷。
☆ 技术支持和服务是网站项目非常重要的环节，它保持双方的联系和业务往来，合理控制服务成本，可以增加客户的忠诚度。
● 技巧方法：
☆ 电话、邮件、网站都是建立客户支持的良好手段，将相应文档发布在网站上对客户来说有时更加方便。
☆ 可按照客户情况的紧急度确定客户支持的反应时间和方式，使客户支持工作更有效率。
☆ 建立客户服务纪录，跟踪客户运行状况和变更记录，为下次的合作建立密切的联系。
历经千辛万苦到达这里的时候,好好庆祝吧,将成功的喜悦和经验仔细回味……
理想和现实总是有距离的，当我们真正开始实施网站项目的时候，却发现：
☆ 项目的周期太短，写代码还来不及，哪有那么多时间写文档！
☆ 人员有限，一个项目只有两三人干，经验又不足！
☆ 掌握项目管理软件和相应工具的学习成本太高，一个临时的队伍没有培训时间！
☆ 项目小组分散在各地，无法集中，进度质量控制不住！
☆ 没有人会测试方法，没有人会建模，没有人会……怎么办？
对网站项目来说，存在着各种各样的问题，本文探讨的是一般方法，不是形式，其目标是为将网站项目分阶段、分角色进行有效地组织和管理，从而完成网站项目的要求。虽说不管黑猫白猫，能抓老鼠的猫就是好猫，但毕竟会放捕鼠夹的猫更可能会成为一只最出色的猫。
最后让我们来看看网站项目管理成功和失败的典型特征：
失败网站项目总有这样那样的原因：
● 始终弄不清楚客户的需求，丢三拉四，尤其对变更无法管理；
● 总期望奇迹发生，有英雄出世去完成不可能的任务；
● 谁也说不清楚究竟哪一天能把项目做的完；
● 没有测试报告和性能分析；
● 程序员成为项目的主宰，万一程序员走了，项目就无法进行下去；
