前言

　　ant是java开发者工具箱的重要一环，junit,xdoclet等都与它紧密关联，程序员可能习惯了IDE提供的自动构建，甚至部署的功能，从而忽略了ant本身，其实，主流的IDE通常是内置ant任务来完成这些工作的，熟悉ant内在的机理，可以阅读或简单修改build.xml无疑可以帮助你更灵活地集成、管理应用项目,如果需要学习maven这种开源项目管理解决方案，也是要以理解ant为基础的哟。另外，使用ant的过程实际上对构建进行了文档化，它是无关于IDE的，想象一下，你的同事中可能三分之一在用JbuilderX,三分之一用eclipse，还有一些是别的。

　　本人使用eclipse3.0.1，以前的构建和发布工作都由myeclipse插件作了，趁周末实践了一下手动构建，记此备忘。

　　实践

　　准备工作：这是我的个人习惯，把所有公用的类库jar置于一个固定目录，分好类，不要丢在一个文件夹下，如jakarta-commons、hibernate、spring、struts等，这些是源码构建时需要用到的，在部署时可能有一些不用再打进去了，比如servlet.jar。如果你们有自己的framework,也一并放在这里。然后，打开eclipse,进入Windows-＞Preferences-＞Java-＞User Libraries,增加一个自己的库，比如说mylib,把刚才那些公共的jar全部添入，这样有个好处，在eclipse项目中，不用再看到烦人的长长的jar列表了，比较整洁。

　　下来正式进行：

　　1.新建一个Java Project，此时就不要再选你的j2ee插件内置的一些选项了，至简即可。

　　2.在root下建几个文件夹，我们在网上下载的开源项目中经常可以看到这些，比如：

　　src - 源码
　　classes - 编译
　　web - jsp等
　　lib - 库,这里可以简单地把mylib下的东东copy过来，便于将来发布源码。
　　dlist - 输出的jar或war

　　当然，我们要建一个build.xml，eclipse中会出现一个蚂蚁的小图标，一般这个文件建立后，下一个项目简单的copy过去，稍加改动就可以了。

　　3.打开项目的属性页，在Java Build Path的库选项中，加入我们自定义的公共库mylib.至于Builders方式就不用改了，使用默认的Java Builer即可，我只是项目部署时使用ant，平常的排错工作就交给IDE吧。

　　4.重中之重，写你的build.xml，网上文章很海，我这里就不再啰嗦了，基本上就分那几个任务：

　　4.1 先要声明一些路径变量，如

　　＜property name="war.dir" value="dlist" /＞

　　也可以将其写至properties文件中，在这里引用;

　　4.2 声明编译的类路径，如下:

　　＜path id="master-classpath"＞
　　＜fileset dir="${lib.root}/struts"＞
　　＜include name="struts-menu-2.3.jar" /＞
　　＜include name="struts.jar" /＞
　　＜/fileset＞
　　＜fileset dir="${lib.root}/jakarta-commons"＞
　　＜include name="commons-*.jar" /＞
　　＜/fileset＞
　　＜fileset dir="${lib.root}/ibatis2.0.9"＞
　　＜include name="ibatis-*.jar" /＞
　　＜/fileset＞
　　＜fileset dir="${lib.root}/jdbcdriver"＞
　　＜include name="jtds-0.9-rc2.jar" /＞
　　＜/fileset＞s
　　......
　　＜/path＞

　　4.3 清空输出目录，如web,dlist等。

　　4.4 编译构建:

　　＜target name="build" description="Compile main source tree java files into class files, generate jar files"＞

　　＜mkdir dir="${build.dir}" /＞

　　＜javac destdir="${build.dir}" source="1.3" target="1.3" debug="true" deprecation="false" ptimize="false" failonerror="true"＞
　　＜src path="${src.dir}" /＞
　　＜classpath refid="master-classpath" /＞
　　＜/javac＞

　　＜copy todir="${build.dir}" preservelastmodified="true"＞
　　＜fileset dir="${src.dir}"＞
　　＜include name="**/*.xml" /＞
　　＜include name="**/*.properties" /＞
　　＜/fileset＞
　　＜/copy＞
　　＜!-- ============================================= --＞
　　＜!-- 据测试，资源文件不能被打到jar文件中，其余均可 --＞
　　＜!-- ============================================= --＞
　　＜copy todir="${webclasses.dir}/conf" preservelastmodified="true"＞
　　＜fileset dir="${src.dir}/conf"＞
　　＜include name="springResources*.properties" /＞
　　＜/fileset＞
　　＜/copy＞

　　＜mkdir dir="${weblib.dir}" /＞

　　＜jar jarfile="${weblib.dir}/${name}.jar" compress="true"＞
　　＜fileset dir="${build.dir}"＞
　　＜include name="**" /＞
　　＜/fileset＞
　　＜/jar＞

　　＜copy todir="${weblib.dir}" preservelastmodified="true"＞

