产品构想在敏捷项目管理中怎么做？

本图介绍了敏捷项目管理中产品构想如何做？相关知识点有：可发布的产品、敏捷三要素：价值、质量、约束、构想做法、产品构想框、电梯测试说明书、项目数据表、产品构想、项目目标和约束、权衡矩阵、探索系数、项目社团、自组织策略、流程架构裁剪、做法选择裁剪项目计划的演变。

敏捷项目管理之构想阶段

• • 6.1 可发布的产品
    • 敏捷成功的基础：敏捷三要素：价值、质量、约束---战略目标，不是具体要求
      • 可交付的产品：产品构想框；项目数据表 --- 项目目标声明、企业目标、性能、性能价值
      • 可靠的、适应性强的产品：项目数据表 --- 质量目标
      • 在可接受的约束内：项目数据表 --- 均衡矩阵（范围、进度和成本）
    • 产品的一个发布标准：功能或者故事的完成
    • 导致产品不能交付的负面因素将成为适应性策略的输入信息
• • 6.2 构想做法
    • 目的：明确地鉴定需要做什么，以及如何做
      • 客户的产品构想是什么？
      • 项目的商业目标是什么？
      • 项目的质量目标是什么？
      • 项目的约束是什么（范围、进度和成本）？
      • 团队将如何交付产品（方法）？
    • 在构想阶段，产品构想经常随着新信息而不断演变；而在构想阶段后，则需要对构想定期审核以确保团队能持续理解它
    • 构想阶段决定了项目的启示
    • 敏捷项目管理的构想和推测阶段，尤其要记住：
      • 团队成员应经常自问“我们需要的刚好够的流程和文档是什么？”
      • 与团队交付“方式”有关的所有做法，都随着项目的进行，需不断做出裁剪和调整，以调高业绩
      • 项目社团将不断演变其团队做法
        • 1| 产品构想
          • 产品构想框 和 电梯测试说明书
          • 产品体系结构 和 指导原则
        • 2| 项目目标和约束
          • 项目数据表（Project Data Sheet, PDS）
        • 3| 项目社团
          • 找到合适的人选
          • 确定参与者
          • 客户团队-开发团队 界面
        • 4| 方法
          • 流程和做法的裁取
• • 6.3 产品构想
    • Pre：
      • 团队把构想看作是一种输入
      • 创新（创造我们无法预测的突发结果）需要一个能够容纳探索和错误的演变流程
      • 每个产品需要一个框：营销主题、简明直观的图像和功能描述
        • 对于软件及小型产品 --- 产品包
        • 对于大型产品如汽车、医疗设备 --- 可能是一两页产品小册子、一两个网页
        • 产品盒：
          • 正面：产品名称、图形、3～4个关键卖点
            • 从15～20个功能到3～4个功能-构想框练习-讨论、提高团队凝聚力
          • 背面：详细功能描述及操作要求
      • 工具方法：
        • 构想框 / 产品构想框 / 构想框练习
          • 构想框
            • 将产品构想的信息浓缩在两页活动挂图上（构想框的正反两面）
        • “电梯测试说明书”
          • 编写产品定位的简短陈述---用几个句子表明目标客户、主要好处和竞争优势
          • 两分钟内向其他人解释项目的句子，格式：
            • 对于（目标客户）
            • 谁（需要或有机会声明）
            • 这个（产品名称）是（产品类别）
            • 它（主要的优点、引入注目的购买原因）
            • 不同于（主要的竞争产品）
            • 我们的产品（主要差别）
        • 生动描绘了产品构想
        • 构想会议
          • 讨论记录在活动挂图纸上的产品构想
            • 如：任务说明、构想框图、目标客户、客户需求、电梯测试说明书、客户满意评估标准、主要技术和业务需求、关键产品限制（如性能、简便性、体积等）、竞争分析、主要财务指标等
          • 促使形成对产品宏伟蓝图的统一意见
        • 原型或工作模型
      • 以产品为中心的思维
      • 为需要什么样的产品确立了基线
    • 6.3.1 产品体系结构
      • 🎯目标：描述项目的内部沟通渠道，是一种促进探索和指导正在进行的产品开发的设计。
      • 旨在把较大项目背景传达给开发团队，而不是局限于一个设计
      • 敏捷开发中，体系结构是指引，而不是紧箍咒
      • 软件项目可以使用 业务领域模型 和 技术上的 框图概念模型。
      • 一般而言，技术体系结构是由一些由平台、部件、界面和模块等组成的综合体系结构
      • 工具：
        • 功能分解结构（Feature Breakdown Structure, FBS），用来描述软件或硬件项目的产品体系结构
          • 客户和团队间的沟通渠道
      • 大型项目中，项目团队结构和技术体系结构往往随项目同时演变
    • 6.3.2 指导原则（Guiding Principles,GP）
      • 作用：协助开发团队塑造产品，满足客户需求
        • 通常不是可衡量的。而只是概念上的指导
      • 时机：
        • 在具体要求和设计决定制定之前，就可以使用知道原则了
        • 一些指导原则除了可以在构想阶段就制定外，通常要到早期的开发迭代时才出现。
      • 早期的指导原则可能在以后的演变中成为具体要求
      • 原则的原则：
        • 每个原则应该用一两个句子描述
        • 任何情况下，一个项目的全部原则描述不得超过十个句子
