在企业架构:使用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
  • 反向工程
• 分布
  • 问卷调查