　　＜fileset dir="${lib.root}"＞
　　＜include name="log4j-1.2.8.jar" /＞
　　＜/fileset＞
　　＜fileset dir="${lib.root}/struts"＞
　　＜include name="struts-menu-2.3.jar" /＞
　　＜include name="struts.jar" /＞
　　＜/fileset＞
　　＜fileset dir="${lib.root}/jakarta-commons"＞
　　＜include name="commons-*.jar" /＞
　　＜/fileset＞
　　＜fileset dir="${lib.root}/spring-1.1.3"＞
　　＜include name="spring.jar" /＞
　　＜include name="aopalliance.jar" /＞
　　＜/fileset＞
　　......

　　＜/copy＞

　　＜/target＞

　　＜!-- ============================================= --＞
　　＜!-- Compile main Java sources and copy libraries --＞
　　＜!-- ============================================= --＞
　　＜target name="warfile" description="Build the web application archive"＞

　　＜mkdir dir="${dist.dir}" /＞
　　＜war warfile="${dist.dir}/${name}.war" basedir="${war.dir}" webxml="${war.dir}/WEB-INF/web.xml"＞
　　＜include name="*" /＞
　　＜include name="WEB-INF/*.*" /＞
　　＜exclude name="WEB-INF/web.xml" /＞
　　＜include name="WEB-INF/classes/*.*" /＞
　　＜include name="WEB-INF/lib/**" /＞
　　＜exclude name="**/.*" /＞
　　＜/war＞

　　＜/target＞


　　4.5 打成war

　　＜target name="warfile" description="Build the web application archive"＞

　　＜mkdir dir="${dist.dir}" /＞
　　＜war warfile="${dist.dir}/${name}.war" basedir="${war.dir}" webxml="${war.dir}/WEB-INF/web.xml"＞
　　＜include name="*" /＞
　　＜include name="WEB-INF/*.*" /＞
　　＜exclude name="WEB-INF/web.xml" /＞
　　＜include name="WEB-INF/classes/*.*" /＞
　　＜include name="WEB-INF/lib/**" /＞
　　＜exclude name="**/.*" /＞
　　＜/war＞

　　＜/target＞

　　4.6 把几个任务串起来，弄一个default target

　　＜target name="all"＞
　　＜antcall target="clean" /＞
　　＜antcall target="build" /＞
　　＜antcall target="warfile" /＞
　　＜/target＞

　　打完收功。在实践中发现，一些配置文件，如struts-config.xml ibatis和spring的xml都可以打进jar文件，spring资源文件好象不行，得单独copy至WEB-INFclasses下，另外，你的web文件夹下，事先得放好web.xml，以及一些tld文件哟。

做好产品需求文档的这十步，是经过长期的实践经验和反复验证而得到的。可能这里描述的不是很全面，但他已经足够让你做一个成功的产品需求文档。做好这几步花费的时间要以项目的大小、复杂程度、个体学识、基本技能熟练度而定。

　　第一步：做好准备工作

　　你要做的是一个让人无可争议的产品，为了做好他，你必须做好前期的准备工作。你需要去了解你的顾客、竞争对手、产品团队的实力和需要的技术。你需要从顾客、用户、竞争对手、分析师、产品团队、销售队伍、市场、公司职员等收集他们能发现的问题和可能的解决办法。这里有很多的工作需要你去完成,在“成功的产品背后”这篇文章中有详细的描述。

　　建立良好的交流也非常重要，它会影响着产品团队。如果你的准备工作做的够好，你也会变得越来越有信心和说服力。

　　第二步：确定产品的目的

　　任何一个好的产品都开始于一个需求。你必须清楚的了解这个需求，你的产品如何达到这个需求。

　　产品经理需要提出一个清晰、简明的价值主张，让它很容易被接受，要让产品团队、管理人员、用户、市场人员清楚的明白这个产品到底是什么意图。虽然这听起来很简单，但是也只有少数产品才有这样的价值主张。考虑“velevator pitch ”(电梯间演讲、电梯行销)测试。假设你在做电梯的时候遇到公司CEO，他问你产品的意图是什么，你能在电梯到达之前回答这个问题吗？如果不能，你就还有工作需要做。也许是你的说明没有针对性，他可能表现出来和其他产品做的没有什么明显区别；也许你提出的观点不能和你的用户产生共鸣；也许你解决的是一个非常规的问题，可能你想应用一种技术。这个价值主张可能需要满足公司的产品战略。注意你不需要阐述太多的细节，从某些方面来说，一个有价值的观点应当是越简越好。

　　 产品需求需要确切的指出这个产品发布的目标，同样的这个目标也有优先之分。例如，你的目标可能是：1）易用，2）零售价不足$100，3）和前期产品很好的结合。然后你需要说明如何去测算。对于“易用”这类项目，你需要明确指出产品可用性达到某个水平。这是通常用目标用户来定义。可用性工程师能测算出你的产品对目标用户的可用性，也测算出可用性问题的严重程度，同样你可以说明没有重大的可用性问题。

