我举个例子，以一台ATM机为例。

第一个问题：ATM机提供什么服务?

ATM机的核心服务：取现金

第二个问题：一台ATM机的设计，有哪些特性?

在这个问题上，很多产品经理，会有这样的想法。
他经过深刻观察与思考之后的用专业态度来回答：ATM机的前端界面，是公司形象，还是操作提醒;从第一次操作，到拿到钞票，需要几步达成;提醒放在哪个环节出现，声音提醒还是字幕提醒;先取卡，还是先取钞……这些特性，叫显性特性。

ATM机，还有关键特性。是隐形特性。比如，一台ATM机里要放20万现金。也就是说，如果一个银行提供100台ATM机，那么他要把2000万现金放在外面。所以，看似ATM机分流了银行的营业压力，提升了品牌曝光，同时也分流了公司的核心资源。

因此，如何统计数据同步数据，支持决策，让ATM机发挥战略价值，同时不让资金过多闲置，是一台ATM机设计的隐形特性。也是核心服务。

第三个问题：一台ATM机，服务的全流程是什么?

作为一个用户体会到的一台ATM机的服务是，查卡，输密码，输金额，取钞，打印凭条，退卡。如果有问题，拨打服务热线。
作为一个ATM机的服务提供者，为了让用户持续稳定的获得上述简单的服务，日常操作性的服务流程包括：

• 现金管理：保证ATM机里随时有钱。包括了数据、现金出库、运送等复杂流程。
• 硬件管理：电源工作正常，打印机工作正常，打印机的纸、油墨耗材正常…
• 客服管理：遇到客户问题或者投诉的处理全流程。

这时，回到更重要的问题：战略问题。

银行为什么要提供ATM机的服务?

1. 第一是为了分流营业网点的取现压力。
2. 第二是更多的品牌曝光机会。

因此，每一台ATM机，对银行这个服务提供者来说，必须具备战略价值。
这就是数据统计的运营意义，不单纯是让管理运营的人知道，某台机器没钱了，再不补现金进去，客户要投诉了。还要按照数据了解，这个服务点的设置，是否有足够的客流，是否达到战略要求。该增加服务，还是裁撤这个网点。

因此，我们觉得像空气一样简单流畅的ATM机，正常运转的背后，有7个以上岗位，在保证它的持续稳定服务。

如果以每次取款2元收入计，一台ATM机的总体成本回收期大约是10年。
过分强调显性特性的，是初级的想法。过去，我最怕的就是听谁说，我们要改版了，新版哪天……显性特性很重要，但是显性特性救不了你。把核心资源与时间，放在一次次优化显性特性上，基本上是互联网初级从业者的狂热症。

不能由衷有兴趣有热情地研究用户的，我们的产品经理就没机会长成产品专家。

我觉得腾讯内部以“服务”来定位自己做的每件事!

我们很多人觉得自己是乔布斯传人，大神的子孙。会以自己为中心，以自己的认知和感受来设计一个产品该是什么样子。
而腾讯，最应该谈的是服务。服务是以服务对象的需求和满意度为中心，定义所做的一切。

放下自己，研究服务对象。如何研究我们的用户，我们的对象，我们应该有一套科学的方法，及硬性指标。

我们的每个产品经理每个月是不是要做10个用户调查,关注100个用户博客,收集反馈1000个用户体验?我觉得，是非常有必要的。怎么做?比如通过我们自己的反馈工具，或者通过像问卷网这样的第三方平台等等。

这是2014年腾讯内部一次会议马总的分享，他认为：研究用户，听取用户反馈，多做用户调查，这是每个产品经理的必修课。

编者按：戴维·米尔克（David Mierke）是ÄKTA高级用户体验研究人员，ÄKTA是总部设在芝加哥闹市区的数字产品用户体验设计与开发咨询服务公司。

您喜欢苹果还是香蕉？喜欢咖啡还是茶？喜欢意大利辣肠还是奶酪披萨？问题问的简单，回答起来也就很简单，每一个硬件厂商在研究和开发产品时，他们的梦想就是能获得这样简单的回答。“只要告诉我你想要什么，我就会做出来。”快速，便捷，简单。

但问题也就来了：通常情况下，产品开发并不是一个快速、便捷和简单的过程。尽管厂家会诱导用户回答这些问题，不过提出这样的问题往往会伴随着某些潜在风险，导致结果出现偏差，错过某些信息，最终可能还会导致产品的失败。以下即是向用户直截了当提出问题或许是一件极为危险的事情的三个主要原因。

用户并不一定知道自己想要什么

你之所以不能简单地问用户想要什么东西，第一个原因就是他们并不一定知道自己真正想要什么。已故苹果联合创始人史蒂夫·乔布斯（Steve Jobs）曾经说过这样一句被广为传颂的话：“只有在产品面世后，人们才知道他们想要什么。”

通常情况下，相比让人们想象还不存在的东西，让他们看到并评论放在面前的实实在在的东西更容易一些。这意味着，这种东西既可以是开发用于可点击演示的功能齐全的原型产品，也能是简单、手绘“屏幕”，用以帮助用户感受某种体验。

除此之外，用户还很难在头脑中形成他们想要或需要东西的大概轮廓，特别是这种东西还与他们并不经常想到的话题有关的时候。人们往往习惯于使用他们知道的东西，正因为如此，某些产品吸引用户注意力所用的时间可能会更长。

人类对培养模式和习惯的渴望

直截了当向用户提出问题带来的第二个风险是，人类对培养模式和习惯的渴望。西格蒙德·弗洛伊德将这种现象称为是“强迫性重复”，即人类会从熟悉的东西中寻找慰藉，渴望重新回到之前已知的事物状态。

比重回早前事物状态更令人满意的事情是，保持对某种习惯的渴望。在《习惯的力量：为什么我们这样生活，那样工作》一书中，《纽约时报》记者查尔斯·杜希格花了很大篇幅来描述产品和相关习惯的各种例证，并利用“提示→惯例→回报”图表来阐述人们形成和保持某些习惯背后的心理原因。

这些习惯有时是长期形成的，试图改掉旧有习惯或形成新习惯是一个极为困难和微妙的过程。在对用户实施调查的阶段，我们应该避免提出可能不利于用户当前习惯的问题，而尽量问相关的问题。

例如，为了了解一个人如何组织派对或旅程，我们可以让他们谈一谈自己通常是如何去购物的。这样一来，我们就可以通过上下文来理解他们是心思缜密的人（这类人会提前在纸上写下想要购买的东西，然后直接到货架上挑选这些东西），还是说他们做事总是很随性（随意穿过一条条过道，看到自己喜欢的东西就放进购物篮。）

