【工作总结】IPD开发管理流程
前言
集成产品开发(Integrated Product Development, 简称IPD)是一套产品开发的模式、理念与方法。当然,世界上不只这一种产品开发模式,还有类似的,但总体来说,其知识体系都大同小异,学会一个以后,灵活运用。
- 产品开发是一项投资决策:需要严谨的阶段性评审。在开发各个节点评估是否要启动、暂停、终止、改方向。
- 基于市场开发:充分了解市场需求、竞争产品的情况下,进行产品定位。
- 跨部门、跨系统协同:利用一切可利用资源,并进行有效、及时地沟通。
- 异步开发模式,也称并行工程:通过严密的计划,把接口定义完善,把在时间上后续的开发任务提前,并行开发,缩短开发周期。
- 重用性:不管是硬件还是软件,一些可以重用的模块,进行公司技术积累,当然也可以包括工作总结、FAQ等。
- 结构化的流程:开发是一件不确定性的工作,需要在结构化和非结构化之间找到平衡,灵活运用管理模式。
投资决策的参考标准
通过上述的这些要素,对产品立项的指导还是具有一定的意义。毕竟,开发一款产品最终是为了创造利润,当然新产品也要符合公司的战略方向,例如小米公司这几年会投资一些电源插板、空气净化器等零碎的家具产品,那是小米在部署家庭物联网生态圈的战略中一分子。公司制定的产品战略方向,也还是根据市场决定的。
之前听过单副院长的讲座,开发一款产品,要研究竞争对手。竞争对手的产品,成熟、稳定、价格极低,软件、硬件、利润已经没有多少竞争空间,就不要再做(我以为如果是公司战略,还是需要开发的)。
市场 | 市场规模 |
总市场:百万、千万? 单个用户:十万?百万? |
成熟度 |
市场刚起步发展 (价格、功能很有利润余地) 发展已经成熟(价格、功能由部分利润余地) 发展末期,有垄断 (价格、功能没有利润余地) |
|
带给客户的价值 |
分析客户需求(价格、功能、外观、性价比、易用性的需求程度) 收回成本时间 年化收益 |
|
实施 | 开发资源 |
技术人员齐备 |
市场资源 | 市场推广人员齐备 | |
技术风险 |
can or not can(是否技术壁垒、过度依赖) can & better |
|
服务、支持 |
售前、售后、技术支持 |
|
财务 | 成本 | 人力成本、物料成本 |
利润 | 毛利润、净利润 | |
风险 | 资金收回 |
忘记上述的知识
“ 乔纳森刚加入谷歌不久,就目睹了两位创始人对传统商业模式的厌恶。作为一名资深的产品管理高管,他对产品研发中所设的“过关制”("gate- based" approach)并不陌生。多数企业都在用这种方式:设立明晰的阶段和步骤,并安排公司自下而上的各级管理者进行层层评估。这种方法的初衷是节约资源, 将广泛散布的信息汇集到一小撮决策者那里。乔纳森本以为自己的使命就是将这种制度带入谷歌,他非常自信传播这一制度的使者非他莫属。
几个月之后,乔纳森给拉里提交了一份产品计划,将“过关制”研发方式展示得淋漓尽致。计划中包含了步骤、审核、优先次序,还有两年内推 出的产品种类及上市日期。这份计划是教科书思维模式的杰作,乔纳森应该赢得一阵热烈的掌声和校长在背上鼓励的一拍。可惜,现实并非如此,因为拉里讨厌这种 方式:“你见过哪个团队的表现能超越既定目标?”呃,没有。“你的团队研发过比计划中更出色的产品吗?”也没有。“如果是这样,计划还有什么意义?计划只 是在拖我们的后腿罢了。一定有比计划更有效的方式,去和工程师谈谈吧。”
听了拉里的话,乔纳森豁然意识到,原来他所说的“工程师”并非通常意义上所指的工程师。没错,拉里所说的工程师都是杰出的程序员和系统设计师,但除了技术方面的资深经验之外,很多人还具备敏锐的商业头脑,在创意上也是才思泉涌。
从大学校园出来的谢尔盖和拉里给了工程师非同寻常的自由和权力。传统的计划管理方式对这些工程师并不适用,这些条条框框虽然能够提供一定的指导,但同时也设下了羁绊。“为什么要束缚大家的手脚呢?”拉里告诉乔纳森,“这样做太蠢了。”-----from《How Google Works》
总结
听说一句话:大公司里,员工只要按照定好的流程做事情,就能把事情做的很好。所以一直比较推崇在公司里建立各种工作流程和制度。但是,开发产品是一件创造性的事情,对于IPD不可迷信,不可不信,摘取有用的,指导自己的工作。
尽信书则不如无书,人是最灵活、也最有创造力的。创造,不要让规则局限了思维和脚步。