思维导图
管控产品失败（降低不确定性）的方法
不确定性、累计成本与开发阶段的关系
标准的决策框架
产品开发流程基本阶段
- 探索（Exploration）
- 筛选（Screening）
- 商业评估（Business Evaluation）
- 开发（Development）
- 测试（Testing）
- 商业化（Commercialization）
常见产品开发流程
- 门径管理流程（Stage - Gate@）
- 集成产品开发（IPD）
- 精益开发（Lean）
- 敏捷开发（Agil）
- 设计思维（Design Thinking）
模糊前端FFE
模糊前段（Fuzzy front end，FFE）：产品开发项目的前端是一个早期极端的起点，在进入正式的产品开发流程前，组织在该阶段识别机会，形成概念。
该阶段包括创意生成阶段，初始概念发展阶段和高级业务阶段。
是项目中定义最不确定的一个阶段
注：创意阶段可能有5个，概念开发阶段经过淘汰与融合变成了2个，最后立项分析，确定要做的项目
门径管理流程
阶段-关口概念
什么是阶段
产品开发流程中的一个确认区域，包括：
活动：项目负责人及团队成员依照项目计划必须完成的工作
综合分析：通过跨职能部门及团队成员依照项目计划必须完成的工作
可交付成果：是综合分析结果的呈现，这是团队必须完成的并在关口时所以提交的内容
什么是关卡
基本上，他是产品开发流程中的一个确认节点，在该阶段时需要做出有关项目未来的关键决策。包括
可交付成果：关口评审点的输入内容（阶段中的可交付成果）。它是前阶段行为的结果，是实现确定的，在每个关口都有一个可交付成功的标准清单
标准：判断项目是继续还是停止以及优先级决策的标准，这些标准通过以分数呈现，包括财务和定向标准
输出：关口评审结果。关口必须有明确的输出包括一个决策（继续或者停止）以及下一个阶段的路径
阶段 - 关口（Stage - Gate）新产品开发过程
根据需要，可灵活裁剪与添加
分为六个阶段，由来自公司内部不同职能领域的人员一起完成：
发现（Discovery）：寻找新机会和新产品创意
筛选（Scoping）：也叫观察，初步评选市场机会、技术需求以及能力的可获得性
立项分析（Business Case）：也叫构建产品框架，建立在筛选阶段之上的一个关键阶段，包括更为深入的技术，市场和商业可行性分析
开发（Development）：产品设计，原生制造，生产设计，制造准备和上市规划
测试与修正（Testing and Validation）：也翻译成测试与确认，测试产品以及商业化计划的所有方面，以修正所有假设和结论，和证实对产品的预期和总结
上市（Launch）：也翻译为投放市场，产品的完整商业化，包括规模制造以及商业化上市
阶段：一个确定区域，包括 活动，综合分析，可交付成果
关卡：一个确定阶段，必须又明确的输出包括一个决策（继续或者停止等）以及下一阶段的路径。包括：可交付成果，标准，输出
瀑布模型
- 要求：了解要设计产品需要什么功能、目的、用户需求
- 设计：确定完成项目所需的软件与硬件，之后被转化为物理设计
- 实施：根据项目要求和设计规范编写实际代码
- 验证：确保产品符合顾客的期望
- 维护：通过客户确定产品设计中的不足或错误，进行修正
集成产品开发IPD
integrated Product Development，PID
前身 - 并行工程
含义
在产品的设计与制造流程中，跨职能团队采用并行模式进行工作，而不是各个功能的顺序依次开发，从而促使团队全面考虑产品生命周期中从概念到实施的全部元素，包括质量、成本、维护等方面
主要特征
- 并行交叉：并行工程强调产品设计与工艺过程设计、生产准备、采购等活动交叉进行
- 按部件并行交叉，将一个产品分成若干部分，使其各部件能并行进行交叉开发
- 各个组件的设计、采购、生产等各种互动尽可能的交叉并行
- 尽早开始工作，目的就是争取时间
具体做法
在产品开发的初期，组织多种可协同工作的项目组，使得有关人员从一开始就获得有关项目的最新消息，积极研究涉及本部门的工作任务，并将需求提供给设计人员，使得许多问题在开发早期就得到了解决从而保证设计质量，减少返工与浪费
发展 - 集成产品开发IPD
含义
系统综合地应用不同职能体系的成果和理念，有效、高效的开发新产品，满足客户需求的方式
IPD管理的精髓
- IPD基于并行工程发展而来
- IPD首先是一个商业流程，关注商业结果，将产品开发作为一项投资进行审慎管理
- IPD采用跨职能团队，加强部门合作，形成合力，共同承担
- IPD流程分为不同的阶段，通过在决策评审点的决策实现集成组合管理团队（IPMT）和产品开发团队（PDT）互动，资源受控分配与投入，既满足项目进展的需求，又避免了投资失控的风险
- IPD是灵活的，发展的，持续改进设计的，在不断吸纳业界实践和解决业务问题的过程与时俱进
- IPD流程是基于市场的开发，关注市场需求和竞争分析，鼓励创新基于着二者之上
集成产品开发系统分级
精益产品开发
定义（Lean Product Development）：创建在丰田首创的精益方法（TPS）的基础之上。目的是：从流程中去掉浪费
精益开发的原则（提升生产效率）
- 确定客户定义的价值
- 尽最大努力探索不同的解决方案
- 创造顺畅的产品开发流程
- 尊重颜色的标准，以减少变异
- 首席工程师全程参与
- 跨职能整合
- 学习不断改进
- 准求卓越与不断学习的文化
- 团队整个组织
消除浪费 + 强化学习 + 慎重政策 + 尽快交付 + 授权团队 + 品质为先 + 全局优化 + 消除浪费 = 精益产品
潜在的浪费来源包括
- 混乱的工作环境
- 缺乏可用的资源
- 缺乏明确的优先级顺序
- 不同职能之间的沟通存在障碍
- 糟糕的产品需求定义
- 缺乏对可制造性的早期考虑
- 过度设计
- 太多无效会议
- 太多的电子邮件
直接效益
- 显著提升生产效能
准时制
准时制生产方式（Just In Time简称JIT），又称作无库存生产方式（stockless production），零库存（zero inventories），单件流（one - piece flow）或者超市市场生产方式（supermarket production）
JIT的基本理念：只在需要的时候、按需要的量，生产所需的产品，故又被称为准时生产、适时生产方式。
JIT的目标：彻底消除无效劳动和浪费。具体要达到以下目标
- 废品量最低 2. 库存量最低 3. 准备时间最短 4. 生产提前期最短 5. 减少零件搬运，搬运量低 6. 机器损坏低 7. 事故降低
单件流
批量生产虽然是降低成本的生产方法，但是容易出现堆积浪费，周转麻烦，容错率低的问题
单件流则有目的的降低周转问题，并且减少堆积浪费，同时增加容错率
5WHY法（刨根问底法）
安灯法
操作：产线异常，按下按钮 - 产线报警 - 领班支持
收益：
- 一线员工既要动手，也要动脑
- 鼓励员工持续成长，获得成就感
- 公司流程优化，持续改善
现场现物
亲临现场 - 细致观察，分析/评估 - 找出原因
构建学习型组织
- 超越短期利益，着眼长期利益
- 致力提升员工，合作伙伴能力
- 继任领导延续公司文化基因
丰田模式的核心精神是通过支持和鼓励员工持续改善工作流程
让他们不断成长与进步，进而获得工作成就感和主人翁意识
精益产品开发过程的核心概念
精益产品开发的优劣势
优势
- 流程的聚焦点在于信息的顺畅流动,而非严厉管控
- 通过事件驱动方法简化合作，优化设计
- 重视对进度、成本、消极和质量方面的风险的积极管控
- 适用于各种规模的项目
- 用于记录学习和进展、判定优先级和解决问题的工具是简单的，可视化的
劣势
- 参与人员必须是相当敬业并且经验丰富的
- 需要改变组织的结构和文化
- 需要强有力的供应商管理
- 组织有意愿且有能力接受项目目标的和方向上的变化
敏捷开发
传统方法VS敏捷方法
| 传统的写作方式 | 敏捷的写作方式 | |
|---|---|---|
| 确定主题 | 与读者互动 | |
| 整理大纲、搭建框架 | 确定主题 | |
| 书写内容 | 与读者互动。收集反馈 | |
| 设计、排版、校对 | 试写第一张 | |
| 出版 | 与读者互动，收集反馈 | |
| 与读者见面 | 试写第二章 | |
| 筹集反馈 | … | |
| 设计、排班、校对 | ||
| 出版 |
传统VS敏捷之客户互动对比
确定性项目VS不确定性项目
生命周期类型
增量型：楼盘 定下来不会变 但是要不断交付
敏捷性：互联网项目 不断在变化
预测型：铁路建造 变化极小，有规律的项目
迭代型：研发疫苗 不断变化，但是只需要交付一次
Stacy斯泰西图
敏捷宣言
| 敏捷宣言 | 价值观 | |
|---|---|---|
| 个体以及互动 胜于 流程和工具 | 以人为本 | |
| 可工作的软件 胜过 完整的文档 | 以价值为导向 | |
| 客户合作 胜过 合同谈判 | 合作共赢 | |
| 响应变化 胜过 遵循原则 | 拥抱变化 |
敏捷开发十二大原则
- 通过尽早和持续地交付有价值的软件来满足客户
- 欢迎对需求提出变更，敏捷过程要善于利用需求变更，帮助客户获得竞争优势
- 经常交付可用软件，并周期越短越好
- 业务人员与开发人员必须通力合作
- 要善于激励项目人员，基于他们所需的环境和支持，并相信他们能完成任务
- 团队内部和各个团队之间，最有效的沟通方式是面对面沟通
- 可工作的软件是衡量进度的首要指标
- 敏捷过程体长可持续的开发。项目方、开发人员和用户应该能够保持稳定恒久的进展速度
- 对技术的精益求精以及对设计的不断完善将提高敏捷性
- 尽量做到简洁，尽最大可能减少不必要工作，这是一门艺术
- 最佳的架构、需求和设计出自于自组织团队
- 团队要定期回顾和反思如何能够做到更有效，并相应地调整团队的行为
敏捷Scrum框架
敏捷实践SCRUM的333555
| 三个支柱 | 三个角色 | 三个工件 |
|---|---|---|
| 透明性（Transparency） | 产品负责人（Product Owner） | 产品待办事项列表（Product Backlog） |
| 检查（Inspection） | 敏捷教练（Scrum Master） | 冲刺待办事项列表（Sprint Backlog） |
| 适应（Adaptation） | 项目团队（Scrum Team） | 可交付产品增量（Increment） |
| 五个事件 | 五大价值观 |
|---|---|
| 冲刺 | 承诺（Commitment） - 愿意对目标做出承诺 |
| 冲刺规划会议 | 专注（Focus） - 全身心都用到你承诺的工作上去 |
| 每日站会 | 开放（Openness） - 团队内所有信息对所有人开发 |
| 迭代评审会议 | 尊重（Respect） - 每个人都有他独特的价值与经验 |
| 迭代回顾会议 | 勇气（Courage） - 勇于承诺，履行承诺，敢于说不 |
敏捷实践 - 3个角色
| 产品负责人 | 敏捷教练 | 敏捷团队 |
|---|---|---|
| 确定产品的功能和标准 维护产品待办事项列表 指定软件的交付内容 代表客户利益 拥有最终解释权 平衡有竞争关系的利益相关者 |
团队和产品主管之间的协调者，消除他们之间的障碍 工作职责不是管理团队 激发团队的创造力，给团队授权 提升团队生产率 改进工程工具的实践 确保团队取得进展的信息实时更新与同步 服务团队、教导团队、保护团队 |
5到9个人 多职能部门人员组成 冲刺阶段，团队通过自组织的方式实现冲刺目标 实现目标的帆帆上有选择自主权 责任属于整个开发团队 一起成功，一起失败 一起调整，一起改进 |
敏捷实践 - 用户故事
作为 学员 我想 看直播课 以便于 和老师互动
作为老师 我想 提前排课表 以便于 合理安排事件
作为xx 我想 xx 以便于xxxxx
用户说出自己的问题而不是给出具体解决方案
敏捷实践 - 产品代办列表
待办事项是所有工作的有序列表，他以故事形式呈现给团队。价值大的排在上面。他是产品需求变更的唯一来源
他是一个持续完善的清单，根据产品和开发环境的变化而演进。
产品负责人Product Owner负责待办事项列表的内容，可用性和优先级
几种开发流程的对比
瀑布模型 VS 敏捷流程
| 瀑布模型 | 敏捷流程 |
|---|---|
| 瀑布使用阶段 | 敏捷使用迭代 |
| 瀑布使用不提供高低频率的互动（开发阶段低频率，业务测试阶段高频率） | 有频繁的业务互动 |
| 瀑布模式一个项目经理 | 敏捷流程是scrum master |
| 瀑布不能迭代 | 敏捷能迭代 |
敏捷与精益
敏捷开发：敏捷设计的初衷是再短时间内执行任务，与客户进行频繁互动，并能够对变化做出迅速相应，比较常用于软件开发
精益开发：精益旨在减少浪费，提高运营效率，特别适用于制造过程中常见的重复性任务
门径管理 VS 敏捷
| 特征 | 门径管理 | 敏捷 |
|---|---|---|
| 模型类型 | 宏观技术 | 微观计划，项目管理 |
| 范围 | 创意到结束，端点到端点 | 只有开发与测试阶段 |
| 组织广度 | 跨职能 - 技术、市场、生产 | 技术 |
| 结束点 | 上市成为新产品 | 已开发或测试的软件 |
| 决策模型 | 投资模型：设计高级管理层治理的继续或停止模型 | 主要是战术性的：下一个冲刺需要的动作 |
集成产品开发与其他流程对比
- 集成产品开发提供一种将产品开发中的功能，角色和行为集成起来的框架。
- 定义为系统地、综合的应用不同职能体系的成功和理念，有效、高效地开发新产品，满足客户需求的方式
- 集成产品开发模型的一个重要功能是“学习与持续改进”，模型表明专注于产品开发过程和技术的组织如何发展以知识为基础的学习型组织
- 各流程模型是潜在互补的，而不是相互排斥的，应以持续学习和改进为重点，将每个模型中的元素融合为一个真正适合于产品开发的模型
| 特点 | |
|---|---|
| 门径管理模型 | 宏观规划、决策基础 |
| 敏捷模型 | 微观技术和灵活性 |
| 精益生产 | 减少浪费 |
| 集成产品开发 | 学习型组织，对新产品开发的综合集成 |
开发流程的治理
治理：用于指导项目、程序和项目组合管理中的活动框架、功能和流程。治理是采取高层级和战略性的视角，而不是陷入过程和项目细节
| 治理 | 管理 | |
|---|---|---|
| 职能 | 监督、控制、整合和决策 | 技术、组织、领导和控制 |
| 关注点 | 结果和目标 | 方法和技术 |
| 层面 | 宏观（战略、决策角度） | 中观和微观（战术、执行角度） |
| 负责人 | 董事会 | 管理层 |
| 作用 | 为管理提供框架、功能和过程授予管理者经营权并加以监督 | 再治理提供的框架和监督中形式经营权，实现经营目标 |
总结
所有流程模型均遵从一下共同原则
- 关注战略一致性
- 基于知识进行决策
- 降低产品失败的风险
- 剪掉将利益相关者的输入信息融入设计决策
- 应用跨职能团队
- 是一个结构化框架，要被整个项目所理解和应用
| 门径管理流程 | 集成产品开发 | 精益开发 | 敏捷开发 | |
|---|---|---|---|---|
| 是否对整个新产品开发流程进行管理 | 是 | 是 | 是 | 否 |
| 是否专注于跨职能团队的使用 | 是 | 是 | 是 | 是 |
| 能加快上市速度吗 | 是 | 是 | 是 | 是 |
| 最适用什么类型的产品行业 | 硬件、实物 | 多产品 | 制造 软件 | 软件类 |
| 如何降低产品失败的风险 | 关口 | 决策点 | 消除浪费 | 快速迭代 |
| 是线性还是迭代 | 线性 | 线性 | 线性+迭代 | 迭代+线性 |