我们不应是要求人们想象一个改变他们当前生活习惯的“新世界”——此举可能会让对方产生抵触情绪——相反，我们应该去更好地理解他们的自然倾向、当前的心理状态和偏好，最终带来更为丰富和更具洞察力的信息。

我们取悦于别人的迫切需要

最后一个风险是，人们对参与某种活动以及受到别人喜欢的渴望，以及取悦于别人的迫切需要。虽然相比另外两个风险，这个风险稍微容易克服一些，但对了解这种行为如何对个人产生影响，导致结果或信息出现偏差，仍然是十分重要的。

在调查中，他们往往会以某种他们自认为能回答这个问题的方式来作出回复，或是干脆提供一个他们认为是“正确”的回答。产生这种结果的一个主要原因是，对方提出所谓的“诱导性问题”。换言之，在向用户提出问题时，对方只给出一个或两个问题，让他们直接做出回答。

同样，像“你喜欢咖啡还是茶”这样的问题，不会给你原创的思考或回答留有太多的空间，因为这个问题太死板，也为各种回答预设了条件。此类问题会给发现人们对某个话题的真正想法设置了一个障碍，最终只能起到适得其反的作用，即便获得了什么信息也没什么用处。

对用户进行采访应该更多地被当作交谈，而不是调查或拷问，只有这样才能赢得他们的共鸣，让他们心甘情愿去分享自己生活的故事或事件。正是通过这些故事，我们可以发现一个人的思考过程，他们对各种环境的反应，同时还能了解他们是如何真正感受某些产品、应用和体验的。

本文提到的风险并不是说，“非此即彼”式的问题完全没有一点用处。在某些条件和环境下，比如说A/B可用性测试，这类问题就相当重要，而且信息量也很大。然而，在探索研究过程中，当你试图了解用户对某个产品的需要、渴望和痛点时，这些问题恐怕会对这个项目带来不利影响。

因此，当你寻求改善现有产品质量，开发新的体验，或是进入新的市场时，请记住，在了解用户想要或需要的东西上，没有一个快速且简单的答案。

——————————-

如果你本身就是你要改善的一个产品，会是”我是一个好人还是坏人？”这么简单的问题吗？你不一定知道自己真正想要什么，你也许是在取悦别人的期望，多给自己一些思考的空间，做自己的原创。

9格方法通过三个方面（列）和三种提问方式（行）组合成9个格子，它要求我们按照上图的数字顺序来进行，对每个问题进行沟通，可以把以前没有系统化的访谈方式更好的组织起来，帮助我们整理和清晰谈到的内容。

三个方面

1. 定义问题
   这可以帮助客户确定问题，一起讨论。可以从组织结构、岗位职责等了解总体的工作情况，对于具体问题，可以更有针对性的设计问题。
2. 标识涉众
   产品解决的价值一定是与人相关的，这可以很好的把涉众标识出来。
3. 描述愿景
   这可以初步确定产品成功的目标，注意，这里不会谈到具体的问题解决方案，而只是一旦问题得到解决后，会有什么样的场景。

三种提问方式

1. Open
   这类问题属于开放式问题，可以这样提出来，”告诉我…“，”请描述一下…“”这样发生什么了？“等故事情节问题
2. Control
   这类问题属于封闭式问题，如多少（如一张入库单有多少条明细）、什么频度（如多久填写一个单子）、在哪里等一些事实问题
3. Confirm
   这个步骤很重要，因为有可能会引起对方思考之前他没有提及的事情。如果发生这种情况，你应该返回之前的步骤重新开始。

用户故事

当我们使用9格访谈后，会发现这些内容可以直接应用在用户故事中。在《Scrum 之 roduct Backlog》中我简单讲了一下在Scrum方法中如何描述用户故事的一般写法是：作为【用户的类型】，我希望可以【先这样做，然后那样做，就应该得到…的结果】以便【业务价值】。

为客户着想

在进行访谈过程时，我们需要做到的三个方面是：为客户着想，了解客户期望和积极倾听。下面一副漫画可以很好的表达这个意思：（鱼饵就应当符合鱼儿的胃口，而不是钓鱼者）

上图是需求工程的组成部分，从图中可以看出，需求工程划分为两个部分：需求开发和需求管理。需求开发又分为需求获取（Elicitation）、需求分析（Analysis）、编写规约（Specification）和需求验证（Validation）。需求管理又分为基线管理、变更管理、需求跟踪。

下面我将分别介绍一下上面各个主要组成部分主要的工作内容，以便那些不熟悉需求的人员读后能够从总体上把握需求所涉及的工作内容。

需求开发

需求开发活动包括以下几个方面：

1. 确定产品所期望的用户分类。
2. 获取每类用户的需求。
3. 了解实际用户任务和目标以及这些任务所支持的业务需求。
4. 分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息。
5. 将系统级的需求分为几个子系统，并将需求中的一部份分配给软件组件。
6. 了解相关质量属性的重要性。
7. 商讨实施优先级的划分。
8. 将所收集的用户需求编写成规格说明和模型。
9. 评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组接受说明之前将问题都弄清楚。

实际工作中很难一次性得到完全正确的需求，所以以上步骤并不是严格顺序执行到底的，它是一个不断反复的过程。这些步骤也不是完全顺序的，很可能需要迭代的进行。

下面就需求开发每个活动进行简单介绍：

需求获取

在《软件需求的三个层次》中介绍了三个层次的需求，在需求获取中，这些需求都是我们需要获取的，我们需要收集问题域的描述，要求解决的问题列表，以及了解系统的行为或约束。

信息来源

• 客户（实际的和潜在的）
• 用户（实际的和潜在的）
• 已有系统及其文档
• 领域专家
• 相关技术标准和法规

获取技术

• 阅读背景资料
• 用户访谈、调研
• 需求讨论会
• 现场观摩

需求分析

需求分析是指通过对需求获取中获得的问题域的研究，获得对该领域特性及存在其中的问题特性的透彻理解并用文档说明。

• 不需要等到需求完全捕获后开始，在“业务需求”充分理解下，并且收集了本质的“用户需求”之后就可以开始进行需求分析
• 交替进行，先把握“用户需求”主要部分，然后在分析的基础上引入系统级的需求（系统的涉及与实现角度），并且分析模型，成为开发人员之间、开发人员与客户之间达成共识的一个平台
• 分析的基础上，就会发现更多的不明确项，更多待捕获的信息，这时就可以生成第二次的需求调研计划、问题和素材

编写规约

