如何进行需求调研

1. 如何进行需求调研

力，才能真正体现出软件的价值。
4.编写用户需求说明书
需求调研的步骤
需求分析员对收集到的所有需求信息进行分类整理，消除错误，归纳与总结共性的用户需求，然后形成文档，编写《用户需求说明书》。对于《用户需求说明书》要和客户以及相关的行业专家进行共同评审。以前整理的需求记录可以作为附件整理在《用户需求说明书》之后。
《用户需求说明书》与《产品需求规格说明书》的主要区别与联系是：
（1）前者主要采用自然语言（和应用域术语）来表达用户需求，其内容相对于后者而言比较粗略，不够详细。
（2）后者是前者的细化，更多地采用计算机语言和图形符号来刻画需求，产品需求是软件系统设计的直接依据。
（3）两者之间可能并不存在一一影射关系，因为软件开发商会根据产品发展战略、企业当前状况适当地调整产品需求，例如用户需求可能被分配到软件的数个版本中。软件开发人员应当依据《产品需求规格说明书》来开发当前产品。
需求调研的步骤
用户需求说明书的模板
需求调研中的注意事项
对每一次的调研形成正确的文档
需求调研中的注意事项
需求调研是一个漫长的过程。能够正确理解用户的需求，并且将用户的各种需求完整地体现在《软件需求规格说明书》中将更是一个复杂而艰辛的过程，因此在每一次的会谈之后必须将当天的会谈纪录形成文档，可以以备忘录的形式让用户进行确认。
需求调研后形成的文档文档必须是正确的，是经过验证的，是在受控的状态下变更的。而很多开发人员往往会问：“简单的系统就不用写需求了吧？”其实简单的系统未必简单，只有想清楚、写清楚、说清楚才说明已经真正把需求整理清楚了。
做好需求变更的控制
需求调研中的注意事项
对每一次的变更要双发进行确认，并进行版本控制，做到有据可依。

2. 谁知道如何进行需求调研

力，才能真正体现出软件的价值。
4.编写用户需求说明书
需求调研的步骤
需求分析员对收集到的所有需求信息进行分类整理，消除错误，归纳与总结共性的用户需求，然后形成文档，编写《用户需求说明书》。对于《用户需求说明书》要和客户以及相关的行业专家进行共同评审。以前整理的需求记录可以作为附件整理在《用户需求说明书》之后。
《用户需求说明书》与《产品需求规格说明书》的主要区别与联系是：
（1）前者主要采用自然语言（和应用域术语）来表达用户需求，其内容相对于后者而言比较粗略，不够详细。
（2）后者是前者的细化，更多地采用计算机语言和图形符号来刻画需求，产品需求是软件系统设计的直接依据。
（3）两者之间可能并不存在一一影射关系，因为软件开发商会根据产品发展战略、企业当前状况适当地调整产品需求，例如用户需求可能被分配到软件的数个版本中。软件开发人员应当依据《产品需求规格说明书》来开发当前产品。
需求调研的步骤
用户需求说明书的模板
需求调研中的注意事项
对每一次的调研形成正确的文档
需求调研中的注意事项
需求调研是一个漫长的过程。能够正确理解用户的需求，并且将用户的各种需求完整地体现在《软件需求规格说明书》中将更是一个复杂而艰辛的过程，因此在每一次的会谈之后必须将当天的会谈纪录形成文档，可以以备忘录的形式让用户进行确认。
需求调研后形成的文档文档必须是正确的，是经过验证的，是在受控的状态下变更的。而很多开发人员往往会问：“简单的系统就不用写需求了吧？”其实简单的系统未必简单，只有想清楚、写清楚、说清楚才说明已经真正把需求整理清楚了。
做好需求变更的控制
需求调研中的注意事项
对每一次的变更要双发进行确认，并进行版本控制，做到有据可依。

3. 如何做需求分析

4. 如何做需求分析

