华为带火的IPD流程，对智能硬件制造企业还有多大价值？飞书项目 X 智能硬件制造，聚焦商业目标，以用户视角交付产品

原创于 2025-09-16 17:29:29 发布 · 1.2k 阅读

CC 4.0 BY-SA版权

文章标签：

华为当年把 IPD（集成产品开发） 流程推向大众视野后，很多制造业企业都开始思考：在今天的智能硬件时代，IPD流程还有用吗？答案是肯定的，但关键在于——如何把它真正落地。过去，很多企业把IPD当成“流程口号”，结果执行困难、效率不高，无法支撑复杂的研发与交付场景。

去年，飞书项目针对制造业正式发布了 IPD 产品解决方案，把战略、需求、研发、质量、风险与变更等环节串联起来，帮助企业将“以用户为中心”的理念真正落到流程与工具中。👉 想深入了解方案详情，可以查看：飞书项目IPD产品解决方案。

本文将结合行业背景与标准流程，聚焦智能硬件制造企业在交付管理、质量管理、用户反馈管理等方面的挑战，解读为什么飞书项目能够把 IPD 真正做“实”，并让制造业从中看到业务价值。

行业背景

智能硬件是通过软硬件结合的方式，对传统设备进行改造，进而让其拥有智能化的功能。智能化之后，硬件具备连接的能力，实现互联网服务的加载，形成“云+端”的典型架构，具备了大数据等附加价值。当前比较热门的领域有智能家居，VR，教育，智慧园区等，这类产品往往要结合前沿的AI技术，比如机器学习，自然语言等，业务和结构都非常复杂，人员角色和数量也非常多，所以对项目管理也是个极大的挑战，而飞书项目可以助力新产品的全生命周期管理，做到对齐目标，减少成本，提升效率。

行业标准流程梳理

说到硬件制造流程不得不提起IPD，IPD流程之所以被大家所熟知并被讨论和学习，绝大多数是因为2家知名企业的持续增长，一个是IBM一个是华为，两家企业到现在都成为了各自领域的龙头，下面是一个标准的IPD流程：

DCP点：叫做决策评审点，是集成产品开发过程中的一项关键流程，通过对产品的全生命周期进行决策评审，以达到控制商业风险的目的，保证项目是在做正确的事情。
TR点：叫技术评审点，目的是提供关于技术层面的对与错，越早发现缺陷，越能减少无效开发从而达到减少资源浪费和有效控制研发成本，保证项目在开发过程中正确的做事情。

行业痛点综述

从项目管理的角度，智能硬件产品有以下行业特点：

市场变化快市场竞争大：智能技术不断迭代升级，产品创新不断，市场不确定性加剧；
涉及角色和工种众多软硬件耦合问题极多：除了互联网相关的RD、QA、交互、运营等，还涉及销售、市场、BD、电子、结构、工厂产线各角色等，在产研过程中会有很多的质量问题；
重视用户反馈但是效果不佳：一个好的智能硬件产品的使用周期是比较长的，想要提升品牌效益，就得赢得客户的口碑，随着产品和功能的更新换代，既要守住硬件成本，也要保证软件产品性能，再加上各种无线终端的兼容性问题，用户的使用问题也越来越多。

飞书项目IPD解决方案

场景一：新硬件产品项目的交付管理流程

痛点：如何通过标准化的流程，站在用户视角驱动产品交付

一个新的硬件产品从孵化到上市，不仅仅是一个产品研发的过程，更是一个商业投资的过程，所以如何让产品在合适的阶段做合适的决策，让项目目标对齐商业目标就显得极为关键；与此同时在投入工作量最多的产研场景，如何协同多角色向着共同的目标努力，站在用户的视角驱动产品交付，在流程上又应该怎么标准化才能实现这个愿景？接下来我们通过飞书项目来看看解决方案。

解决方案一：新产品软硬件交付的标准化IPD流程

为了让大家更好的理解如何以用户视角交付产品，我们这里引入一个更能让大家理解的名称“阀点”，来和决策评审点对齐，阀点也叫Gate，在汽车领域也会经常用到，我们用流程图做一个对比交互：

Gate1 == Charter：解决为什么做的事情。主要讨论的内容包括不限于：分析市场/竞手/用户/产品运作需求， N+12的产品布局建议。
Gate2 == CDCP：解决做什么样的事情。主要讨论的内容包括不限于：基本确定市场机会点、目标用户、产品定义，核心卖点、软硬件主要功能，可行性评估。
Gate3 == PDCP：解决怎么做的事情。主要讨论内的容包括不限于：确定ID手板、确定上市成本、确定开发方式、确定质量风险及对策，全部功能的详细排期。
Gate4 == ADCP：解决怎么卖的事情。主要讨论内的容包括不限于：上市计划、开卖时间、销售渠道、首单PO。
LR评审：解决用户体验的事情。主要讨论的内容包括不限于：用户体验报告，基于用户的价位预期，卖点满意度。
- 这个评审点在IPD流程中并没有被强调，但是在IPD的核心价值里有重点强调成就客户，我们将这个理念标准化到流程中。
- 在流程中单独设立LR评审，是因为我们做的产品如果不被用户买单，卖点功能不被用户接受，那么这个产品一定卖不好，所以这里要把好最后一道关，只有通过外部用户测试的产品才能量产。
- 以用户为中心的理念贯穿整个研发过程，最终在量产前完成第一个闭环，第二个闭环我们将在下面的场景三，进行介绍。