• 规格说明书是对需求分析结果的文档化过程
• 需求规约必须与实际开发紧密结合，否则很容易造成与开发脱离
• 为需求规约定义统一的格式是一个很重要的工作
• 规约内容必须严谨、正确、无歧义

需求验证

• 不重视需求验证工作会在系统交付时，客户发现不是这样的，导致不期望的需求变更
• 提高需求质量的重要手段有：需求评审、需求确认和原型验证
  

需求管理

需求管理活动包括：

1. 定义需求基线（迅速制定需求文档的主体）。
2. 评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它。
3. 以一种可控制的方式将需求变更融入到项目中。
4. 使当前的项目计划与需求一致。
5. 估计变更需求所产生影响并在此基础上协商新的承诺（约定）。
6. 让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪。
7. 在整个项目过程中跟踪需求状态及其变更情况。

说明：下面的内容，我把分享中关于公司的GCS工具的几页PPT省略了：）

客户满意度模型Kano

1. 基本型需求：顾客认为产品“必须有”的属性或功能。当其特性不充足时，顾客很不满意；当其特性充足时，对客户满意度没有多少影响，顾客充其量是满意。例如只要酒店浴室满足了我的基本需要，我并不会关心洗漱台的台面是用什么材料制作的。
2. 期望型需求：要求提供的产品或服务比较优秀，但并不是“必须”的产品属性，有些期望型需求连顾客都不太清楚，但是是他们却希望得到 的。顾客通常谈论的是期望型需求，期望型需求又叫做线性需求，这类需求越多越好。线性需求在产品中实现的越多，顾客就越满意，当没有满意这些需求时，顾客 就不满意。因此，产品的价格通常和线性特性相关。如果酒店有健身器材，我会更加高兴，相比没有这类器材的酒店，我下次可能就会在此入住这里。
3. 兴奋型需求：提供给顾客一些完全出乎意料的产品属性，使顾客产生惊喜。兴奋点和惊喜点常常是一些未被用户了解的需求，客户在看到这 些功能之前并不知道自己需要它们。当其特性不充足时，并且是无关紧要的特性，则顾客无所谓，当产品提供了这类需求中的服务时，顾客就会对产品非常满意，从 而提高顾客的忠诚度。这类需求可以为产品增加额外价格。

Kano模型分析

这3种不同类型如下图所示：

由图可以看出，

• 右下方箭头：一旦实现了一定数量的必须功能，就无法再通过增加这类功能来提高客户的满意度了。无论增加多少必须功能，客户满意度都不会超过中点以上。
• 左上方箭头：只是实现一部分兴奋点就可以明显的提升客户满意度，这也是为什么企业把追求卓越作为企业的价值观之一
• 中间的箭头：期望型功能的增加和客户满意度呈线性增长，所以这类需求越多越好

通过以上分析，我们会对这三类需求分别对待：

1. 对于必须完成的功能，在产品发布时需要完成，但并不是要求在第一次迭代时就开发完成。
2. 完成尽可能多的线性需求
3. 如果时间允许，至少应该确定少量的兴奋点优先级，把它们包含进发布计划

评估需求类型

在应用这个模型时，需要注意随着时间的发展，功能会在模型中向下移动。例如手机彩屏以前是期望的，而已经是必须的。 所以需求的正确归类非常重 要。使用Kano模型最简单的方法就是考虑每个主题或故事，对它所属的类型进行讨论。我们可以设计一套问卷，对用户进行问卷调查。Kano建议通过对一个 功能问两个问题来确定分类：一个问题是如果产品中有这个功能，用户会觉得如何；另一个问题就是如果功能不存在，用户又是觉得如何。对每个问题采用5点的度 量方式进行回答：

1. 我希望这样
2. 我预期这样
3. 我没有意见
4. 我可以忍受这样
5. 我不希望这样

经过调查后根据下图的归类矩阵，将问题进行归类来确定需求的类型

PDF限期提供下载：http://down.51cto.com/data/941446

本文会包含几块内容

1. 什么是流程图？流程图和其他图表（如线框图，概念图，架构图，用例图）有什么不同？
2. 为什么需要流程图？
3. 流程图的分类？
4. 如何绘制流程图？
5. 流程图绘制工具

第一部分：什么是流程图？

1. 定义

了解一个事情，我习惯从它的定义开始。那什么是流程图呢？说文解字是一种了解定义的好方法。

流程图=流程+图，如下图：

流程：Flow,是指特定主体为了满足特定需求而进行的有特定逻辑关系的一系列操作过程，流程是自然而然就存在的。但是它可以不规范，可以不固定，可以充满问题。所以就会造成看似没有流程。前不久，团队每个人对接一个业务团队去调研流程，反馈给我的流程有一些缺失。询问时，负责人反馈给我的答复是：这一块业务他们没有流程。其实严格意义上讲，业务已经开展，不可能没有流程，只是说没有固定的流程或者你调研的对象也讲不清楚。

图：Chart 或者 Diagram, 是将基本固化有一定规律的流程进行显性化和书面化，从而有利于传播与沉淀、流程重组参考。

从定义可以看出，只要有事情和任务，流程就会有，但是并不是所有的流程都适合用流程图的方式去表现，适合用流程图去表现的流程是一定程度固定的有规律可循的，流程中的关键环节不会朝令夕改的。

2. 流程图与其他图表的对比

工作中我们还用到或听到很多其他类型的图表，比如交互设计师们经常说的线框图(Wireframes)，信息架构图或站点地图(Site Map)，，开发工程师们经常说的用例图(Use Case)或E-R图。这些不同的图表要表达的内容有何种差异呢？简单做个对比，如图：

如果要串到某一个项目来说，可以理解成：

用例图（Use Case）：

表现了一个角色在系统里要完成的活动是什么，比如用户这个角色与ATM取款机的交互过程中，用户需要完成的活动有存钱，取钱，查询等。而存钱这个活动再可以进一步细分为插卡，输入密码，输入金额，ATM吐钞，用户收款，退卡等活动。用例图可以不考虑用户动作的前后次序，而仅仅提取一些关键的动宾短语，映射出系统应该满足的功能点。常用用例图的人是产品经理和开发工程师。

流程图则表示用户每一个活动的前后次序，比如用户必须要先插入银行卡，才能够输入密码，且流程图必须直接表现出各种异常判断，比如当密码错误时，出现什么提示，密码输入错误超过多少次时，出现什么提示和动作。常用流程图的人是产品经理，设计师，或者任何需要讲述业务如何运作的人。

信息架构图,站点地图(Site Map)：

