admin 产品项目流程和规范, 需求分析 需求收集

[#2: Edit Options>MightyAdsense>Adsense Code]

好的需求需要有好的收集方法，比如如下需求源：
1、顾客
2、用户
3、系统管理员和维护人员
4、合伙人
5、领域专家
6、行业分析家
7、竞争对手的信息

Good requirements start with good sources. Finding those quality sources is an important task and, fortunately, one that takes few resources. Examples of sources of requirements include:

• Customers
• Users
• Administrators and maintenance staff
• Partners
• Domain Experts
• Industry Analysts
• Information about competitors

  需求收集技巧

• 组织头脑风暴会议
• 访谈用户
• 发送问卷
• 在对应行业环境下工作
• 学习类似的系统
• 分析建议和问题报告
• 和支持团队谈话
• 学习由用户所作的改进
• 观察不期而遇的用户
• 引导workshops
• 给股东演示原型
  Requirements Gathering TechniquesTo get the requirements down on paper, you can to do one or more of the following:
• Conduct a brainstorming session
• Interview users
• Send questionnaires
• Work in the target environment
• Study analogous systems
• Examine suggestions and problem reports
• Talk to support teams
• Study improvements made by users
• Look at unintended uses
• Conduct workshops
• Demonstrate prototypes to stakeholders
  将需求快速的纪录下来，然后鼓励用户去说服提高他们，并重复这些需求。马上去做、保持小、立刻改正。最好能够从你设计的结构上开始，杜绝从流程上修正。
  成功的提示：Do it now, keep it small, and correct it immediately.

The best idea is to get the requirements down quickly and then to encourage the users to correct and improve them. Put in those corrections, and repeat the cycle. Do it now, keep it small, and correct it at once. Start off with the best structure you can devise, but expect to keep on correcting it throughout the process. Success tips: Do it now, keep it small, and correct it immediately.

Conduct a brainstorming session

Brainstorming is a short group session where everyone is allowed to say whatever they feel is important to the topic of discussion. After that, a facilitator leads the group in organizing and prioritizing the results. The following basic rules for brainstorming ensures better results:

头脑风暴会议是一个简短的集体会议，与会人员畅所欲言，主持人带领大家进入秩序并优化会议结果。以下是一些基本的规则：

• Start out by clearly stating the objective of the brainstorming session.
• Generate as may ideas as possible.
• Let your imagination soar.
• Do not allow criticism or debate while you are gathering information.
• Once information is gathered, reshape and combine ideas.
• 清晰确定会议对象入手
• 尽可能引导鼓励大家发言
• 让你的想象力翱翔
• 在你收集信息的时候不允许评论或者评论
• 信息一旦收集，就要从新整理和组合
  

  Interview users

  Face-to-face contact with users through individual interviewing is the primary source of requirements and an important way you gather and validate their requirements. Remember that it is not the only possible technique, and that you can conduct interviews many different ways. Develop a repertoire of styles to fit different situations. Unless you use the system yourself, you will need to make an effort to understand and experience the user’s problem to describe it clearly and correctly.

• 访谈用户
  面对面访谈是非常主要的手机需求的方法，但是你不要觉他是唯一可能的方法，也许你可以不同的方式进行。准备一个提纲来应对不同情况吧。除非你自己在使用这个系统，那么你需要努力去理解用户的问题并正确清晰的表达出来。

Send Questionnaires

If face-to-face meetings are possible, they are always preferable, because they provide a better means of uncovering the problem behind the problem. Sometimes, though, face-to-face meetings with stakeholders are not feasible (when developing products for the consumer market, for example). In those situations, consider using questionnaires. Send a set of questions, possibly with multiple choice responses, to the relevant stakeholders, and ask them to complete it and return it to you. Success tips: Keep it short and given them a deadline.

面对面访谈当然是最好的，但是某些情况下发送问卷也是必不可少的，需要注意的是：

1、问卷简短

2、标出截至日期

This technique has the advantage of providing a lot of information for statistical analysis. However, the questions must be well designed to be clear and to avoid so-called “leading questions”, which bias the responses.

能够提供许多分析统计信息，然而需要问题清晰便于回答。

Work in the target environment

Experience the work of the users for yourself. Working with users helps you understand problems that have resisted previous solutions. Familiar systems developed in this way inevitably include tools for programmers, such as interactive editors and compilers, as the developers naturally have both the expertise in the subject area, and the desire to solve their own problems. It would be good to see the same dedication devoted to solving problems in other areas too. Where the work cannot easily be experienced in this way, it may still be possible to do a bit more than just sit quietly and observe. Users can give you a commentary on what they are doing, what the problems are, and what they would like to have to make the work easier.

与用户一起工作可以帮组你理解之前一直反对的解决方案。当你发现之前你是错的话，你就会反省你的错误。即使这样不能完全进入对方的工作，但至少可以容易理解一些问题。

Study analogous systems

The starting point for many projects is often a similar or an existing system. Sometimes, comparable products and systems contain working versions of good ideas for solving user problems. You can save the time lost in reinventing the wheel by looking at systems already on the market, whether they are systems installed at the user’s site or products made by rival organizations. Even if they are trying to solve slightly different problems, they often provide valuable clues as to what you need to do.

竞争对手的产品可能会很好地解决用户的问题，你要用心投入时间在市场上的该类产品，即使他试图解决一些微不足道的问题，他们通常可以提供给你一些有价值的思路。

Listen when a customer asks why a product couldn’t do something that the customer wants, and keep a list of these suggestions. Later, use it to start discussions with other users. You should be able to obtain some requirements directly this way. If not, capture and store suggestions for future use.

纪录并保留顾客提出的关于产品的建议，然后用这些记录作为和另一些用户讨论的话题。通过这种直接的方式，你应该能够获得一些需求，如果没有，也要留下来备用。

You can describe to users selected features of other products. Explain that the system is designed for another purpose but contains an interesting feature, and you wonder it or something similar would help them. Sometimes these systems are described in documents, such as a contract from another organization or a report written for management. Often, these documents were never intended as formal requirements, and were written merely to communicate a stream-of-consciousness idea. Define a process of going from disorganized to organized information.

区分正式需求和非正式需求，非正式需求需要一个流程使之组织化

Such a process might involve the following activities:

• Read the document from end to end (several times) to comprehend what the customer wants and what actually has been written.
• 多次阅读确定哪些需求已经记录那些还没有
• Classify all of the types of information in the document. (user, system requirements, design elements, plans, background material, irrelevant detail)
• 按照用户、系统、设计元素、计划、背景资料、不相关细节分类
• Mark up the original text to separate out such requirements.
• 标记原始文本以便于与需求区分
• Find a good structure for each of the different types of information such as: a scenario for the user requirements, functional breakdown for the system requirements, and architecture for the design.
• 为这三类信息寻找一个好的结构，如用户需求、功能（系统需求）、信息的设计
• Organize the information to show gaps and overlaps. Feel free to add missing elements, but confirm these decisions with the users.
• 说明差距和重叠。悠闲的加入备望表，但是要与用户确定这些决定。
• Create traceability links between these information elements to show the designers exactly what the users want.
• 在这些信息元素之间建立可跟踪的连接，可以准确地向设计师们表达用户所需要的东西。
  Convince the customer to accept the new information as the basis for the contract.
• 说服客户接受新信息作为基础和约。

admin 产品项目流程和规范, 需求分析 需求收集

[#3: Edit Options>MightyAdsense>Adsense Code]

admin 产品项目流程和规范, 网站项目开发, 需求分析 需求

admin 产品项目流程和规范, 网站项目开发, 需求分析 需求

本书结构

1. 了解需求过程
2. 需求模式目录

本文是 了解需求过程 的阅读笔记。书籍地址

需求是定义系统需要做什么而不是怎么做。需求是系统必须满足的单一的、可测量的目标，必须没有二义性，陈述了系统所有需求及任何使温昂更容易阅读和理解的背景材料。

在内容方面，一般包括功能性需求和性能、规格等非功能性需求。对于传统的需求模式来说，一般是：

还有敏捷的需求方式，它应该满足四个基本原则

1. 定义问题，而不是解决方案；
2. 定义系统，而不是项目 ；
3. 区分正式和非正式部分；
4. 避免重复。

按照具体方式分为 极限 和 增量。

与传统的 准备，收集信息，编写需求规格草稿，评审规格 和 评审后修改 比较，敏捷需求流程满足两个指导原则：

1. 区分问题和解决方案是重要的；
2. 定义需求后，一定要记录它以便别人可以找到。

按照实践上来说，极限需求流程要求用户编写完整的用户故事。根据用户故事分配给开发人员，首先编写测试用例(验收测试），以需求的方式写下来，总以它使用需求模式的方法有三种：

1. 为用户故事及其内容提供建议（更准确/更像需求）；
2. 更系统化的方法解释用户故事，揭示需求，同时识别需要增加的额外功能；
3. 指导建立整套“公共需求”，特别是所有开发人员应该遵循的良好实践的规则。

对于增量需求流程，它要求前期做最少的需求工作，尽可能早开始开发。分两点：

1. 前期充分的定义需求，是客户相信已经理解了他们对系统的期望（确信获得业务目标），获得客户批准后进行；
2. 当开发人员准备后开发一个特定的部分时，扩展那部分的高层需求，定义满足高层需求的系统需要的所有详细需求。

在确定需求大致流程后，就进入需求规格的内容，一般来说，分为

在进入的实际的需求工程阶段，总有一些系统需求本质上彼此类似，或者他们出现在大部分系统中，以一致的方式定义同样类型的所有需求是有必要的，因此我们引入需求模式。它定义为：

需求模式：定义一种特定类型需求的方法

使用它，我们可以提供指导、节省时间、并且促进同种需求的一致性。一些需求模式要求或者鼓励定义一些额外需求：跟随性需求、普遍性需求。模式有不同的详细程度和价值，它需要描述什么时候使用模式以及基于模式如何编写需求。还可以提示如何实现以及如何测试这种需求，为了达到目标，包含如下要素：

• 模式名称，唯一的
• 基本细节，声明、领域、相关模式、预期使用频率、模式分类和作者
• 适用性
• 讨论，如何编写这类需求，需要考虑什么？
• 内容，必须描述什么？可能描述额外的？
• 模板，编写可能基于一个或者多个出发点
• 实例
• 额外需求，通常跟随什么需求？普遍性系统级需求？
• 开发考虑，提示！
• 测试考虑，决定如何测试什么时，必须记住什么？

给模式分配有助于条理化，内容上，信息是关于信息存储和CRUD的；数据实体是关于如何处理特定种类的数据；用户功能是一些公共类型的功能，加上易 用性；性能；灵活性；访问控制；以及商业。领域里，有基础架构和领域的关系，每个基础架构概述分为下列小节：目的、调用需求、实现需求。

在几个需求模式有共同的特性时，可以建立一个需求模式组，用于描述共同的方面，它与领域的区别在于，领域中有一个主题，而模式分组有共同的细节特性。

模式之间关系存在两种基本类型：引用和扩展。需求模式可以按照多种方式分类，每个分类都需要定义以下内容：名称、读者、目的、允许值、缺省值。书中 使用三种需求模式分类：功能，普遍性 和 影响数据库。保持每个需求定义在核实的范围内有助于读者理解需求，一个需求到达10个段落就太长了，因此提炼需求，分割成多个部分，使它们变成附加需求。 我们还可以用例和业务规则来精确化模式。

在介绍了模式之后，进入使用和编写需求模式阶段。在定义系统间，可以使用模式：

1. 当定义需求时，是否存在模式可以知道定义需求；
2. 当考虑需求是否完全时；
   1. 当评审需求规格时，
   2. 当评估系统时；
3. 当实现需求时；
4. 当测试需求时。

使用模式，可以根据需要裁剪需求模式，在裁剪时，要建立一个新的需求模式声明。在新的需求模式时，需要慎重，考虑模式的价值。在需求模式的应用中，可以系统化 和 机会化 来发现潜在的需求模式。

如果确实发现了新模式，和信领域，它有一个清晰的主题，看看差异、避免依赖、确保领域中是否需要任何基础架构。在模式编写上，分为如下步骤：

1. 是否有足够的价值
2. 建立模式的骨架
3. 编写模式的“适用性”部分
4. 收集需求实例
5. 检查需求实例
6. 描述需求可能包含的信息
7. 编写需求模板
8. 编写剩下的“讨论”和“内容”不放呢
9. 开发潜在的额外需求实例列表
10. 确定额外需求的候选主题
11. 编写“额外需求”部分
12. 编写“开发考虑”部分
13. 编写“测试考虑”部分
14. 是否值得？
15. 评审模式

admin 产品项目流程和规范, 网站项目开发, 需求分析 需求

对于许多网络创业公司来说，起草网站的《服务条款》(Terms of Service)和《隐私声明》(Privacy Policy)是一件令人窘迫的事情。这两份文档属于法律文件，看起来平时不起什么作用，可是一旦和用户或者其他的公司发生了纠纷，并且有可能上升到诉讼层面，那么这两份文件的作用就发挥出来了。总的来说，法律文件都是防范于未然，尽量为公司免责。然而，请律师起草这些繁琐的条文需要花费一笔不小的费用以及不少的时间。对比多家网络公司发布在网站上的这两份文件，发现一些有趣的现象。 · 形形色色的《服务条款》 Digg的《服务条款》极为繁琐，共有十五则，其中第七则是关于版权的，详细讲了关于《新千年数字版权法案》(Digital Millennium Copyright Act，DMCA) 的许多情况，这让人不由得想起今年五月所发生的Digg叛乱事件。 Twitter在《服务条款》的最后还特别鸣谢Flickr，“这些服务条款的内容灵感来自Flickr，是他们许可的。”（These terms of service were inspired, with permission, by Flickr.”。想起Twitter在年初火爆的时候，网站上教用户如何使用字母D和符号@的FAQ都没有人写，热心的用户只能互相传授Twitter的使用技巧。而Flickr被Yahoo收购之后，点开《服务条款》的链接就直接跑到Yahoo的服务条款页面去了。如果是Pro用户身份登陆的话，则显示很长的服务条款，详细说明关于Pro用户的一些情况。比起《服务条款》，Flickr的《社区指南》是更为人知的文档。这个社区指南的第一条是：請和睦共處。本社群会员众多，背景各异，每个人均有自由使用本社群的权利，而彼此看待问题的角度与观点可能不同。因此，在与其它会员互动时请礼貌待人并相互尊重。 Do play nice. We’re a community of many types of people, who all have the right to feel comfortable and who may not think what you think, believe what you believe or see what you see. So, be polite [...]

对于许多网络创业公司来说，起草网站的《服务条款》(Terms of Service)和《隐私声明》(Privacy Policy)是一件令人窘迫的事情。这两份文档属于法律文件，看起来平时不起什么作用，可是一旦和用户或者其他的公司发生了纠纷，并且有可能上升到诉讼层面，那么这两份文件的作用就发挥出来了。总的来说，法律文件都是防范于未然，尽量为公司免责。然而，请律师起草这些繁琐的条文需要花费一笔不小的费用以及不少的时间。

对比多家网络公司发布在网站上的这两份文件，发现一些有趣的现象。

· 形形色色的《服务条款》

Digg的《服务条款》极为繁琐，共有十五则，其中第七则是关于版权的，详细讲了关于《新千年数字版权法案》(Digital Millennium Copyright Act，DMCA) 的许多情况，这让人不由得想起今年五月所发生的Digg叛乱事件。

Twitter在《服务条款》的最后还特别鸣谢Flickr，“这些服务条款的内容灵感来自Flickr，是他们许可的。”（These terms of service were inspired, with permission, by Flickr.”。想起Twitter在年初火爆的时候，网站上教用户如何使用字母D和符号@的FAQ都没有人写，热心的用户只能互相传授Twitter的使用技巧。

而Flickr被Yahoo收购之后，点开《服务条款》的链接就直接跑到Yahoo的服务条款页面去了。如果是Pro用户身份登陆的话，则显示很长的服务条款，详细说明关于Pro用户的一些情况。比起《服务条款》，Flickr的《社区指南》是更为人知的文档。这个社区指南的第一条是：

請和睦共處。
本社群会员众多，背景各异，每个人均有自由使用本社群的权利，而彼此看待问题的角度与观点可能不同。因此，在与其它会员互动时请礼貌待人并相互尊重。

Do play nice.
We’re a community of many types of people, who all have the right to feel comfortable and who may not think what you think, believe what you believe or see what you see. So, be polite and respectful in your interactions with other members.

同样在被Yahoo收购之后，Del.icio.us的《服务条款》却还是保持简洁的风格。

最简洁的风格看来应该是Mahalo.com莫属。这是由Weblogs Inc.联合创始人Jason Calacanis离开AOL之后所创办的“人类搜索引擎”，他们的清单都保持在十个条目以下，每个条目大部分都只有一、两行。看起来就像是Google的服务条款的摘要了。

最为繁琐的应当是Google了，它的服务条款共有20则，以至于要开辟另外一个新页面专门显示服务条款的摘要。这份最后更新于2007年4月16日的服务条款，第一则的标题就是：“你与Google的关系”（Your relationship with Google）。

· 最酷的《服务条款》花落谁家？

哇，最酷的应该是WordPress.com了！刚刚发现开发WordPress开源Blog软件和运营WordPress.com的Automattic将“创作共用”（Creative Commons）的图标放在他们的《服务条款》和《隐私声明》上。他们说：

请注意，我们决定将如下的服务条款遵循创作共用（Creative Commons）—-保持一致（Share alike）的授权协议，这意味着欢迎大家把它“偷”去改头换面成自家宝贝！只是你需要像我们一样将修改后的内容做同样的声明，我们也乐意你在自己网站的任何地方加个链接到WordPress.com。我们花费了大量的金钱和时间弄出这个家伙来，大家现在可以省省事儿了：）

创作共用-保持一致（Creative Commons Share alike license），这个条款的要求是：

如果您改变、转换本作品或者以本作品为基础进行创作，您只能采用与本协议相同的许可协议发布基于本作品的演绎作品。

仔细一想，Automattic与自由文化运动的关系是很密切的，WordPress是一款开源的Blog软件，而Blogosphere则是支持自由文化运动的中坚力量，他们这样的举动也不足为奇。一间公司的品牌个性往往不是依靠宣传包装出来的，而是公司长期的做事风格营造出来的。言行一致是创建品牌的奠基石。

这里看大图。 这里看大图。

那么，大陆的网络创业公司，哪家会在花了大价钱请律师起草《服务条款》和《隐私声明》后，又将它们以“创作共用”（Creative Commons）方式授权出来呢？！

admin 产品项目流程和规范

     需求分析是指理解用户需求，就软件功能与客户达成一致，估计软件风险和评估项目代价，最终形成开发计划的一个复杂过程。（这个和我在微软体验到的又不太一样，微软的需求分析大多是市场人员和用户协助小组的人去评估用户的接受程度，这一点也可以理解，因为公司的性质有根本差别）在这个过程中，用户的确是处在主导地位，需求分析工程师和项目经理要负责整理用户需求，为之后的软件设计打下基础。需求分析阶段结束后，要求得到：1.SRS文档(System Requirement Specification); 2.DRM 文档；3.Acceptance Plan.

admin 产品项目流程和规范 产品原型, 产品经理, 需求分析

【内容摘要】1引子太多了！终于签下合同–>得到了“正式”的客户提供的“需求书”的几片纸–>凭借自己的理解立即投入开发–>“木已成舟”，生米终于熬成粥–>用户拒绝接受？–>艰难地修改，反复修改，开发人员厌倦了，而用户对系统用之无味，弃之可惜，遂成鸡肋。– ……
—————————————————————————–

1 引子
              
 太多了！终于签下合同–>得到了“正式”的客户提供的“需求书”的几片纸–>凭借自己的理解立即投入开发–>“木已成舟”，生米终于熬成粥–>用户拒绝接受？–>艰难地修改，反复修改，开发人员厌倦了，而用户对系统用之无味，弃之可惜，遂成鸡肋。–>由此后期收款遥遥无期，软件公司不再和用户保持沟通–>互相埋怨，扯皮由此而生。或者，一个项目拆成为多期，从而收取一部分款项，而很多的开发都作废。这样的案例真是何其多也！
 究其主要原因，与其说是没有搞定关键客户，或者项目管理不当，不如说是没有帮助客户解决其问题，对客户真正的需求研究不够。实际上，原型方法是解决此类问题、确保项目成功的最佳途径。
 
 我在写此文的同时，也试图寻找资料，不知道是本就没有，还是自己所不幸而未找到。看来原型并没有明确的标准，而目前不同软件公司的理解和做法各不相同也就不奇怪了。但从软件过程的角度来考察，原型法仍有着通用的优化的做法。本文试图从作者的实践经验出发，对原型方法进行思考与探讨。
 另外，本文是发散型的，在研究原型的同时，也讨论了原型相关的内容。原型本质上有些象是抛砖引玉，而本文也旨在抛砖引玉，但无意于一概地论定什么。              
2 什么是原型             
2.1 原型的定义
              
 原型(prototype)即把系统主要功能和接口通过快速开发制作为“软件样机”，以可视化的形式展现给用户，及时征求用户意见，从而明确无误地确定用户需求。同时，原型也可用于征求内部意见，作为分析和设计的接口之一，可方便于沟通。
 
 2.2 原型的主要价值
 
 原型法主要价值是可视化，强化沟通，降低风险，节省后期变更成本，提高项目成功率。一般来说，采用原型法后可以改进需求质量；虽然投入了较多先期的时间，但可以显著减少后期变更的时间；原型投入的人力成本代价并不大，但可以节省后期成本；对于较大型的软件来说，原型系统可以成为开发团队的蓝图；另外，原型通过充分和客户交流，还可以提高客户满意度。
 
 2.3 基本要求
 
 对原型的基本要求包括：
 
 * 体现主要的功能；
 * 提供基本的界面风格；
 * 展示比较模糊的部分，以便于确认或进一步明确，防患于未然。
 * 原型最好是可运行的，至少在各主要功能模块之间能够建立相互连接。
 
 2.4 处理方法
 
 原型的处理方法基本上有2种不同类型，即抛弃型和演化型（不同的软件工程书籍称发不同，实质意义则类似）。可以抛弃原型，在取得的明确需求基础上重新开始设计与开发；也可在原型的基础上继续开发。一般小项目不采用抛弃型原型，否则成本和代价似乎会偏高。
 
 2.5 表达工具
 
 原型的表达工具可以有很多，如果是演化型的原型，当然优先选用软件本身的开发工具。否则还可以应用各种快速显示的工具，例如，HTML，Powerpoint等等，只要能够充分而形象地表达就可以了。
 根据笔者的经验，在原型系统中，可以采用一些与常规不同的做法，例如，可以在界面上比较显著的地方写明当前模块或界面的主要目的，由哪些角色操作，能解决其什么问题。这么做可以使得用户或开发团队成员一开始就有非常清楚的概念；又如，对于决策分析，你可以直接把一些分析结果画成图，并且配上一些文字说明，这样可以避免输入大量初始数据，等等。              
3 原型在软件过程的地位
              
 软件的根本目的是实现用户的需求，提供用户日常使用，解决用户工作中有所不便的问题，提高其工作效率，改进质量，加强管理控制，最终直接或间接地提高其效益。因此软件开发本质上就是需求的处理和实现，而软件原型对需求确定来说具有非常重要的意义。原型方法包括2个基本过程，即原型制作和原型评价。              
如果从需求角度看软件过程，我们不妨可以把软件过程这样划分：
                
                 3.1 需求收集和分析
                
                 搜集需求得到需求说明书，了解软件要做什么，做成什么样，解决用户什么问题。
 这时候软件公司以书面文档方式提出，例如需求问询表等。
 
 3.2 提供原型并进行评价
 
 制定原型开发计划，根据用户需求及不确定的高风险部分进行原型开发，在内部进行原型评价，请客户进行原型评价，以保证确实反映了用户的真正想法。
 
 3.3 实现需求
 
 当前的软件开发过程常常采用迭代方式进行开发，逐步求精，以降低风险和成本。对迭代的次数，每次迭代的里程碑，要实现的目标，及可提交的成果必须有可验证的清晰的计划。项目管理是一种艺术，迭代规划及里程碑定义都是一种挑战、一种艺术，但项目管理不在本文讨论范围。
 
 3.4 需求变更
 
 需求变更是正常的，也是难免的，应允许用户和开发团队自身对需求进行变更。变更处理的关键在于跟踪和控制，如何使产生的影响应得到控制，这属于配置管理的内容，也不在本文讨论范围。
 
 原型在软件过程中的定位如下图所示：              

                
                
                
 图1 软件原型的定位              
实际上我们可以把原型看得更为广义一些。任何用户或者内部演示的材料，都可以看作为原型。例如，如果你的产品是某种通用的或者行业解决方案，虽然你其实还没有产品，但先做出一个原型，再加一个漂亮的白皮书，就可以在市场上进行预销售了。
                
 对于抛弃型和演化型原型来说，也不是绝对的。演化型原型中必然会不断抛弃一些内容，而抛弃型原型，尽管在完成历史使命后不再使用，但很多思想以及部分设计还是可以继承的。              
4 原型方法的一般过程             
基于原型方法在整个需求过程中的地位，我们需要把原型法和需求处理放在一起进行讨论。采用原型法的一般过程如下图所示：              
             
图2：原型法的处理过程              
在上图中已经清楚地描述了原型的处理过程，值得一提的是，原型不仅用于给用户或者最终用户进行评议，同时完全可以在公司内部组织评议，看看我们周围吧，多数程序员对技术的兴趣远远高于对需求的兴趣，因此其对系统的理解并不会比市场人员或者项目经理理解的深多少。这里的公司内部人员角色可以包括很多，系统分析员/程序员自身、项目经理、部门经理、用户代表、领域专家、测试人员等等，不同的角色往往会在其不同立场对系统提出中肯的意见来。
 另外值得注意的是界面设计的引入。我们认为将界面风格在原型阶段即进行基本确定是一种优化的做法，因为软件前期对界面的确定可以避免后期开发时对界面进行统一调整所带来的不必要的成本花费，良好的界面也可以使客户增加对系统的好感，当然，但愿用户不要只是欣赏界面而忽略了他们对系统功能的思考。要知道，如果仅仅是让用户看到美观的界面，那么整个原型几乎是白做了。
 
 
 5 使用原型方法的相关问题探讨             
5.1 为什么要采用原型法？
                  
               原型对一个项目取得成功具有重要的意义。俗话说：隔行如隔山，实际上软件公司很难保证其制作的软件正好就是用户所需要的，用户也很难一次性把其真实的要求完全提交，开始阶段提出的往往只是对系统的期望，和比较模糊的设想而已。而原型系统为用户提供了一个靶子，看着原型系统，用户往往就能进一步提出他们的真正想法。显然软件公司明确用户需求的最佳方式就是为用户提供原型并由用户进行评价。
 也许，跳过原型可以节省时间和前期成本，但你应该注意到，跳过原型的话，后期变更的成本会明显增加。
 
 5.2 为什么在需求说明书之外需要原型？
 
 1）眼见为实，文字具有歧义性，不同的人理解都不相同；
 2）最终用户往往在看到一套可运行的系统的基础上，才可能提出其真实的意见，如果到最终提交时才看到这样的系统就为时太晚。这也是以前无数软件开发留下的教训；
 3）便于发现问题，及时纠正；
 4）便于进一步展开，并取得用户的细节需求；
 5）体现原型的其它功能：便于公司内部如经理、市场部等对软件提出意见，便于开发人员对整个产品达成统一认识，等等。对内部人员来说，同样地，一套形象的原型也远胜过一堆专业术语文字；也就是说，原型对软件公司内部也十分重要。这些评价工作无形之中改进了项目质量。              
5.3 原型方法有什么风险？
              
 任何方法都是有利有弊，在我们可以探讨一下原型方法可能存在的风险。以下是一般软件公司所担心的风险：需要付出前期进度和人力成本；由于程序员对问题的不了解而效率低下，受客户牵制而在原型上反复修改；因为仓促设计而做不利于进一步在其基础上继续开发；由于过早展示原型给客户，使得客户可能提高其期望值，并提出更多离谱的要求，等等。
 
 值得一提的是原型方法的主要价值之一就是尽早揭示软件中可能存在的风险及不确定因素，尤其是关于用户需求一致性方面的风险。              
5.4 原型方法和其它方法或过程的关系如何，是否一致？
              
 生命周期法中并不包括原型，或者说没有明确提供原型的概念和定义。原型可以认为是需求分析中的一个子部分。另外，应该说原型方法是对生命周期法的有益补充和完善。
 RUP中是最优化的统一软件过程，但RUP中似乎没有提到原型，RUP的核心过程是在迭代中精化。我个人的见解是，原型非常类似于第一次迭代的过程和结果。实际上，如果把原型看作为第一轮交付的成果，那么原型的很多不利之处，诸如花费前期成本等等，这些担心都将变得不复存在。
 XP方法对原型非常推崇，这是因为XP方法非常强调需求的重要性，甚至要求客户参与开发过程。但原型方法和XP也有区别。XP是分批交付，先做一个几个功能点的版本，完成后再每个开发周期往上面加其它功能点，而原型法一般要求做出比较完整，能覆盖主要功能点的粗略的版本。XP方法仁者见仁，智者见智，不一而举。              
5.5 如何避免项目团队做原型的时候出现部分人员闲置？
              
 在项目管理中，对人力资源的调配应和项目进展相匹配。实际上在用户接触到原型制作的同时，可以进行项目计划、架构设计、技术培训以及技术难点攻关等等。
 如果从广义上理解原型的话，架构设计者甚至可以设计出一种用户开发团队使用的所谓框架原型，包含了主要的设计成分、模板和示例。
 比较理想的结果是，当原型完成后，需求分析、架构设计和界面风格设计都趋于完成，从这一点可以看到，原型方法可以作为快速软件开发的重要手段。              
5.6 如果避免项目在原型上停滞不前？
              
 应使用有经验的开发人员，避免因为程序员不熟悉业务而延误进度；不要在界面设计上犹豫不决而占据时间；如果用户对原型提出了很多意见，其中部分比较明确的意见可以在开发过程中进行实现；和客户的交流应该简洁明了，而不是似是而非；另外，原型方法在项目过程中占据的时间应该在项目计划中保留出来，而不仅仅是隐含在需求调研与分析的一个部分。              
5.7 如何避免用户看了原型后漫无边际地提要求？
                
 首先，应该充分尊重客户，想想其它行业的服务质量吧。有没有听说过这样的说法，项目管理也是客户满意度的管理；软件是一种对客户的关怀，等等。确实，客户提出的思路可能和你已经形成的思路不同，一下子打乱了你的思路，也许项目经理并不介意，但这确是让设计者特别心烦的事情。如果确有把握，或者你可以不做到原型中去。有时候，即使原型很完美，用户也会额外地提出一些意见，这也是人之常情。但不管怎样，你不能认为用户根本不懂软件，让他们到时用就行了，抱这样想法的多半会付出代价。
 
 其次应该进行坦诚协商，多数用户其实都是通情达理的。如果你在签订合同时答应满足任何要求，而此时又无法忍受用户的要求，那么孰是孰非应是题外之意了。一般来说，比较合理的做法可以通过增加费用、延长进度或者把需求实现分阶段来提交，以保持工作的延续性。对有些软件，尤其是信息管理系统来说，客户的实施时间其实并不是主要的，客户最需要的不是及时，而是合用。
 
 其实，客户有着很多种类型，确实，个别客户会参考同类产品来提要求，极个别用户并不真正懂得计算机技术而对技术路线、技术手段等提出其意见，等等。但我们为什么还可以反过来想一下，如果是等到软件全部提交的时候，这部分用户仍有会提出同样的意见。提早暴露并解决分歧，对双方睹是有利的。如果软件公司明知可能存在矛盾，仍然先做好，然后等到用户提出反对后，再提出补充收费，如果喜欢，也无话可说。
 
 总之，原型应本着对软件需求的基本理解来做，这样才能预防不一致性的发生。尤其应该针对不清楚的地方制作原型，从而尽量暴露问题，引发用户的联想，不能回避问题，掩盖问题（以免用户提出太多的想法），很多问题虽然一时掩盖了，但最终还是要发生的。              
5.8 如何避免在原型基础上继续开发时的可维护性降低？
              
 问题是这样的，制作原型时常希望快速提供原型，往往不及对软件结构或者数据库进行细致设计。所以在此基础上继续设计和开发的话，有必要在开发前先进行调整。同时，在设计原型前就有必要确定，该原型是要抛弃的，还是要演化要继承的。对于要演化的原型，其设计不能过于粗略，显然这直接影响到今后的开发成本。              
6 小结
              
 原型方法是可视化的方法，已成为快速软件开发常用的手段。软件公司或部门一旦得到了原型方法的回报，就会坚持使用。原型不是绝对必要，但非常有意义。
本贴来自天极网群乐社区–http://q.yesky.com/group/review-17600505.html

admin 产品项目流程和规范 UML, 产品原型, 产品经理

写这个的目地，主要是系统理下目前产品设计的流程,提醒自己尽量去避免一些常见的问题，也能让大家系统的了解天极网的产品设计流程。当然，不保证任何产品都能套用这套方式，主要还是跟据自己工作性质来定。也许这段文字会比较枯燥,希望阅读下去能给大家带来一些启发。

如果当中有问题及更好的方法，请邮件(peter.xiao999#gmail.com )或加我MSN(pitiaoxiao#hotmail.com)联系.

先从沟项目人员说起吧,项目需要沟通的部门基本是:需求部门(比如:产品经理，某频道负责人或主编) 、销售部、程序部。涉及到我这边主要有:UI(界面设计) 、UE(交互及用户体验) 、 UID(制作) 、SEO(搜索引擎优化)。

大多数产品都是由需求部门提出,当项目完成审批流程后,就会交由产品负责人直接和我们(目前天极网UE还处于起步阶段，我主要扮演UI及兼任UE的职责)进行沟通,进行可行性评估,经过N次讨论后确定结构、风格、功能、并确定开发周期及最终的上线时间。

每个产品主要经过以下几个阶段：

1. 可行性评估
2. 产品原型
3. 产品界面设计
4. 规范整理、功能实现
5. 产品上线
6. 分析报告、优化方案

针对每个环节细化，我将拿出近期的 ChinaByte产品库 项目来做进一步说明 ，相关地址：http://www.webdoc.com.cn/demo/p/

一　可行性评估

主要执行人员：UI、UE、需求部门、程序部
需沟通人员：销售部

当产品经理确定基本的思路后,会先会跟我们沟通，并说明这个产品的思路、受众及一些自己的想法．接着会拿来一个结构图来和我们探讨实现方面的可行 性。我们也会准备相关资料与其进行沟通，主要会从数据报告、功能性及可行性三方面下手，在探讨的同时会指出功能或结构上的一些问题，并提出改善方案，这步 一定得仔细，UI、UE深入探讨并尽可能考虑到每个实现的细节,待框架打好后,出好的产品很容易.但如果在可行性评估上出现隐患,余下的其它工作也将会遇 到诸多问题。

我们主要从以下三方面进行评估:

1. 数据报告
   通过99Click、Netratings、Counter三套系统来进行数据收集，并在分析报告中指出相应的问题。
2. 功能性
   站在用户角度上，对方案的结构及功能性进行评估，提出并解决操作上的问题。
3. 可行性
   每个产品初期都是感性的，但在不能保证每个功能都能按原有思路进行实现，具体还需要和相关技术     人员进行探讨、碰撞后形成最终的产品思路。

由于各人思考问题的角度不同, 这个环节常遇到大家意见不统一情况，在我接触的项目中，很多产品经理都会将个人喜好溶入到产品设计思路中，如＂颜色用红吧，这样显得比较跳跃＂，＂按钮上 加下样式，太不吸引人…＂，跟据自己的经验判断，如果认为不可取，会尽最大能力去说服对方，当然前提是把自己的位置摆正，站在中立的角度上去审视产品。

顺便谈谈沟通，相信大家经常会遇到和产品经理矜持不下的情况，这时用理论及实际案例去说服对方基本是无效的。建议可以采用一对一的方式单独沟通，遇 到问题先记下来，放到会后进行单独讨论，人都是要面子的嘛。只要让对方意识到你是在帮他改善问题后，接下来的沟通就会比较轻松。在之前在做 Yesky产品库 时自己也经遇到这类问题。总之，说服的方式有很多种.无论是威逼还是利诱,前提一定是我的这种方式是可行的,实用的。

二 产品原型

主要执行人员：UI、UE、需求部门
需沟通人员：程序部、销售部

在产品原型方面,主要指的是黑白稿或线稿，除了颜色基本采用黑白的形式，最终出的产品原型将会和实际产品没区别。这个环节会拟定出产品页面的宽度,广告的形式,导航基本样式,各内容的区域的表现形式等…

当经过可行性评估阶段后,产品经理的思路和自己也基本达成共识，接下来将进行原型设计，我将主要分为三个步骤来实现：

1) 　纸稿

一般情况下结构图都是采用word文档描绘，我选择笔和纸的方式，主要还是比较方便、易修改，有任何突发的思路只需要擦一下，就可以直接在已有的基础上进行调整，由于之前的讨论没有实物参照，在这个环节你一定会发现更多有趣的问题。

2)　线稿、黑白稿   

当纸稿确定后，则由UI或UE使用做绘图工具来描绘黑白稿(我主要使用Photoshop来进行这个步骤，跟据个人习惯不同，大家的方式也有所区 别，比如淘宝UED Team及Baidu UE更多的则采用线稿的形式)。也许是做UI的原因，我习惯还是采用黑白稿，方便界面设计，在结构上也会精确到像素,比如:导航高度40px.头条采用 20px黑体,图片规格:104×85px,页面的各区域的留白为5px…等等，只有这样才会发现更多细节上的问题，当然到界面设计的同时你也会尝到更多 的甜头。

3)　原型

完成以上的二个步骤后,产品的基本功能,结构,规范都已经大致成型.这时你可以叫上程序部、销售部及需求部门产品经理，在白板上对着黑白稿做最终的讨论。经过二次、三次调整，最终定下完整的产品原型。

另外，值得提的一点是，在产品原型未确定前,千万别急着去做界面设计,因为之前的讨论主要会通过白板、Word或纸稿。在原型未确定前，有很多潜在 的问题表现不是很直白，比如：”窄了、窄了，完了，新闻列表只能放八个字”、”广告放不下了”、”数据提不出来，目前没这个接口…”。如果提前进入界面设 计的环节,一但有问题，就意味着重新又需要找产品经理、技术部、销售进行再次沟通，这个步骤是很烦琐的,也会让人很郁闷的。

三 产品界面设计

主要执行人员：UI、UE、需求部门
需沟通人员：UID、SEO

目前产品的雏形已基至的本成型，虽然还没华丽的外衣，但凹凸有至身型已隐约可见。下一步将进入界面设计阶段.设计师们也将再次体会到黑白稿给他带来的各种便利.

1)　UI
我的习惯是,主要针对首页进行风格设计，并出3-4套界面,最终挑选出2套左右提交给需求部门,同时也会指出自己最满意一套，和需求部门进行二,三次碰撞后,最终拿出定稿。