一、 我们应当如何做需求分析
需求分析不是一蹴而就的，它应当贯穿整个开发周期，不断的分析确认的过程。这就是敏捷开发倡导的需求反馈。敏捷开发认为，需求分析阶段不可能解决所有的需求问题，因此在设计、开发、测试，直到最终交付客户，这整个过程都应当不停地用开发的成果与客户交流，及时获得反馈。只有这样才能及时纠正需求理解的偏差，保证项目的成功。
二、我们应当怎样做需求调研
1.初识。
我们对客户提出的需求进行深入理解以后，运用我们专业知识，提出比客户的原始需求更加合理、可操作的解决方案，让客户感觉你说的正是他们想要的。如果能够这样，客户不仅能够欣然接收你提出的方案，而且会感觉你非常专业，你在客户心目中的形象也会无形中提高，使你有更多的机会提出有利于开发的可行方案，降低开发的风险。这毫无疑问会形成一个良性循环，但要做到这一点并不容易，毫无疑问，在与客户接触初期的表现起到了极其关键的作用。
(1)高层领导关心的是宏观的目标，因此软件研发目标、宏观统计报表、决策支持功能，我们应该怎样做需求分析,应当与高层领导谈。
(2)中层领导关心的是具体的效益，即软件给各个部门信息化管理方面带来的效益，因此，中层领导是各项业务流程、功能模块的需求决策者。他们关心功能的定义、业务流转的衔接、查询报表的设计，但不太关心一些具体的操作，以及一些具体业务流程的细节。
(3)基层人员是每一项业务流程的操作者，也是软件今后真正的使用者。他们是真正了解你所要开发的软件的业务需求的领域专家，是你进行需求调研的重点对象。但是，基层人员往往受到自身视野的局限，可能只清楚自己工作涉及的十分狭小的一个范围，因此我们需要努力寻找那些业务涉及面广，经验丰富，又有一定大局观的真正的专家。另外 ，他们就是软件今后真正的使用者，让他们参加，会让他们成为今后软件推行的忠实支持者，对其他操作人员的指导者，益处多多。而他们关心的则是每项操作的细节。
俗话说：万事开头难。如果你在项目开始的时候总感觉千头万绪不知如何着手，在这里我给大家的三点建议：
1）树立良好的职业威信；
2）进行详细角色分析，将与会各方代表对号入座；
3）从宏观上制订目标与方案。随后的工作，就是与各方代码建立联系，逐一拜访他们，将需求调研工作一步一步进行下去。
2.拜访。
需求调研不是一蹴而就的事情，是一件持续数月甚至数年的工作（假如项目还有后期维护） 。在这漫长的时间里，我们需要依靠客户这个群体的帮助，一步一步掌握真实可靠的业务需求 。不仅如此，技术这东西总有不如意甚至实现不了的地方，我们需要客户的理解与包容，这都需要有良好的客户关系。尽管如此，我们也不能总是期望客户中的所有人都能与我们合作，很多项目都不可避免地存在阻碍项目开展的人。
3.研讨会。
(1)由于业务人员自身的局限 ，不可能对所有业务领域的细节全面掌握，往往总是有自己熟悉的部分，也有自己不熟悉的部
分。划分业务组，可以让业务人员分别在自己最熟悉的业务范围内参与讨论，可以有效提高业务讨论的质量；
(2)集中式的业务研讨形式和分散式的业务研讨形式；
(3)有效抑制个性化差异、分模块组织专项研讨会。
4.业务研讨
在需求分析过程中，客户存在的最大问题就是提不出正确的需求，这表现为几种形式：
(1)由于对软件不了解，客户提不出需求，不知道软件最终会做成什么样子。这类客户在需求讨论过程中，往往只能描述目前自己手工管理的方式是怎样的，不知道计算机会怎样管理。
(2)能提出一些业务需求，但当软件做出来摆在自己面前时，需求就变了。这类客户，他们能熟练使用电脑，对信息化管理是清楚的。他们提出的业务需求从整体上应当是八九不离十的 。但是，由于没有实物，在软件中的一些具体操作并没有完全想清楚。
(3)能非常详细地提出业务需求，甚至有时候该怎么做的提出来了。这类客户，参与过很多软件信息化建设，甚至有些还是软件开发的半专业人士。但是他们提出的业务需求过于具体 ，甚至怎样实现都说出来了，但这些有时候不是最佳设计方案、可能在技术上难于实现，甚至有些就是过于理想化而不可实现。
   解决办法:
业务领域分析:客户现有的业务流程是什么样的，都有些什么操作？客户在业务中都有些什么事物，什么专用名词，都是怎样定义的，相互之间的关系是什么？客户在每一项操作中的目的是什么，为什么要这样做，他们制作的手工报表都说明了什么问
题？
(1)我们做需求分析，眼界不能仅仅停留在软件本身，应当更开阔一些，应当扩展到跟这个业务有关的那些领域知识中。
(2)在客户提出的所有原始需求中那些与业务实现有关的需求都是无效的需求，它们仅仅只能作为我们的一个参考。
(3)还有一些是技术难于实现或者根本就无法实现的需求，我们应当耐心地说服和引导客户，并给他提出一个更加合理的方案。
(4)需求分析不是一种简单的你说我记的收集活动，而是在大量业务分析与技术可行性分析基础上的分析活动。只有建立在这种分析基础上的软件研发，才能保证需求的正确与变更的可控。
5.迭代
在第一次的需求分析阶段，我们在一段时期内需要与客户进行反复地讨论，这个过程往往是这样一个反复循环的过程：需求捕获->需求整理->需求验证->再需求捕获······
(1)需求捕获:就是我们与客户在一起开研讨会，讨论需求的活动,客户可能会描述他们的业务流程，这时我们在纸上绘制简单的流程草图，及时地记录下来；客户在描述业务的同时，可能会反复提到一些业务名词，详细询问这些名词的含义，以及它们与其它名词的关系，用类图或者对象图绘制简单的草图；客户在描述业务的同时，还会提出今后的软件希望实现的功能，如能够展示某个报表、能够导出文件，以需求列表的形式记录下来。一个功能，在需求列表中会有多个需求，而每个需求应当能够用 1、2 句话，在 20 个字以内就可以描述清楚 。需求列表是客户提出的最最原始的需求，他不掺杂任何分析设计，是我们的每项功能必须实现的内容。
(2)需求整理:就是在需求研讨会后，需求分析人员对研讨内容的分析和整理的过程。首先，需求分析人员应当通过用例模型，划分整个系统的功能模块，以及各个模块的业务流程。用例模型分析是一个由粗到细的过程，这样一个过程也是符合人类认识世界的思维习惯的一个过程。最先，我们应当对整个系统绘制用例图，设计用例场景，并依次对这些用例进行用例描述、流程分析、角色分析等分析过程。当然，在整体用例分析的同时，我们还应当进行一个整体的角色分析，绘制一个角色分析图，进行一个流程分析，绘制一个流程分析图（可以是传统的流程图、UML 中的行动图，甚至一个简单的示意图，等等）,再在整体用例图的基础上，依次对每个用例绘制用例图。每个用例图中，会更细致地划分出多个用例，并依次进行用例描述、流程分析、角色分析等分析工作。如此这般地不断细化，直到我们认为需求已经描述清楚为止。
(3)领域模型 :是对用户业务领域中相关事物、相互关系、相互行为操作的描述，它是以对象图和类图的形式表达的。需求人员对领域模型的分析，对业务理解的深度，对日后软件的设计，以及软件的功能扩展、升级演化，都起到了至关重要的作用。
(4)需求验证:需求验证工作应当贯穿整个研发周期，并且在不同时期表现出不同的形式。首先，在需求分析阶段，需求验证工作表现为对需求理解是否正确的信息反馈。需求分析人员与客户再次坐在一起，一项一项描述我们对需求的整理和理解，客户则时不时地对一些问题进行纠正，或者更加深入地加以描述。我们则认真地记录，回来整理，并等待下一次的验证。在需求分析后期，我们还可以制作一些简单的原型，更加形象地描述我们对需求的理解，会使我们与客户的沟通更加顺畅。随后的设计开发阶段，我
们则应当以迭代开发的形式进行。每开发完一个迭代周期，将开发的成果与客户反馈。这样做的结果是，客户可以及时地提出我们对需求理解的偏差，或者及时提出对我们设计不满意的地方，使我们存在的问题得到及时地发现与解决。问题及时的解决，使我们修复问题的代价得以降至最小。
6.需求捕获
经过深入分析我们会发现，从客户嘴中说出来的需求，只是整个软件需求中的冰山一角，还有两类需求需要我们自己去挖掘：客户嘴中没有说出来的需求 ，和客户压根儿就没有想到的需求
(1)什么是客户嘴中没有说出来的需求：并不是客户故意卖弄官子不愿说出来，而是在客户所在业务领域已经约定俗称，在他们看来已经是天经地义，根本就不用说出来的业务规则。然而 ，作为刚刚涉足该领域的需求人员，他们是不了解这些规则的。如果采用被动的方式去仅仅记录客户说出来的需求，毫无疑问会遗失这部分需求，这就是为什么直到项目后期，软件被研发出来即将交付使用，客户才提出说这不是我想要的软件，并提出大量变更需求的原因。要求我们在需求分析的整个过程，不断进行业务领域知识的学习。在我做需求访谈的初期，我往往不是跟客户谈需求，而是先跟客户谈业务。你们是怎样操作的？都经过些什么流程？谁来完成这些操作的？为什么这样操作？注意，在所有这些问题中，最后一个问题是最重要的。客户业务领域中的所有操作、所有流程都是有它存在的意义的，它体现了其内部的原因与作用。多问为什么，可以让我们深入地理解这些领域知识 。站在客户的视角去思考问题，进而深入地理解客户为什么要提出他们的那些业务需求
(2)另一种就是客户压根儿没有想到的需求：在需求分析阶段，虽然客户压根儿没有想到，但需求分析人员是软件研发领域的专业人员，他们应当在深入理解业务领域与需求的基础上，通过分析提前发现这些需求。作为需求分析人员，他们应当站在客户的角度去思考，我们的软件应当设计成什么样子，每个需求的真实意图是什么。站在这个基础上，再运用专业知识去整理、分析与设计。我前面谈到，客户描述的最原始的需求是编写在需求列表中的，而经过需求分析人员的整理、分析与设计，经过用例分析、领域建模，最终形成产品需求说明书（或称为产品规格说明书）。先在一些非正式的场合单独跟客户聊，产生第一手资料，最后将这些需求在比较正式的场合，如各部门参加的业务讨论会、有用户代表参加的

