文件与记录的区别 文件和记录的关系

　　网站项目管理（WPM）的含义为Web-based Project Management文件与记录的区别，即以Web 应用程序为主要表现方式的架构来进行的项目设计及管理，这样的架构中包含了浏览器、网络和Web 服务器等关键主体，主要体现在网站设计、以浏览器为客户端的Web应用程序开发（例如信息类网站、网上商店、虚拟邮局、客户关系管理。）等项目管理中。

　　在本文中，笔者将网站项目管理（WPM）与软件工程的统一过程管理（RUP）进行参照比较，并结合实际工作经验，力求将网站工程管理（WPM）的角色、分工、流程进行完整的阐述，使网站项目管理逐渐走向规范化。

　　按照笔者的经验，网站项目管理可以分为以下六个阶段进行控制文件与记录的区别：

　　1. 需求分析及变更管理

　　2. 项目模型及业务流程分析

　　3. 系统分析及软件建模

　　4. 界面设计、交互设计及程序开发

　　5. 系统测试和文档编写

　　6. 客户培训、技术支持和售后服务

　　需要说明的是，这些阶段虽然具有一定的延续性，但是并非完全隔断的，例如需求变更管理和测试工作、文档编写都是贯穿整个项目过程的，许多工作时交叉进行或同时进行的。 网络技术的应用所产生的电子流程工作方式既不能彻底更改传统的工作流程，也不是对传统工作流程的简单复制，而需要对传统的工作流程进行合理的优化、改进和重组。

　　本章包括以下内容：

　　一. 编写项目模型文档，使所有人都一目了然

　　二. 业务流程分析员进行流程设计

　　三. 界面工程师设计用户界面原型

　　四. 以用户为中心的设计思考

　　五. 制作设计计划书

　　六. 总结

　　一. 编写项目模型文档，使所有人都一目了然

　　为什么要制作项目模型文档？

　　通常用户提出的需求是凌乱的，不完整的，甚至是不正确的，而且更细致的需求经常是在项目开发进行中才被挖掘发现的，这对于开发人员来说是个极其困扰的问题。那么，在进行需求分析后制作项目模型文档，能在项目进入开发前，双方对即将要开始完成的项目的结果有个共同的认识，并提早暴露可能出现的需求变更，那么将大大提高开发的效率和质量。 缺乏经验的项目人员往往在接受任务后迫不及待地进行系统分析和开发，而不愿意多一点时间在和客户反复推敲项目需求和模型，开发过程中想当然地凭空为客户做了很多假想，费了九牛二虎之力却吃力不讨好，可想而知，在不知道终点在哪里的马拉松比赛中，你会跑到哪里去？！ 因此在确认了客户的初步需求以后，业务人员应该进行项目模型的设计描述。

　　首先，我们要定义一下词汇表，并非每个客户或者项目小组成员都能够明白“用户”、“角色”、“用例”之间的差别，也不见得都能很好地理解“通道”、“前台”、“后台”到底是什么含义，为了让项目模型文档使每个浏览者正确地理解，定义词汇表是非常需要的，尤其是面对传统行业初次进行信息化设计的用户。

　　模型描述采用最自然的语言进行描述，这份文档是对需求分析报告的进一步描述。使得客户代表、项目经理、开发人员对即将展开的项目通过项目模型的描述产生最直观的印象，并针对关键的问题进行讨论并达成统一认识，比如功能要求、性能指标、运行环境、投资规模等等。

　　二. 业务流程分析员进行流程设计

　　业务流程分析员的人员应该善于简化工作，担任此角色的人员中必须要有具备广博的专业领域知识，并且具有良好的沟通技巧。

　　业务分析人员重点需要协助客户将需求进行归纳分析，查找出所有的业务主角，确定业务主角后，每个主角的相关活动及流程应清晰地制定出来，最终设计出逻辑视图、用户界面示意图。比如一个微页网站目录系统，除了系统管理员、业务经理、业务员、物流配送员、客户服务人员等角色以外，可能还存在外部协作单位的不同角色，比如供应商、分销商、广告客户，还有购买用户，甚至再细分为普通消费用户、VIP消费用户、集团消费用户等等，每一类角色参与系统活动时的入口和流程都有所不同，通过逻辑图和示意图，业务流程分析员将系统的机构简要明确地进行描述。

　　在进行业务流程设计，需要注意以下事项：

　　* 调查用户网络环境和配置，使架构设计师能够制定合理可行的系统架构；

　　* 调查用户偏好和技能水平，这将直接影响到项目开发的深度和用户界面的设计；

　　“虽然开发人员和管理人员很容易自认为文件与记录的区别他们了解用户需要，但实际情况常常不是这样。人们往往关注于用户应该如何执行任务，而不是用户偏好如何执行。多数情况下，偏好问题不仅仅是简单地认为已掌握了用户需要，尽管这本身就很值得研究。偏好还要由经验、能力和使用环境决定。”

　　* 预测并制定系统的性能指标，为测试人员编写测试计划提供依据。