点击放大

更多请访问：http://www.webdoc.com.cn/demo/p/

2)　UE
UE则开始针对原型进行操作上的优化调整,召集用户并组织头脑风暴,收集到相关意见后，由UE整理出交互及用户体验方面改善意见,并反馈给UI及需求部门。比如:”这个文字需要加下划线”、”按钮上不要加样式,反而没有点击的欲望了…”。

3)　UID
UID即开始着手准备制作方面相关文档.并提出实现方面的意见.等待效果图最终确定后,则开始相关代码的编制(CSS+DIV、AJAX、Java)。

4)　SEO
SEO则根据原型提出搜索引擎优化的意见,为制作阶段代码优化做准备.

这个阶段一定要保证与需求部门沟通到位,当产品界面最终定稿后,建议再组织一次讨论,这次用户面对着是实实在在的产品,所感受会和之前有所不同.对产品效果上来说,这次的讨论也会有不少收获。

四 界面设计规范及功能实现

主要执行人员：UI、UE、程序、SEO
需沟通人员：UE、销售

1)　设计规范
考虑到在动态实现方面,光凭效果图很难直接的给予表现，这时需要配合使用说明文档及设计规范规范来做辅助。比如按钮及文字链在触发前后的样式,文字间距…。如下图：

2)　代码及程序开发
由UID进行页面的代码开发（CSS+DIV），并需严格参考SEO理出的相关规范，针对一些AJAX的动态效果还需要程序部人员协助完成，当静态HTML完成后即由技术人员进行程序嵌套，并实现预期的功能。
这个阶段由UI、UE全程跟踪，保证HTML和设计稿最大限度相似前提下，对已实现的功能进行测试，并出交互设计改善文档，提交给技术人员。