　　这里的关键就是让每个人都知道产品成功的时候是什么样，还有给产品团队在设计和实施中遇到问题如何进行取舍的指导。

　　第三步：确定用户原型、用户目标和用户任务

　　现在你已经明白你想要解决什么问题，下接下来就要深入了解目标用户和顾客，在这步中，和你的PD（产品设计）紧密联系非常重要。

　　用户原型

　　在这个阶段，PM需要和很多用户交流，需要花费大量的时间去直接观察和讨论。现在我们需要对用户和顾客进行分类，然后决定那一类是我们的首要用户。

　　比如你正在做一个像eBay一样的互联网拍卖服务，你同时拥有买家和卖家，在这之中还有使用频率少的用户和经常使用的用户，不难想象还有个别特殊的用户，比如团体公司采购者。

　　PM（产品经理）和PD（产品设计）需要首先确定类型是最重要的，然后尽量对这个用户群的特征进行详细的描述，以便使用这个模型去指导产品的设计。这个模型通常称其为“人物角色”。 虽然是想像的，但是应该是典型的、可行的和真实的，让你能够使用。这个想法来自与一个能代表这类用户的本质的原型。

　　举个例子：

　　“里昂是一个超级卖家，46岁，男性，居住在Fresno，经营小型摩托车配件。虽然他开着一个小店，但是他的生意大部分来自Ebay,每个月平均有400多次交易。他出售的东西品种非常多，但是他最受欢迎的商品还是哈雷戴维森的负重袋。他自己拥有两个哈雷，还开着1993年的丰田皮卡。里昂已经结婚了还有两个小孩。

　　里昂买电脑仅仅是因为他需要使用Ebay,除了ebay和电子邮件很少再使用其他东西。里昂已经在Ebay上销售产品已经三年了，他学会了在ebay应该掌握的东西，他非常自豪的拥有超过5000的信用度。如果Ebay更改了网站，特别是销售的过程方面，对于他来说改变习惯、学习这些变更是非常困难的。 里昂已经形成了自己的习惯，星期一列出销售的商品，星期五拍卖结束，设法让在收到货款的几个小时内出货。”

　　但愿这样的描述能让你了解里昂和知道他是怎么来的。当我们考虑新功能时，我就要问问自己里昂会是什么发应，为了让他能顺利的使用这个功能我们需要做什么。

　　注意缩小范围，让他仅仅描绘必不可少的。满足所有人是徒劳的，通常最后没人会满意，所以尽量提出几个最重要的和最流行的角色描述是非常重要的。同样，如果你不去精确的定位你的目标用户，你就只会存在模糊的概念，你会发现理解你用户的反应非常困难。你要倾向于设想，让你能更像你的用户。


　　用户目标（用户意愿）

　　一旦我们确定并描绘了我们主要的用户类型，我们就需要找出用户在使用产品中的目标(想要干什么).这听起来很简单，但是解开根本问题是非常具有挑战性的，特别当你周围的人告诉你你已经解决了他们想要的。

　　从CEO、销售代表、工程师到客户，每个人都太兴奋而不能帮助你找到解决根本问题的办法，他们会告诉你在某个地方添加一个快捷按钮，或则添加一个功能仅仅是因为竞争对手有，或则是改变成他们喜欢的颜色。

　　最好的解决办法取决于清晰的了解到底什么问题需要解决，每个用户模型可能有不同的目的，需要在用户原型涉及的方面中进行寻找。有可能将来某个功能解决的问题并不是主要用户需要达到的目标之一。


　　用户任务（tasks，用户为达到目标使用产品而需要做的任务）

　　掌握了用户原型与他们的目标愿望，我们就开始着手设计任务来满足他们的目标意愿，这是产品制作进程中最核心的部分，也是创造力和创新力被激发的地方。

　　许多优秀的产品仅是用更好更新的办法解决一个已有的问题，有时候这种办法仅仅是应用一个种新技术，但是大部分是来自深刻的见解而使一种新方法的产生。例如TiVo（美国市场占有率第一的数字录像机）在电视节目录制的老问题上面想出一个全新的办法，让顾客更加容易地实现他们的目标并且建立了电子设备一个全新的类别。

　　注意我们虽然谈到了目标和任务但是还没有谈到具体的功能，这些功能都需要达到用户目标而必须的。你以后会发现许多功能都是低优先级或则是完全多余的。

　　以“必须功能”这个理由可以排除很多功能。讽刺的是，你用越少的功能，你的产品被发现得越来越强大。这是因为产品的功能越少，你的用户就会发现并使用更多的功能，成功的使用越来越多的功能他们就认为你的产品非常强大。这些理由都是违反我们直觉的，我们大多数人都不能和我们的用户一样，我们在自己的行业中愿意比用户花费更多的时间去探索功能和容忍复杂性。

　　第四步：定义产品原则