　　许多项目设计中比较重视功能的实现，测试阶段看似满足了客户的需求，但一旦投入使用的时候，便会发现性能上面临着一个个瓶颈。客户由于对专业知识的了解程度有限，也往往忽略了这方面要求，因此为了避免日后陷入纠纷，事先预测并制定性能指标是非常重要的。

　　三. 界面工程师创建用户界面原型

　　为了在实际系统开发投入之前，创建用户界面模型是非常重要的，开发原型的成本远远低于实际开发的成本，在项目初期，创建完整的用户界面揭示和测试系统的所有功能和可用性，并能够使客户代表参与讨论及修改，可以大大提高项目的成功几率。

　　创建正确可行的原型以后，系统分析、设计及代码的编写都必须遵照原型进行，确保构建的系统是正确的，测试人员和客户也能够在开发过程中即实时地参与检查，可以有效地保障了项目的质量。

　　根据业务流程分析员所提供的流程分析逻辑图及示意图，淘站目录界面设计工程师开始设计制作用户界面原型，目前这个阶段，对于界面设计人员来说还没有进入精细设计的阶段，所以最重要的是将业务流程完整地表现出来，并和客户就设计风格，设计规范进行确认和定义。

　　界面工程师在充分理解客户需求和所有的业务流程之后，利用合理的布局设计用户界面。比如网站的首页风格、首页需要显示的各个元素、导航的分类和表现方法、各类业务角色的入口等等。

　　在此需要注意的是，用户界面不仅仅是网站访问者所浏览的界面，也包括了特殊用户、管理员、业务伙伴等不同的用户界面，甚至还有提示界面、警告界面、出错界面等等，设计完整的用户界面原型不仅能够使客户及测试人员更容易明确需求，也对项目的质量起到不可忽视的作用。

　　四. 以用户为中心的设计思考

　　无论项目设计开发人员的水平多么精尖，毕竟不是系统的最终用户，最大限度地满足客户的需要才是关键，系统设计人员往往口头上挂着以用户为中心的口号，而实际上工作中又在大量地假想，或是出于懒惰或是出于条件限制，对于将来使用系统的不同用户来说都可能产生意想不到的障碍。

　　真正做到以用户为中心，就要先放弃沉淀在脑子里的经验和想象，到客户工作的地方去、观察记录客户如何工作、然后与客户谈论文件与记录的区别他们的工作。

　　在团队拓展训练中有一项叫做“盲人方阵”的课程，可以想象一群什么也看不见的人如何把一根长绳子拉成正方形景象吗？目中无人的人会懂得倾听和服从吗？我们不能假设用户到底是个健全人还是盲人，也不能假想用户应该会怎么做不该会怎么做，只有去仔细观察和沟通，才能制定出真正符合用户需要的计划。

　　有专家提出：开发人员应决定用户的组成，并让用户尽可能早地涉入，并提出了几种熟悉用户、他们的任务以及需求的方法：

　　* 与用户交谈

　　* 到办公地点拜访用户

　　* 观察用户工作

　　* 将用户工作录像

　　* 了解工作组织

　　* 自我尝试

　　* 使用户在工作时边想边说

　　* 让用户参与设计

　　* 在设计小组中包括专家级用户

　　* 执行任务分析

　　* 利用调查和问卷

　　* 制定可测试的目标

　　在有可能的情况，在需求和流程设计中努力做到精确、客观和细致，不但能保证系统开发的质量和成熟度，也会使你得到客户高度的满意和信任，为今后更多的业务合作敞开大门。

　　五. 制作设计计划书

　　到了这个阶段，可以说掌握了客户的需求并对计划实施的系统开发有了清楚地认识，与客户之间达成了共识，那么在进入下个阶段的工作时，制作设计计划书是非常必要的。

　　设计计划书是全面描述整个系统的全貌，作为系统分析、测试人员工作的基础，同时也是客户验收的标准，作为业务合同的内容之一，因此，应该仔细谨慎地撰写设计计划书。

　　根据项目的不同，设计计划书的内容或许有所不同，以下笔者提供一份样本供大家参考，该份样本基本涵盖了需要在计划书中进行确认和描述的核心要素。

　　六. 总结

　　在本阶段的工作过程中，核心的任务是通过上个阶段的需求分析，进行项目模型设计和业务流程分析，并制作用户界面原型得到用户的确认，最终完成双方认可的《设计计划书》，作为下一阶段系统设计和软件建模的依据。

　　如何高质量地完成业务流程分析阶段的工作，笔者总结的经验如下：

　　* 真正以用户为中心的设计，到客户的实际工作环境中观察和记录；

　　* 仔细查找各种业务主角，并表述不同主角的各种操作流程步骤；

　　* 简化需求，将客户的需求归纳整理，抓住核心问题；

　　* 细化需求，针对核心问题，模拟用户角色，进一步确认流程和规范；

　　* 认真制定设计计划书，为下阶段的工作打好基础。

　　欢迎关注“站长网志”，一起分享站长资源，探讨网站运营推广之道！