五 产品上线

主要执行人员：需求部门
需沟通人员：UI、UE、程序、销售

这个阶段主要是内容的添加，主要由相关频道编辑完成，对于软性广告位这块还需要和销售进行协调。完成内容添加后，由需求部门、UI、UE进行核查，在保证和内容、功能完整后，进行整体上线。

六 分析报告及优化方案

主要执行人员：UE
需沟通人员：UE、UID、程序、需求部门、 销售

产品上线后，由UE进行数据及意见的收集，在二周后出相关改善文档，协调各部门进行优化的工作。

在产品设计中我基本上都是采用这套流程，也希望和大家同共探讨。
这篇文章没啥外链，还是来点吧，推荐看下 白鸦的Blog。

admin UI&UE, 产品项目流程和规范 UE, UI, 产品原型

这几天新到一个公司，投入他们的产品线开发，几天下来发现旧系统分层结构中竟然没有BO层，任何VO的变动都会影响相应的业务层发生改变，可能变动仅仅就是加了一些字段。

整个公司统一采用powerdesigner做设计，完全就是忽视概念模型，通通的采用数据库建模，之前工作的一家公司也是一样的设计方式，甚至这边，很多公司都是这样，而且基本都是一些大公司。

郁闷的，整个系统最稳定的概念模型层没有，除了基本的曾删改，很多业务逻辑都需要通过SQL去实现，一旦VO或者业务逻辑发生小许改变，系统就变得很不稳定。