　　现在你需要开始把你的需求和用户体验定义成详细的要求。同时你仍然会面临着许多的决定和权衡，为你的产品标准作出最佳的决定是非常重要的。

　　在大多数的产品团队中，每个成员都有做好产品的原则，但很少有两个人有同样的想法，这些差异都会导致不可思议的结果。
尝试和制订一系列指导整个团队的产品原则是非常有价值的，这些原则需要具体到域名和项目。

　　用TiVo举例，在产品团队工作开始时，以下这些产品规范就被建立，并在团队里传达：

　　　　1.它是娱乐的
　　　　2.一个傻瓜式的电视
　　　　3.一个该死的视频设备
　　　　4.平滑柔顺的
　　　　5.没有模式和深层次
　　　　6.尊重观众的隐私权
　　　　7.像电视一样强大

　　这些规范很大的影响到产品的定义而且在很大程度上加大了难度，但是他们确实是成功产品的来源。比如易趣的口号就是：1、易于使用 2、安全 3、有趣

　　它将在该项目中，在面对众多问题而作出决定的时候进行指南.

　　第五步：产品原型和检验

　　这是一个拿出你想法的阶段，创造力和创新力拿出成就的地方.

　　很多人都容易犯一个常见的错误，他们对产品设计规范太有信心，结果一旦得到beta的测试他们就必须调整产品。但是肯定beta测试版并不是进行重大改变的时候，所以才会有许多首次发布的产品离目标太远。

　　对于许多产品来说，这个时候你可以用大量的原型做很多的实验。首先，下面的三个非常重要的测试你可能需要做

　　可行性测试
　　一个直接的问题就是产品是否可以开发，你的工程师和设计师应当介入技术的可行性调查和探索可用办法。有些办法是行不通的，但是有其他的办法可行是非常有希望的。
　　工程师会发现在产品的某个阶段不可能逾越，现在知道比以后知道要好。

　　可用性测试
　　产品设计师将要和你紧密工作共同提出产品功能，让它能适应不同的用户。可用性测试常常会找出遗漏的产品要求，同时确认产品最初的要求是否是必须的。在你拿出一个成功的用户体验之前需要多做一些测试工作。可用性的目的是在真正的用户身上测试，从产品目标用户得到质量反馈的测试是非常艺术和科学的。当然产品经理和产品设计将模仿使用，但是实际是没有人能取代真实的目标用户。

　　概念测试（Product Concept Testing）
　　光是可用和可行是不足的。真正的问题是你的用户想要购买吗—你的用户有多喜欢-你做的有什么价值。这测试可能与可用性测试联系在一起。

　　对于一部份小产品，您的想法写在纸就足够了，但是对于多数产品，为了预计产品是否达到目标，复杂用户互作用或新技术的使用、某种形式原型都是非常重要的。

　　原型也许是一个物理设备，或者它也许是软件产品的一个预览版本。关键是它需要足够现实，您能用原型在实际目标顾客身上测试，并且他们可以给您质量反馈。

　　以前做原型主要有两个障碍。第一是缺乏良好的原型工具，需要花费很多的时间制作原型；另一个是管理方不知道原型和真实产品的区别，在不可预计的情况下，按照最终产品来要求原型。

　　今天有优秀的原型设计工具可以让工程师或设计师快速的制作原型，可以有效的模拟未来的产品以达到必要的程度让实际用户进行测试。而且大多数管理者都知道模仿和实际的区别 — 就如同缩小比例的房子模型和真实的家一样。

　　在实际去做产品之前去检验你的产品是非常重要的。一旦实际的工程开始，作出重要的变动会变得非常困难，花费也会变得很高。

　　第六步：验证和质疑

　　当你认为你弄懂了你需要解决的问题，现在是时候开始验证和质疑假设。

　　假设甚至当作不知道是很容易的，但是切勿把不可知的结论当作指引，那会妨碍你获得成功。天文学最初定义是研究太阳和其他行星如何围绕自己转，本身的定义就是一个臆断，反而阻止人们获得真相。

　　第七步：写

　　当然你需要把这些都写下来，大多数的PRD都是word文档，但也有一些是帮助文档，PowerPoint，或则写在白纸上。当然用什么格式不是很重要，重要的是让团队成功能轻松的看懂，不会遗漏，还有就是PRD可以随着项目开发而更新。

　　记住对话是两个人之间的，但是PRD是要沟通整个小组。你也要记住获得产品的销售才是是重要的，所以不必担心要有什么漂亮的外观、PRD写的有多厚，只要它是可读的、可理解的、是需要的内容。

　　PRD文档主要有四个部份组成

　　产品用途
　　你的工作就是指出目标，团队需要知道他们的目的是什么，目标说明要尽可能的明确，请确保你的内容包括：
　　*那些问题你要解决，不是解决方案
　　*谁是目标用户
　　*细节很多，但是大图片必须清晰
　　*情景描述
　　多开展集思广益的会议和临时口头的讨论，从而更好的写出来，更会让团队深入了解。