表现为了做一个这样的系统，功能与内容的展现层次是什么，比如用户一进去后，欢迎页面的导航如何设计，是否直接出现取款，存款，查询，或者还有别的导航？常用信息架构图的是设计师。但是常用组织架构图的是HR。

线框图（Wireframe）：

将具体每个界面的内容布局和权重表达出来，且标注出一些交互细节的设计，比如当密码错误后，如何提示下一步动作。常用线框图的人是设计师。

实体关系图(E-R图):

则是数据库架构的工作，表示一个业务系统或场景中的实体时间的关系，比如储户与银行卡的关系是归属1对多，通过开卡事件产生关联。一般来讲，用矩形来表示实体，椭圆标识这个实体的属性，比如储户这个实体的属性有：姓，名，手机号码，住址等。而银行卡的属性有：开户行，开户名称，银行卡号等。

以上的这些图表各自都有领域的专家，我这里就不班门弄斧了。

那么流程图要体现出他的差异定义，要素是什么？总结出了流程图的6大要素，希望大家能够记住，这6个要素可以在以后的文章里不断回顾，你也可以拿来判断你所看到的流程图是否专业。

• 参与者：谁在这个流程中？可以是系统，可以是个打印机，更多的指什么角色——一般是有某种工种的人。比如客服同时有小A和小B两人，但是若他们的工作性质完全一样，那么在流程图里只需要写一个客服角色就可以了。
• 活动：做了什么事，比如点餐，结帐等活动。
• 次序：这些事情发生的前后顺序如何，哪个任务是其他任务的前置条件？比如客人不结帐，就不会产生送他优惠卡的活动。
• 输入：每项活动开始取决于什么样的输入物或数据，比如做饭的师傅开始做菜时，需要拿到具体的点菜单。
• 输出：每项活动结束后，会输入什么样的文档或数据传递给下一方，比如师傅做好菜后，如何让负责传菜的人知道菜已经做好？
• 标准化：采用一套标准化的符号用以传递你的流程图，从而使受众更快明白。

关于流程图的标准化，并不是强制的，事实上，我们见过很多种类的流程图，只要能够传递明白任务和次序其实已经归类于流程图了。如下面的图：

但是若在一个公司的环境下，你的流程图的受众又非常多的话，采取标准化的符号会带来很多交流上的好处，总之你懂的。

第二部分：流程图的分类？

常见的流程图有业务流程图（Transaction Flow）, 页面流程图（Page Flow）。

在工作中，作为UED，你可能会发现PD经常谈的是业务流程，而作为交互设计师，我们更多产出的是页面流程图。页面流程图和业务流程图到底有什么关系呢？ 先有谁，其次再有谁呢？

先讲个故事。

假设你的梦想是开个中高档的全国连锁餐馆，那么首先你想到的应该不是如何去选址，而是将为何要开连锁餐馆这件事情，以及你的定位，核心竞争力想清楚。是快餐，还是点餐，是连锁还是加盟？定位于社区还是繁华商圈？是川菜还是江浙海鲜？是面向中老年还是年轻人？是家庭主题还是动漫主题？竞争对手是谁？需要什么样的投资？可能的风险是什么？这些都想清楚了，问题都有答案了，所谓战略层要清晰了吧。然后假设你现在分析来分析去，与主要投资方决定了一个方向：面向年轻人的时尚动漫茶餐厅，连锁，但是先在杭州开始第一家，选址定位于年轻人约会，扫街的地域，比如风景区，著名商圈，电影院旁…………等等等等，那么接下来呢？

接下来就是想办法让这些实现吧？那么需要做什么事情呢？选址？拉投资？搞装修？选餐饮菜单？雇佣员工？每一步怎么去做，时间点是什么？等等的任务拆解以及计划，就需要到战术层了。

这些事情的执行，总是需要请人的吧？先是核心团队分工去部署各项建设任务，当餐厅开设起来后，就需要组织稳定的运营团队，如服务、卫生、厨房、采购、人事等等，厨房里面还得分工，白案，热菜，冷菜等等吧？每个部门需要设置管理层以及汇报关系吧？所以你的组织结构就诞生了。

那具体每种角色是如何顺畅合作完成日常稳定的以及突发的各项任务呢？比如，当顾客上门时，谁去引导客人入座，谁去点菜，怎么将点菜的讯息迅速传递到厨房，并分发到酒水间、冷菜间、热菜间？并保证客人尽快能够吃到所点的菜？你必须要考虑各种人员的协作流程，优化效率，所以业务流程就出现了。

人肉运营了一段时间，没有借助任何点餐系统，你发现也还可以。客人点菜时，服务员手抄写下客人的要求，因为有复印纸，所以服务员能够将副本送入厨房，同时写下餐桌号码。厨房规模较小，负责分配任务的员工看下菜单，分别往冷菜处的黑板上写下需要他们处理的，以及跑到热菜区的黑板上写下待处理的菜品，以及去酒水间报下品名即可。可是随着经营的扩大，以上的人肉方式出现了很多问题，首先，手抄效率太低，顾客频繁换菜，响应来不及，手抄出错，导致经常报错菜。厨房很混乱，不得不多招了几个人专门跑堂。而一旦顾客要加菜，撤菜就更麻烦了，需要找出他们当时点的菜，再进行人工的批注和修改，同时要修改厨房后端的各个黑板……

所以你们想要开发一套智能系统，取代很多人肉工作，你们请了系统开发团队，他们经过评估，判断从点菜开始，一直到传菜都可以用系统解决。手持终端，能够快速传递顾客点菜需求到打印机，打印系统能够根据顾客点菜的类型进行自动的分单打印，所以热菜间看到自己的热菜菜单，冷菜间看到自己的冷菜菜单，而酒水间看到酒店菜单。当他们准备完毕后，送出，传菜员可以根据菜名与打印出来的单据进行传菜并根据顾客的点菜小票进行核对。这套系统同时必须配备结算系统，将最终确认掉的菜单及消费价格传递到结算前台，收银员能够快速进行操作。

这套系统最终是需要展现出来的，那么手持终端的界面如何设计？服务员能够用更少的点击完成一个菜的点餐吗？结算中心的界面如何设计？

通过以上的故事，是不是更明白从战略、战术、业务流程图到页面流程图的关系了？总结下：

