软件项目管理的50个需求实践

软件项目管理得需求实践，需求战略实践：可行性研究报告,SWOT分析,发布计划电梯演讲,价值主张画布等，需求获取实践：用户画布、影响地图、用户故事、同理心地图，需求拆分实践、需求估算、需求方案评价等50 个需求管理实践活动详解。

软件项目管理实践 之 需求实践50+

• 战略
  • 可行性研究报告
    • 可行性研究内容
      • 项目的投资建设的必要性
      • 项目的建设周期
      • 项目需要的人力、财力资源
      • 项目的功能和目标是否可以实现
      • 项目的经济效益、社会效益是否可以保证
      • 项目从经济上、技术上是否是合理的
    • 可行性研究的步骤
      • 1.确定项目规模和目标；
      • 2. 研究正在运行的系统；
      • 3. 建立新系统的逻辑模型；
      • 4.导出和评价各种方案
      • 5. 推荐可行性方案
      • 6.编写可行性研究报告
      • 7. 递交可行性研究报告
  • SWOT分析
    • 优势（Strengths）：企业或项目的特点，使其比其他企业或项目更具优势；
    • 劣势(Weaknesses）：使企业或项目相对于其他企业或项目处于劣势的特点；
    • 机遇(Opportunities）：企业或项目可以利用的环境要素；
    • 威胁（Threats）：环境中可能给业务或项目带来麻烦的元素。
  • 发布计划
    • 发布计划是产品路线图（战略）的战术落地规划，它将战术和战略联系起来。
    • 它是产品经理指导开发团队的重要手段，也是管理利益相关人期望的有用工具。
    • 如何使用
      • 制定明确、具体和可衡量的目标
        • 描述产品应该创造的结果或好处。
      • 确定达成产品目标需要完成哪些工作
        • 这通常需要开发团队提供粗略的、高层级的估算。
      • 了解日期和预算限制
        • 是否有任何必须满足的硬性期限，或者预算是否固定？
      • 确定发布日期和发布内容
  • 电梯演讲
    • 电梯演讲是指在乘坐电梯的时间跨度内（即30秒-2分钟时间内）将想法或产品描述完毕。
    • 这个描述要解释产品/想法是什么以及价值是什么。它的目标是以令人兴奋的方式传达整体概念或主题。
    • 1.设定产品的目标，要明确以下几点：
      • 产品关键目标。正在开发的这个产品将如何为公司带来利益？
      • 这个产品支持公司的哪个特定战略？
      • 客户。谁会使用这个产品？
      • 需要。客户为什么需要这个产品？对于客户来说，哪个特性最为关键？
      • 竞争与差异。这个产品和类似的产品相比较，竞争力如何？有何差异？
    • 2. 使用电梯演讲创建愿景声明草案：
      • 为了<目标客户>
      • 他们<需要>
      • 这个<产品名称>
      • 是一个<产品类别>
      • 它<产品的好处，购买理由＞
      • 不同于<竞争者>
      • 我们的产品<差异/价值主张>
    • 3. 与项目利益相关者、开发团队、Scrum Master、敏捷教练共同审核。
    • 4. 确定愿景声明并定期持续维护，确保产品能够符合市场现状并支持公司需求的变化。
  • 价值主张画布
    • 价值主张画布有助于：
      • 了解客户的需求和期望；
      • 根据客户的需求开发产品；
      • 将现有产品与用户需求进行比较；
      • 找到适合你的产品市场；
      • 避免生产没人想要的东西；
      • 节省时间和金钱。
    • 何时使用
      • 在创业初期。
      • 为产品添加新功能，这些新功能可能需要时间或资源方面大量的投入。
      • 要扩展到新市场或客户群，你需要了解这些新客户将如何接受你的产品/服务。
  • 商业模式画布
    • 定义
      • 商业模式就是—个描述企业如何赚钱的计划。
      • 它解释了你的客户群是谁，你如何为他们提供价值，以及融资的相关细节。
      • 商业模式画布是一种可视化的工具，它允许你把商业模式中九大要素放在同一张纸上，从而更加易于评估商业想法或概念。
      • 商业模式画布实际上是另一种形式的商业计划，但它比传统的商业计划更加易用，更加直观，更加高效。
    • 组成部分
      • 1.客户细分(Customer Segment）
        • 你要把产品或服务卖给谁。
      • 2.价值主张 (Value Proposition）
        • 为客户提供的利益的集合或组合。
      • 3.渠道通路(Channels）
        • 一家企业如何同它的客户群体达成沟通并建立联系，以向对方传递自身的价值主张。
        • 与客户的交流、分销和销售渠道构成了一个企业的客户交互体系。
        • 渠道通路在客户体验中扮演着重要角色的客户触点。
      • 4.客户关系(Customer Relationships）
        • 一家企业针对某一个客户群体所建立的客户关系类型。
      • 5.收入来源(Revenue Streams）
        • 企业从每一个客户群体获得的现金收益（须从收益中扣除成本得到利润）。
      • 6.核心资源(Key Resources）
        • 保证—个商业模式顺利运行所需的最重要的资产。
        • 核心资源可包括实物资源、金融资源、知识性资源以及人力资源。
        • 核心资源可以是自有的，也可以通过租赁获得，或者从重要的合作伙伴处获得。
      • 7.关键业务(Key Activities）
        • 保障其商业模式正常运作所需的最重要的事情。
      • 8.重要伙伴(Key Partnerships）
        • 保证—个商业模式顺利运行所需的供应商和合作伙伴网络。
      • 9.成本结构(Cost Structure）
        • 运营—个商业模式所发生的全部成本。
  • 产品路线图
    • 产品路线图是产品战略目标和期望的高层级可视化概览。它包括产品主要的高层级特性和目标。
    • 为什么
      • 有助于描述愿景和战略
      • 为战略的执行提供一个向导性文档
      • 让所有的内部利益相关者能够对齐
      • 有助于和外部的利益相关者（包括客户）进行沟通
    • 何时使用
      • 制定完产品的战略/价值主张/愿景之后，就可以进行产品路线图的制定。
• 需求获取
  • 需求访谈的三架马车
    • 在需求访谈时 定义三个角色进行需求访谈
      • 1.主问者：
        • 推荐需求工程师担当，事先准备了需求访谈问题单，负责现场对照问题单提问，并根据客户的回答临时追加问题。
      • 2. 记录员：
        • 可以是需求工程师或开发人员，负责记录客户回答的问题，并思考追加新问题。
      • 3.思考者：
        • 推荐测试工程师担当，负责思考需求的可测试性，根据客户的回答，追加问题，澄清需求，确保需求可测试。
    • 作用
      • 通过明确需求访谈的三个关键角色，能够让需求访谈更加全面
      • 可以使团队的工作分工和工作风格保持一致和连贯，确保访谈的质量。
      • 针对访谈的改进也因此有章可循。
    • 注意事项
      • 1. 不建议一个人兼任三个角色，太累，访谈效果不好，容易遗漏问题，需要迭代多次。
      • 2.最少2个人，可以主问者同时担当记录员，也可以思考者担当记录员。
      • 3.记录员可以通过录音笔替代之，自动形成文字版记录。
      • 4.主问者可以与思考者每半小时交换一下角色。
  • 实例化需求
    • 实例化需求通俗地讲就是“三剑客”（产品经理、开发人员和测试人员）一起共创需求，最后将需求以实例的方式形成活文档。
    • 在需求共创时使用，在Scrum框架中，一般是本迭代对下一个迭代的需求采用实例化需求的方式进行共创。
    • 同类型实践
      • 敏捷验收测试
      • 验收测试驱动开发
      • 实例驱动开发
      • 故事测试
      • 行为驱动开发
      • 实例化需求说明
    • 示例
  • 用户画像
    • 基于真实目标用户数据绘制的典型用户的情况介绍，它帮助产品经理（以及组织中参与产品开发的其他人）根据特定类型（而不是广泛意义上的）用户的关键特征、行为、目标、痛点、期待等打造产品。
    • 使用步骤
      • 1.做调研
        • 首先要收集有关客户的信息，用户画像要基于真实的信息来做。
        • 最好是直接访谈最终用户，实在不行的话，可以访谈与用户接触的角色，如销售及客户服务人员等。
      • 2.做用户细分
        • 分析收集到的调研数据，确定具有相同角色人的共同属性，找到他们的模式。
      • 3.构思用户画像布局
        • 用户画像是可以根据产品及团队的实际情况进行个性化定制的。
      • 4.增加人口统计信息
        • 如姓名、性别、年龄、婚姻状态、工作等信息。
      • 5.增加一些额外的背景信息（如有必要）
        • 很多时候，额外的背景信息有助于增强同理心，提供更多的洞察。然而如果提供不恰当，有可能会造成误导。
      • 6.定义用户的目标
        • 定义用户的目标非常重要。这样可以让产品的目标与用户的目标对齐。
      • 7.定义痛点和期待
        • 在用户画像中描述痛点和期待，可以让我们的产品更好赢得用户的忠诚。
  • 影响地图
    • 何时使用
      • 为不存在的产品定义功能
      • 规划下一个迭代或发布，即对特性进行优先级排序
      • 论证某个功能是非常有价值还是毫无价值
    • 如何构建影响地图
      • 1.设置业务目标
        • 业务目标要满足SMART。
      • 2.列出利益相关者
        • 列出有助于目标达成的以及有可能阻碍目标达成的利益相关者角色。
        • 可以使用用户画像技术来辅助分析
      • 3.列出影响
        • 为每个利益相关者列出他们行为的哪些变化有助于业务目标的达成。
      • 4,列出交付物
        • 我们要提供哪些功能可以可以导致/促进利益相关者行为的变化。
        • 将相邻层级用线连接起来,表示它们之间的关联关系。
  • 验收标准
    • 验收标准在需求/用户故事梳理的过程中制定，由产品负责人、开发、测试等人员共同讨论并达成一致。
    • 验收标准的确认工作要先于估算活动，因为验收标准不同，工作范围和工作量也会有所不同。
  • 用户故事
    • 用户故事是需求获取的一种手段：
    • ·首先，它从用户的视角提供简短的描述，说明想要解决一个什么用户问题
    • ·然后，它鼓励大家通过对话来澄清需求的细节
    • ·最后，要记录用户故事的细节以及做到什么才算完成的标准。
    • 何时使用
      • 只要想到要解决的问题，就可以使用用户故事记录下来（仅提供简要描述即可），放到需求池中，待后期临近实现再澄清需求细节。
      • 并在开发的全程根据工作的进展和新的信息更新用户故事。
  • 用户故事地图
    • 是一种安排用户故事的方法，将客户旅程的基本步骤安排在水平轴（行）上，将用户故事安排在相应的步骤（列）下面。
    • 在同一列中，用户故事的优先级由上至下依次降低。
    • 当用户故事地图完成时，可以在单一的逻辑视图中看到用户与产品交互的所有方式，从第一次交互到完成总体用户目标。
    • 使用用户故事地图，可以以更全局的视角了解用户故事如何融入整体用户体验。
  • 客户旅程地图
    • 描述了单个用户为了实现其目标而必须执行的阶段和行动步骤、客户在整个过程中的情绪变化、不爽的触点，或未满足的需求等。
    • 如何使用
      • 1.选择为哪个角色描绘旅程地图。如果有多个不同的角色，要绘制多张旅程地图。
      • 2.说明场景和期待：
        • 场景是该旅程地图想要解决的问题域的综述。
        • 期待是角色对解决方案域的期待3.确定高层级阶段，方便问题的分析。
      • 4.填写动作、心态和情绪：
        • 动作：角色在相应阶段采取的步骤心态：角色在旅程的不同阶段中各个触点的想法、问题、动机和信息需求等。
        • 理想情况下这来自于客户访谈的逐字记录。可以结合同理心地图使用。
        • 情绪：横跨各个阶段的单条线，表示角色的心情在各个阶段的心情高涨还是低落。
      • 5.机会：
        • 是从整个旅程地图中获得的洞见，说明如何优化用户体验。
        • 包括我们需要做些什么来改善?谁负责哪些修改?最大的机会是什么?我们如何度量这些改进?
      • 客户旅程地图应该是动态维护的，随着时间的推移和更多信息的获得，要持续更新客户旅程地图。
  • 同理心地图
    • 同理心地图是一个可视化工具，它能够帮助团队使用同理心来获取对于目标群体的洞察
    • 该工具提供了一系列的提示，以确定目标群体的想法、感受、动机、期待和需要。这迫使调研的团队关注目标群体的需求，而不是自己的需求。
    • 何时使用
      • ·商业模式设计。
        • 如果你使用同理心地图来帮助设计你的商业模式，你可以从一开始就获得巨大的优势。
      • ·产品开发。
        • 帮助开发者／工程师与那些实际使用你的产品的人产生共鸣。
      • ·开发客户资料。
        • 虽然客户资料是用户画像开发的一部分，但同理心地图可以帮助团队成员为这些用户画像添加更多深度。
      • ·用户界面和用户体验讨论。
        • 这种讨论有助于设计师和开发人员做好他们的工作，但所有部门的人员都应该参与其中。
      • ·了解用户行为。
        • 当你发布了一个新产品，并在使用和可能的改进方面度量其影响。
• 需求拆分
  • SPIDR用户故事拆分法
    • 构成
      • 探针(Spikes)
        • 是为了获得完成复杂故事所需知识的研究活动。
        • 例如：自制/采购决策
      • 路径(Paths)
        • 按路径（Paths）拆解：用户在采取某种行动时可能通过不同的路径达成自己的目的
      • 交互(Interfaces)
        • 按交互（Interfaces）拆解：按照在不同的浏览器、硬件平台等进行分拆，对于复杂的交互场景还可以通过多个迭代交付。
      • 数据(Data)
        • 我们可以通过化简支持的数据集，或为支持的数据集添加限制，以便能够持续交付价值。
      • 规则(Rules)
        • 当一条故事中需要大量的规则约束时，将这些规则分批实现可以把大故事有效拆小。
• 需求排序
  • MoSCow排序法
    • 是一种用于管理、业务分析、项目管理和软件开发的优先级排序技术，用于与利益相关者就需求的重要性达成共识。
    • 在任何需要对需求进行排序或者做计划的时候都可以选择使用MoSCoW优先级排序方法，如做需求梳理、发布计划、迭代计划等
  • RICE排序
    • RICE是用来对优先级进行评估的四个因素的开头字母缩写
      • 影响范围（Reach)
      • 影响力（lmpact）
      • 信心（Confidence)
      • 工作量（Effort)
    • RICE值=（影响范围X影响力X信心）/工作量，值越大，优先级越高。
    • RICE优先级模型可用作产品路线图规划会议的输入数据。
  • Kano模型
    • 第一个维度是“客户满意度”，表示客户对实现（或不实现）特定特性的满意度。
    • 第二个维度是“功能”，它表示该特性在多大程度上实现了预期的功能。
    • 将潜在特性分为四类：
      • 兴奋型需求
        • 若不提供此需求，用户满意度不会降低；
        • 若提供此需求，用户满意度会有很大的提升。
      • 期望型需求
        • 当提供此需求，用户满意度会提升；
        • 当不提供此需求，用户满意度会降低。
      • 基本型需求
        • 当不提供此需求，用户满意度会大幅降低，但优化此需求，用户满意度不会得到显菩提升
      • 无差异需求
        • 用户根本不在意的需求，对用户体验毫无影响。
  • 相对权重优先级排序
    • 相对权重是一种通过评估特性的相对价值、成本和风险，并可为其分配权重来计算优先级的一种方法
  • WSJF
    • 加权最短作业优先 (WSJF) 是一种优先排序模型，用于对待开发的产品功能进行排序，它的计算方法是将工作的延迟成本除以工期。
    • 在最短的时间内能够提供最大价值（或延迟成本）的工作，被优先选择实施。
    • 何时使用
      • 在做功能特性排序的时候使用
• 需求估算
  • 故事点
    • 故事点是相对估算中的一种度量单位。设定某个基准故事的大小为1，其他故事的大小即为这个基准故事大小的倍数。
    • 如何使用
      • 1.选取一个所有人都清晰的、较小的用户故事作为基准故事，指定其故事点为1。
      • 2.将其他故事的规模和这个基准故事进行比较，其他故事是基准故事的多少倍，那么故事点即为多少。
      • 3.估算的时候要考虑如下因素:
        • 完成工作所需的预期工作量和专业知识
        • 团队过去完成类似任务的经验
        • 估算时的不确定性、疑虑和风险
        • 完成任务所需的测试和错误修复
        • 工作流程管理开销，包括沟通、会议和完成所需的管理工作
      • 4.通常结合使用估算扑克或者亲和估算来使用。
  • 亲和估算
    • 亲和估算是将大量的条目按照规模相对大小依次顺序排列并分组，然后按组分配估算值的快速估算方法
    • 当待估算的需求条目数比较多的时候（如超过25个），用亲和估算就比较高效。
  • 计划扑克
    • 计划扑克是一种基于共识的游戏化估算技术。
    • 计划扑克是宽带德尔菲法的一种变体，同时亮牌的方式，可以避免自己的估算无意中受到他人的锚定。
    • 通常在需求梳理活动中对需求/用户故事进行估算的时候使用计划扑克。
• 需求监控
  • 需求跟踪矩阵
    • 需求跟踪矩阵是一种主要管理需求变更和验证需求是否得到了实现的有效工具
    • 借助需求跟踪矩阵，可以跟踪每个需求的状态。
  • 变更控制委员会
    • 变更控制委员会（CCB）是一个委员会，由主题专家（SME，如软件工程师、测试专家等）和经理（如质量保证经理）组成，他们决定是否对项目实施拟议变更
    • 变更控制委员会将审查与客户商定的原始基线要求的任何拟议变更。 如果委员会同意任何变更，则该变更将传达给项目团队和客户，且要求以变更为基准。
• 解决方案评价
  • 礼宾MVP
    • 礼宾MVP是全程使用手动的方式引导用户解决问题，和用户一起探索问题/解决方案，通过亲自与用户进行交互，对用户和你所提供的价值有很大的了解。
    • 作用：礼宾MVP不仅可以通过跳过产品建设节省大量的时间，还可以让你直接与你的早期客户接触，深入了解他们的需求
    • 如果你自己对客户问题的理解不太自信，并且希望与客户进行更深入的互动，请使用礼宾MVP
  • 绿野仙踪MVP
    • 绿野仙踪MVP依靠人工服务客户，但最终用户不知道是人躲在后面，它给客户一个假象，以为这就是最终的产品。
    • 绿野仙踪的MVP是测试假设的最快和最有效的方法之一，它不需要实际构建任何东西，就可以测试拟议的解决方案是否会给客户创造价值。
    • 由于测试是手动进行、低成本的，因此可以快速修改MVP，测试大量的假设，找到最有效的解决方案。
    • 何时使用：如果你对问题有很强的理解，并且希望缩小特定解决方案的范围，请使用绿野仙踪MVP
    • 如何使用
      • 1．确定要测试的假设。
      • 2．构造未来产品和最终用户之间的交互界面。
      • 3．后台操作全部采用手工的方式进行。
      • 4．分析测试的数据。
      • 5．根据测试的数据调整假设并继续测试，直至达成满意的效果。
  • 着陆页MVP
    • 1.着陆页是一个单一的页面，它：
      • 。描述你的产品或服务。
      • 。说明使用你的产品或服务的一些优势（你的独特价值主张）。
      • 。包含一个按钮，让感兴趣的访问者点击阅读更多内容、加入邮件列表、立即购买或其他一些行动
    • 2.着陆页的目标不是销售某些东西成产生潜在客户，而是通过对不存在的商品和服务做出广告宣传，从而获得有效的学习， 而在之前，这些商品和服务只存在于企业家的脑海中。
  • 电子邮件MVP
    • 这是一种使用电子邮件对目标市场进行测试的方法，它相对更便宜、更快速
    • 如果你有独特的有价值的信息，你可以在电子邮件简报中分享，看看你会得到什么样的需求。
    • 1.确定要测试的假设。
    • 2.利用合适的邮件服务平台向潜在的客户发送与要测试的假设相关的邮件，或者提供邮件订阅服务。
    • 3.观察潜在客户的反应并调整邮件的内容。
    • 当潜在客户的反应达到预期，就可以向产品投入更多精力打造细节。
  • 碎片拼接MVP
    • 碎片拼接MVP指的是推出新的产品或服务时，用第三方服务或应用程序来填补特定的空白，而不是花时间自己开发产品的那个方面，达到的效果是整体方案比其各个部分的总和更有价值
    • 想要验证自己的想法，同时这个想法中的很多部分是可以通过第三方的服务协助进行的，就可以尝试使用碎片拼接MVP。
  • 众筹MVP
    • 没有现有客户或客户数据的公司可以使用众筹平台以非常经济的方式测试全新概念。
    • 众筹活动是与早期采用者签约并从感兴趣的受众那里获得直接反馈的好方法。
    • 当要开发一款产品，但缺乏资金的情况下，可以使用这种方法来筹集资金。
    • 要注意，此时这个产品的概念是要经过慎重调研且有强有力的故事和推进计划的。
  • 单一特性MVP
    • 单一特性MVP是只包含一个单一特性的MVP，它是一个软件产品，旨在测试用户对一个特定特性的接受程度。
  • A/B测试
    • A/B测试是一种用户体验研究方法，它随机测试某个主体对版本A和版本B的反应，从而确定哪一个版本更有效。