以前一直关注项目管理的书籍，现在公司做产品，跟之前项目的感觉有些不同，但又说不上来具体不同在哪些地方，刚好看到这本书，就拿回来看看。
首先这本书立意比较高，“构建世界一流的产品研发管理体系”，同时又希望做到“即学即用即实践”，仔细想想，这两者还是有点互斥的，中小型企业可以借鉴其中一些做法而远不能做到体系，大中型企业才有希望实践这套体系。但是他们通常又已经有了自己的研发管理体系，再综合看完之后的体会，我觉得最有价值的读者，是一些中型企业，或者希望改革的大中型企业。
说实话翻目录的时候有点吃惊，这本书涉及到产品战略管理，产品开发流程，项目管理，技术及平台管理，产品营销，财务及成本管理，质量管理，绩效管理等，但是感觉这书不厚啊，看看页码340，再看看内容，字号大行距高，额有种黑人问号的感觉。由于书里很多主题我都没有经验，于是只挑了一些感兴趣的章节看。就像前面说的，这套体系我现在肯定是很难理解和实践的，充分相信这本书的干货全都被我跳过了，以下是一些比较浅显的内容。
第一章 集成产品开发管理是企业不可跨越的阶段
“集成产品开发(IPD)以市场需求为核心，将产品开发堪称一项投资，通过共享货架产品和跨部门的团队准确，快速，低成本，高质量地推出产品，是世界一流企业普遍采用的一套系统工具方法和策略，是企业不可跨越的阶段。”
首先有个大前提，书里把研发(Research & Development)看作是两件事情，Research是指技术开发，偏重原理研究，强调技术领先性，Development是产品开发，偏重技术成果产品化，强调市场和财务方面的成功。
1.2.1 传统的产品开发方式
传统的开发方式有两种：一种是先开发技术，然后在技术的基础上做出通用的产品，然后卖出去，可以称为通用产品；另一种是根据客户需求完成定制产品的交付，可以成为定制开发。
对于通用产品来说，模式如下：
通用产品模式的市场环境，风险和优缺点：
市场环境：产品短缺，以产定销的买方市场。
优点：通用产品，快速产生规模，容易交付，可批量生产和复制。
竞争要求：技术必须具有不可替代性和领先性。
风险：由于是通用产品，不能满足个性化的用户需求；技术一旦落后，没有后续产品推出，客户就容易被转移。
对于定制开发来说，模式如下：
定制开发的市场环境，风险和优缺点：
市场环境：个性化定制的卖方市场。
优点：由于满足客户定制化，通常满意度较高。
竞争要求：必须及时交付。
风险：如果碰到技术问题，就很难及时交付；个性化定制导致企业没有技术积累；每个项目都从头做起，很容易出现质量问题；人员没有专业发展通道，容易流失；项目越多管理越难，甚至项目增多企业反而亏损。
1.2.2 竞争环境下的产品开发方式 集成产品开发
有没有一种开发模式，既能满足定制化需求，又能保证质量进度，还能将技术风险提前化解，最可能做到的就是集成产品开发。其主要做法是：
1. 产品开发和技术开发以及平台开发分离。
2. 技术和平台开发按通用产品开发模式，形成货架产品，供产品开发时共享。
3. 产品开发按定制开发模式，在货架的帮助下，分成细分客户群版本。
通用产品开发模式与集成产品开发模式的对比：
科匠属于定制开发，书里提到的风险我们全碰到了，都想了一些措施去规避或减轻，其中有些效果不错，有些没什么用。为了处理定制化没有技术积累和技术成熟度带来的质量问题，成立了技术管理部，这个部门的同事不参与项目，只做框架和组件级的开发，这个模式很类似集成产品开发里的技术和产品开发分离。但是实际运作效果并不怎么样，有多方面的原因。第一，本来是各分公司自己组建技术管理部，但是这样带来了成本问题，同时也还是没解决公司整体层面的技术积累和质量问题。第二，后来改成总部成立技术管理部，同时带来的问题是他们做的东西跟各分公司真实项目存在一定脱节，而且分公司并没有太强的意愿用他们的东西。第三，不论技术管理部在哪里，都存在一个根本性的问题，就是全公司统一框架。PMO为这个事情讨论了太多次，从我的角度出发，每个项目规模都不同，统一一个框架不现实。当时我给的意见是提供多套框架，分别对应轻量，中等，重量级项目使用，当然也不能强制使用，只能作为一个最佳实践推荐使用。后来结果是公司强制统一一个平台，在这个平台上提供框架和一些可插拔的组件，说实话平台做得还不错，但实际上最终大家还是退化成了各部门用各自的框架，维护各自的组件。这里面有一些定制开发天然的因素在里面，也有一些是人为失误，还有一部分是由于分公司的因素，我相信如果再有一次机会，我们会处理得更妥善。
1.2.3 货架管理与产品分类
货架是对公司的所有产品或组件按照一定的层级结构进行统一管理，以利于产品开发时方便地共享以前的成果。
对于软件企业来说，我觉得货架有组件，套件和子系统三层就够了。
对于产品分类，通常分为三类：
1. 内部共享产品，通过包括货架上所有的产品。
2. 对外销售产品，指可以对外销售的单机，整机或软件模块，同时也能作为内部共享产品。
3. 解决方案产品，通常跨越几个对外销售产品，需要进行系统集成的产品组合。
1.2.4 产品版本的VRM定义
V版本(Version)，指平台版本。
R版本(Release)，指最终交付给客户的版本。
M版本(Modification)，指在R版本上位某些客户定制化的版本。
第二章 产品战略管理
2.4.1 如何选择产品开发的扩张路径
对于很多没有建立产品线的企业来说，研发和市场分别属于两个相对独立的部门，研发倾向于关注新产品新技术，市场则喜欢围绕老客户和老产品，导致的结果就是对老客户的需求关注不够，对新产品推出进度和质量不如人意。如何在新老产品和新老客户上配置合理的资源，以便企业的扩张风险最低，投入产出最高，速度最快，也就是如何选择产品开发的扩张路径问题。
营销第一路径：老产品卖新客户。
研发第一路径：为老客户开发新产品。
谨慎投入路径：用老技术做新产品进入拓展市场。
第三章 建立以产品为中心，面向客户的组织体系
3.2.3 产品经理与项目经理的区别
在一些定制开发的企业，他们通常选择强矩阵或者项目型组织结构，为了资源利用率，会把产品经理跟测试，UI设计，前端这些岗位放在同个职能部门，所以我可以认为在定制开发企业里，产品经理更偏向于需求分析师和原型制作等执行层的工作，是属于项目经理的一个资源，我们之前就常常抢口碑好的产品经理进自己项目。而在产品开发的企业，却非常不同，项目经理变成了产品经理的资源。
产品经理下可以设立项目经理，产品经理也可以兼任项目经理，但两个角色的职责是不同的。产品经理管理所有产品的V版本，R版本和M版本，项目经理管理当前项目的R版本。具体区别如下：
1. 在新产品开发，没有老产品销售时，产品经理通常兼任项目经理。
2. 当产品经理负责新产品开发和老产品维护时，产品经理可以选择兼任项目经理，也可以将新产品交由另外一位项目经理。
3. 产品经理是对产品全生命周期的管理负责，包括产品规划，产品开发，产品生命周期维护等，它是一个例行职位；项目经理对产品开发全过程负责，他是一个项目职位，随着项目启动时任命，随着项目结束时撤销。
4. 一般项目规模较小时，产品经理兼任项目经理，当产品规模变大，同时有老产品正在销售或运营时，产品经理应该将精力放在老产品上，任命其他人为新产品的项目经理，此时项目经理想产品经理汇报。
5. 一般没有承担过项目经理职责的人员不能升任产品经理。
这里谈到的产品经理，应该是产品开发企业里的产品线经理，感觉比项目集管理的要求还高了。所以单独拉出一条没做过项目经理的一般不能升产品经理，还是有道理的。
3.3.1 怎样避免矩阵组织里的多头管理问题
矩阵的多头问题很经典，PMI里把它作为矩阵型组织的一个缺点，但没有给出解决方案，以前一个朋友，说多头是理论上存在的问题，现实中不常出现，一个员工，是项目经理能帮他搞定问题还是职能经理能帮他搞定问题，他是清楚的，谁帮他搞问题他就听谁的。这又引起另一个朋友说，这是一个广泛存在，但是不科学的解释，就像抽烟多多少少能给项目经理带来一些工作上的便利，但是抽烟无法作为管理学上的考虑因素。我想这就是book smart和street smart吧，哈哈。
这里给出来的办法很粗暴，强矩阵就听项目经理的，相当于职能经理把人外包给项目经理，弱矩阵就听职能经理的，但职能经理要跟项目经理汇报，相当于项目经理把事外包给了职能经理，平衡矩阵呢就看情况。关键或者重要的项目，就用强矩阵，同时考核项目经理的成本，资源释放率。不是很重要的项目就用弱矩阵，同时考核职能经理的任务计划完成率，人员闲置率等。
第五章 产品开发流程
这章没仔细看，主要是把产品开发分解成三级流程，六个阶段，以及若干个评审点(四个决策评审，六个技术评审)，因为是以华为做示例，所以涉及到很多结构设计，硬件设计，样机生产之类的环节，软件企业并不需要。
其中提到一个发布阶段，是非常重要和有借鉴意义的一点，之前和现在的工作里，从没想过把交付工作单独拿出来作为一个阶段去设计，评审和执行。
发布阶段的目标：
1. 完成早期客户的总结。
2. 完成产品定位，定价，宣传，推广策略。
发布阶段的主要交付物：
1. 销售指导书，售前胶片。
2. 定价策略，宣传策略。
3. 生命周期管理计划。
发布阶段的主要活动：
1. 完成早期客户的建设和总结。
2. 完成产品定价和定位策略。
3. 完成产品样板点建设。
4. 完成产品销售工具包。
5. 完成产品销售培训。
6. 成立LMT(Lift Management Team)，对产品开发进行总结和绩效评估。
第六章 产品开发的项目管理
这章也没仔细看，主要在讲项目计划，分为三级计划，一级二级用PERT图，三级用甘特图。然后讲到单项目和多项目管理分离，由项目管理部对多项目管理负责，主要是对项目排序，资源配置管理，以及项目经验数据库的建设，可以理解为控制型的PMO。