　　产品功能特性
　　产品需求文档最主要的当然是需求。 具体的需求完全地将取决于您的领域，但是不管你是什么行业，您的产品团队将受益于陈述需求的清楚，毫不含糊的要求，而不是模糊的解决方案。
　　描述每个功能的互动设计和使用案例。您必须非常清楚每个功能和用户体验，还需要给工程团队留下足够多的灵活自主空间。
　　同样重要的是确定那些要求满足哪个目的。这里就需要提到“需求跟踪”，对于关键的产品这是一个重要的流程。每种产品规范可能受益于清楚确定那些要求满足哪个目的，如果某人决定削减要求，想要深入了解就会非常困难。 从要求到目的明确说明将会是文档更加清晰。

　　发布标准
　　发布标准经常是不断变化的，但是好的PRD应该考虑到为每种标准定一个最低要求。典型的如：性能，可测量性，可靠性，可用性，可控性。

　　时间进度
　　其中很困难的一个问题就是描述产品需要的时间进度表。随便列出一个时间是没用的，你需要描述环境、动机、预计目标。你需要整个团队都和你一样达到预计目标，最终完成一个成功的产品。

　　第八步 优先级

　　除了明确的要求，对每一个您的要求给予优先和排列秩序是很重要的。多数产品经理，如果他们给予优先级，一般都是表明要求是否是“必须有， “重要”或“希望拥有” (或其他一些分类系统)。分类是很重要的，不可掉以轻心。

　　产品经理对任何一个标记“必须拥有”都需要有高度的标准。如果还没有找到必须拥有的功能意味着产品还不应该产生。所以小心标注“必须拥有”，这些标注“必须拥有”的功能直接反应出产品的核心价值。
　　“重要”的分类也很重要，在产品销售前只要有机会就要满足这些功能。
　　“希望拥有”产品团队也应该注意到，即使大多数也都没有实现，在未来版本也适当的慢慢实现。

　　这些有时候是不够的，从1到n每一个分类优先排序都是很重要的。有几个原因：
　　首先，上市时间总是被关注，并且日程表经常下降，您说不定被迫使削减有些特点为了尽快进入市场。 你也不想产品团队先开发简单的功能而放松重要的功能，导致最后客户使用的关键功能还没完成。
　　其次，在产品设计和开发阶段，团队将会发现更多的问题产生并解决这些问题，所以很有可能有更多关键功能出现。优先顺序会可以帮助你如何平衡以容纳更多的功能。
　　这点就是说产品经理如何不给出优先级和重要等级，其他相关较少的因素也会跟着无法确定。

　　整个PRD是一个不断完善和思维提高的过程，明朗锐利就是可以成功的产品的，模糊就是失败的产品。在争论最激烈的时候也能容易做决定，并且帮助工程师做出计划。

　　第九步 测试完整性

　　现在你有一个PRD草稿，你需要测试它的完整性。工程师是否可以充分了解并达到目标？OA Team（质量管理团队）是否有足够的信息来做出测试计划，是否可以开始做案例？

　　当投资人或相关人审核了PRD，确定了各个需要说明的方面，所有的问题得到解决，现在你就可以按PRD进行产品开发。

　　第十步 管理产品

　　在产品实施期间，就算是最好PRD，也有不计其数的问题被解决。解决所有PRD中存在问题，如果不在PRD中就写进去。你的任务就是迅速解决问题并记录在PRD。

　　如果你做了你的工作并准备记录在PRD，项目审查就会变得非常简单，因为任何一个部份都历历在目。

　　记住PRD是一个“活”的文件，在要跟踪记录在产品开发期间的所有功能过程。最后你会发现很多额外的东西，如果你认为是必要的就在PRD中写进。

做好产品需求文档的这十步，是经过长期的实践经验和反复验证而得到的。可能这里描述的不是很全面，但他已经足够让你做一个成功的产品需求文档。做好这几步花费的时间要以项目的大小、复杂程度、个体学识、基本技能熟练度而定。

　　第一步：做好准备工作

　　你要做的是一个让人无可争议的产品，为了做好他，你必须做好前期的准备工作。你需要去了解你的顾客、竞争对手、产品团队的实力和需要的技术。你需要从顾客、用户、竞争对手、分析师、产品团队、销售队伍、市场、公司职员等收集他们能发现的问题和可能的解决办法。这里有很多的工作需要你去完成,在“成功的产品背后”这篇文章中有详细的描述。

　　建立良好的交流也非常重要，它会影响着产品团队。如果你的准备工作做的够好，你也会变得越来越有信心和说服力。

　　第二步：确定产品的目的

　　任何一个好的产品都开始于一个需求。你必须清楚的了解这个需求，你的产品如何达到这个需求。

