研发项目管理
分组
为小组命名
选定项目经理
选定项目名称（后面的练习将依据此项目进行演练）
派代表发表
目录
一. 研发项目管理概述
二. 跨部门产品开发流程
三. 产品开发项目计划制定
四. 产品开发项目计划控制
五. 产品开发项目风险管理
六. 产品开发项目质量管理
七. 研发团队运作与激励
项目管理发展
经验式项目管理（30年代前）
1917年Henry L. Gantt发明甘特图
20世纪30年代：里程碑（Milestone）的提出与广泛应用
传统项目管理（40年代-80年代）
1957年杜邦公司应用CPM（Critical Path Method），使维修停工时间由125小时锐减为78小时。
1958年美国海军在北极星导弹项目应用PERT（Program Evaluation & Review Techniques），缩短了2年工期（计划时间6年）。
现代项目管理（80年代以后）
项目管理形成系统学科。PMI与IPMA协会提出项目管理标准——项目管理知识体系。
项目概念
项目（Project）
创造唯一的产品或服务的时限性工作。
（美国项目管理协会-PMI）：项目是为了在规定的时间、费用和性能参数下满足特定的目标而由一个人或者一个组织所进行的具有规定的开始和结束日期、相互协调的独特的活动集合。
例如：
新产品/新服务的开发项目
房地产开发项目
大型体育比赛项目或文娱演出项目
咨询项目、企业管理变革项目
项目的特征
目的性
具有特定而明确的最终目标
时限性
具有明确的开端和明确的结束，历时有限
唯一性
每个项目只发生一次
合作性
由一系列具有内在联系的活动组成，靠项目团队的努力来实现
项目与运作
“一切皆项目”？
何为运作(Operation)？
日常工作
显著区别
运作具有连续性和重复性的
列车按时刻运行表运行
项目则是有时限性和唯一性的
某次军用物资的运输
项目管理
项目管理就是把知识、技能、工具和技术应用到项目活动中去，以满足或超过项目干系人的要求和期望。
项目干系人
项目经理、项目团队
客户
项目执行组织
发起人
其它
PMI定义的项目管理九大知识领域
范围管理
时间管理
成本管理
质量管理
人力资源管理
沟通管理
风险管理
采购管理
项目综合管理
满足或超过项目干系人的需求和期望
工具、技术
工具、技术
项目干系人的需求和期望
约束三角形
质量
成本
时间
范围
项目管理五大过程
启动过程（Initiating）：授权批准一个项目或阶段。
计划过程（Planning）：界定和改进项目目标，从各种备选的行动方案中选择最好的方案，制定项目计划。
实施过程（Executing）：协调人员或其他资源以执行计划。
控制过程（Controlling）：通过定期监控和测量进展，确定与计划存在的偏差，以便在必要的时候采取纠正措施，从而确保项目目标的实现。
收尾过程（Closing）：项目或阶段的正式接收并达到有序的结果。
启动
计划
控制
实施
收尾
项目管理过程是重叠的
收尾
研发项目管理面临的挑战和问题
外部挑战
产品生命周期大幅缩短
客户需求多变，对产品质量与性能的要求越来越高
技术发展迅猛
价格竞争导致利润持续下滑
关键人才短缺
内部问题
项目本身的需求、范围不确定
技术导向的项目经理
团队缺少项目管理经验，缺少研发流程、规范支撑
跨部门沟通协调困难
组织及人员目标的不同
…
研讨要求：
列出K公司产品开发项目管理方面存在哪些问题（8-12项）
时间安排：研讨20分钟，汇报交流15分钟
研讨：产品开发项目管理存在的典型问题
产品开发项目管理方面通常存在的问题
项目目标不明确
需求分析不充分
缺乏充分的技术储备
产品设计只关注功能实现，不关注可生产性、可测试性、可维护性
项目计划不准确，过于乐观，工作量估计不足
项目控制不力，阶段控制不严格
跨部门协作不畅
资源配备没有保障
技术评审流于形式
产品测试不充分
缺乏物料认证
生产导入不受重视
设计变更随意性大
……
成功的产品开发需要系统的研发管理体系
缺乏产品与技术规划的危害
同时投入开发的产品与技术开发项目太多，超出资源许可的范围
项目普遍延期严重，项目质量不理想，重点项目资源得不到保证
没有从市场出发建立项目选择标准，选择项目更多的靠领导“拍脑袋”，随意性大
开发出的产品与技术缺乏市场潜力，缺乏高效益项目，研发投入产出比差，投资浪费巨大
没有设立优先级评估标准，产品与技术开发项目缺乏合理的先后顺序
市场急需的产品与技术不能及时开发成功，过早投入开发一些市场不急需的项目
没有建立市场导向的产品与技术规划机制，企业产品与技术开发将缺乏方向，可能造成巨大失误
缺乏产品规划和决策的代价
产品与技术规划的主要内容
理解市场与市场细分
组合管理与产品优先级排序
产品开发路标规划
技术规划与产品规划的衔接
技术开发路标规划
良好的规划需要大量的市场信息支持
市场活动
销售活动
用服活动
公开信息
商业伙伴
专业数据
一手信息
二手信息
市场信息库
活动
信息整理分析
其他市场信息
报告交流
竞争者信息.
网上公布的信息
新闻剪报
专业期刊
用户访谈
客户反馈
产品试用
客户投诉
安装施工
现场服务
专题研讨会
高层拜访
展览
用户大会
行业调研报告
市场调研咨询
细分市场是产品规划的基础
细分市场与产品线、产品族、产品型号等关系如下：
细分市场A
细分市场B
细分市场C
产品族甲
产品族乙
产品族丙
产品包1
产品包2
产品包3
产品包4
产品线
（大的细分）市场
产品与技术项目优先级评估
评估方法：
要素评估法
财务收益评估法
产品和技术项目的优先等级评估
战略地位分析（SPAN）
低
高
避免/退出
增长/投资
收获/重新细
分
市场吸引力
竞争地位
获得技能
低
高
财务分析（FAN）
低
高
内部投资回报率
（%）
累计收入
（$）
低
高
0%
k%
必须达到的最低投资回报率
各个方面的评估要素
市场吸引力
竞争地位
财务收益
属性
评估要素
评估子要素
客户/供应商压力
进入的威胁
直接/间接竞争
竞争激烈程度
市场成长
市场空间
产品优势
品牌优势
市场份额
成本结构
税前收益率
开发费用
战略价值
累计税前收益
给每个要素确立标准，然后使用“高－中－低”对每个产品或技术项目的每个要素进行评分，“高－中－低”数值化为“5-3-1”表示并统计计算。
市场吸引力各要素含义及示例如下：
高：大于80%
中：20~80%
低：小于20%
高、中、低
机会的相对增长率
市场增长率
根据对产品定位的了解，将给出一个高、中、低的定性评估
高、中、低
公司参与的策略价值
策略价值
高、中、低
子要素3：进入威胁
三个子要素一起考虑。根据对市场情况的了解，将给出一个高、中、低的定性评估。
高、中、低
子要素1：来自客户/供应商的压力
竞争的剧烈程度
高、中、低
子要素2：直接/间接竞争
高：大于5千万元人民币
中：1-5千万元人民币
低：小于1千万元人民币
高、中、低
市场机会的相对规模
市场规模
示例
分值
要素描述
市场吸引力要素名称
要素评估法
根据对与竞争对手品牌比较的了解，将给出一个高、中、低的定性评估
高、中、低
与竞争对手相比的相对品牌形象
品牌优势
根据对与竞争对手成本结构比较的了解，将给出一个高、中、低的定性评估
高、中、低
公司产品的成本结构
成本结构
根据对与竞争对手产品比较的了解，将给出一个高、中、低的定性评估
高、中、低
与竞争对手的产品相比的相对产品优势
产品优势
高：大于50%
中：20~50%
低：小于20%
高、中、低
公司的市场份额
市场份额
提议的定义（示例）
分值
要素描述
竞争地位
要素名称
竞争地位各要素含义及示例如下
要素评分汇总
3
3
5
5
3
5
15％
该产品对公司的战略价值
战略价值
市场吸引力得分
3
5
1
5
3
1
3
5
5
3
5
5
3
3
5
3
5
5
15％
10％
10％
子要素1:
直接/间接竟争
子要素2:
进入威胁
子要素3:
客户/供应商压力
获利潜力
5
3
3
5
5
3
20％
细分市场机会的相对增长率
市场增长率
3
1
5
5
3
5
30％
产品的市场空间
市场空间
评分
评分
评分
评分
评分
评分
要素权重
要素描述及子要素
市场吸引力要素
特大型企业集团用产品
个人用产品
军队用高可靠产品
军队用产品
政府用产品
电信运营商用产品
产品名称
以上只是对市场吸引力各要素/子要素的评估，对竞争地位各要素的评估也类似，各自评估后按加权汇总，或者按总和100%分配给各要素/子要素。
财务评估法
净现值（或净利润）
投资回报率
投资回报期
利润评估法
根据数据获取的难易程度选择不同的预测方式：直接预测各项目未来各年的收入、成本、费用，计算税前利润额，并预测研发投入，以计算收益率；或预测各项目下一年的收入、各年增长率、各项目毛利率，然后计算税前利润额，预测研发投入，计算收益率。下表为财务预测数据汇总表：
税前利润
研发投入
销售与管理费用
成本
收入
总计
…
…
2011
2010
2009
产品/项目1：名称
示例：
中长期产品开发路标规划
年度产品开发计划
产品线、产品、技术平台与技术的关系
最终产品
技术要素1
技术要素2
技术要素3
技术要素4
技术要素5
技术要素6
技术要素7
技术要素n
产品平台1
产品平台2
产品线1
2
1
3
产品线2
2
1
3
产品线3
2
1
3
产品线4
2
1
3
产品线5
2
1
3
产品线m
2
1
3
专用技术*
公共技术
专用技术
*技术要素也可按照其作用划分为：决定性要素、支持性要素。
示例：某电声产品与技术平台关系图
防水技术
抗高频干扰
声学结构
相位一致性控制技术
指向性批量测量技术
IC的应用
零件产品共用技术要素
ECM产品专用
IC的应用
si-mic产品专用
超薄结构设计
RCV、SPK产品专用
USB驱动程序开发
MIC Array产品专用
MEMS工艺
半导体后道封装工艺
MEMS芯片的声学结构
SMT工艺
磁路组件加工工艺
点胶工艺
封装设计
固件程序的编写
极化工艺技术
耐高温性
寿命实验
算法的开发
硬件电路的开发
指向结构设计技术
振膜组件加工工艺
振膜成型技术/失真的降低/灵敏度的提高
ECM产品平台
si-mic产品平台
RCV、SPK产品平台
MIC Array产品平台
ECM系列产品
si-mic系列产品
RCV、SPK系列产品
MIC Array系列产品
UWB数据传输模组技术
UWB天线技术
蓝牙路由器技术
无线车载技术
蓝牙立体声和主动降噪技术
蓝牙耳机技术
蓝牙适配技术
无线通信
多媒体音视频组合技术
立体声声讯技术
语音识别技术
主动降噪技术
多媒体
音频IC芯片技术
图像传感技术(CMOS)
电声结构技术
声学阵列技术（MIC ARRAY）
硅微传感技术（Silicon MIC）
电子零部件、光电技术
4
3
2
1
4
3
2
1
4
3
2
1
4
3
2
1
4
3
2
1
2010年
2009年
2008年
2007年
2006年
关键技术
技术类别
示例：某电声产品技术开发路标
产品与技术规划相关的组织结构设置
市场部
市场代表
产品经理
PMT（产品组合管理团队）
研发部
产品与技术规划的几个重要跨部门团队
C： 公司/集团
PL: 产品线/业务单位BU
IPMT:集成组合管理团队
PL-IPMT
ITMT
C-IPMT
C-PMT
PL-TMG
PL-PMT
TDT/TRT/PRT
PDT
C-TDT/TRT
C-PRT
ITMI:集成技术管理团队
PMT: 组合管理团队
PDT: 产品开发团队
TMG: 技术管理组
TDT: 技术开发团队
PRT/TRT: 产品/技术预研团队
产品经理
产品经理
供应部
生产部
财务部
生产部长
服务部长
服务部
制造总监
总裁
技术管理中心
软件部
PDT经理
市场总监
硬件部
…
结构部
总 工
测试部
系统部
…
产品线总监
品质部
质量总监
供应部长
各大区
销售总监
人力资源部
HR总监
财务总监
总裁办
研究部
市场研究部
IPMT
PMT
PMT
PDT
PDT
PDT经理
PMT等在公司组织结构中的位置（举例）
举例：H公司的主要规划角色
案例分析
举例：3M公司的业务计划小组
3M公司的业务计划小组有一名产品经理加上几名营销和非营销专业人员组成（如右图）。
3M公司按照这种形式将其商用磁带部门分成9个业务计划小组。在这个小组里，并不是由产品经理一个人对产品的计划负全责，而是由他或她与来自公司关键部门的代表共同负责。
产品经理
市
场
调
研
人
员
信
息
沟
通
专
家
销
售
经
理
分
销
专
家
财
务
专
家
技
术
专
家
业务计划小组
案例分析
目录
一. 研发项目管理概述
二. 跨部门产品开发流程
三. 产品开发项目计划制定
四. 产品开发项目计划控制
五. 产品开发项目风险管理
六. 产品开发项目质量管理
七. 研发团队运作与激励
产品开发流程与项目管理相辅相成的关系
流程定义活动和相应的角色，建立规范、模板；项目管理保证流程落实。即：
研发流程保证“正确地做事情”
项目管理保证按流程做事，顺利推进，“把事情做正确”
流程为项目管理提供了基础，如：活动定义是项目计划的基础
有效的流程可以降低对人员的素质要求
集成的跨部门产品开发流程
角色 / 阶段
IPMT
PQS
POP
TRG
CM
PMT团队
市场代表
制造代表
工艺工程师
采购代表
测试代表
系统工程师/ 硬件、软件、结构、机械、工业设计工程师
LPDT/市场 代表
产品概念开发子流程
业务计划开发子流程
系统设计子流程
软件开发子流程
产品测试子流程
研发采购子流程
生产导入子流程
新产品上市子流程
产品退市子流程
概念
计划
开发
生命周期
验证
发布
项目管理
技术评审
决策评审
C B B 管理
变更管理
配置管理
产品数据管理
过程质量保障
文档管理
业务类子流程
支撑类子流程
工业设计子流程
硬件开发子流程
结构开发子流程
机械开发等专业子流程
物料选型和认证子流程
工艺开发子流程
需求分析与跟踪子流程
可靠性工程子流程
产品开发主流程的阶段划分
库柏的门径管理流程模型的阶段划分：
投放市场
验证与矫正
开发
开发项目立项
确定范围
创意与
构思筛选
评估市场表现
美国PRTM公司PACE模型的阶段划分
通常3-6个阶段，典型的阶段划分如下：
产品发布
评估
开发
策划/规范
概念评估
集成产品开发（IPD）流程的阶段划分
生命周期
发布
验证
开发
计划
概念
市场管理与产品规划
IPD流程的输入：
《未来3~5年产品开发路标规划》
《年度产品开发计划》
《产品开发业务计划书（初稿）》
《产品开发任务书》
《市场需求说明书》
IPD流程
需求管理
创意开发
任务书开发
决策评审
决策评审
决策评审
决策评审
决策评审
决策评审
产品开发主流程的阶段划分
概括为三大段进行分析：
后期阶段
中期阶段
前期阶段
产品开发流程阶段划分因产品创新程度和行业、产品等不同而有很大不同
产品开发前期阶段的目的
确定项目目标
规划项目范围
启动项目
产品开发项目目标的确定
通用项目目标：
进度、质量、成本
传统企业产品开发项目目标设定：
从开发任务完成、按时量产出发设定目标
进度、质量、成本
领先企业产品开发项目目标设定：
从投资成功出发设定目标
进度、质量、成本、市场、收入、利润
演练：制定项目目标
各小组为选定的项目制定项目目标
或为M公司BPAPP产品开发项目制定项目目标
明确性（Specific）
最终目标是否明确了应该做到哪一步以及何时完成
可度量性（Measurable）
你能在多大程度上测量最终目标的完成情况
可完成性（Achievable）
在规定的时间内，最终目标是否合理，能够实现？
相关性（Relevant）
最终目标是否很重要、很有价值、是否值得进行下去？
可跟踪性（Time-Bound）
你能够对整个项目的时间进程进行跟踪检查吗？
制定有效的项目目标（SMART原则）
背景介绍
项目需求
交付件
里程碑时间
确定资源（主要是人力资源）
……
任务书是领导与项目团队的相互承诺
项目目标的主要载体——任务书
项目任务书举例
高创新程度的产品开发面临高失败率的风险
七个概念只有一个成功
50%的新产品上市后失败
66%的CEO对他们的公司在新产品开发上的表现感到失望
资料来源：PDMA and Booz-Allen & Hamilton Surveys，98年
新产品开发失败的原因分析
资料来源：《新产品开发流程管理（第三版）》（加）罗伯特·G·库柏，机械工业出版社
高创新程度的产品开发对流程的要求
更充分的产品创意/构思开发
更多的市场调研分析和市场测试
更严格的风险控制
更充分的技术路线和方案分析
更多的跨部门工作：产能/产线规划、装备开发
更充分的新产品上市工作
......
IPD任务书开发流程的内容
市场机会和目标市场分析
用户需求分析
销售预测
资源平衡
风险评估
开发业务盈利计划
任务书（决策）评审
任务书开发流程的输出：
《产品开发业务计划书（初稿） 》
《产品开发任务书》
示例：典型的IPD概念阶段流程框架
不同创新程度的产品开发主流程有所不同
库柏对新产品的分类：
全新产品
新产品线
新产品品种
改进型新产品
重新定位新产品
降成本新产品
PDMA对新产品的分类：
突破型新产品
平台型新产品
改进型新产品
产品开发前期阶段流程划分的不同做法
任务书开发
概念
计划
……
任务书与概念开发
计划
……
决策评审
决策评审
决策评审
决策评审
模式二：
模式三：
决策评审
立项（或产品策划）
方案设计
……
立项评审
模式一：
产品开发项目启动
明确项目目标和范围
组建项目团队
明确项目团队成员职责
明确沟通方式
建立项目环境
研讨：
如何启动产品开发项目？
产品需求对项目范围影响较大
·书面标准
·事实标准
原始客户需求
市场需求
质量属性
DFX
标准约束
产品需求
设计需求
总体设计
软件需求规格
硬件需求规格
概念开发
需求分解、分配
·功能需求
·非功能需求
概念阶段
市场管理
计划阶段
获取原始客户需求的有效方式
成为使用者：成为自己或竞争对手产品的客户
与客户一起：观察客户如何使用产品
倾听客户的声音
准确的理解和描述客户需求
清楚
使用客户明白的语言
避免二义
完整
一致
可测试
可修改
可跟踪
市场需求优先等级划分
卡诺（Kano）模型：
基本需求（Basic）
满意需求（ Satisfier）
兴奋需求（Attractor） /更有吸引力的
库柏提出的划分方式：
战略性需求/决定性需求
战术性需求/重要需求
细节需求
其他优先等级划分方式：1-5级，1-10级，......
产品需求转化为设计需求
确定每项产品需求具体的操作方式及可接受的参数范围：
功能
性能
环境
强健性
可靠性
可维护性
可用性
安全性
重量
电源
尺寸大小
可运输性/可移动性
灵活性
……
示例：某厨具产品需求
国家标准：吸油烟机GB -1998；GB -1999；GB/T 17713-1999
内控标准：Q/FT 006-2004吸油烟机
相关标准
产品上要有裸露的接地测试点
模具要有安全防范装置
可生产性/可测试性需求
外型尺寸与橱柜及吊顶相配，对安装的墙壁无特殊要求；灯、电控部分的维修方便，集烟罩拆卸方便，方便拆卸叶轮（清洗）
外表面易清洗（一擦即可）
可维护性需求
无煤气泄漏、无漏电等安全隐患，安装牢固，炒菜时不碰头，外表面不割手
产品应能通过CCC/CQC/卫生许可证等认证要求
安全性 需求
照明、吸力大小调节、自清洗、煤气泄漏报警等
吸力、功率、风量、噪音、风压等性能指标
功能/性能需求
线条流畅、时尚与高贵结合
形状、颜色等
外观需求
产品需求的评估和选择
多方面评估可选的产品需求项
需求项二
结论
需求项一
……
对产品成本的影响
对上市速度的影响
技术风险
客户关注程度
产品需求可选项
通过选择、评估形成确定的产品需求
原始客户需求 → “我希望（手机上的）照片能看得更清楚些”
市场需求 → 客户要求手机屏幕要更大一些，分辨率要更高一些，至少不低于“26万色，240×320像素，英寸”，最好能到“1600万色，240×400像素，英寸”
产品需求 → “1600万色，240×320像素，英寸”
产品设计需求：
“1600万色TFT彩色屏幕，240×320像素，英寸”
可靠性：耐轻微磨损和划伤
环境：耐潮湿天气、汗水腐蚀
产品开发中期阶段的目的
快速高质量的开发出符合需求的样机/样品
为导入生产和产品上市提前做必要的准备
示例：不同企业的产品开发中期阶段划分
计划
开发
……
……
……
示例一：
示例二：
示例三：
方案设计
详细设计
样机试制
详细设计
设计验证
工程验证
……
……
……
方案设计
示例：典型的IPD计划阶段流程框架
示例：典型的IPD开发阶段流程框架
产品开发过程中的物料采购
制定物料需求计划
物料选型
新供应商开发
新物料认证
物料采购
原型机物料计划、工程样机物料计划、小批量物料计划
关键物料选型、常规物料选型
与供应链管理相衔接
技术认证、商务认证
原型机物料采购、工程样机物料采购、小批量物料采购
各类物料计划、采购与设计活动的衔接
研发工程师
技术路线选择
系统设计
原型机物料风险采购申请
项目经理
批准风险采购
决策层
关键物料清单
关键物料复核
采购代表
制定初步供应商和关键物料选择计划
更新供应商和关键物料选择计划
概要设计
详细设计
下达原型机物料采购计划
供应商谈判
订购原型机物料
下发预测BOM
原型机测试
工程样机测试
下达初始产品物料采购计划
订购初始产品物料
锁定BOM
确定供应商
下达生产物料采购计划
长货期生产物料采购
示例：不同企业的产品开发后期阶段划分
验证
……
……
……
示例一：
示例二：
示例三：
发布
小批量试制
受控量产
稳定量产
工程验证
小批试产
量产
生命周期
示例：典型的IPD验证阶段流程框架
示例：典型的IPD发布阶段流程框架
目标
在产品稳定生产到产品生命终结期间内对产品进行管理。
关注
管理产品直至产品生命终止，注意收集内部和外部信号，以
确定产品过渡/替换，制定产品过渡策略，为客户提供产品工程支持以满足客户需求；
证实发布阶段的假设。
交付
终止/替换产品
生命周期
IPD生命周期阶段流程概述
新产品导入生产贯穿整个产品开发过程中
启动量产
持续工艺改进
… …
发放技术工艺文件
制定小批量试产计划
工艺验证
小批量生产
生产设备和生产线准备和确认
… …
编制制造BOM
工艺装配图纸设计
制定工艺文件及作业指导书
工装夹具制作
… …
制定工艺总体方案
制定装备总体方案
制定制造计划
… …
工艺需求分析
制定可制造性需求
制定制造策略
… …
发布与生命周期
验证
开发
计划
概念
项目结束的标志是什么？
典型做法一：样机通过评审后结项
典型做法二：首批验证 — 更改批验证 — 稳定批验证后
典型做法三：样机试制 — 受控量产 — 稳定量产后
典型做法四：正式量产，五批“零不良”后
研发项目收尾
部署产品后续维护工作
整理项目文档并归档
进行项目总结
关闭项目环境
解散项目团队，释放项目资源
产品开发流程裁剪
不同的业务模式，如自主开发与定制开发
不同的产品类型：
全新产品开发：完全不同的产品线，如抽油烟机厂家开发热水器产品。
新一代产品开发：在现有产品线基础上采用全新技术、全新系统架构的产品开发
升级产品开发：在现有产品基础上局部采用新技术的产品开发
现有产品改进：在现有产品基础上改进现有产品不足或局部功能扩展的产品开发
降成本产品开发
……
公司标准过程不可能适用于所有的产品开发
通过流程裁剪适应企业多种产品开发类型和业务模式
产品开发流程规划和裁剪的主要步骤
新产品开发流程
P0
产品生命周期
P1、P2、P3
项目裁剪细则
组织级裁剪：
业务模式
产品类型
开发类型
项目级裁剪：
技术复杂度
项目周期
项目规模
人员技能
项目风险
项目定义过程
项目计划
演练：
请各组按下表格式制定产品开发主流程：
划分阶段，并确定各阶段主要内容：
各阶段
主要内容
阶段名称
目录
一. 研发项目管理概述
二. 跨部门产品开发流程
三. 产品开发项目计划制定
四. 产品开发项目计划控制
五. 产品开发项目风险管理
六. 产品开发项目质量管理
七. 研发团队运作与激励
全流程的、覆盖所有阶段的项目计划
包括所有跨职能部门（市场、开发、测试、制造、技术支援、财务和采购）的活动，确保各职能部门间的配合
进度、资源、成本、风险计划和控制过程有机的集成在一起
跨部门产品开发项目计划
Activity Sequence
活动排序
Scope Planning
范围计划
Activity Definition
活动定义
Activity Duration
Estimate
活动工期估算
Schedule
Development
进度计划制定
Scope Definition
范围定义
Resource Planning
资源计划
Cost Estimate
成本估算
Project Plan
Development and Control
项目计划制定和控制
Risk Management Planning
风险管理计划
风险管理
成本管理
时间管理
范围管理
综合管理
Quality Management Planning
质量管理计划
质量管理
Cost
Budgeting
成本预算
项目计划核心过程
项目计划书的主要内容：
质量目标及过程质量控制计划
客户试用计划
测试与生产设备计划
研发物料采购计划
人力资源计划
文档归档计划
知识产权计划
安规认证计划
……
产品开发项目计划的主要载体——项目计划书
示例：项目计划书
Activity Sequence
活动排序
Activity Definition
活动定义
Activity Duration
Estimate
活动工期估算
Schedule
Development
进度计划制定
Project Plan
Development and Control
项目计划制定和控制
项目进度管理分为五个步骤
WBS的分解方法
依据产品开发流程进行分解
按产品开发流程分解到第一层
依照产品分解结构进行分解
各项活动分解到步骤
利用WBS模板
头脑风暴法，列出活动清单
WBS： Work Breakdown Structure（工作分解结构）
WBS示例
销售信息系统
Beth
问题界定
Beth
系统分析
Jim
系统设计
Tyler
系统开发
Hannah
测试
Maggie
实施
Beth
收集
数据
Beth
可行性
研究
Jack
准备
报告
Rose
会晤
用户
Jim
研究现
有系统
Steve
明确用
户需求
Jeff
准备
报告
Jim
数据输
入输出
Tyler
处理数
据建库
Joe
评估
Cathy
准备
报告
Sharon
菜单
Tyler
数据输
入屏幕
Tyler
定期
报告
Steve
特殊
问题
Jeff
硬件
Joe
软件
Hannah
网络
Gerri
准备
报告
Jack
包装
软件
Hannah
定制
软件
Maggoe
硬件
Gene
软件
Maggie
网络
Greg
装备
报告
rose
培训
Jim
系统
转换
Beth
装备
报告
Jack
O级
1级
2级
3级
1
2
3
4
5
6
WBS的分解标准
完整性。活动的总和完全定义了项目所有要完成的工作任务
最底层工作包的历时估计
不超过80h（PMI）
不超过20h（IPD）
最底层工作包可分配给个人
分解后的活动结构清晰
示例：WBS分解细化
单板硬件调试与单元测试：
单元电路功能调试
信号质量测试
时序测试
单板基本功能调试
失效分析与验证
单元电路性能调试
需求跟踪
单板硬件调试与单元测试报告正规检视
问题跟踪和解决
结构件设计：
2D图设计
会同软件及硬件工程师选择并确定主要的元器件
会同硬件工程师确定主要器件的放置位置
输出供工业设计所用的设计输入文件
拟制初版的BOM表
参与工业设计各个阶段的评审
归档所有相关文件
活动的排序1
完成—开始
Finish-to-Start (FS)
开始—开始
Start-to-Start (SS)
完成—完成
Finish-to-Finish (FF)
开始—完成
Start-to-Finish (SF)
某活动结束前另一活动必须开始。
前
后
前
后
前
后
后
前
活动之间的四种依赖关系：
活动
紧前事件(前置任务）
1
收集数据
－
2
可行性研究
－
3
准备问题界定报告
1，2
4
会晤用户
3
5
研究现有系统
3
6
明确用户需求
4
7
准备系统分析报告
5，6
8
数据输入输出
7
…
…
19
准备测试报告
16，17，18
20
培训
19
21
系统转换
19
22
装备实施报告
20，21
制作活动和紧前事件序列表：
活动的排序2
1、估计的层次
（产品）系统级估计； （软件/硬件）子系统级估计；
（模块）项目级估计； 活动级估计；
2、估计的对象
可分为三类：规模、工作量、工期(进度)
3、规模、工作量、工期(进度)的关系
工作量 ＝ 规模/生产率
工期(进度)＝ 工作量/资源(人数)
工期估计
类比/比较
专家估计法
三点估计法
推测
估计方法
步骤
动作
1
协调人向各专家提供时间估计表格
2
协调人召集小组会，各专家讨论估计时间的相关因素
3
各专家单独填写表格(匿名)
4
协调人召集会议在互相不通报结果的情况下一同开会详细讨论评审要素，对整个评审的要素进行优化，达成统一的评估因素
5
各专家再次单独填写表格(匿名)
6
重复3～5，直至有一个趋于一致的结果
Delphi专家估计法
采取对每项分工作估计三种时间的办法，然后加权平均计算出这项分任务的计划时间。
1、最可能时间T可能
根据以往的直接经验和间接经验，这项工作最可能用多少时间完成，也就是我们一拍脑袋所确定的时间
2、最乐观时间T乐观
当一切条件都顺利时该项工作所需时间
3、最不利时间T不利
在完成过程中不利条件都在起作用时该项工作需要的时间
计划时间T计划=（T乐观+4T可能+T不利）/6
三点估计法
类比/比较是工期估计的首要方法
专家估计法是第2通用方法
留有一定的余量（10%-25%）
持续使用一种方法，逐步估计准确
估计方法应用经验
PERT图示例
需求分析
10
07/01
07/10
总体设计
21
07/11
07/31
A概要设计
7
08/01
08/07
08/14
08/08
7
A详细设计
08/08
08/01
8
B概要设计
08/11
08/01
11
C概要设计
08/18
08/09
10
B详细设计
08/20
08/12
9
C详细设计
09/20
09/11
10
测试计划
10/31
09/21
41
后续活动
08/26
08/19
8
B编码
08/31
08/21
11
C编码
08/20
08/15
6
A编码
08/27
08/21
7
A单元测试
09/03
08/27
8
B单元测试
09/10
09/01
10
C单元测试
总的开发时间为27天，与关键路径相比，时差14天
总的开发时间为34天，与关键路径相比，时差7天
41天
产品开发项目多级计划形式
里程碑计划
1/2级项目计划
1/2/3/4级项目计划
周工作计划
演练：指定项目进度计划
可选的活动组：
小批量试制
……
各小组任选一组活动进行WBS分解、细化、估计工时：
项目计划的制定过程
由上往下制订与由下往上修改相结合
在制订每一层计划时均要充分考虑上下层计划的约束关系
与各相互关联的计划、职能部门充分沟通、协调
识别假设与约束
留有余量
70%
30%
资源线
自上而下制定
自下而上修订
目录
一. 研发项目管理概述
二. 跨部门产品开发流程
三. 产品开发项目计划制定
四. 产品开发项目计划控制
五. 产品开发项目风险管理
六. 产品开发项目质量管理
七. 研发团队运作与激励
计划监控的重要性
里程碑管理
项目报告
项目会议
项目问题管理机制
项目变更控制：设计变更、计划变更
预警系统
决策评审和例外管理
非正规控制
计划控制的主要手段
各级监控点的设立遵循两个原则：
A、里程碑
B、时间间隔比较合理
监控计划的表现形式为：计划监控总揽图和计划监控一览表。
计划监控总揽图将各级计划的关键点浓缩在一起，直观，便于控制。
通过计划监控一览表，严格定义每一监控点的完成标志。
计划监控
控制手段：里程碑管理
管理高层
项目管理部
部门经理
产品经理
项目经理
QA
QA经理
质量部经理
反馈—解决问题、风险
反馈—解决问题、风险
反馈—解决问题、风险
反馈—解决问题、风险
项目状态报告
汇总报告
项目状态报告
质量周报
质量周报
项目状态报告
升级问题
汇报、反馈相对应，业务线与质量线相互牵制，达到质量与进度的平衡
控制手段：项目报告
报告关系示例
计划控制手段：项目报告
产品开工会
产品周例会
产品月度例会
产品阶段决策评审会
产品项目结束会议
计划控制手段：项目会议
会议内容（以问题为中心）
里程碑计划为什么没有完成？
其影响如何？
工作何时可以完成？
是否需要替补行动计划？
何日才能回到计划进度上来？
（如何保持会议高效？）会议程序
会前
会中
会后
会议内容与程序
控制手段：问题受理和升级机制
项目经理
提出问题
受理问题
指定问题责任人
分析、制定解决方案
制定解决方案
IPMT决策
项目组
职能部门
决策层
问
题
升
级
升
级
问题解决
问题解决
决策
对于A、B类问题，如果项目组无法解决，将分别升级到职能部门进行解决和IPMT进行决策。
示例：产品开发问题分类
该问题发生将导致：
1、对某项工作项目进度产生延误，但不影响总体项目进度
C类问题
该问题发生将导致：
1、对项目进度有一定影响，对于战略性研发项目进度延期小于5%,重大研发项目进度延期小于10%
2、对项目的质量有一定的影响，但不产生重大质量问题
3、项目费用超出预算小于20%
B类问题
该问题发生将导致：
1、对于战略性研发项目进度延期超过5%,重大研发项目进度延期超过10%。
2、造成重大送样机会损失
3、大客户早期订单交付延期
4、产品重大质量问题，如验证不足，测试设备不足，关键技术无法突破导致关键技术指标无法实现等
5、产品成本超过目标成本
6、项目费用超出预算20%
A类问题
问题定义
问题类别
研讨：下列哪些情况需要设计变更控制？
小试过程中，市场部要求提高产品的分解温度。
中试过程中，主要物料的一致性不好，需要换成其他品牌的物料。
中试完成后，在中试转批量试制的评审中，生产工艺工程师提出中和温度控制范围太宽，质量难以保证，要求缩小控制范围。
批量试制过程中发现主要物料的一致性不好，需要换成其他品牌的物料。
控制手段：设计变更管理
计划
发布
概念
开发
验证
生命周期
BL(基线)
BL
BL
BL
BL
各阶段过程中应进行版本控制，对于尚未建立BL的内容进行的变更，不需执行变更控制流程
产品开发工作的交付成果经过评审并建立基线(BL)后，对该交付成果内容进行的变更，都应执行严格的变更控制
建立设计变更影响分类标准
示例：典型的变更影响程度分类标准
D类更改：
能现场决定实施方案，能够得到立即验证及实施的简单更改
B类更改：
关键性技术方案不变， 产品主要功能不变，对关键物料、组件替换，或弥补设计漏洞的更改
已设计确认，但生产批量较少时的更改
对已认证的产品，更改后产品需要重新认证
C类更改：
功能模块的局部设计优化, 不影响原设计思路或效果
按照已确认文件进行的更改
尚未设计确认，生产批量极少时的更改
客户觉察不到，又不影响其使用的更改
对生产、采购、发货没有影响的更改
对已认证的产品，更改后产品需要重新报备
A类更改：
关键性技术方案变动，关键部件的更改
将严重影响项目进度的更改
导致生产库存物料报废数额或金额较大的更改
控制手段：计划变更管理
计划变更：对里程碑计划变动超过一定程度的变更
影响程度：
绝对时间，如：1周以上
时间比例，如：总计划10%
对客户试用产生影响
……
变更控制流程
提出变更
变更分析
变更批准
变更实施
变更批准
由相应层级的CCB（公司级、项目级）进行批准 如：影响较大的变更由公司级CCB批准，影响较小的变更由项目级CCB批准
工程师
系统工程师
项目CCB
公司CCB
批准者
D类
C类
B类
A类
变更类别
例：不同变更影响程度的批准者
示例：变更控制委员会CCB的构成
项目经理
测试组长
PPQA(质量保证)
配置管理员
架构设计师
系统工程师
项目级CCB
项目经理
测试部经理
质量部经理
制造部经理
研发部经理
客服部经理
公司级CCB
市场部经理
......
......
控制手段：预警系统
控制手段：决策评审和例外管理
通过工作之外的交流和沟通进行控制，在非正规控制的场所要比在办公室更坦率、更诚实，这样能了解到正在酝酿的问题，这要比等到这些问题出现在情况报告中或某次会议上快得多
控制手段：非正规控制
目录
一. 研发项目管理概述
二. 跨部门产品开发流程
三. 产品开发项目计划制定
四. 产品开发项目计划控制
五. 产品开发项目风险管理
六. 产品开发项目质量管理
七. 研发团队运作与激励
风险不可管理？
PM：项目根本不可控，一天到晚都在忙于突发事件。今天老总说还要抽调3个人去支援别的项目。
采购人员：供应商无法准时供货，我们没有后备供应商。只能等待他们供货。
市场人员：你们怎么搞的嘛？这么慢！Andeway已经推出新产品了，我们的计划被全部打乱了。
RD人员：没有办法，我们的进度只能Delay了。原以为没有问题的算法现在无法采用，只能重写。
风险 vs.问题
风险（Risk）
是可能发生的、潜在的事件。
问题
已经发生的对项目有害或负面的事件
风险及其影响
风险管理4个步骤
风险识别
风险评估
风险响应计划
风险监控
项目团队
风险识别
标识风险的常用方法
访谈、调查
头脑风暴（Brainstorming）
专题讨论会（Workshop）
历史经验数据、风险数据库RDB（Historical Information）
专家建议法（ SMEs ：Subject Matter Experts）
确定项目有哪些风险。分析风险产生的各种原因或影响因素，以确定风险来源， 识别风险触发器，定义风险 。
风险来源
市场突变/客户需求变化
技术不成熟
竞争对手行为
合作伙伴/供应商事件
资源冲突
资金困难
风险评估
风险评估维度
发生概率（Risk Probability）
得失量（影响程度）（Amount at stake）
风险影响（Risk Impact）= 发生概率平P * 得失量A
比较风险的大小，确定风险的性质。通过对识别的风险进行定性、定量的分析，包括发生的概率、影响的严重性等，进行风险优先级排序。
确定风险等级（定性）
M
L
L
H
M
L
H
H
M
概率P
得失量A
(影响程度）
高
中
低
低 中 高
风险响应计划
风险应对策略
规避
转移
缓解
接受
制定风险响应的措施和实施步骤。按照风险的优先级，制定相应的措施，包括风险规避、转移、缓解、接受。
风险控制/监控
风险控制（Risk Control）
对风险管理和响应计划进行监控并确保顺利实施的过程。
这是一个在产品生命周期内持续进行的活动，所以在风险控制过程中，必须注意识别新风险。
监督、检查风险事件的发生情况以及风险措施的落实情况。通过对风险事件及其来源的控制和对风险落实情况的监督，确保风险措施有效。
风险管理职责
监控风险；执行风险响应计划。
风险行动责任人
识别风险，经PDT经理认可后进行归档。
业务代表
关闭风险。
在每个DCP向IPMT报告项目风险状态;
当风险响应计划评审通过3个工作日内，归档所有风险和更新风险响应计划；
安排项目例会审视风险响应计划，监控风险状态；
指派风险响应计划的责任人；
持续地组织风险识别，分析风险，并制定风险响应计划；
PDT
经理
风险管理跟踪表
风险管理计划
项目
注释
1 介绍
描述风险管理计划的用途。风险管理计划陈述项目风险和危险性，项目过程中对风险的重新估计，风险征兆和减缓或规避的计划。
2 项目风险
描述项目风险的识别方法。如果使用检查表，那么应在附录中附上这个表格。列出有极高或高危害的风险。
3 风险重估过程
描述项目过程中如何估计风险和风险状态值改变时的措施。评估程序可以包括以下步骤，如周期性的检查风险或召开关于风险的专门的项目团队的会议，会上逐一讨论每个风险发生可能性和影响力的变化。
当风险发生变化或新风险发生时，要及时更新风险管理计划及相关内容，确保文件的阅读者能了解当前的风险，而不仅仅是项目前期识别的风险。
风险管理计划（续）
4 风险分析
完成对每个极高或高危害的风险的识别。
（风险1）
描述
对风险进行详尽的描述
风险征兆
列出一些事件和征兆，当这些事件和征兆发生时，风险即将出现。
风险缓解
描述如何缓解每一个风险。是风险缓解程序的事例。
（风险2）
描述
风险征兆
风险缓解
研讨：风险应对措施
请各小组分析所选项目风险及应对措施
目录
一. 研发项目管理概述
二. 跨部门产品开发流程
三. 产品开发项目计划制定
四. 产品开发项目计划控制
五. 产品开发项目风险管理
六. 产品开发项目质量管理
七. 研发团队运作与激励
产品开发质量控制的主要手段
技术评审
测试
静态分析
评审对象
技术文档
计划
测试用例和数据
测试报告/试验结果
正式及非正式的评审方法
优化设计
发现错误
跟踪需求
质量评估
风险规避
技术评审的操作方式
技术评审的目的
技术评审的目的和操作方式
技术评审是早期发现问题的重要手段
缺陷纠正成本
越早发现问题总体成本越低
技术评审的多个层次和多种形式
子过程
子过程和TR和DCP之间关联
子过程
子过程
子过程
开始
开始
开始
结束
结束
结束
配合关系
TR评审会
子评审
子过程活动
内部评审
产品级评审：引用子评审的结果对产品质量进行评估，对PDT提出改正建议。包括：需求评审、技术方案评审、概要设计评审、样机评审、试产评审等。
子评审（功能级）：对各功能领域活动输出质量把关。包括：软件/硬件/测试/结构评审、工艺/装备开发评审、产品数据评审等。
正规检视/走读（模块级评审）：非正式，同行设计和问题讨论。包括：PCB走查、软件代码走读、零件图纸走查等。
正规检视流程
评审会议前，评审人员做好准备，发现问题
评审会议上，确认问题并寻找解决方案
评审会议后，解决所有发现的问题
走读/走查
计 划：确定产品是否满足检视入口标准，安排检视资源和计划。
介绍会议： 可选阶段。开发人员向检视小组介绍产品的背景信息。如果检视小组成员对被检视对象很熟悉，可不用召开产品介绍会议。
会议准备： 这是一个关键阶段。本阶段检视小组的成员单独对检视对象进行审查，检查和发现错误。发现的问题将在检视会议上进行确认。
检视会议： 正规检视的小组一起审查产品，发现、分类和记录经确认的问题，但不讨论问题的解决方法。
第 3小时会议：可选阶段。主要讨论无法确认问题的解决方法，也包括其它问题的解决方法等。
修改错误： 修改已确认的错误。
问题跟踪： 确认错误是否被改正，并保证修改过程中没有引入新的错误。
走读/走查
走读是最宽松的一种评审形式，被走读的材料量比较少，适用于。
走读可兼有培训、指导的目的。
通常情况下都是由作者兼任组织者、讲解者、记录员。
在走读过程中，收集数据无正规的项目要求，可就地做。
在需做决定时，都由作者来决定。
发现问题或缺陷的更改，是作者的权利。
更改验证留给其他项目控制人员。
技术评审流程
评审计划
预审材料自检
预审材料审核
预评审
预审问题沟通及解决
签署并发布评审报告
评审问题处理及跟踪
技术评审会议
预审材料自检
由项目组成员完成
也可建立互审机制，不同项目组之间互相检查
对照评审要素表进行检查
自我确认是否达到评审要求
预评审
是项目组和各评审专家在评审会前的沟通
各评审专家要留出充分的时间阅读评审材料
各评审专家提出问题
项目组就问题与各评审专家沟通
项目组主动提出潜在问题和希望讨论的重点
能形成一致意见的按意见实施，需要解决的问题及时解决
不能达成一致意见的留到评审会上讨论
技术评审会议
主要是就预评审不能达成一致意见的问题进行讨论
项目组不在评审会议上介绍情况
各评审专家不在评审会议上了解情况
技术评审中的角色和职责
SE——“技术主持人”
PQA—— “过程主持人”
PDT核心组——代表本领域提出专业意见，并代表功能部门承担责任
技术专家——贡献个人才智，不承担直接责任
PDT Leader——以业务需要为出发点对技术问题做决策
IPMT——介入到PCR（项目更改请求）中
技术评审的三个结论
通过： 没有遗留问题和只是一些没有解决风险可以很快解决的问题
有条件通过： 遗留问题的解决存在一定风险，但不影响下一步活动的启动
不通过： 遗留问题影响到下一步活动的启动，必须首先解决，然后再次进行技术评审
做好技术评审的关键
留出充分的时间和预算给评审工作
评审前充分准备和沟通
安排合理的预审时间以便评审人员阅读评审材料
技术评审应当“就是论事”，不要把评审会开成“批斗会”，不要打击有失误的开发人员的工作积极性，更不准搞人身攻击，如挖苦、讽刺等
记录评审中出现的问题，跟踪改进
定期改进技术评审检查单，把检查单作为知识经验积累的重要载体
自查、走查、评审相结合，抓住容易出错的环节重点评审
评审者必须是领域内的专家
产品测试框架流程
概要设计
产品需求分析
总体方案设计
详细设计
模块集成与测试
用户测试、认证测试等
产品整体集成与测试
单元/器件/零件测试
单元/零件实现
产品测试是与产品设计与实现过程相辅相成的
测试/实验通常的过程
测试/实验方案与计划
测试/实验准备
测试/实验执行
测试/实验评估分析
测试/实验方案调整与优化
测试/实验方案与计划
测试/实验策略
工作量估计、进度
资源、分工
测试方法
环境、工具
示例：实验方案
实验步骤：
反应： 降温到25℃以下开始滴加溴素，反应温度控制在25~28℃，滴加完毕保温2个小时。
中和： 加入浓度12%的亚钠溶液，升温到80℃搅拌洗涤45分钟。停搅拌静止分层。
……
关键控制点：
在溴化加料时温度上升较快，应严格控制溴素滴加速度，操作时应提前开启循环水
测试/实验准备
测试/实验工具开发
脚本和用例编写
环境准备
测试用例/实验方法的内容
<描述测试用例针对的功能项>
测试用例说明
……
预期结果
测试输入/过程
测试条件
测试用例编号
<描述在测试后预期得到的结果>
<描述进行测试的所有输入>
<进行测试所需的环境设置>
<项目名>_UT_<模块名>_<001/002/003>
测试/实验执行
检查测试对象
执行测试用例
记录结果
测试/实验评估分析
有效性分析
预期差异分析
测试/实验方案调整与优化
调整方向和思路
调整后预期效果
做好测试/实验的关键
做好充分的需求分析
根据行业特点建立不同的测试/实验子流程
制定详细的测试/实验方案和计划
良好的测试/实验记录
充分的测试/实验结果分析和方案修订
目录
一. 研发项目管理概述
二. 跨部门产品开发流程
三. 产品开发项目计划制定
四. 产品开发项目计划控制
五. 产品开发项目风险管理
六. 产品开发项目质量管理
七. 研发团队运作与激励
研发与行销管理委员会
项目管理部
技术开发部
总工办
市场部
财务部
其他职能部门
中
试
研
究
室
硬
件
研
究
室
测
试
研
究
室
结
构
研
究
室
软
件
研
究
室
PDT1
PDT2
PDT3
跨部门产品开发团队在公司组织结构中的位置
不同紧密程度的跨部门团队
“轻度矩阵”团队结构
DEV
SVC
MKT
FM
FM
FM
项目经理（L)
项目经理的影响
组员 (M)
M
M
L
M
主管
“重度矩阵”团队结构
DEV
SVC
MKT
FM
FM
FM
M
M
M
P
IPMT
项目经理是协调人
项目组成员是职能部门的联络员（没有权力）
职能部门经理仍然做出本部门的关键决策
当规模和复杂度增大时，这种结构也难于支持
项目经理在不同功能中发挥直接的、综合性的影响
组员完全代表相应的职能部门
项目经理和成员有项目权力和责任
职能部门经理关注于建立优秀的部门，而不是日常的决策
是复杂项目和组织的最好的组织结构
核心小组组长在不同功能中发挥直接的、综合性的影响
组员完全代表相应的职能部门
核心小组组长和成员有项目权力和责任
职能部门经理（资源经理）关注于建立优秀的部门，而不是日常的决策
是复杂项目和组织的最佳结构
核心小组
外围组
核心小组组长
协调人
用户服务
制造
硬件设计
软件设计
市场营销
质量
PDT（产品开发团队）采用“重度矩阵结构”模式，保证沟通、协调和决策的高效。
重度矩阵跨部门团队的先进实践--核心小组法
供应部
生产部
财务部
生产部长
服务部长
服务部
制造总监
总裁
技术管理中心
工艺部
PDT经理
市场总监
结构部
…
电气部
总 工
实验室
燃气部
…
产品线总监
产品总监助理
品质部
品质部长
供应部长
各大区
销售总监
人力资源部
HR总监
财务总监
总裁办
研究部
市场研究部
IPMT
PMT
PMT
PDT
PDT
PDT经理
产品经理
产品经理
PDT在公司组织结构中的位置（举例)
领导整个项目小组：
建立和领导整个PDT团队，直接对产品的市场成功负责；
召集PDT核心组，针对项目任命和期望值做沟通，将项目职责分配到PDT核心组成员；
启动项目和保持项目正常沟通，当无法达成一致时做出决策；
与管理层进行沟通：
作出各DCP的日程安排及将业务计划和建议提交和呈现给公司管理层；
从公司管理层获得承诺，并确保所需要的资源的到位；
及时提供项目的进展情况；
PDT经理（LPDT）的角色及职责
管理整个项目小组：
确保财务、开发、制造、技术支持、采购、市场行销和销售计划互相耦合；
为所开发产品包制定和管理跨功能部门的计划；
制作和综合项目交付件、预算和时间进度承诺；
对整个项目准备工作分解结构图（WBS），并指导各功能部门的核心项目组成员详细制定各功能领域的WBS；
制定和维护项目计划，确保根据时间表、预算和规格说明书执行各类活动；
进行风险评估和制定风险管理计划 ；
跟踪问题直到问题解决；
管理项目更改控制；
确保合法的有调整的需求被满足。
PDT经理（LPDT）的角色及职责（续）
PDT核心小组的职能专家
负责职能领域的设计并解决问题
代表功能部门做决策
共同负责小组的最终结果（管理项目计划，履行PDT与IPMT的合同）
对计划、预算、关键问题等的进展情况进行汇报
对功能部门的交付负责
充当与职能部门的桥梁
向职能部门经理汇报项目情况
应用职能部门的策略、工具和标准
协同外围小组的活动
管理职能部门外围组的项目计划和预算
负责PDT与职能部门间的信息交换
在职能部门内对设计/项目进行评审
向职能经理提供外围组成员的项目绩效输入
PDT核心小组成员的职责
执行项目计划，独立完成产品定义、市场交付、设计、测试等工作（关注于特定的功能性任务，“Just do it”）
向PDT成员和资源部门经理提供项目时间表、预算、风险和开发工具需求方面的输入
向PDT成员提供项目交付件状态和出现问题的输入
应PDT的要求参加PDT会议（如需要）
在特殊情况下，PDT小组可能没有外围小组
在PDT中没有直接代表的资源部门的成员在推动他们的资源部门活动方面要更加积极主动
外围小组成员的职责
支持PDT工作
在预算和质量的范围之内，按时完成对项目的承诺
避免直接控制项目，但提供技术方面的专业技能和建议
建立优异的功能（能力）
招聘和培养员工，及对员工进行绩效考评
持续改进功能部门基础设施，支持产品开发管理流程的不断优化
领导职能部门的项目（如TDT、CBB）
执行职能部门预算
提供技术指导
定义职能部门的策略、指导原则、工具和标准
协调跨项目的技术合作
对PDT和外围组成员提供技术指导
管理“人”
而不是“项目”
职能部门经理的职责
选择合适的跨部门产品开发团队结构
建立跨部门沟通、协调机制
给项目经理和团队成员充分授权
加强项目计划管理
加强项目管理技能培养
建立跨部门的评价机制
高层推动文化建设
如何有效运作跨部门产品开发团队？
不同的跨部门产品开发团队结构
产品线经理领导下的重度矩阵产品开发团队和产品组合管理团队的结合
重度矩阵的产品线团队：针对系列产品设置产品开发团队而不是单个产品，保持团队的稳定性和延续性
精简的核心小组，加强关键角色配置：产品经理、项目经理、系统工程师、市场代表、生产代表、采购代表等
跨部门沟通模式
下达项目任务时，公司指定各项目成员
项目经理与职能部门主管确认、调整项目成员
项目经理与项目成员直接沟通项目任务
职能部门主管支持和指导项目成员工作
研讨：如何进行有效的跨部门沟通？
项目经理需要具备综合性的素质和技能
业务才干
25%
软硬件开发技能
15%
市场技能
15%
项目管理技能
35%
团队合作技能
10%
项目管理35％
业务25％
团队合作10％
市场15％
开发15％
矩阵式跨部门考核机制
示例一：某家电企业跨部门考核关系
示例二：某照明企业跨部门考核设计
项目奖： 根据年度项目奖总额预算和项目评分确定每个项目奖基数，按照项目评价得分，结合绩效考核结果计算奖金额，打包分配
效益提成： 根据产品的销售额或利润提取一定比例用于奖励开发团队
研发团队激励方式
季度奖： 根据季度绩效考核（含关键行为考核）结果发放季度奖
年终奖： 根据公司效益/研发贡献，结合个人年终综合评价（绩效＋能力），发放年终奖
对主管的要求（如计划技能、考评技能）比较高
矩阵运作中，项目经理的评价权容易遭到削弱
过于关注利益，容易淡化研发工作本身的动力因素
容易诱发短期行为
评价较困难，容易导致不公平，影响团队合作
诱发攀比现象，与其他部门不好平衡，影响跨部门配合
缺点
对员工的激励作用中长期内明显
配合绩效考评频率及结果
通过关键行为考核贯彻公司核心价值观（如团队合作）
与研发贡献/公司效益挂钩
牵引个人的综合和长期表现
结合项目目标的短期激励作用明显
项目经理自主权，项目经理激励到位
提高人力资源利用率
鼓励项目和人员之间的竞争
优点
季度奖/年终奖
项目奖/效益提成
研发团队激励方式
季度（年度）绩效和项目绩效的结合
按季度或年度对员工进行考核
以项目计划与目标作为研发人员主要的绩效计划目标
项目KPI是研发人员季度考核的重要指标
项目任务考评结果作为研发人员季度考评的重要依据
示例：某企业硬件工程师季度绩效考核表
贵公司产品开发团队运作存在哪些问题、困难和障碍？
如何解决贵公司产品开发团队运作存在的问题？
研讨：贵公司产品开发团队应该如何运作？
总结及研讨
如何改善我公司研发项目管理？
欢迎交流！
谢谢！
经过2天的课程，研发对企业的重要性，想必大家都已经很清楚了。而对研发项目进行有效管理，是项目成功的重要手段。项目管理是一整套系统的方法。虽然，各种各样的项目，在人类社会中存在已有几千年，但系统的项目管理方法，也只有50年左右的历史，而项目管理所使用的工具、技术也还在不断地丰富发展。
…
IPMA成立于1965年，总部设在瑞士洛桑，目前有成员国30-40个。成立于91年的PMRC（Project Management Research Committee, China
）是唯一代表中国的项目管理专业团队，于96年加入了IPMA。
PMI（Project Management Institute），即美国项目管理学会，成立于1969年。它是一个有着近5万名会员的国际性学会，是项目管理专业领域中最大的由研究人员、学者、顾问和经理组成的全球性专业组织。
20世纪80年代以后, PMI与IPMA协会创立并不断完善项目管理标准，项目管理形成系统学科，在企业的战略发展和日常经营中越来越得到普遍应用。PMI于1987，1996，2000三次更新PMBOK。
一切皆项目？项目管理的某些思想也可用于日常管理，但日常的运作与项目还是有很大差别的。
不同干系人的期望可能不同。
研发项目的项目干系人比较复杂。由于研发项目涉及到的开发、制造、采购、售后服务等等。这些都是项目干系人。生产人员希望容易生产，生产成本较低，以组装与装配；采购人员希望设计人员尽可能采用标准件，常用件，使用的原材料和零部件是市面上容易采购获取到的；售后服务人员希望产品投放市场，交付客户后，比较稳定，维修时方便拆卸，方便更换备板备件等等。
各种项目干系人都有各自的需求和期望。有效的项目管理之所以难，很重要的一方面就在于需要在各种项目干系人的欲望与要求之间进行平衡。
项目是由各种过程组成的，这些过程可分为两类：1) 与项目管理有关的过程，涉及项目组织和管理；2) 与产品有关的过程，涉及具体的项目产品生成。这两类过程结合起来，才能完成整个项目活动。PMBOK主要讨论项目管理过程。
启动。成立项目组开始项目或进入项目的新阶段。启动是一种认可过程，用来正式认可一个新项目或新阶段的存在。
问：你们的项目开发过程中有没有启动过程？有几次？ 正常的产品开发项目，不应该启动一次，就必须执行到产品开发出来上市。启动，是本阶段的启动，评审通过后，再启动下一个阶段。
2) 计划。定义和评估项目目标，选择实现项目目标的最佳策略，制定项目计划。计划也不是一次搞定的，后面会详解。
3) 执行。调动资源，执行项目计划。 4) 控制。监控和评估项目偏差，必要时采取纠正行动。 5) 结束。。
以部门交接点设置来划分阶段，部门分割严重、沟通效率低。
主要考虑技术和工程活动，较少考虑业务管理活动，业务控制薄弱，风险不受控。
工程技术活动和业务管理活动割裂，相互之间是串行的，整个周期长。
各阶段输入输出内容不明确，要求不清晰
各阶段控制不严格，产品开发在各阶段之间来回次数多，返工周期长，上市速度慢。
市场管理与产品规划有很多工作要做，包括：理解市场、市场细分、产品组合管理等工作。不过我们华峰很幸运，前面有世界巨头在前面带路，很多工作他们替我们做了，我们可以采取跟随策略，跟着走，世界巨头推出了什么好的产品，我们跟着走就可以了。国内很多企业也都是这么做的，华为当年是这样做的，金发科技当年是、现在也是这么做的。但并不意味着我们就可以不做了，还是有几项工作我们要去做的，包括PPT上几点。 我们要决定跟哪些、不跟哪些？我们还是要分析哪些最有潜力？哪些我们能做？哪些我们现在还不具体这种能力？我们应该先进行哪些技术储备？等等问题，都是我们要考虑的。
良好的产品与技术规划需要大量的市场需求和情报信息，需要多渠道获取相关信息，信息质量的好坏很大程度上决定了规划成果的质量
卢刚：产品线可以按照很多维度来进行划分
在充分收集市场信息的基础上，通过组合分析评估各产品和技术项目的优先等级，从市场吸引力、竞争地位、财务收益等几个方面进行综合评估
对市场吸引力及竞争地位各要素的评估一般采取定性评估法
在给各要素评分后，还要对每个要素/子要素分配一定的权重，各要素得分与权重相乘得出最后的得分，示例如下：
财务收益评估是基于未来3~5的预测，计算累计税前利润、收益率等
关于优先级排序：
严格的排序不一定就准确，成本也比较高。我们可以简化一下，就简单的分高、中、低，我们会发现有些项目很显然是高的，汽车ABS材料市场已经开始火了，市场前景很明朗了，不用做太多的分析，肯定要做。有些项目很显然不重要，也不用做多少分析。最难确定的是不高不低的，我们总是在这些项目之间犹豫、迟疑，到底是做A项目还是做B项目呢？母亲和老婆掉水里，先救谁？
在评估优先级后，制定未来3~5年产品与技术开发规划，以及下一年度产品与技术开发计划，如下图所示为中长期产品开发规划示意图
定义平台、定义支撑业务范围时不仅仅看产品的表现出来的共性有多大，而是深入考察可以共用的技术特性是多少，例子中水面舰艇和潜艇，甚至可以扩展到地面的防御指挥系统——不再移动的舰艇。
流程好比是登山通道。共同到达顶峰才算成功：市场、研发、采购、中试制造等，这就需要项目管理----进行组织、协调、指挥控制，保证过程安全、顺利，最好是整体同时到达，而不是拖拖拉拉长蛇阵。因为这个比赛的规则是以最慢的那个人到达目的地为计时标准。（产品稳定量产上市，产品开发项目才算结束）.
好的流程可以在QCT方面…，还能降低对人的要求。
流程中的指导书、模板是知识经验的积累
项目经理最头疼的是跨部门协调、沟通，有了跨部门流程和相应的计划，沟通将更顺畅，解决冲突也会有章可循
（有了登山通道，非专业人士也能成功登顶）
从案例分析中可以看到，各个专业领域/各职能的工作很多欠缺。怎么办？要建立各个方面的流程，明确要求和标准。
那么是不是把这各个领域的工作都做好了，就可以了呢？显然不是。
跨部门协作的问题，有时候其他部门认为产品开发就是研发部门的事，他们只是义务协作，更多的原因还在于大家不知道应该怎样跨部门协作，在什么时期该做什么工作，应该怎么配合，大家是不清楚的。怎样解决这个问题，当然是流程，应该说是流程集成，我们要把各职能/各专业领域活动集成为一个整体框架。形成主流程、阶段流程，严格控制。
划分阶段：把整个过程划分为有先后顺序的几个部分，合理安排各项活动在流程中的位置，明确各阶段任务，明确各阶段控制点和控制标准，增强产品开发过程的可控性，控制风险、控制进度、控制品质。
划分阶段：把整个过程划分为有先后顺序的几个部分，合理安排各项活动在流程中的位置，明确各阶段任务，明确各阶段控制点和控制标准，增强产品开发过程的可控性，控制风险、控制进度、控制品质。
需要回答：SQCT，投资及回报的要求
在这里可以展示山特自身的Project Charter
全新产品/突破型新产品：SONY今年推出了OLED电视机，3cm厚。
平台型新产品/新产品线：
模式一：市场管理与产品规划做得不规范，需求管理流程运作不好的时候，把需求收集等工作并入任务书开发流程，并作为产品开发流程的一个阶段来做。
模式二：
需要回答：SQCT，投资及回报的要求
需要回答：SQCT，投资及回报的要求
基本需求 - 这是最基本的类别，比如：如果这些需求没有满足，这个市场细分的客户将不会考虑这个交付
更满意的需求 - 这是在基本以外的类别，它能向市场细分中的客户提供区别的和附加的价值
更有吸引力的需求 - 更有吸引力的需求向客户提供了其他的基本需求和更满意需求所不能满足的独一无二的或附加的利益和价值
补充一个通俗易懂又有代表性的产品设计需求分析案例
增加产品包设计需求模板示例
通过产品实现分析找到冲突点，并进行充分的分析
增加产品开发任务书的模板示例（二张PPT）
测试也是一个设计过程，不仅仅是简单的操作性工作
增加产品开发任务书的模板示例（二张PPT）
可考虑将标题改为“从需求分析就开始新产品生产导入工作而不是从设计完成后才开始”，而将现有标题放到正文中来。
需要回答：SQCT，投资及回报的要求
需要回答：SQCT，投资及回报的要求
通常没有流程的情况下，第一次做开发项目，才用到头脑风暴法。
设定出口条件。
向关键路径要时间，向非关键路径要时间
计划不是部门领导、项目经理一个人定出来的，沟通。计划不能只考虑一切顺利的情况。
唯一不变的是变化。项目优化级变化，也要调整计划
研发质量控制（评审＋测试）
研发成本控制
计划监控总揽图将各级计划的关键点浓缩在一起，直观，便于控制。同时，各监控点在时间上也形成对应。
通过计划监控一览表，严格定义每一监控点的完成标志，以使监控点不会产生歧义性的理解。
引出下一步PPT：变更管理存在产品开发的各个阶段、各个环节。
1.团队是虚拟的
2.可以通过电子邮件完成
提示：由于多数研发人员（尤其是新进员工）不太喜欢主动沟通，出了问题也希望能够悄悄解决。非正式的沟通能及时了解问题，以便项目经理及时采取有效的行动。
HR风险、供应风险、市场风险、技术风险
研发项目的典型风险：技术不成熟、人员变动、需求变更、外协、采购延误（新供应商开发）
风险控制的目的：最小化风险对项目的影响
建议兴森快捷通过走读/走查机制形成资深工程师对项目组的指导机制，也形成项目组向领导求助的机制。
建议兴森快捷通过走读/走查机制形成资深工程师对项目组的指导机制，也形成项目组向领导求助的机制。
测试也是一个设计过程，不仅仅是简单的操作性工作
测试也是一个设计过程，不仅仅是简单的操作性工作
测试也是一个设计过程，不仅仅是简单的操作性工作
测试也是一个设计过程，不仅仅是简单的操作性工作
测试也是一个设计过程，不仅仅是简单的操作性工作
测试也是一个设计过程，不仅仅是简单的操作性工作
测试也是一个设计过程，不仅仅是简单的操作性工作
这张PPT除了讲解矩阵关系，还要讲解PDT向IPMT的汇报关系。