5. 从哪些方面如何具体做好需求分析

1. 访问并与有潜力的用户探讨

为找出新软件产品的用户需求，最直截了当的方法是询问他们。本章讨论如何寻找合适的用户代表，而在第8章讲述从这些代表中获取需求的技巧。
2. 把对目前的或竞争产品的描述写成文档

文档可以描述一种所必须遵循的标准或产品所必须遵循的政府或工业规则。
3. 系统需求规格说明

一个包含软、硬件的产品需要一个高档次的系统需求规格说明以介绍整个产品。系统需求的子集被分配到每个软件子系统中（ Nelsen 1990）。附加的详细软件功能需求将从有关软件的系统需求里获得。
4. 对当前系统的问题报告和增强要求

指导用户和提供技术支持的工作人员是最有价值的需求来源。他们收集了用户在使用现有系统过程中所遇到问题的信息，还接受了用户关于系统改进的想法。
5. 市场调查和用户问卷调查

调查有助于从广大有潜力的用户那里获得大量定量的数据，务必调查相关的用户并询问一些能产生反响的好问题。
6. 观察正在工作的用户

对当前系统的用户和将来系统的有潜力的用户，分析员观察“日常工作”以获得经验，这些经验能提供很有价值的信息。分析员可通过观察用户与所关联的任务环境的工作流程来预见用户在使用当前系统时所遇到的问题，并能分析新的系统可有效支持工作流程的方面（McGraw and Harbison 1997; Beyer and Holtzblatt 1998）。比起仅仅简单地询问用户，并记下用户在处理任务时的步骤来说，直接观察用户的工作流程可以对他们的活动有更正确的理解。分析员必须抽象和总结用户的直接活动，以确保所获得的需求具有普遍性，而不仅仅代表单个用户。一个富有技巧的分析员还可以为改进用户的当前事务处理过程提出一些见解。
7. 用户任务的内容分析

通常通过开发具体的情节（ s c e n a r i o）或活动顺序（有时称作“情节”），可以确定用户利用系统需要完成的任务，分析员由此可以获得用户用于处理任务的必要的功能需求。

6. 如何做需求分析

市场需求分析步骤
第一、确定目标市场
在市场总人口数中确定某一细分市场的目标市场总人数，此总人数是潜在顾客人数的最大极限，可用来计算未来或潜在的需求量。
第二、确定地理区域的目标市场
算出目标市场占总人口数的百分比，再将此百分比乘上地理区域的总人口数，就可以确定该区域目标市场数目的多寡。
第三、考虑消费限制条件
考虑产品是否有某些限制条件足以减少目标市场的数量。
第四、计算每位顾客每年平均购买数量
从购买率/购买习惯中，即可算出每人每年平均购买量。
第五、计算同类产品每年购买的总数量
区域内的顾客人数乘以每人每年平均购买的数量就可算出总购买数量。
第六、计算产品的平均价格
计算产品的平均价格。利用一定的定价方法，算出产品的平均价格。
第七、计算购买的总金额
把第五项所求得的购买总金额，乘以第六项所求得的平均价格，即可算出购买的总金额。
第八、计算企业的购买量
将企业的市场占有率乘以第七项的购买总金额，再根据最近 5 年来公司和竞争者市场占有率的变动情况，做适当的调整，就可以求出企业的购买量。
第九、需要考虑的其他因素
有关产品需求的其他因素，例如：若是经济状况、人口变动、消费者偏好及生活方式等有所改变，则必须分析其对产品需求的影响。根据这些信息，客观地调查第八项所获得的数据，即可合理地预测在总销售额及顾客人数中公司的潜在购买量