　　产品经理需要提出一个清晰、简明的价值主张，让它很容易被接受，要让产品团队、管理人员、用户、市场人员清楚的明白这个产品到底是什么意图。虽然这听起来很简单，但是也只有少数产品才有这样的价值主张。考虑“velevator pitch ”(电梯间演讲、电梯行销)测试。假设你在做电梯的时候遇到公司CEO，他问你产品的意图是什么，你能在电梯到达之前回答这个问题吗？如果不能，你就还有工作需要做。也许是你的说明没有针对性，他可能表现出来和其他产品做的没有什么明显区别；也许你提出的观点不能和你的用户产生共鸣；也许你解决的是一个非常规的问题，可能你想应用一种技术。这个价值主张可能需要满足公司的产品战略。注意你不需要阐述太多的细节，从某些方面来说，一个有价值的观点应当是越简越好。

　　 产品需求需要确切的指出这个产品发布的目标，同样的这个目标也有优先之分。例如，你的目标可能是：1）易用，2）零售价不足$100，3）和前期产品很好的结合。然后你需要说明如何去测算。对于“易用”这类项目，你需要明确指出产品可用性达到某个水平。这是通常用目标用户来定义。可用性工程师能测算出你的产品对目标用户的可用性，也测算出可用性问题的严重程度，同样你可以说明没有重大的可用性问题。

　　这里的关键就是让每个人都知道产品成功的时候是什么样，还有给产品团队在设计和实施中遇到问题如何进行取舍的指导。

　　第三步：确定用户原型、用户目标和用户任务

　　现在你已经明白你想要解决什么问题，下接下来就要深入了解目标用户和顾客，在这步中，和你的PD（产品设计）紧密联系非常重要。

　　用户原型

　　在这个阶段，PM需要和很多用户交流，需要花费大量的时间去直接观察和讨论。现在我们需要对用户和顾客进行分类，然后决定那一类是我们的首要用户。

　　比如你正在做一个像eBay一样的互联网拍卖服务，你同时拥有买家和卖家，在这之中还有使用频率少的用户和经常使用的用户，不难想象还有个别特殊的用户，比如团体公司采购者。

　　PM（产品经理）和PD（产品设计）需要首先确定类型是最重要的，然后尽量对这个用户群的特征进行详细的描述，以便使用这个模型去指导产品的设计。这个模型通常称其为“人物角色”。 虽然是想像的，但是应该是典型的、可行的和真实的，让你能够使用。这个想法来自与一个能代表这类用户的本质的原型。

　　举个例子：

　　“里昂是一个超级卖家，46岁，男性，居住在Fresno，经营小型摩托车配件。虽然他开着一个小店，但是他的生意大部分来自Ebay,每个月平均有400多次交易。他出售的东西品种非常多，但是他最受欢迎的商品还是哈雷戴维森的负重袋。他自己拥有两个哈雷，还开着1993年的丰田皮卡。里昂已经结婚了还有两个小孩。

　　里昂买电脑仅仅是因为他需要使用Ebay,除了ebay和电子邮件很少再使用其他东西。里昂已经在Ebay上销售产品已经三年了，他学会了在ebay应该掌握的东西，他非常自豪的拥有超过5000的信用度。如果Ebay更改了网站，特别是销售的过程方面，对于他来说改变习惯、学习这些变更是非常困难的。 里昂已经形成了自己的习惯，星期一列出销售的商品，星期五拍卖结束，设法让在收到货款的几个小时内出货。”

　　但愿这样的描述能让你了解里昂和知道他是怎么来的。当我们考虑新功能时，我就要问问自己里昂会是什么发应，为了让他能顺利的使用这个功能我们需要做什么。

　　注意缩小范围，让他仅仅描绘必不可少的。满足所有人是徒劳的，通常最后没人会满意，所以尽量提出几个最重要的和最流行的角色描述是非常重要的。同样，如果你不去精确的定位你的目标用户，你就只会存在模糊的概念，你会发现理解你用户的反应非常困难。你要倾向于设想，让你能更像你的用户。


　　用户目标（用户意愿）

　　一旦我们确定并描绘了我们主要的用户类型，我们就需要找出用户在使用产品中的目标(想要干什么).这听起来很简单，但是解开根本问题是非常具有挑战性的，特别当你周围的人告诉你你已经解决了他们想要的。

　　从CEO、销售代表、工程师到客户，每个人都太兴奋而不能帮助你找到解决根本问题的办法，他们会告诉你在某个地方添加一个快捷按钮，或则添加一个功能仅仅是因为竞争对手有，或则是改变成他们喜欢的颜色。

　　最好的解决办法取决于清晰的了解到底什么问题需要解决，每个用户模型可能有不同的目的，需要在用户原型涉及的方面中进行寻找。有可能将来某个功能解决的问题并不是主要用户需要达到的目标之一。


　　用户任务（tasks，用户为达到目标使用产品而需要做的任务）

　　掌握了用户原型与他们的目标愿望，我们就开始着手设计任务来满足他们的目标意愿，这是产品制作进程中最核心的部分，也是创造力和创新力被激发的地方。

