产品思维分析IPD集成产品开发

IPD，即 " 集成产品开发 "，这篇文章里，作者就从软件产品开发的角度切入，对 IPD 流程做了解读和分析，一起来看一下。

前些时间在面试一家 AI 企业时通过 " 用户体验五要素 " 和面试官讨论了下我对于产品方法论的理解，随后拉回到之前面试官关于 " 市场调研报告 " 的问题，期望用这种方式表达我对 " 用户体验五要素 " 或 " 市场调研报告 " 等映射出的产品思维的理解，达到回答面试官 " 我虽然没写过市场调研报告，但是我会，并且能够胜任 " 的效果。

所谓大道至简，" 问渠那得清如许，为有源头活水来 "，产品思维源头活水不断，这些一个个复杂耦合的概念自然而然水到渠成。最后面试官问我 IPD 模型，第一次听说这个概念，就答不上来。今天通过在网上查阅的资料谈谈源头活水如何水到 " 渠 " 成。

一、定义

IPD 全程 integrated product development，翻译过来就是集成产品开发，集成产品 + 开发，前者是对象后者是行为，就会引出何为集成产品，简单说就是硬件 + 软件的产品，于是 IPD 就可以简单的拆成硬件开发 + 软件开发。

到这我们知道了 IPD 的简单定义，软件开发和硬件开发又有什么区别，PM 的岗位还是软件产品居多，相信大家对软件开发是比较熟悉的，那么我们就从软件产品开发切入聊聊 IPD。

二、软件开发

软件开发是产研团队将需求分析转化开发最终交付软件程序的一系列活动。

Why：为什么要开发产品？

公司开发产品投入锚定市场能够给公司带来什么价值，或是商业价值或是社会价值（如果公司没办法给自己带来价值，公司也没有动力进行产品开发），这就引申出了公司的愿景、战略目标、计划等（什么价值），以及相应的评价规则（价值多大）。接下来我们寻找价值的来源，也就是开发产品给谁用的问题。

What：开发产品给谁用？

开发产品需要锚定一个市场，这个市场的用户就是我们的产品用户，公司的价值就是来自于这些用户。那么如何锚定一个市场并在汪洋的市场中找到核心产品用户，那么我们需要相应的市场调研的策略和流程，进而知道哪个市场能带给公司期望的价值。市场调研还是一样的思路，市场的现状、市场的发展规划，搞清楚市场的机会点和风险点即可。

到这我们搞清楚 Why 和 What 的问题，也就是上面说的公司开发产品投入锚定市场能够给公司带来什么价值，接下来我们谈 How 的问题。

How：如何开发产品？

开发产品是一种专业性活动，是团队在一定的空间一定的时间内进行的，需要对应的人力、物力、财力等资源支撑，接下来我们分开聊 who、when、where 的问题。

Who：谁开发产品 ?

这就要把公司内直接参与产品开发的所有角色全部拎出来进行分层固化，这个我就不详细分析了，思路都一致，有人负责为什么做、有人负责做什么、有人负责怎么做，怎么做需要各职能支持，下面给出 IPD 中对这一问题的答案。

IRB 就是为产品开发提供物力和财力支撑的，具有最高的决策权；IPMT 就是一个大产业的产品线，BMT 就是小产业的产品线；IPMT 和 BMT 这种中间部门在小公司中一般没有，也就是组织架构更扁平，直接 IRB-PDT。

PDT 开发团队是 IPD 团队的原子单位。

产品经理处在 PDT 开发团队的开发部门中，典型的开发部门组成如下：

When：开发产品的活动时间线

活动时间线就是活动的流程，什么时间点做什么事，并固化成为流程，下面给出 IPD 中对这一问题的答案。

总体框架：可以看出从客户业务经过 MM 市场管理和 RM 需求管理得到我们的产品需求，产品需求经过 IPD 产品开发发布给客户业务。

产品经理涉及到 RM 需求管理，接下来我们看一下 RM 需求管理的全景流程。

1）RM 需求管理流程

需求管理的主线是不难分析得出的，需求管理的开始必然是收集需求结束必然是验证需求，中间需求转化和需求实现，团队协作涉及到需求分发，需求转化就是需求分析。总的来说需求管理经过了收集 - 分析 - 分发 - 实现 - 验证的五个阶段，参与的人员是上述 PDT 开发团队成员，自然而然按照流程分为提出需求的人、承接需求的人、实现需求的人和验证需求的人。

补充说下分支流程：1. 需求分析升级流程，2. 需求变更流程，3. 需求验证异常流程，这里以需求变更流程为例说一下。

需求变更流程：

需求变更就是提出一个新需求并替换掉之前的旧需求，因此分两步，1 新需求的流程按照上述来即可，2 旧需求已经开发成功能交付给客户了，因此需要评估撤下旧功能的风险。