7. 如何做需求分析

1:抓核心点，不是所有用户诉求都是需求
我们每做一个项目迭代或者新项目一定有目的，而需求分析阶段，需求采集渠道中的需求往往是零散的、无重点的、逻辑性不强的，所以我们需要从这些离散的需求点中要抓住核心，梳理实际使用场景去分析问题，所有的核心点一定是以最终目的为导向的，不是所有用户诉求都是需求。
以我的项目为例，由于历史原因，自配送人员关系没有进入OA系统，所以配送员工资结算数据只能做进配送系统，相当于是一个简单考勤记录，其实最早之前系统是有这个功能的，但是由于之前没有仔细整理需求，导致这个功能白做了，所以这次我接手几乎从做，我以为这个事情比较简单就让一个产品助理先去整理需求，当把原型图出出来时发现并不能解决结算工资的功能，只是一个简单的排班。
所以，当时我就跟那小兄弟说，你这东西只是完成了排班，然而排班的目的为了结算工资这还不能满足需求。所以我跟他强调，我们做这个需求的目的是为了考勤，诸如请假、值班、加班工时、轮休日加班等数据要能提供出来，他的第一版原型其实没有充分了解到我们为什么要做这个排班功能，所以在了解需求过程中没有抓住核心点，导致需求不明确。
      2:制定规则、改善复杂流程
我的上一家企业做的是互联网电商，其实在我看来电商和O2O有很大的区别点就是电商在当下盛行的情况下已经变的很有规则了，首页、产品列表页、详情页、下单页等等，每个页面展示的信息也大相径庭，而O2O不一样，一方面是O2O差不多13年才兴起，到目前为止（15年）还没有一个标杆行业，另一方面是O2O与日常生活联系的太紧密，落地下来就是很复杂的业务流，这些是to C产品的规则化和流程化，而流程化的东西在to B产品上体现的尤为明显，to B产品最经典的例子就是公司后台系统。
不论是一个to C的产品还是to B的产品，我们都要考虑到用户使用场景，PM需要把自己当作用户，充分考虑各种情况下的用户思维才能设计一个满足用户需求的产品，这里并不是一味的去迎合用户，做互联网的都知道当一个业务不是规则化时很难用产品去满足用户，所以我们有必要制定规则，或者优化不完善、流程复杂的
规则。
下面说说制定规则，其实统一规则有利有弊，举个例子，滴滴打车的订单是抢的，uber打车的订单是系统自动分配的，滴滴那种做法能提高司机积极性、自主性，司机可以选择高金额的订单，但是这种做法也会影响用户体验，比如说万一以后不补贴了，我只是一个起步价，有些司机就不愿意接单，要等待很久；而uber打车制定了自动分配的规则，先分配目前离乘客最近的空闲司机，如果他不接再分配给下一个，这种做法能不能满足用户我不说，我只说这种规则简化了下单流程，司机和乘客只有两个选项，接还是不接，坐还是不坐，司机如果不接，但他并不知道下一单能等到什么时候，订单金额有多大？虽然司机间的积极性和自主性减少，但是对用户来说体验很好。
说完了制定规则，再说一下改善流程，我上面说了这种流程化精简在to B产品上尤为明显，很多人有个看法就是后台系统反正是自己人或者其他企业人员用的，完成功能就行，没必要做的这么便捷和细致，其实不然，优秀的PM在这方面总能善始善终，因为在他们眼里一点点的产品优化或者流程优化能为企业带来很多的效益，这个我有切身的体会。
之前做的多个项目，其中有两个就是我在做需求的时候发现业务部门在实际运营中思维定势或者每日重复做属于他的工作，但是他们并没有发现这样做其实效率很低，在没人观察流程有问题的时候，业务部门已经形成规范，但是这种规范并不是最优的，当PM做需求分析的时候需要细致观察他们部门或者个人的工作内容，想一想为什么这么样做，有没有其他方案能提高其工作效率。
在做数据统计需求的时候我发现业务部门某同事每天要先导出所有新用户电话、订单号、餐厅金额、订单金额等数据用于考察配送员满意度、用户满意度，然而她每天导出的数据其实有另外两个同事也需要用，只是使用目的不一样，但是他们都很死板，他们三个每天导出一份完整数据，然后筛选条件，组合成自己要的数据，这种工作其实很没必要，我们可以每天为他们部门发一份当日订单报表，标注新用户即可。
还有个例子是，财务在结算物流人员工资的时候很多计算公式是相互关联的，比如说A=B+C，D=A*E+B-C，然而他们就计算成D=(B+C)*E+B-C，暂且不说他们部门管理流程怎么样，但是PM在遇到这样业务流程的时候结合产品设计考虑是否可以精简流程，实现产品设计的初衷的同时也能简化流程。
      3:离散需求整合