　　许多优秀的产品仅是用更好更新的办法解决一个已有的问题，有时候这种办法仅仅是应用一个种新技术，但是大部分是来自深刻的见解而使一种新方法的产生。例如TiVo（美国市场占有率第一的数字录像机）在电视节目录制的老问题上面想出一个全新的办法，让顾客更加容易地实现他们的目标并且建立了电子设备一个全新的类别。

　　注意我们虽然谈到了目标和任务但是还没有谈到具体的功能，这些功能都需要达到用户目标而必须的。你以后会发现许多功能都是低优先级或则是完全多余的。

　　以“必须功能”这个理由可以排除很多功能。讽刺的是，你用越少的功能，你的产品被发现得越来越强大。这是因为产品的功能越少，你的用户就会发现并使用更多的功能，成功的使用越来越多的功能他们就认为你的产品非常强大。这些理由都是违反我们直觉的，我们大多数人都不能和我们的用户一样，我们在自己的行业中愿意比用户花费更多的时间去探索功能和容忍复杂性。

　　第四步：定义产品原则

　　现在你需要开始把你的需求和用户体验定义成详细的要求。同时你仍然会面临着许多的决定和权衡，为你的产品标准作出最佳的决定是非常重要的。

　　在大多数的产品团队中，每个成员都有做好产品的原则，但很少有两个人有同样的想法，这些差异都会导致不可思议的结果。
尝试和制订一系列指导整个团队的产品原则是非常有价值的，这些原则需要具体到域名和项目。

　　用TiVo举例，在产品团队工作开始时，以下这些产品规范就被建立，并在团队里传达：

　　　　1.它是娱乐的
　　　　2.一个傻瓜式的电视
　　　　3.一个该死的视频设备
　　　　4.平滑柔顺的
　　　　5.没有模式和深层次
　　　　6.尊重观众的隐私权
　　　　7.像电视一样强大

　　这些规范很大的影响到产品的定义而且在很大程度上加大了难度，但是他们确实是成功产品的来源。比如易趣的口号就是：1、易于使用 2、安全 3、有趣

　　它将在该项目中，在面对众多问题而作出决定的时候进行指南.

　　第五步：产品原型和检验

　　这是一个拿出你想法的阶段，创造力和创新力拿出成就的地方.

　　很多人都容易犯一个常见的错误，他们对产品设计规范太有信心，结果一旦得到beta的测试他们就必须调整产品。但是肯定beta测试版并不是进行重大改变的时候，所以才会有许多首次发布的产品离目标太远。

　　对于许多产品来说，这个时候你可以用大量的原型做很多的实验。首先，下面的三个非常重要的测试你可能需要做

　　可行性测试
　　一个直接的问题就是产品是否可以开发，你的工程师和设计师应当介入技术的可行性调查和探索可用办法。有些办法是行不通的，但是有其他的办法可行是非常有希望的。
　　工程师会发现在产品的某个阶段不可能逾越，现在知道比以后知道要好。

　　可用性测试
　　产品设计师将要和你紧密工作共同提出产品功能，让它能适应不同的用户。可用性测试常常会找出遗漏的产品要求，同时确认产品最初的要求是否是必须的。在你拿出一个成功的用户体验之前需要多做一些测试工作。可用性的目的是在真正的用户身上测试，从产品目标用户得到质量反馈的测试是非常艺术和科学的。当然产品经理和产品设计将模仿使用，但是实际是没有人能取代真实的目标用户。

　　概念测试（Product Concept Testing）
　　光是可用和可行是不足的。真正的问题是你的用户想要购买吗—你的用户有多喜欢-你做的有什么价值。这测试可能与可用性测试联系在一起。

　　对于一部份小产品，您的想法写在纸就足够了，但是对于多数产品，为了预计产品是否达到目标，复杂用户互作用或新技术的使用、某种形式原型都是非常重要的。

　　原型也许是一个物理设备，或者它也许是软件产品的一个预览版本。关键是它需要足够现实，您能用原型在实际目标顾客身上测试，并且他们可以给您质量反馈。

　　以前做原型主要有两个障碍。第一是缺乏良好的原型工具，需要花费很多的时间制作原型；另一个是管理方不知道原型和真实产品的区别，在不可预计的情况下，按照最终产品来要求原型。

　　今天有优秀的原型设计工具可以让工程师或设计师快速的制作原型，可以有效的模拟未来的产品以达到必要的程度让实际用户进行测试。而且大多数管理者都知道模仿和实际的区别 — 就如同缩小比例的房子模型和真实的家一样。

　　在实际去做产品之前去检验你的产品是非常重要的。一旦实际的工程开始，作出重要的变动会变得非常困难，花费也会变得很高。

　　第六步：验证和质疑

　　当你认为你弄懂了你需要解决的问题，现在是时候开始验证和质疑假设。