这么复杂的流程，落到工具上很难想象如何能直观的表达，接下来看看飞书项目的实现效果，你会发现整个流程非常清晰，哪些节点延期了，哪些节点处于进行中，哪些节点已经完成，可视化效果极佳。

免费试用飞书项目行业专版IPD流程可视化泳道图

解决方案二：需求管理的价值交付

需求管理和项目管理是两个不可分割的话题，我们在强调项目管理的价值交付就不得不去强调需求管理的价值交付，有了标准化的项目流程，接下来我们就要解决站在用户视角驱动的需求管理流程了。

首先我们通过工作项的关联，将需求和项目进行绑定，实现商业目标到项目目标到需求目标的价值拆解，项目中要做哪些需求都可以全部追溯。

需求结构化撰写，描述清楚场景和价值收益，OKR等关键信息让产研团队对需求一目了然，核心需求的收益后续也要通过埋点去监控是否达到预期。

需求可视化，通过甘特图快速排期。直观展示需求整体排期，在甘特图绘制区，通过日期区域的背景颜色，也可以明确区分工作日与节假非常的方便。

通过自动化提醒，较少沟通成本。我们在一个新产品的整个生命周期中，沟通成本往往会很大，尤其是对于一些跨部门的信息同步上，那么通过工具，在一定的规则下，对延期需求/缺陷状态的流转进行提醒，对于问题的评论，直接同步到飞书中，就会极大的减少这些沟通成本，提高信息同步率。

DIY的创建过程：

自动化提醒的消息卡片效果

工具集成，打通端到端链路。需求的提测和上线，研发同学可以将GitLab的Branch、commit、MR和飞书项目的工作项进行关联，并可以通过Merge事件自动流转状态。

解决方案三：风险的管理

项目的研发过程充满着不确定性，会伴随着出现很多的风险和问题，而风险管理是指如何在项目和需求中把风险减至最低的管理过程。飞书项目对风险，通过流程从识别——影响分析——监控执行，来选择最有效的方式，主动地、有目的地、有计划地处理风险，以最小成本争取获得最大安全保证。

解决方案四：变更的管理

项目的生命周期较长，项目组织为适应项目运行过程中与项目相关的各种因素的变化，保证项目目标的实现的同时需要对项目计划进行相应的部分变更或全部变更，并按变更后的要求组织项目实施的过程。

解决方案五：没有度量就没有管理

著名管理大师德鲁克有句名言，“没有度量就没有管理”。

在新产品项目的交付过程中，飞书项目通过自己强大的度量能力，可以对项目的过程进行监控，比如通过缺陷DI值的监控，对目前产品质量的高低做判断，通过在不同阶段中缺陷的收敛趋势判断项目风险。

场景二：质量问题的精细化管理

痛点：质量管理流程不够灵活

智能硬件领域，软硬件强耦合，在一个新的智能硬件上市的过程中，如果发生质量问题，原因可能是主控设备端，也有可能是被控设备端，还有可能是云端。在一个空间里管理质量问题，对于同一个业务团队而言，流程是统一，但是Bug的关闭流程根据测试的不同阶段和发现的Bug端类型，往往就会不同。那么如何快速且高效的流转Bug，如何让不同端的问题统一抽象成一个workflow，且对Bug能做到自动提醒，还要精准度量，就成了目前项目管理工具急需解决但是又不好解决的问题。

下面是一个业界比较精简的缺陷管理流程：

如上图标红的区域，会出现流程搁置，流转混乱的情况，举个实际的例子
- 云QA测试发现了云问题，正常流程如图所示。
- 云QA发现了端问题，正常流程是如图所示。
- 端QA测试发现了端问题，正常流程如图所示。
- 端QA测试发现了的云端问题，尤其是全功能回归阶段，正常的流程是：先由云端验证，再由端上回归，验证通过后由端QA关闭缺陷；
  1. 为什么不是云端直接端到端验证呢？
    - 一是考虑云端通常要求更快的上线，多数情况下只验证接口和基本功能；
    - 二是考虑系统本身比较复杂，云端的改动逻辑很可能对其他的端功能造成或多或少的影响，在回归期间有可能云端已修复的问题会被其他改动影响到，所以由端去验证关闭，更合理。
  2. 为什么不是端直接验证呢？
    - 一是角色分工的问题，通常端和云的RD以及QA都是不同的同学；
    - 二是会影响度量的准确性以及状态的准确性；
    - 三是端上验证比较滞后不够敏捷，且回归功能的成本较高。