• 先是有一个业务需求和业务目标，也即我们的愿景是什么？（战略）
• 然后就诞生了我们需要分解出什么样的任务，如何执行战术？（战术）
• 然后就诞生了需要架构什么部门，岗位去分工协作？（组织架构）
• 然后就诞生了不同的部门在协作完成某件任务时的业务流程？（业务流程）
• 业务流程基本稳定后，往往会考虑优化效率，所以会诞生出系统来支持流程，减少人肉环节，促进数据采集（系统愿景）
• 为了设计这个系统，PD需要思考什么功能能够取代某个环节的人肉工作（功能需求，系统流程）
• 不管是怎么样的功能最终都会以界面的方式呈现，设计师们会关注用户在系统里的任务流，行为路径，让用户完成任务更加高效愉悦。（页面流程）

当然，除了业务流程，系统流程，页面流程，还有数据流程被人关注。

我们平时工作中，还会经常听人谈到泳道图啊，任务流程图啊等等概念，究竟是神马关系呢？

本文着重于上述流程中的“业务流程图”——并会分享如何绘制泳道图——也即是PD们最多使用，技术们最多参考，UED们最多看到的流程图。

在工作中，我们经常能够看到两种业务流程图，从表现形式来看，一种很好区分，俗称为“泳道图”的它，在样子上也确实像个泳道，可以有横向的泳道，也会有纵向的泳道。泳道图在某些文档里会被称为“以活动为单位的流程图”，浮在泳道中的都是一个个活动。

另外一种类型是以部门和岗位为单位的流程图，下图中的圆形就代表一个个部门或岗位。矩形代表活动。这种流程图关注事情如何完成的逻辑，但是在体现各个部门的责任上比较弱。如果是某个岗位的人来看，很难像泳道图那样一眼就能看到自己部门的职责和任务。所以现在用得比较少。

再回过头来说泳道图，泳道图有几个关键点：两大维度，活动流转，流程要素。我们会在以后详解。

第三部分：为什么需要业务流程图？

流程图可以提供一种简单扼要的“缩略俯瞰图”，帮助观众快速了解业务如何运转。它包含了几个关键词：谁，什么时候，在什么条件下，做了什么事情，输入什么，输出什么，输出给谁……

与系统流程不同，业务流程更关注于业务本身如何运作，讲的是业务故事，包含的是业务规则。而系统流程则是满足业务流程，实现部分流程或全部流程的信息化和系统化。

所以业务流程是所有环节的前置条件——软件需求分析，信息系统建设也会先进行业务流程的梳理。

下面表现了业务流程图是如何在三个主要场景中发挥作用的：

1. 员工培训

在此场景中：流程图能够提供一种快速了解业务如何运作的视图，通过业务流程图，新员工能够快速明白业务的最终目标是什么，中有哪些角色在参与以及他们的职责，以及彼此之间的联接。

除了培训新员工，在员工轮岗、调职场景中，员工也需要业务流程图参考，明白新的工作内容如何开展，以及自己所处的位置，自己的上游是谁，下游是谁，自己需要交付的工作内容是什么。

2：流程优化与重组

业务流程重组（Business Process Reengineering）的存在可以明确反驳：存在即合理。事实上，存在的业务流程并未是合理的，有可能是参与的多个角色习惯了某种做法，有可能是变革尚未影响到末端的操作，也有可能缺乏对于运行中的业务流程问题的洞察以及强有力的变革推动——因为要推动业务流程变革，不是某个部门的事情，而是需要流程中各个部门的通力配合。

更多时候，业务流程优化是自上而下的，但是老板们未必对实际运作的业务流程那么心知肚明，业务流程图能够很好去表现这个“运作模型”。通过看业务流程图，找关键节点的人访问，能够直接切入：为什么要这么做，为什么不这么做？从而探索出更深层次的问题，而不是问：你们现在怎么做？

通过调研，分析业务流程图，引入更多角色，能够分析出目前业务流程的问题：缺失，重复，风险，效率等等。从而制定相应的优化方案。

3：信息化的基础

正如上文所述的餐馆梦想的案例，信息系统的一项任务就是解放员工的手脚，取代一些重复的人力劳动工作。系统上了之后，不是说业务流程不需要而是经过了一些调整，其中某个参与者变成了系统，或手持设备，或打印机而已。

那么在做系统的功能设计和系统流程设计时，是不是必须先要了解目前业务是如何运作的呢？从而更好分析分析，更好说明系统在什么环节取代了什么类型的人肉工作？

所以我们看到的PRD往往也会先以业务流程图开始说明，而叙述一个系统建设的好处时，也可以用以前的业务流程与系统上了之后的业务流程进行对比。根据分析，将愿景中的新的业务流程图背后需要系统的功能点撰写清楚。

第四部分：如何绘制业务流程图？

首先绘制业务流程图本身有没有流程？一定是有的。在软件工程学里听说一句话叫：万物皆对象。那么在流程学里，万事皆流程。吃饭难道没流程吗？就吃饭的动作而言，就有流程：拿筷子——夹菜——入口——咀嚼——吞咽。

有不少同学在这一部份很快想会问一个问题：Heidi，请介绍画流程图的工具吧？

我个人是工具派，从不否认人工欲善其事，必先利其器的道理。好的工具本身就是一名好的老师，除了技能，也能够教会我们一些理论与理念，这些理念也是“器”中很重要的一部分。其次才是具体的工具应用技能。所以我并不建议直接跳转到工具应用。对于初学者而言，笔与纸永远是最好的入门工具，因为你无需和任何一个陌生的软件较劲。

1. 业务流程图的“烹饪三部曲”

在绘制业务流程图前，思考如何精美，如何交互，使用什么工具，都不应该是重点。

真正重点的是将业务流程图的关键要素给搜集一番。请试图回答清楚以下几个问题，否则不要开始绘制流程图：

• 整个流程的起始点是什么？整个流程的终结点是什么？
• 在整个流程中，涉及到的角色都是谁？
• 在整个流程中，都需要做什么事情？（可是是一个会议，可以是一个任务）
• 这些会议和任务是可选还是必选的？
• 分别产出什么文档？

这有点像一个头脑风暴，能够帮助你将所需用到的原材料获取到，有了这些“米”和“水”，那就不愁去如何烹饪了。

在项目管理中，上个月，我们也试图给去规范化一个数据产品的设计开发流程。

这是一个数据产品的项目，而我们都不是对此很有经验的人。所以我们召集到所有相关的角色，组织了一次头脑风暴及卡片分类法的混合式应用。