　　假设甚至当作不知道是很容易的，但是切勿把不可知的结论当作指引，那会妨碍你获得成功。天文学最初定义是研究太阳和其他行星如何围绕自己转，本身的定义就是一个臆断，反而阻止人们获得真相。

　　第七步：写

　　当然你需要把这些都写下来，大多数的PRD都是word文档，但也有一些是帮助文档，PowerPoint，或则写在白纸上。当然用什么格式不是很重要，重要的是让团队成功能轻松的看懂，不会遗漏，还有就是PRD可以随着项目开发而更新。

　　记住对话是两个人之间的，但是PRD是要沟通整个小组。你也要记住获得产品的销售才是是重要的，所以不必担心要有什么漂亮的外观、PRD写的有多厚，只要它是可读的、可理解的、是需要的内容。

　　PRD文档主要有四个部份组成

　　产品用途
　　你的工作就是指出目标，团队需要知道他们的目的是什么，目标说明要尽可能的明确，请确保你的内容包括：
　　*那些问题你要解决，不是解决方案
　　*谁是目标用户
　　*细节很多，但是大图片必须清晰
　　*情景描述
　　多开展集思广益的会议和临时口头的讨论，从而更好的写出来，更会让团队深入了解。

　　产品功能特性
　　产品需求文档最主要的当然是需求。 具体的需求完全地将取决于您的领域，但是不管你是什么行业，您的产品团队将受益于陈述需求的清楚，毫不含糊的要求，而不是模糊的解决方案。
　　描述每个功能的互动设计和使用案例。您必须非常清楚每个功能和用户体验，还需要给工程团队留下足够多的灵活自主空间。
　　同样重要的是确定那些要求满足哪个目的。这里就需要提到“需求跟踪”，对于关键的产品这是一个重要的流程。每种产品规范可能受益于清楚确定那些要求满足哪个目的，如果某人决定削减要求，想要深入了解就会非常困难。 从要求到目的明确说明将会是文档更加清晰。

　　发布标准
　　发布标准经常是不断变化的，但是好的PRD应该考虑到为每种标准定一个最低要求。典型的如：性能，可测量性，可靠性，可用性，可控性。

　　时间进度
　　其中很困难的一个问题就是描述产品需要的时间进度表。随便列出一个时间是没用的，你需要描述环境、动机、预计目标。你需要整个团队都和你一样达到预计目标，最终完成一个成功的产品。

　　第八步 优先级

　　除了明确的要求，对每一个您的要求给予优先和排列秩序是很重要的。多数产品经理，如果他们给予优先级，一般都是表明要求是否是“必须有， “重要”或“希望拥有” (或其他一些分类系统)。分类是很重要的，不可掉以轻心。

　　产品经理对任何一个标记“必须拥有”都需要有高度的标准。如果还没有找到必须拥有的功能意味着产品还不应该产生。所以小心标注“必须拥有”，这些标注“必须拥有”的功能直接反应出产品的核心价值。
　　“重要”的分类也很重要，在产品销售前只要有机会就要满足这些功能。
　　“希望拥有”产品团队也应该注意到，即使大多数也都没有实现，在未来版本也适当的慢慢实现。

　　这些有时候是不够的，从1到n每一个分类优先排序都是很重要的。有几个原因：
　　首先，上市时间总是被关注，并且日程表经常下降，您说不定被迫使削减有些特点为了尽快进入市场。 你也不想产品团队先开发简单的功能而放松重要的功能，导致最后客户使用的关键功能还没完成。
　　其次，在产品设计和开发阶段，团队将会发现更多的问题产生并解决这些问题，所以很有可能有更多关键功能出现。优先顺序会可以帮助你如何平衡以容纳更多的功能。
　　这点就是说产品经理如何不给出优先级和重要等级，其他相关较少的因素也会跟着无法确定。

　　整个PRD是一个不断完善和思维提高的过程，明朗锐利就是可以成功的产品的，模糊就是失败的产品。在争论最激烈的时候也能容易做决定，并且帮助工程师做出计划。

　　第九步 测试完整性

　　现在你有一个PRD草稿，你需要测试它的完整性。工程师是否可以充分了解并达到目标？OA Team（质量管理团队）是否有足够的信息来做出测试计划，是否可以开始做案例？

　　当投资人或相关人审核了PRD，确定了各个需要说明的方面，所有的问题得到解决，现在你就可以按PRD进行产品开发。

　　第十步 管理产品

　　在产品实施期间，就算是最好PRD，也有不计其数的问题被解决。解决所有PRD中存在问题，如果不在PRD中就写进去。你的任务就是迅速解决问题并记录在PRD。

　　如果你做了你的工作并准备记录在PRD，项目审查就会变得非常简单，因为任何一个部份都历历在目。

　　记住PRD是一个“活”的文件，在要跟踪记录在产品开发期间的所有功能过程。最后你会发现很多额外的东西，如果你认为是必要的就在PRD中写进。