在和业务部门打交道的时候发现他们的思维逻辑性可能稍微差点，在PM了解需求的时候业务人员或者用户表述的没有前因后果，也就是没有逻辑性，这时如果PM不追问下去自己很容易被带到坑里面，合格的PM应该在这种情况下峰回路转，把问题再阐述一遍，如遇到稍微强势一点的PM，此时应该会指出刚才的表述有错误。
还有的业务部门人员在你去沟通的时候哗啦啦的说了一大推产品改进意见或者新需求想法，此时PM应该细心聆听，记录下需求点，千万不要给他们答复这个功能什么时候做、什么时候上线，因为系统永远是不完善的、需求却永远是数不尽的，而资源是有限的，你给的答复实现不了别人会有不好的看法，优秀的PM需要大局观，能够和团队一起评估需求优先级，规划产品生命周期，这才能推进产品迭代。
        4:技术人员参与需求分析阶段
现在很多互联网公司基本上都是产品驱动，很难说技术驱动，因为产品团队可以知道用户想要什么，我在参与需求分析过程中事业部技术负责人喜欢跟着我一起去了解需求，这在我之前的工作组中没遇到过，现在做需求的时候他参与进来后我发现整个产品需求被乱了，阻碍了我需求分析进度，因为他总是以技术的角度考虑这样实现的难度，由于他是技术负责人，逻辑思维能力很强，每当听到这个数据没有需要新增一个入口去维护时他就站出来说为什么要这样做，然后劝说业务部门说这个数据提供不了，能不能先不做。
但是从产品角度上考虑，既然选择做这个项目那么就该从产品角度去设计好，等一整套产品方案出来之后再去精简功能是一个很好的方法，还有一些情况是当有一个比较好的idea产生时技术人员会首先考虑能不能实现、实现的复杂度，如果有一点困难或者技术可行方案不能当场给出时，这个功能就暂且搁置了，也许就会提出另一个不会错但是并不是最好的方案，所以技术人员参与需求分析阶段最容易把原本一个好的产品扼杀在摇篮之中。综上考虑，我的理解是技术人员在需求分析阶段暂且不要参与进来，等产品团队内部讨论之后技术团队参与审评，这样也许能达到事半功倍的作用。

8. 如何做需求分析？