1. 让大家头脑风暴出自己认为在项目里必须的节点，如“需求调研”，“需求分析”，“kick off会议”，“PRD撰写及确认”，“数据评估”，“技术架构”，“DEMO绘制”，“指标算法定义”，等等。
2. 在头脑风暴过程中，主持人将这些节点都写到白板上，等没有新的节点诞生后，大家一起对节点进行合并归类。之后呢？
3. 将这些剩余下来的真正有价值的节点，撰写到即时贴上，开始进行排序。在排序过程中，可以由一个人先主导，他会按照自己的理解，将各个节点放到按角色排布的泳道中，并设计好先后的顺序。在他进行的过程中，其他人不断进行提问：“这项任务开始前，需要什么样的条件？”“这个任务是必须的吗？”然后一起调整先后顺序。直到最终没有人有任何重大的异议。
4. 之后拍照留念。
5. 然后可整理成电子文档，如project或者excel版本（使用excel做项目管理？）

但是，业务流程图和上述项目中的流程不太相同的是：

项目中的各种活动节点有更宽泛的可配置性，任务A和任务B是否并行，还是串行，如果项目组成员达成共识，是可以调整，并且多做尝试的。所以可以用集思广益的做法去头脑风暴出一个暂定比较合理的流程。而业务流程图的梳理，有两种:

• 一种是基于现实发生的业务流程如实反映。这显然不是你一个团队能够YY的结果。更需要走到现实环境中，去调研，去梳理，去确认。
• 另一种是基于流程优化的方案，当你已经掌握了目前的流程现实如何运作时，基于分析，讨论，能够判断出流程中不合理的地方，给出一个更完善或者有更效率、成本更低的新的流程出来——或许你要求增加一个部门，或者你需要删减一个环节，或者中间的若干步使用新开发的系统去取代。

总之，大多数时候，你要想做第二种流程图，必然要先将第一种给梳理出来。所以，第一种如实反映的流程图是躲不过的。既然如此，基于YY或者头脑风暴是不现实的。我们需要走到前线去，掌握现实中业务是如何运作的。而且很多时候，越细节越好。

那怎么做呢？基于有限的知识与经验，我可以给如下建议：

1. 调研——2.梳理呈现——3.评审确认三部曲，如图所示：

2. 调研——问正确的问题，多问问题，多问几个人

除了在本部分开始的那几个问题要顾及到，其实调研过程解决的仍然是who，what，why，how，以及where的问题：谁，在什么情况下，做了什么事情，这个事情需要什么前置条件，又输出了什么，这个事情在哪里完成的？搞明白这几个问题，我们的调研就可以圆满完成了。

流程图的表现，要回答这几个问题：

1. Who——谁？部门，角色，岗位
2. What——什么事情？
3. Where——在哪里做的？在我梳理的业务流程图上，where更多表示是文档还是各种系统，用来表示信息化的程度。比如当我们梳理中发现，有一项登记，是用excel而不是业务系统来进行的，那么在这里的where就可以表示为：excel文档。
4. Document——那产生的这份文档叫什么名字？也写出来，代表有文件的传递，而以后要进行信息化的话，此份人肉文档也是需要被消除而被系统取代的。（相反，如果这项工作是在某个系统里操作的，where就可以写成“人事系统”，文档可以继续存在，即该系统中的表单名称：“员工登记表单”）
5. Condition——条件。在这种条件下，下一个活动还能够继续，即用逻辑链接线的方式来表示一项活动的输入和输出，指向某个活动的箭头就表示此活动的前置输入条件。
6. Dicision——决策。有些活动会产生一个条件判断，根据不同的判断结果从而走不同的分支流程。比如输入员工信息的时候，可以根据员工之前是否就职过，选择不同的流程，对于已经就职过的，选用之前的工号而不用生成新的工号。

举个案例（如果不太恰当，请意会）。假设你受命要调研两家餐饮店的业务流程，目的是给他们提供性价比最高的点餐系统。

在调研中：

1. 你首先可以要求精通业务流程的人给你系统讲解一遍。
2. 调研具体操作的人，来验证他给你讲解的是否全面和偏差。
3. 实地观察和记录（花点时间走遍业务流程）

三种方式相互结合使用。第一种方法可以让你首先建立一个系统观，了解大体枝干，但是很难切入到可能会出现问题的细节。第二种方法太依赖于问题的质量以及问问题的场景。有很多结论的不正确其实是因为问错了人或者问问题的方法不对。那么就需要借助第三种，在观察中再进行验证。

比如，你现在找到了一个厨师：

• 你主要负责做什么菜系？
• 热菜。
• 那菜单都是谁给你的？
• 我们的服务员。
• 她都怎么提供给你？
• 她负责客人点菜后，然后手写一个单子，给我放到窗口上。
• 单子上都会写什么？
• 桌号，菜名等
• 那如何客人点的是冷菜呢？
• 恩，有复印本，直接拿一份给冷菜间。
• 那你怎么开始工作呢？从洗菜到切菜，一直烹饪都是一个人吗？
• 哦，不，我只负责烹饪。当接到菜单后，首先我的助理会进行择菜，刀工进行切菜，这样如果有几个菜就完全可以并行。
• 当你们做好后呢？
• 放到窗口，按铃，喊桌号和菜名，传菜员就会传菜。
• ……

在这些问题中，就涉及到了“分单”，“切菜”，“择菜”，”烹饪”，“传菜”，“上菜”几个活动，也涉及到了“服务员”，“厨师”，“助理”，“刀工”，“传菜员”几个角色。几个活动的次序也比较清楚了。

而另一家餐饮店的业务流程却是不一样的，你同样抓住一个厨师进行询问：

• 要做什么菜，菜单是哪里来的？
• 打印出来的。
• 所有菜都会在这里打印吗？
• 哦，只有热菜在这里打印出来，冷菜、酒水就会在冷菜间和酒水间打印出来。
• 打印机是谁在操作的？
• 没人操作，它会自动打印不同的单子给我们。
• ……下面的问题，可能厨师就不了解了，要问点菜员了。
• 请问你是怎么点菜的？
• 拿设备啊，客人点菜就按几下，确认就好了。
• 之后呢？
• 之后就可以将菜单打印出来。
• 不同的菜系会在不同的烹饪间打印吗？
• 是的，我们可以分单打印。是在这中心打印机里完成分单。
• 然后，你可以继续调研烹饪后的传菜和上菜流程。

3. 梳理并呈现

你的调研和观察使你拥有了“烹饪”所需的原材料。

• 角色：部门、岗位或人
• 活动：做了什么事情
• 次序：做这些事情的次序如何
• 规则：什么情况下到什么事情

还记得我们之前提过的流程图要素吗？回顾下：

接下来的任务是不是很简单，对，就像填空题一样简单。将活动/事件按照一定的规则填到由部门和时间两条维度决定的框框里。

这个阶段是paper work，你需要将调研阶段收集到的原材料用更直观明了的方式呈现出来。从而能够更好进行评审和确认。也为以后的流程评审和优化做准备。