产品需求作为 RM 需求分析的输出肯定有优先级，我们按需求的重要性（对公司对客户）对需求进行分层，先是客户问题再是系统特性最后是系统需求。

产品需求分层：

原始需求: 来自公司内、外部客户的关于产品与解决方案的所有需求，包括销售项目需求和非销售项目需求。

初始需求：原始需求经过 RAT 分析后，站在客户视角，以准确的语言（完整的背景、标准的格式）重新描述的需求，它有个好听的名字 " 用户故事 "，是我们在 PRD 文档中需要重点描述的，也是需求论证的重点依据。

客户问题：客户面对的挑战与机会（客户战略痛点），也就是该需求给客户带来的核心价值。

系统特性：指产品为支撑客户问题所具备的重大能力，是产品的卖点集合。

系统需求：是系统对外呈现的，可测试的全部功能需求和非功能需求。

通过以上我们知道了 RM 需求管理的输入输出和产品需求的分层和优先级，接下来进入到 IPD 开发流程。

2）IPD 开发流程

通过 RM 需求分析我们将原始需求转化为产品需求进入到 IPD 开发阶段，上述在 RM 中我们已经粗略介绍了需求分发、实现、验证等，接下来在 IPD 开发流程中我们详细介绍下。

在产品需求池中的需求离散度一般比较高，IRB 需要从产品需求池中根据相关性找出符合公司战略的需求，定义出战略产品，这个阶段就是概念阶段。一个产品会有多个迭代版本，就要制定计划。接着就是开发验证和发布，最后在锚定市场中经历产品的生命周期。

产品开发可以说是对设计和实现一致性要求最高的环节，由于当下协同场景的条件现状必要的决策和评审会议是必要的。IPD 中对此分为两条线，1DCP 商业决策，2 技术评审。业务和技术两条线是清晰有效的，业务为主导，技术评审可行性。技术评审作为 DCP 评审的输入，DCP 评审通过表明下一阶段资源可以投入。

DCP 是商业决策，投资方 IRB 对产品商业计划的可行性、产品定位及竞争力、成本、盈利目标等进行评估，确定是否继续投资。

CDCP（Concept DCP）：概念决策评审，对产品包有个清晰的定义并达成一致。

PDCP（Plan DCP）：计划决策评审，对产品包开发有清晰的计划，并签署合同约定好偏差范围，按照承诺交付产品包。

ADCP（Availability DCP）：可获得性决策评审，产品包达到足够的质量水平，可以针对某特定机会销售。证实在计划阶段制定的业务计划中的假设，并评估产品发布前用户的准备情况。

EOXDCP（End of x DCP）：生命周期终止决策评审，销售制造服务停止时间评审，IRB 必须要审核产品生命终止的发布是否与新产品战略保持一致以及是否很好地考虑了潜在的客户满意度方面的问题。

TR 是技术评审点，关注产品的技术成熟度和风险，其评审结果作为 DCP 决策的输入，PDT 核心组成员均参与评审，确保每个领域的诉求均被考虑到。

TR1：产品需求和概念评审

TR2：需求分解和规格评审

TR3：总体方案评审

TR4：模块 / 系统评审

TR5：样机评审

TR6：小批量评审

IPD 各阶段的目标和关注点：

where：开发产品的活动地图

综上整个 IPD 开发流程就简单介绍完了，需要特别注意的是真实世界中的活动都受到空间的限制，因此在需求收集、分析需求或产品开发等等环节都会受到空间限制，空间成本也是影响商业决策的重要因素。这就是最后一个 where 的问题，我称之为 "IPD 活动地图 "。

我就不展开分析了，大家以后在分析时记住空间维度这点即可。最终期望的是大家的脑海中应该浮起一段 PDT 开发人员按照上述时间线在 3D 地图中的移动轨迹动画，且评估这个动画应该是必要、忙碌而高效的。

至此软件产品开发算是讲完了，那么前面我们也提到 IPD 还包括硬件产品开发，现在我们还有个问题没解决就是 " 软件开发和硬件开发有什么区别 "，鉴于笔者也没有硬件开发经验，这点我按下不表，等后面有机会再与大家说道说道。

洋洋洒洒写了这么多，不知不觉到了下班点。^.^

这篇文章希望能够给大家带来一些启迪，向底层多思考才能掌握方法论背后的精髓，汲取其中的营养培育我们的产品思维，这样就能做到水道渠成，一切都是那么的自然而然。只要场景和需求的输入足够丰富，我们的产品思维神经网络就会帮我们构建出一个 " 适合 " 的产品方案。

本文由 @立志成为 CEO 的 PM 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议

查看原文