随着技术的不断发展和用户对网站功能性的需求不断提高，如今网站项目的设计已经不能再仅仅简单地利用静态Html文件来实现，与前几年网站设计由一两名网页设计师自由的创作相比，网站项目的设计和开发越来越像一个软件工程，也越来越复杂，网站项目的设计和开发进入了需要强调流程和分工的时代，建立规范的、有效的、健壮的开发机制，才能适应用户不断变化的需要，达到预期的计划目标。

    网站项目管理（WPM）的含义为Web-based Project Management，即以Web 应用程序为主要表现方式的架构来进行的项目设计及管理，这样的架构中包含了浏览器、网络和Web

    服务器等关键主体，主要体现在网站设计、以浏览器为客户端的Web应用程序开发（例如信息类网站、网上商店、虚拟邮局、客户关系管理。）等项目管理中。

    按照笔者的经验，网站项目管理可以分为以下l六个阶段进行控制： 
    1. 需求分析及变更管理 
    2. 项目模型及业务流程分析 
    3. 系统分析及软件建模 
    4. 界面设计、交互设计及程序开发 
    5. 系统测试和文档编写 
    6. 客户培训、技术支持和售后服务

    需要说明的是，这些阶段虽然具有一定的延续性，但是并非完全隔断的，例如需求变更管理和测试工作、文档编写都是贯穿整个项目过程的，许多工作时交叉进行或同时进行的。

    （一）如何做好需求分析及变更管理？

    业务员与客户进行的沟通，撰写需求分析报告是项目展开的基础。项目是以客户的需求为中心，而不是为技术而迁就需求。

    一：让客户畅所欲言，罗列出所有的需求

    让用户将所有的想法尽可能的阐述清楚，并把所有的要求罗列出来，不要遗漏。这时候不应该害怕“勾引”起客户的潜在需求而增加设计开发的工作量，从而被今后客户无止境的变更拖入泥潭，直接明白地跟客户把问题和要求一条条地列出来，把条理、归纳、分析先都扔到一边去，将用户最原始、最完整的要求准确地记录下来就完成了第一步的工作。

    很明显，假如客户的需求做的都不完整，随时可能会产生意想之外的变更，甚至这个变更会破坏已经做的模型及结构，那么这个项目从开始就注定了会失败；比如站点所有的功能都实现了，本地测试起来也没有什么问题了，但是你却不知道客户的系统是要承受每天100万独立IP的访问，而你原来想当然的以为了不起就是1万独立IP访问的访问流量，稍微有经验的开发人员都会明白这样的设计是个灾难，无论是应用服务器、数据库还是程序全部要重新开发！

    二：透过现象分析潜在的需求

    很多情况下客户并非专业人士，在他们滔滔不绝的描述中不能指望他们帮助我们整理出重点和技术难关，这需要我们去为客户进行分析、归纳和整理，尤其是客户谈的不多却又是技术上实现难度和强度很高的地方特别值得注意。

    客户往往对需求的概念是非常模糊的，大多时候给出的需求都是笼统而且尺度难以控制的，这就要求业务人员在倾听了客户的详细说明以后，帮助客户进行整理和分析，同时预测客户在开发过程中变更及今后应用中可能进行修改升级的潜在需求。

    比如在为客户设计办公自动化系统的时候，也许就要为客户预留将来与他们的业务单位进行交互的通道；在设计邮件系统的时候要考虑可能会需要广告管理服务器；设计网络电子商店时今后增加库存产品进销存统计分析等等；限于时间财力的考虑，客户通常能够接受分阶段实施的开发过程，在需求分析时，提早为客户设想到今后的需求变更除了使项目开发更加顺利以外，也为今后业务的进一步深入打下了更好的基础。

    笔者曾负责一个大型新闻网站的设计，当客户拿着将近五十页厚的一本设计要求报告时，我发现有四十页的内容对程序开发来说都是重复的，而在其中一页的角落却画了个“搜索其他网站相关新闻”的按钮，并且没有做任何说明，仅仅这10个字所完成的工作量完全顶的上其他整整四十页重复赘述所做的工作，客户完全不知道这个要求引发的问题实际就是一个搜索引擎的开发，通过协商，客人同意了修改成站内搜索的引擎。

    三：利用自然的语言描述项目模型

    在业务员与客户进行沟通和调查时撰写的需求分析，尽可能用自然的语言进行描述，虽然客户的水平和资历有所不同，但是最自然的描述能够使项目开发的各个成员都能清楚地理解需求含义，不至于在理解上产生偏差。对客户而言，这样的模型描述最接近真实，容易参与修订，并能以此为测试和验收的依据。

    请比较以下两份关于需求的描述， 
    “用户在访问首页的时候可以在点击‘客户通道’按钮，弹出填写‘用户名’和‘密码’的窗口，输入正确后在新窗口打开客户通道的首页，在该页显示所有可操作的功能的导航条和最新的导读新闻链接列表 。”

    “站点分为公开和加密两种状态，通过身份验证机制使特有的用户可以访问到加密信息，并提供不同于普通用户的功能。”
  
    前段描述我们就很容易想象的出来设计完成的网站是什么样子，而后一段的描述可能会做出无数不同的版本，造成对需求理解的歧意。

    四：利用示意图和图表将用户的需求表现出来

    需求分析无论文字上怎么样表述都还是抽象的，对客户而言理解毕竟是困难的，将基本确定的需求制作出示意图是最直观有效的。

    制作示意图可以有很多种方式，用PowerPoint或Visio制作流程示意，用Html文档制作界面示意都是可行的，最简单利用画图和Word表格方式也完全可以，关键是利用示意图将客户的需求和即将开始设计的系统体现起来，在进行系统分析和程序开发之前，双方对今后要完成的产品就能够有直观的认识，换言之，就是在产品还没有真正进入开发阶段的时候，双方就对工作的结果达成统一的意见，这将大大地减轻需求变更所带来的困扰，同时客户更容易地参与到项目的开发过程，保证项目往正确的方向进行。

    在RUP中有这样的描述：

    利用电影、卡通、图片、表格和动画片等制作示意图开始，告诉我们用户是谁，要发生什么事情，如何发生。

    以用户友好的方式帮助收集并改进用户需求。

    鼓励更有创造性、更加创新的设计解决方案。 
   
    鼓励团队复审，并避免所有人都不希望出现的特征。

    确保以可理解、直观的方式实施特征。

    使访谈过程变得轻松，避免出现访谈没有结果的现象。

    简单地说，制作示意图就是使用工具向用户 (主角) 说明（有时是动画演示）系统如何适应组织的需要，并表明系统将如何运转。协调员将初始示意板展示给小组，小组成员提供意见。之后，在举办研讨班期间，示意板也进行“实时”演进。所以，您需要一种可以轻松更改示意板的画图工具。为了避免分散注意力，一般最好使用简单的工具，比如图表、白板或PowerPoint。

    五：什么人要看需求分析报告

    项目经理、系统分析员、开发经理、交互设计师、测试人员、文档人员包括客户代表都应该看需求分析，并进行共同的讨论，达成一致的意见。

    我们经常会遇到业务人员辛辛苦苦谈下来的项目，对开发人员来说却是难以实现的，而技术人员设计的产品却常常得不到客户的认可，甚至发生纠纷，因此参与项目开发的人员都应该对这份需求有统一清晰的认识，并根据自己的工作对需求提出意见，通过与客户的沟通修订，最终确定项目实现的目标。

    例如：

    项目经理通过需求分析才能组建所需要的团队包括配置工作环境，制定开发周期。 
    开发周期的限制和功能上的要求可能会影响到程序员采用什么样的语言和工具进行编写； 
    操作用户的技能水平将影响到交互设计师进行前台设计时做到什么样的精度； 
    界面设计人员根据项目的性质和定位确定表现方式。 
    测试人员了解测试环境和条件后才能对项目质量进行跟踪和检测；

    通过下表，我们可以看的出不同角色根据需求的变更所进行的工作流程：