在刚开始，笔和纸的原始搭配仍然是最好的起步工具。你可以暂时忽略掉美观或者可复用的因素。但是当你对要呈现的流程已经有足够的信心时，就可以借助软件工具了。

3.1 复杂流程的分解

不可能将所有的活动都放到一张图里呈现。

“业务流程是有层次性的，这种层次体现在由上至下、由整体到部分、由宏观到微观、由抽象到具体的逻辑关系。这样一个层次关系符合人们的思维习惯，有利于企业业务模型的建立  企业部门之间的层次关系表。一般来说，我们可以先建立主要业务流程的总体运行过程（其中包括了整个企业的大的战略），然后对其中的每项活动进行细化，落实到各个部门的业务过程，建立相对独立的子业务流程以及为其服务的辅助业务流程。”

——引自《百度百科》 业务流程词条

对于很多新人来讲，业务最难的在于划分业务流程图的层次上。

首先，明确你要梳理的业务流程的范围——用大的粗略的关键节点，讲清楚这个业务流程范围中的故事，就是顶层业务流程图。你的顶层业务流程图是业务全局故事的简单表达，但是请注意这里的业务全局不见得是公司整体的业务全局，而是你界定好的业务范围。比如，下图是餐厅的日常运作流程图，若你界定的业务范围是面向顾客的点餐和结帐流程，那么这就是顶层业务流程图。但是若你界定的是整个餐厅的运作业务流程，那这显然还是一个子集——并没有包含餐厅的采购、供应商管理、一级库存管理等工作。

其次，先从顶层的业务流程分解开始，由粗至细。顶层业务流程图的梳理原则：

1. 界定范围内的业务全局故事。
2. 包含该范围内的关键节点。并且，当被质疑说某某环节怎么不存在时，自己要清楚它在下一层分解中应该被包含在那个关键节点中。比如，赠送10周年优惠券，应该会在结帐节点分解中出现。而打印分单，会在点菜节点中分解。而准备儿童座椅应该是接待入座环节。
3. 顶层流程图分解出来的关键节点未必都会细化分解下去，生成二级以及三级的流程图。这要看该节点涉及到的“活动”以及“角色”是否复杂。

再看一个案例，对传统生产型企业的进销存主业务流程进行分解。橙色的代表被分解点，已经可以分解为四层。当我们分解到第四层，发现再往下去涉及到的活动和角色都已经很少时，就不必再分解了，而是可以将第四层的关键节点直接作为第三层业务流程的“活动”，而不是子流程图。

当然，这是依赖于你梳理业务流程的目标。如果你偏偏是要对“打样”环节进行剖析优化，则还可以继续分解下去。

这一步的工作会帮你建立出清晰的流程目录结构，如下图所示是摘选于刚完成的一个流程梳理的项目中的目录结构部分。可以看到全图即是顶层关键节点，作为老大，可能只要看这一层就够了。下面则会对顶层做更多细化拆解。

“H3.样品认证”在顶层业务流程图中，仅仅是一个“活动”，而在自己细化的这一个层次中，则会包含详细的子活动一级参与者。

3.2 流程图的常用图示

我常用的就是前两行的“活动”，“判断”，“逻辑关系线”，“起始与终止”，以及第二行的“子流程”，和“文件/表单”。如果你不是符号控，我建议这几个就足够了。

其中，“子流程”此图示就是可以帮助你将流程分解得到的子流程能够串联起来，比如，当在”A流程”中涉及到进一步需要分解的”A1.1流程”时，就可以在”A流程”中用子流程符号代表“A1.1”。然后你的读者就会明白要想进一步了解”A1.1″应该参考另外一个流程图。

流程图的常用结构：

给大家看一些案例：

文档地址：http://www.ais.npic.edu.tw/ais/971%20materials/DfdSfPm_20080724.pdf

只用到少数几个图示画的简单流程图（台湾人的文档中称为程序图——不过这里的程序不是指计算机程序，而是process，仅仅是体现任务之间的处理流程，所以使用极简单的符号也不为怪了）：

以上两个流程图案例，从符号的复杂程度上来讲，一个是完整流程图，一个是基本流程图，但是从表现形式来讲，都属于“泳道图”——Swimlane。这也是我们最常用的一种表现形式了。泳道图能够很好体现部门或者角色在流程中的职责以及上下游的协作关系。且流程图本身的标准容易掌握，达成共识也就更加容易。

3.3 泳道图精要

在上文中的软件推荐部分，我推荐过smartdraw工具，此工具还附带了泳道图的模板，大家比较更快能够上手：

3.4 Do vs Donnot 业务流程图的注意事项！

DO

1. 让涉众参与，不要闭门造车
   业务流程图包含了你图上的各个参与角色代表，与他们适时确认事情的原本流程，禁止自己YY。
2. 恰当的层次分解，不要将所有都铺到一张图上
3. 逐渐深入，先抓枝干
4. 流程一定有开始和结束
   切忌交付出来的流程图，让读者还来问你：流程的开始点是什么？用清晰的代表开始和结束的符号来完成第一步和最后一步。
5. 编号，编号，编号
   这是让沟通效率更高的优化措施。当你有了编号系统，相当于对你的流程图都赋予了唯一识别身份证号。这比中文名称更有效。比如当我们完成了业务流程图后，负责业务流程规则审核和优化的部门能够清楚在邮件里传达：H5.1流程优化，大家就更明确指的是什么。

第五部分：绘制工具？

如果不搞工具研讨会的话，这部分比较简单.

Windows: 线下工具大家常用的就是下面三个：

小的流程图用用PPT就够了，完了就导出图片或截图。交互设计师们因为常用axure绘制线框图，所以也不必为了流程图去学习新的工具，完全可以用axure的flow控件完成简单的业务流程图的制作。而PD们则常用微软的visio。

此外，特别推荐一个软件：SmartDraw。

我最近的流程图都是用SmartDraw绘制的，你可以下载一个免费版本体验下。这个工具不仅仅是为了流程图而设计的，几乎上包罗万象：线框图，流程图，E-R图，UML ,韦恩图，甚至甘特图，脑图……没有像很多人推荐就是因为他太庞大了，尤其是里面的模版。大家体验下：

Mac电脑:

自然要推荐omniGraffle. 绘制出来的任何图表不知为何总会觉得很美……

当然，这个软件是可以去www.macx.cn下载免费版的……

但是不管windows还是mac，除了线下的工具，还有更多线上的选择：

不过貌似我们对线上工具普遍来说都不太放心，是对服务器，网速，还有对GFW不放心吧。

