text: 如何入行需求分析师? 
  高效需求的七张画布
  需求是建立在商业、技术和人之间的一组动态的、待验证的假设。挖掘和定义需求的过程，是一个不断验证假设、在试错中学习、逐步逼近直至找到与市场「契合点」的过程。
  但我们在真实工作场景中挖掘和定义需求时，和不同的功能团队讨论和落地需求时，往往会听到身边同事们的众多抱怨，“需求为什么老是变”、“结卡时候发现做的不是想要的”.....
  而这些常见的需求问题也是我们在项目迭代过程中，需要周而复始去处理的难题： • 需求的变更管理 - 变化频繁、剧烈，稳定性差 • 需求的分工协作 - 沟通成本高，需求拆解无标准，分解不够细致 • 需求的优先级排序 - 需求来源过多，优先级难以决策 • 需求的描述与传递 - 需求不明确，表达歧义，传递失真 ......
  若进一步探究需求问题的本质，我们不难发现，面对市场充满的不确定性，需要快速找出有价值的假设；在需求目标落地时，因为组织分工等现实约束会被层层分解，待到每个子团队中落地实现，如何让这个分解 / 组装过程尽量不失去原有需求意图；面对需求的实现，如何保持高效的社会化协作，在需求意图被理解、表达、传递、接受、消化、再传递的过程中，避免需求意图的失真和“被污染”；等需求实现后可以上市时，针对市场的变化 / 目标用户消费习惯的变化，我们又当怎样面对，之前有价值的需求在当下未必持续有价值的问题。
  通过多年的项目沉淀和市场验证，我们认为「设计思维」、「精益」、「敏捷」的核心方法和实践，能帮助产品团队更好地应对 VUCA 时代的不确定性，更高效地处理好需求问题。
  可参考如下基本原则: 1. 对业务领域、市场、用户需求有洞见，主动驱动业务变化，而不是仅理解跟随业务变化 2. 真正以客户 / 用户为中心，像客户 / 用户一样思考，由客户 / 用户价值来驱动决策，而不是利用组织政治来决策 3. 共同一致的需求愿景和目标，高度透明、可视化、协同地、高质量地需求沟通，而不是不写文档、频繁但低效地沟通 4. 去中心化的产品体系架构和产品团队，负责产品的整个生命周期，而不是项目团队只注重交付的速率，不注重交付的价值 5. 以业务成效来度量和验证价值，形成价值闭环，而不是单单衡量 IT 团队的交付效率和产能 6. 产品的需求，少就是多（Less is More），做减法
  Thoughtworks 高效需求 全生命周期管理
  因此，高效需求，关键的核心便是先找到正确的问题，并为问题找到最佳的解决方案，然后把方案拆解为小块产品能力项。从需求的收集到探索、定义、 分析、优先级排序再到需求治理，整个需求全生命周期管理有一系列核心的方法论和实践。
  我们推荐七款画布（地图），希望能帮助大家达成高效需求管理，更灵活地应对当下大环境的不稳定，更高质地挖掘用户 / 客户最根本的需求。
  画布一、 Empathy Map「同理心地图」
  1. 同理心地图是什么?
  同理心地图给设计团队提供了一个思考框架，是帮助团队整理对用户认识的一项工具。它帮助团队整合所观察和调研到的人和事物，并协助挖掘出对用户深层次的理解（目标、需求、观点、痛处、态度、行为）。同时，同理心地图也是一个团队协同设计（Collaboration）的工具，确保每位团队成员对使用者的理解都是相同的。 2. 同理心地图包含了哪些要素?
  在用户访谈的过程中，我们通过四个维度去洞察用户痛点和问题“Pains”， 挖掘用户真实的诉求和期待“Gains”。 “Hear”指代用户周围的人都说了什么、其他影响者说了什么、周围社会环境的声音；“See”指人的行为，周遭的事物和用户所处环境；“Think & Feel”是用户的想法和态度，立场和观点；“Say & Do”指用户在公共场合的态度、外在表现，对别人的行为的反应
  参考案例
  3. 绘制地图小提示
  我们绘制同理心地图，最关键的是想要洞察到用户的真正问题。因此在最后收敛环节，建议使用 POV（Point of View）的方法，将遇到的问题 & 挑战和用户的需求洞察，转换为可采取行动的问题陈述，帮助我们有效地进行后续的发想。一个栗子:
  画布二、 Persona「用户画像」
  1. 用户画像是什么?
  用户画像是根据用户社会属性、生活习惯和消费行为等信息而抽象出的一个标签化用户模型，需要经过各种调研（用户研究、桌面研究、数据分析），总结收敛出基于真实用户的特征、痛点和期待。
  2. 绘制画像 Tips
  不要预设立场；整理时明确产品的出发点：不能只是罗列信息，需要与产品做关联；用户角度出发，而不是从产品功能反推用户需求
  3. 其他常见问题
  1. 用户画像是一类用户信息的抽象呈现方式 2. 产品用户目标，可以参考马斯洛的 5 层模型，产品所满足的需求越深入越容易成功 3. 避免直接从功能反推需求和期待，用户不会说出我需要 *** 功能的话，需要思考背后的动机，洞察问题 4. B 端的用户画像，较之 C 端，不会过多描述个人信息，会更聚焦组织层的目标、优先级、痛点、动机和期待
  用户画像参考案例
  画布三、User Journey Map「用户旅程地图」
  1. 用户旅程地图是什么? 用户旅程地图是以视觉化呈现用户为达成某一目标所历经过程的工具，通过创建历程图，能够更好地理解目标用户在特定时间里的感受、想法和行为，认识到这个过程的演变过程，寻找用户的痛点，通过讲故事（Story telling）的方式描述用户的体验过程，采用视觉化（Visualization）的方式将信息高效简单明了地呈现出来，便于记忆与团队分享。
  2. 如何绘制?
  ZONE A：用户视角区域 1 指代 who，用户的人物画像；2 是 what，产品的使用场景 & 目标 ZONE B：是旅程地图的核心部分，包括用户体验历程的各个阶段划分 第 3 个 Phases，用户实现某个目标所经历的具体步骤；4 指代 Actions，即每一个步骤下用户所产生的具体行为习惯；5 是 Thoughts，用户在这个过程中的想法和体会；6 指 Emotional Experience，用户在这个过程中不同阶 段的情感波动 ZONE C：此区域会因各项目商业目标的不同而不同，为各个项目的洞察 第 7 个维度是 Opportunities，我们洞察到的能够改进的机会；第 8 的 Ownership，指将每个改进点对应到相应的责任人身上
  用户旅程地图
  3. 绘制地图时需要关注的细节
  首先要分析核心用户是谁，以核心用户的视角，关注TA达成目标的典型场景及旅程。如果过程中存在其他角色需要支撑这个过程，可以列出。但是旅程还是以核心用户的视角描述
  一定是基于某个用户画像和某个特定用户场景的，可以体现目标用户的行为特征
  用户旅程中用户、目标是必须先明确的
  从用户的角度去梳理用户行为，不能掺杂系统行为，即跳出系统操作范畴，梳理用户在实际场景中发生的行
  目的是为了找到用户在这个场景下的真正需求点，不是去梳理当前系统上能做什么
  好的用户旅程是非常有画面感的，本身可以表达一个非常生动的故事，读者脑海里会呈现出一副用户旅程的画面
  地图种类分为 As- Is 和 To-Be，第一种是梳理人们已发生的行为的活动，要基于真实的用户观察，包括线上和线下的行为；第二种是规划人们未发生的行为的活动
  用户旅程地图参考案例
  画布四、Service Blueprint「服务蓝图」
  1. 什么是服务蓝图?
  服务蓝图（Service Blueprint）是详细描画服务系统的图片或地图，服务过程中涉及到的不同人员可以理解并客观使用它，而无论他的角色或个人观点如何。服务蓝图不仅包括横向的客户服务过程，还包括纵向的内部协作，是描绘整个服务前、后台、支持过程构成的全景图。
  2. 一个栗子诠释（剧院为例）
  前台是事件发生的地方，以及观众看到的地方，对于我们而言，用户的行为发生在前台。 后台提供前台需要的支持，比如灯光、布景、工作人员，这些都是观众看不到的，后台是我们组织所有的事情来让前台可以发生。幕后组织所有无形的事情使前面和后台成为可能，像规则、规章、政策、预算等。 3. 如何绘制? 一个常规的服务蓝图由 5 个信息泳道，3 条分割线组成：
  信息泳道
  1. 实体证据 2. 顾客行为 3. 前台员工行为 4. 后台员工行为 5. 支持过程
  分割线
  6. 互动线 7. 可视线 8. 内部互动线
  服务蓝图参考案例(某中餐厅为例)
  画布五、Elevator Pitch「电梯演讲」
  1. 什么是电梯演讲?
  电梯演讲来源于麦肯锡要求他的每一个业务人员，都必须有在 30 秒的时间向客户介绍方案的能力，凡事直奔主题和结果。 电梯演讲画布，是帮我们梳理清楚「产品愿景」的一个工具手段。它让团队中每一个人都了解到当下正在进行中的产品的发展方向和存在意义，让每个人都知道产品的「价值点」是什么。
  2. 包含哪些核心元素?
  目标客户 / 用户是谁；聚焦要解决的问题；产品的名字；产品的外观和形态；产品的关键能力；相关竞品或已有解决方案；独特价值和优势 通过包含以上 7 个要素的简洁明了的陈述，明确清晰地表达产品的定位和价值主张。
  3. 主要使用场景
  （1）在创新产品时，向组织决策者争取投资（2）向团队成员表达清楚产品的价值主张，与团队伙伴对产品边界有清晰认知（3）在产品设计时，用来指导产品的边界和范围（4）在产品迭代演进时，用来帮助判断需求是否应做，以及需求的优先级（5）在向核心干系人或决策者做产品阶段性汇报时（6）在产品要进行重要升级或重大转向决策时（7）向外部客户去直接销售我们的产品
  4. 实践小技巧
  • 没有人在第一次就能做到一个100%清晰到位的完美电梯演讲，所以要持续思考、持续更新； • 相信团队的力量，如果能和团队一起共创、并持续与团队在产品电梯演讲达成共识，会形成一个凝聚力超强的团队，协作起来非常流畅； • 如果不能就目标客户、客户问题的关键词达成一致，那意味着需要更深入的客户研究和洞察； • 如果不能就产品的关键能力 / 核心解决方案的关键词达成一致，那意味着对自己的产品和解决方案分析得不够透彻； • 做出好的产品电梯演讲，很需要广泛的知识和概念性思考（Conceptual Thinking，如何把具象的信息抽象为概念、如何很好地使用隐喻、类比、 视觉语言等）的能力，一开始会很困难，但持续练习会很快提升
  电梯演讲参考案例
  画布六、The Value Proposition Canvas「价值主张画布」
  1. 价值主张画布是个啥?
  出自《价值主张设计》一书，是用于可视化、设计和测试产品和服务，如何为用户创造价值的一种工具。价值主张画布一般用于了解客户的真正需求，同时为之设计相对应的真正解决方案，它的终极目标是让产品与市场相匹配，吻合用户需求。
  2. 如何绘制?
  价值主张画布
  Customer Profile
  Customer jobs - 客户任务是客户所试图完成的事项，它可以是功能型任务 （如：订机票、银行取款）、社会型任务，跟社会地位、形象有关（如：在同事面前显得很专业）、情感型任务（如：让心态变平和、获取安全感）
  Gains - 利益点是符合客户自身利益的正面结果，它可以是客户要求、期待的（如：低价买到名牌）也可以是在客户意料之外的（排队获赠饮品）
  Pains - 痛点是客户在完成任务过程中的障碍，以及希望避免的负面结果
  Value Proposition
  Products & Services - 产品 & 服务是企业为客户所提供的价值的载体，它可以是有形的（比如智能机器人、耳机等)，也可以是无形的（比如代取快递服务等） Gain creators - 利益创造者描述的是产品和服务如何帮助客户创造利益、达成正面结果
  Pain relievers - 痛点缓解者描述的是产品和服务通过哪些方式消除或缓解客户的痛点
  小结：在「Products & Services」的产品 / 服务中，采用「Pain relievers」的方案，解决「Pains」的痛点；通过创造「Gain creators」的方案收益，可以帮助「Customer jobs」在「阶段 ] 达到「Gains」的客户价值。
  参考案例(Airbnb)
  在「聚集全球各地房源 & 丰富的当地体验推荐」的产品 / 服务中，采用「相对真实的客户评价 & 房东可以和用户直接交流 & 平台及时响应」的方案，解决「住宿质量问题 & 不安全 & 周边配套少」的痛点；
  通过创造「提供全球各地特色房源 & 多种支付方式 & 本地店家合作」的方案收益，可以帮助「终端房客」在「寻找独特民宿时」达到「方便获取当地特色 好吃好玩的信息 & 房间装修有特色审美」的客户价值。
  画布七、User Story Map「用户故事地图」
  1. 什么是用户故事地图?
  用户故事地图作为一个需求识别和梳理的工具，帮助我们透过时间维度了解所有的产品需求，构建出需求全景图： • 一个有方向的图表 • 横向为时间线，相关的用户行为可以基于时间线放置，纵向为必要程度，自上而下放置产品需求 • 涵盖所有产品需求，表达需求全景
  2. 绘制用户故事地图 Tips （1）产品定义：用户是谁？产品目标是什么？（2）为核心用户梳理骨干故事并拆分（3）从核心场景出发，头脑风暴支撑每个用户任务的功能需求（4）头脑风暴支撑每个功能需求的支撑性需求（质量、体验需求）（5）延展到所有端到端流程（6）审视整个功能需求和支撑性需求，查缺、补漏、去重
  3. 使用地图时常出现的问题
  • 用户故事地图的创建主要是基于一个典型场景展开，需要确定核心用户及该用户的目标是什么。再结合解决方案设计核心用户(To-be) 的用户旅程。如果过程中存在其他角色需要支撑这个过程，可以列出。但是识别产品需 求时，还是需要以考虑如何帮助核心用户达成目标出发为主； • 用户旅程中识别的用户行为的描述需要精炼，动+名词，一件事一个卡片。这样在识别支撑用户行为背后的各个产品需求时相对独立有价值，不至于太碎片化； • 支撑性需求包含为了满足用户的业务需求而需要考虑的系统其他能力要求，大多与技术相关。所以这部分需求一定需要技术负责人的参与，避免遗漏； • 使用用户故事地图进行产品版本规划时，除了考虑高风险高价值等因素外，还需要考虑产品需求之间的次序和依赖关系
  参考案例(预约家具维修)
  本篇文章"高效需求的七张画布"收录于 BeeArt 文集「职」言产品系列第二期，文集合计 11 篇文章，2 篇工具推荐。作为为产品经理和业务分析师量身打造的文集「职」言产品 2，我们对需求理解的不同段位进行了划分，你会看到高阶产品经理对需求背景把控的维度，中阶对需求的全局分析方法，以及初阶对获取需求后的拆解与执行建议。
  希望这本文集，可以在你犹豫不决时，获得些许勇气；在你踌躇不前时，获得些许灵感。
  点击获取电子文集全稿「职」言产品2 ：https://jinshuju.net/f/mYVaZd
  欢迎关注 BeeArt 行知蜂官网：www.beeart.com
  或联系 BeeArt 小助手提供建议和反馈（叶子，lsye@thoughtworks.com）