六：建立需求变更日志，制作新版本的需求分析报告

    尽管我们费了许多功夫在需求分析进行了最大可能的努力，但几乎可以肯定的是，这份需求分析在开发过程中一定会发生变化，也许是出自客户的遗漏，也可能是在开发过程中被激发出来的，这种变更有时是如此的频繁和琐碎，以至于往往不能将变更及时反馈到项目的各个角色中，那么做好需求变更日志就显得非常重要。

    在需求分析后面附上变更日志，并将修改后的需求分析制作成新版本，保留每次更改过的版本，而不是覆盖，这样就比较容易地跟踪到需求变更过程中所带来的工作调整。

    在新版本的需求分析中，将变更多部分用特殊方式表明出来，并在日志中记录变更多重的明细。

    关于需求分析和变更管理可以参照下图示意：

七：本阶段重点工作角色

    在需求分析和变更管理的过程中，工作量最大的角色为客户代表、业务员和项目经理。

    客户代表提出需求，业务员帮助整理和分析，项目经理对整个项目进行评估。

    在实际工作中，很多项目失败的起因都和需求分析有关。 客户代表和业务员通常并非从事技术开发的专业人员，在讨论需求的时候往往对项目的技术难度、工作量、时间进度把握不准确，这时候需要项目经理或技术人员进行参谋。

    为了降低项目的风险，提高工作效率，有必要设计规范的需求管理计划书，帮助客户代表和业务员更好的完成任务。

    以下提供一份需求管理计划的模板可作为参考：

八：总结

    根据笔者的经验，要尽快做好需求分析掌握以下要点，也许能事半功倍：

    仔细聆听，罗列客户的所有要求； 
    将需求进行分析，确认可操作的系统模型； 
    利用最自然的语言将系统进行描述，使每个开发人员不会产生歧意； 
    迅速确定网站的用户角色； 
    比如访客、会员、重要客户、前台管理员、网站管理员、业务员等；  
    分析确定每个角色的权限及可操作的功能； 
    比如会员可以查看特别信息、修改个人信息、退出登陆等； 
    前台管理员能够登录管理系统，能够发布编辑修改信息，能够审查会员资格等； 
    网站管理员可以更改栏目、修改网站界面等； 
    制作流程图和示意图将需求表现出来； 
    让客户参与到示意图的设计中，及时正确的反应出需求变更。 
    制作需求变更日志，保留升级版本，通过版本控制进行需求管理； 
    通过需求《管理计划书》使每个参与人员看到共同的努力目标。