而且这些公司做的还都是移动电信BOSS之类的系统，业务极端复杂，数据库模型已经复杂到根本没办法很好的表现业务模型。理解起来非常费劲，简单的问题都被复杂化到无以忍受。根本没有可能进行组件级的复用，产品化起来太困难了，都是通过配置来写差异化代码。

个人觉得，项目设计中最重要的就是设计概念模型，抽象业务，坚决抛弃powerdesigner建模，不过倒是可以用它设计数据库实现，维护数据库更新。还有就是，OR-Mapping在设计中太重要了，就是要通过它强化对象模型，弱化数据库模型，我本人设计倒无所谓，就算不用OR-Mapping框架，也会按照这样的思想去做，但是开发新手往往做不到这点，没有OR-Mapping框架去限制他，往往项目搞久了，后面的东西不成样了，我总在公司强调在业务层建模，再去设计数据库，没办法，似乎大家都习惯了，认为设计数据库就是设计系统。

—-

很遗憾，目前的很多公司，不论大小，数据库建模还是基本都在用，也都在用java做很多面向过程的编程，他们要的不是过程，只是结果。做出来东西就是好的

——–

工具只是手段，重要的是思想。 思想是：面向对象的分析设计 如Evans DDD 工具：适合面向对象的分析设计的UML工具就可以。

——–

这只是你对PowerDesinger不了解罢了，我一直都是用它来进行思考、设计的。谁说它没有概念模型，只是你不去设计而已。我使用PowerDesinger的设计步骤基本是这样的:先设计概念模型，然后通过概念模型直接生成数据库设计模型和POJO类设计模型，然后在生成好的模型基础上再做进一步改进

——–

可以用starUML,免费，开源，而且也比较小，比Rose小巧得多，而且也支持UML2.0，只是是英文版的，好像没有中文版。它绝对是免费的UML工具中比较好的一个了。

admin 产品项目流程和规范, 网站项目开发 建模