1. https://cacoo.com/

这个是界面做得最好看的一个工具。我用它来绘制过概念图（Concept map）。如下图即是用以上的工具画的。

2. http://creately.com/

3. www.lucidchart.com

在企业架构:使用TOGAF进行产品开发中我介绍了如何使用TOGAF来进行产品开发，我把价值驱动放在第一页，是因为产品开发中最难的不是技术，而是产品本身是否给用户提供了价值。那么产品的价值是怎么来的呢？如何保证我们提出的价值主张是正确的呢？价值点有可能是大家皆知的、也可能是通过自己分析获得的、或者是我们预先提出的假设，但不管是通过何种方法得出的价值点，最终还得由用户来评判。既然是用户来做裁判，那么及早让用户参与进来是一般产品开发的重要策略之一，而需求获取则是其中重要的一项技术。

前一阵子项目组进行了一次较大规模的深度访谈，这就属于需求获取阶段的工作，本篇介绍一下需求获取工作的主要任务和如何结合TOGAF来做这项工作，也算是一个工作总结了：）

需求获取任务

• 1. 准备
  • 目的：保证在需求获取活动中需要的资源（人、资料、设备等）都已被整理和安排好
  • 描述：业务分析需要制定详细的需求获取活动以及日程安排
  • 输入：
    • 项目范围
    • 需求获取技术
    •  涉众列表：涉众角色和职责
    • 定义好的业务问题/机会
    • 业务案例
  • 要点
    • 针对选中的获取技术明确特定的范围，并且收集任何可能获得的材料
    • 安排所有资源，包括人、设施、设备等
    • 通知适合人选
  • 涉众
    • 项目经理
    • 业务分析师
    • 技术代表
  • 输出
    • 安排好的资源
    • 提供支持的材料
    • 统一的标准：例如统一的调查列表、调研记录
• 2. 实施
  • 目的：获取与涉众需要相关的信息
  • 描述：直接沟通、自己分析或分布调研
  • 输入：
    • 安排好的资源
    • 统一的标准
    • 提供支持的材料
    • 定义好的业务问题/机会
    • 业务案例
    • 需求管理计划
  • 要点

    跟踪需求：当获取需求时，很重要的一点就是防止需求蔓延。围绕业务目标可以帮助我们确定这个需求是否包含在项目范围之内。

    捕获需求属性：当获取需求时，记录下需求属性，例如需求的来源、价值、优先级等

    使用术语：业务术语是所有需求获取技术的核心资产。术语将包含业务定义中的主要领域词汇

    度量：跟踪参与者真正花在需求获取上的时间，为后期计划提供指导。例如可以知道哪类客户对获取不能提供价值、什么时候约客户最方便等

    基于事件的获取技术很大程度上依赖于涉众的专业知识，以及他们的参与意愿和组织达成一致的能力。在获取过程中，倾听客户是很重要的，之后很有必要对所有涉众的观点进行一次整理和总结。

  • 涉众
    • 参与者
    • 业务分析师
    • 项目经理
    • 技术代表
  • 输出
    • 获取活动的结果
    • 假定、约束、风险、问题
    • 技术各种不同获取技术的文档（例如，访谈记录、专题讨论会结论、问卷调查反馈等）
• 3. 规范需求
  • 目的：分析涉众提供的信息
  • 输入：需求活动结果
  • 要点：参考后续介绍的具体获取技术
  • 涉众：业务分析师
  • 输出：规范的需求
• 4. 验证需求
  • 目的：验证规范的需求符合涉众的需要，并且能够让他们明白
  • 描述：这个任务一般在访谈和观察技术中使用
  • 输入：规范的需求
  • 要点：参考后续介绍的具体获取技术
  • 涉众：
    • 业务分析师
    • 访谈者
    • 被观察者
  • 输出：验证后的规范的需求

结合TOGAF来做需求获取的准备工作

为了更好的说明如何结合TOGAF来做需求获取工作，我以我最近实际的工作作为案例和大家分享一下准备工作的一个案例。

• 项目介绍
  • 我们现在做的产品属于业务研究阶段，侧重点在业务研究方面
  • 业务架构师分析已经分析过这个业务较长时间，也提出多个可能的项目A/B，在B中又可以细分为B1和B2两个项目，产品现阶段定位与管理类软件（这里采用字母代表项目名）
  • 前几个月刚按照TOGAF做完产品的架构，在进行下一步工作安排之前准备做一次较大规模的用户深度访谈，此次计划访谈25家客户、网上问卷100份。

• 准备工作
  　　访谈可以在产品各个阶段中进行，但不同阶段的目的应该是不一样的。我们都知道开发后需要测试，做完产品的架构之后同样需要测试，所以我把这次用户访谈作为是让用户帮我们测试架构的一个活动。
  • 输入
    • 项目范围：确定主要考虑B1
    • 需求获取技术：以访谈为主，网络调研为辅
    • 涉众列表：
      1.  访谈技术：用户定位在企业高层，通过高层会议以及分支收集的用户列表，确认企业资质、用户角色和职责等，对合格调用者进行逐个电话预约
      2.  问卷调研技术：用户定位在操作层
    • 定义好的业务问题/机会：这个在TOGAF的架构上下文阶段
    • 业务案例：业务产品流程可以通过原型讲解
  • 输出
    • 结构化访谈问题：管理层和操作层的价值点是不一样，所以需要分开来设计。而本次深度访谈主要是高层，所以针对访谈主要针对于As-Is、To-Be、价值点(TOGAF的主要内容)符合度以及客户对软件的迫切度四个方面的访谈问题列表；而针对网络问卷，主要是以操作层面的具体业务应用问题来设计。产品开发前期最好先开发管理层和操作层的共同价值点，至少需要先包括部分价值点，否则不便于产品推动。
    • 准备好的原型产品
    • 预约好的被访谈者
    • 内部访谈人员的安排

• 有待提高的地方
  • 组内需求人员调研后未及时沟通，最好每日集中讨论访谈情况
  • 访谈技术的提高，学会倾听，把握重点，善于引导，并加以确认
  • 对业务流程、价值点的确认路径和方式

需求获取技术

以上谈的是需求获取的步骤，这些步骤适应于所有的需求获取技术。在以后的内容中，我将会继续与大家介绍具体的需求获取技术，在这里只先简单的说一下有哪些需求获取技术。

• 基于事件
  • 头脑风暴
  • 焦点小组
  • 访谈
  • 观察
  • 原型
  • 专题讨论会
• 基于执行
  • 文档分析
  • interface identification
  • 反向工程
• 分布
  • 问卷调查