• • 6.4 项目目标和约束
    • 6.4.1 项目数据表（Project Data Sheet, PDS）
      • 在项目计划的演变过程中，PDS是第二个重要的构想做法
      • 是项目目标和约束的最少文档编制
        • 一页纸，概括了：主要商业和质量目标、产品功能和项目管理信息。
          • 这些人：顾客/客户、PM、PO、高级主管、项目目标申明（Project Objective Statement, POS）---明确而简单的声明（不超过25个字），其中包括重要范围、进度、和成本信息商业目标：做这个项目的金融和商业原因权衡矩阵：确立项目范围、进度和成本的相对优先次序的表格探索系数：衡量项目风险和不确定性的度量标准（1～10）延误成本：项目延误所造成的财务成本（进度被列为最优先次序时尤其有用）功能、质量目标：一个可发布的产品的定量、定性质量目标性能/质量属性：产品主要性能和质量属性清单体系结构知道方针：修正设计决定的主要体系结构指导方针问题/风险：对项目有负面影响的因素
        • 项目目标声明项目数据表：提供运动会员网上自动服务系统，包括场地时间表、账单、会员服务费用结算。这个系统需要在2020年6月30日前投入运营，成本不超过15万美元
      • 产品构想：应该有的东西；项目范围：将要有的东西
    • 6.4.2 权衡矩阵
      • 延误成本是另一个协助团队做项目决策的
      • 当项目的价值、质量和约束三者间的健康平衡被打破时，权衡矩阵就开始发挥作用了
    • 6.4.3 探索系数
      • 用来表示：项目的不确定性和风险指标
      • 探索系数为10表示问题领域是以探索为主（高风险），为1表示比较稳定的环境
      • 阐明项目的探索系数有助于管理客户和主管的期望值
      • 它是从产品需求（目的）的易变性及其技术平台（手段）的新颖性（也就是不确定性）派生出来的
      • 通过确定探索系数，可以从项目整体“不确定性”角度讨论问题
      • 一旦有了这样的认识，按具体的问题量身定制适合的流程和做法将会大大提高成功概率
• • 6.5 项目社团
    • 6.5.1 确定参与者
      • 找到合适的人员，是项目社团的主要目标
        • 合适：
          • 适当的技术能力（或专业技术）
          • 适当的自律行为
      • 本书中，“利益相关方”不仅表示内部参与者，也表示外部参与者（如供应商）
      • 大致来讲：
        • 客户提供需求
          • 他们是使用产品为自己或者他们的组织创造价值的参与者
        • 项目团队成员建造产品
          • 他们是积极从事产品交付的开发人员和管理者
        • 利益相关方监督和制定限制
          • 他们提供监督、约束、合规活动要求和资源（供应商）
      • 产品团队-客户界面
      • 托姆赛特的利益相关方3个级别
        • 关键的
          • 特别有影响力，任何时候可以阻止项目成功
        • 必须的
          • 要围绕他们工作，热河时候他们可以拖延项目成功
        • 非必须的
          • 感兴趣者，但是若不包括他们到社团内，他们可能转变成关键的或者必须的那类人
      • 确定和管理参与者有助于提高协作
      • 项目参与者可能包括：
        • 高级主管
        • 项目领导者
        • 产品经理
        • 产品专员
        • 迭代经理
        • 总工程师（开发人员、架构师）
        • 高层管理
        • 产品团队
        • 项目团队
        • 开发团队
        • 供应商
        • 政府
    • 6.5.2 产品团队-开发团队交互
      • 人员不仅比流程重要，也比角色重要
      • “建造什么”的决策主要由客户团队做出；“如何建造”的决策主要由开发团队做出
    • 6.5.3 交付方法
      • 团队自律的部分内容是团队就某种方法达成一致，然偶实际地应用它。未能达成一致或没有执行该方法，都是缺乏自律的表现
      • 流程和做法的裁剪工作定义了项目团队交付某个产品将使用的方法。她以组织的标准架构为基础，在该架构的限制内根据需要进行裁剪。
      • Focus on 人们如何在一起工作、如何协作以及协作的机制。而流程和各种做法Focus on实际做什么
      • 流程和做法是互补的，是不断演变的
    • 6.5.4 自我组织策略
      • 自组织策略问题：
        • 我们如何与客户协作？来自不同功能团队的项目成员如何相互协作？A地的团队如何与B地或者C地的团队协作？授权对我们团队来说意味着什么？谁需要在何时与谁交谈？相互交谈的这些人如何决策？谁负责什么？他们打算用哪些做法来推动上面提出的问题？
      • 沟通 与 协作
        • 大多数项目管理方法都包括沟通计划
        • 对敏捷而言，管沟通是不够的，更需要协作。
    • 6.5.5 流程架构裁剪
      • 要平衡结构和灵活性
      • 流程架构应该努力找出刚刚好的项目组织标准
    • 6.5.6 做法的选择和裁剪
      • 不应该塑造人使其适应一套流程和做法；而应该熬着团队自身特点，塑造流程和做法
      • 4个基本问题：
        • 哪些做法是必须的？还需要哪些辅助性做法？需要对选择的做法做哪些修改？做法的编档、批准和更改需要什么手续和形式？
      • 不光流程架构要刚刚好，做法也要刚刚好
      • 在一两次迭代中发现有些做法不再有效时，是是实施辅助性做法的最好契机
      • 在丰田，技术规范是结果的文档，而不是计划的处方
      • 在裁剪编档做法时，团队应学会区分：永久性文档：制定了相关预算，而不断更新；工作文件：不需要更新
• • 6.6 结束语
    • 在构想阶段后，构想并没有停止。
    • 在每次迭代或里程碑的开头，团队在一起思考下一次迭代时，需要重新审视该构想。 重新审视是为了修改这个构想，或者提醒团队努力的地方在哪里
• • Tips:
    • 构想的两个关键方面：明确的和令人振奋的目标
      • 明确的构想必须明确探索的边界
      • 好的构想的实质是团队对这个构想的清晰表述
    • 项目计划的演变：
    • 3种做法：
      • 构想框
        • 将产品构想的信息浓缩在两页活动挂图上（构想框的正反两面）
      • 项目数据表
        • 在一页纸上节略出主要的项目范围和约束信息
      • 发布计划（项目功能卡）（推测阶段完成）
        • 将功能的关键信息精简到一张索引卡上
      • 基于有限“地产”原则的3个工具