工程师做热设计不得不注意的若干事项[精选]

第一篇：工程师做热设计不得不注意的若干事项[精选]

在调试或维修电路的时候，我们常提到一个词“××烧了”，这个××有时是电阻、有时是保险丝、有时是芯片，可能很少有人会追究这个词的用法，为什么不是用“坏”而是用“烧”？其原因就是在机电产品中，热失效是最常见的一种失效模式，电流过载，局部空间内短时间内通过较大的电流，会转化成热，热聚。集不易散掉，导致局部温度快速升高，过高的温度会烧毁导电铜皮、导线和器件本身。所以电失效的很大一部分是热失效。

那么问一个问题，如果假设电流过载严重，但该部位散热极好，能把温升控制在很低的范围内，是不是器件就不会失效了呢？答案为“是”。

由此可见，如果想把产品的可靠性做高，一方面使设备和零部件的耐高温特性提高，能承受较大的热应力（因为环境温度或过载等引起均可）；另一方面是加强散热，使环境温度和过载引起的热量全部散掉，产品可靠性一样可以提高。下面介绍下热设计的常规方法。

我们机电设备常见的是散热方式是散热片和风扇两种散热方式，有时散热的程度不够，有时又过度散热了，那么何时应该散热，哪种方式散热最合适呢？这可以依据热流密度来*估，热流密度=热量 / 热通道面积。

按照《GJB/Z27-92电子设备可靠性热设计手册》的规定（如图1），根据可接受的温升的要求和计算出的热流密度，得出可接受的散热方法。如温升40℃（纵轴），热流密度0.04W/cm2（横轴），按下图找到交叉点，落在自然冷却区内，得出自然对流和辐射即可满足设计要求。

大部分热设计适用于上面这个图表，因为基本上散热都是通过面散热。但对于密封设备，则应该用体积功率密度来估算，热功率密度=热量 / 体积。下图（图2）是温升要求不超过40℃时，不同体积功率密度所对应的散热方式。比如某电源调整芯片，热耗为0.01W，体积为0.125cm3，体积功率密度=0.1/0.125=0.08W/cm3，查下图得出金属传导冷却可满足要求。

按照上图，可以得出冷却方法的选择顺序：自然冷却一导热一强迫风冷一液冷一蒸发冷却。体积功率密度低于0.122W/cm3传导、辐射、自然对流等方法冷却；0.122-0.43W/cm3强迫风冷；0.43～O.6W/cm3液冷；大于0.6W/cm3蒸发冷却。注意这是温升要求40℃时的推荐参考值，如果温升要求低于40℃，就需要对散热方式降额使用，0.122时就需要选择强迫风冷，如果要求温升很低，甚至要选择液冷或蒸发冷却了。

这里面还应注意一个问题，是不是强迫风冷能满足散热要求，我们就可以随便选择风扇转速呢，就好像说某件工作，专科学历的知识水平即可胜任，是不是随便抓个大专生就能做好呢，当然不是，风扇的转速与气流流速有直接关系，这里又涉及一个新概念——热阻。

热阻=温度差 / 热耗（单位℃/W）

热阻越小则导热性能越好，这个概念等同于电阻，两端的温度差类似于电压，传导的热量类似于电流。风道的热阻涉及流体力学的一些计算，如果我们在热设计方面要求不是很苛刻，可通过估算或实验得出，如果要求很苛刻，可以查阅《GJB/Z27-92 电子设备可靠性热设计手册》，里面有很多系数、假设条件的组合，三言两语说不清楚，个别系数我也没搞明白如何与现实的风道设计结合，比如，风道中有一束电缆、风道的壁不是均匀的金属板，而是有高低不平带器件的电路板，对一些系数则只能估算了，最准确的方式反而是实验测量了。

热阻更多的是用于散热器的选择，一般厂家都能提供这个参数。举例，芯片功耗20W，芯片表面不能超过85℃，最高环境温度55℃，计算所需散热器的热阻R。

计算：实际散热器与芯片之间的热阻近似为0.1℃/W，则（R+0.1）=（85-55）℃/20W，则R=1.4℃/W。依据这个数值选散热器就可以了。

这里面注意一个问题，我们在计算中默认为热耗≈芯片功率，对一般的芯片，我们都可以这样估算，因为芯片中没有驱动机构，没有其他的能量转换机会，大部分是通过热量转化掉了。而对于电源转换类芯片或模块，则不可以这样算，比如电源，它是一个能源输出，它的输入电量一部分转化成了热，另外很大部分转化成电能输出了，这时候就不能认为热耗≈功率。

以上部分是定量设计部分的内容，在有了一个定量的设计指导后，也有一些具体的工程技巧来帮助实现理论计算结果的要求。一般的热设计思路有三个措施：降耗、导热、布局。

降耗是不让热量产生；导热是把热量导走不产生影响；布局是热也没散掉但通过措施隔离热敏感器件；有点类似于电磁兼容方面针对发射源、传播路径、敏感设备的三个措施。

降耗是最原始最根本的解决方式，降额和低功耗的设计方案是两个主要途径，低功耗的方案需要结合具体的设计进行分析，不予赘述。器件选型时尽量选用发热小的元器件，如片状电阻、线绕电阻（少用碳膜电阻）；独石电容、钽电容（少用纸介电容）；MOS、CMOS电路（少用锗管）；指示灯采用发光二极管或液晶屏（少用白炽灯），表面安装器件等。除了选择低功耗器件外，对一些温度敏感的特型元件进行温度补偿与控制也是解决问题的办法之一，尤其是放大电路的电容电阻等定量测量关键器件。

降额是最需要考虑的降耗方式，假设一根细导线，标称能通过10A的电流，电流在其上产生的热量就较多，把导线加粗，增大余量，标称通过20A的电流，则同样都是通过10A电流时，因为内阻产生的热损耗就会减小，热量就小。而且因为降额，在环境温度升高时，器件性能下降情况下，但因为有余量，即使性能下降，也能满足要求，这是降额对于增强可靠性的另一个作用，将是另一篇博客文章的内容。

导热的设计规范比较多，挑一些比较常见的罗列：

1.进风口和出风口之间的通风路径须经过整个散热通道，一般进风口在机箱下侧方角上，出风口在机箱上方与其最远离的对称角上；

2.避免将通风孔及排风孔开在机箱顶部朝上或面板上；

3.为防止气流回流，进口风道的横截面积应大于各分支风道截面积之和；

4.对靠近热源的热敏元件，采用物理隔离法或绝热法进行热屏蔽。热屏蔽材料有：石棉板、硅橡胶、泡沫塑料、环氧玻璃纤维板，也可用金属板和浇渗金属膜的陶瓷；

5.将散热》1w的零件安装在机座上，利用底板做为该器件的散热器，前提是机座为金属导热材料；

6.热管安装在热源上方且管与水平面夹角须》30度；

7.PCB用多层板结构（对EMC也有非常非常大的好处），使电源线或地线在电路板的最上层或最下层„

8.热源器件专门设计在一个印制板上，并密封、隔离、接地和进行散热处理；

9.散热装置（热槽、散热片、风扇）用措施减少热阻：

（1）扩大辐射面积，提高发热体黑度；

（2）提高接触表面的加工精度，加大接触压力或垫入软的可展性导热材料；

（3）散热器叶片要垂直印制板；

（4）大热源器件散热装置直接装在机壳上；

10.密封电子设备内外均涂黑漆可辅助散热；为避免辐射热影响热敏器件、热源屏蔽罩内面的辐射能力要强(涂黑)，外面光滑(不影响热敏器件)，通过热传导散热。

11.密封电子设备机壳内外有肋片，以增大对流和辐射面积。

12.不重复使用冷却空气；

13.为了提高主要发热元件的换热效率、可将元件装入与其外形相似的风道内。

14.抽鼓风冷却方式的选择„

15.风机的选择„

16.被散热器件与散热器之间充填导热膏(脂)，以减小接触热阻；

17.被散热器件与散热器之间要有良好的接触，接触表面光滑、平整，接触面粗糙度Ra≤6.3μm；

18.辐射是真空中传热的唯一方法，1确保热源具有高的辐射系数，如果处于嵌埋状态，利用金属传热器传至冷却装置上；2增加辐射黑度ε；3增加辐射面积s；4辐射体对于吸收体要有良好的视角，即角系数φ要大；5不希望吸收热量的零部件，壁光滑易于反射热。

19.机壳表面温度不高于环境温度10℃

20.液体冷却设计注意事项„

21.半导体致冷适用于„

22.变压器和电感器热设计检查项目„

23.减小强迫对流热阻的措施„

24.降低接触热阻的措施„

„„

布局：

1.元器件布局减小热阻的措施：

(2)元器件安装在最佳自然散热的位置上；

(2)元器件热流通道要短、横截面要大和通道中无绝热或隔热物；

(3)发热元件分散安装；

(4)元器件在印制板上竖立排放。

2.元器件排放减少热影响：

(1)有通风口的机箱内部，电路安装应服从空气流动方向：进风口→放大电路→逻辑电路→敏感电路→集成电路→小功率电阻电路→有发热元件电路→出风口，构成良好散热通道；

(2)发热元器件要在机箱上方，热敏感元器件在机箱下方，利用机箱金属壳体作散热装置。

3.合理布局准则：

(2)将发热量大的元件安装在条件好的地方，如靠近通风孔；

(2)将热敏元件安装在热源下面。零件安装方向横向面与风向平行，利于热对流。

(3)在自然对流中，热流通道尽可能短，横截面积应尽量大；

(4)冷却气流流速不大时，元件按叉排方式排列，提高气流紊流程度、增加散热效果；

(5)发热元件不安装在机壳上时，与机壳之间的距离应>35~40cm

4.冷却内部部件的空气进口须加过滤装置，且不必拆开机壳即可更换或清洗。

5.设计上避免器件工作热环境的稳定性，以减轻热循环与冲击而引起的温度应力变化。温度变化率不超过1℃/min，温度变化范围不超过20℃，此指标要求可根据产品不同由厂家自行调整。

6.元器件的冷却剂及冷却方法应与所选冷却系统及元件相适应，不会因此产生化学反应或电解腐蚀。

7.冷却系统的电功率一般为所需冷却热功率的3%一6%；

8.冷却时，气流中含有水分，温差过大，会产生凝露或附着，防止水份及其它污染物等导致电气短路、电气间隙减小或发生腐蚀。措施：1冷却前后温差不要过大；2温差过大会产生凝露的部位，水分不会造成堵塞或积水，如果有积水，积水部位的材料不会发生腐蚀；4对裸露的导电金属加热缩套管或其他遮挡绝缘措施；

„ „

上面对降耗、导热、布局的三类措施作了简要的罗列，在我们设计一个系统时，也要有一些系统的指标进行*价和作为设计目标，比如电子设备的进口空气与出口空气温差应<14℃、系统总功耗< ** W、系统用到的电源电压不超过**种(种类越多，变换就多，效率损失就多)„

第二篇：《做项目，不得不这么干》读后感（精选）

《做项目，不得不这么干》读后感

郇长武

《做项目，不得不这么干——从硬功夫到软实力》根据大量的实践经验，尤其是从失败中得到的经验教训，总结出在不确定和可变的项目管理过程中，造就卓有成效的项目经理所需的关键因素及技巧。

结合公司和事业部对项目里程碑达成率的要求，通过学以致用有关的经验教训，强化项目经理责任意识，全力以赴冲刺项目里程碑，按合同要求完成阶段性任务，进一步提高合同履约率，是期望通过阅读实现的目标。读书体会如下：

项目管理“没有近路”

唯有付出不懈的努力

本书没有宣扬大思想。因为大道理好讲，小事情难做。更多的是分析小案例、讲细节、讲实践，关键在落实、对行为的管理。项目问题错综复杂，都用一些常规方法来解决；走捷径的结果往往是原地打转，问题照旧。常见问题解决了，方法落实好了，再配以合适的绩效机制，业务成果自然就有了。“该出的汗总得出，改付出的总得付出。”现实中的最大童话莫过于相信不劳而获，最大悲剧就是相信有点石成金的捷径。

有人类的时候就有项目管理，需要着眼实干，注重解决实践中的常见问题。项目管理做的好无非是善于思考和总结提炼，在行为上更得力。如果忽略细节、忽视常识，那么注定没法建立一流的项目管理。

按套路开展项目，通过启动会议获取团队承诺

好结果来自对客户及其业务的理解，深入了解干系人及项目需求。需求管理问题对于项目的成果和潜在的失败有明确的影响，糟糕的需求管理成为项目最终失败的潜在因素。在改进需求过程上投入精力是一项划算的投入。人的需求一定存在某个“痛点”（Pain Point）令其不舒服，只有找到了痛点，才能明白其所有观点的真正由来。每个人都生活在自己世界中，站在自己的角度看问题。重视干系人（特别是客户）潜在或隐含的业务，是项目最终成功的关键因素之一。

现实中，痛点表现出来就是其最担心的方面，能否找到痛点（或者说看清其最担心的事）几乎决定了项目的成败。一个常见的例子是，项目的本质是业务问题，而技术背景出身的项目经理往往常将项目看作技术问题。寻找痛点的一个简单方法是关注对方的重复语言。需求调研的核心是澄清而非说服，识别需求后面的业务动机，获取真实需求，挖掘痛点并给出相应的解决方案是项目管理者不可回避的挑战。

当今世界正处于快速的变化中，越来越多的不确定性正在发生，社会的节奏现在越来越快，大家更倾向于“先干起来”的理念而忽略了仪式的重要性。一个好的项目启动会（开工会）有助于帮助项目团队的每个人在同一起跑线上、向着同一个目标前进。历史证明，很多项目失败的原因是因为他们不了解管理层对项目的期望。相反，如果我们团队成员时间，让大家彼此了解和与管理层建立良好的关系，当项目后期遇到困难（所有项目都会遇到）时，前期的工作效果就显现出来了。

团队主动沟通，做到有效沟通

一个项目的成功或者失败是与花在跟发起人和团队进行沟通的时间以及沟通的质量直接成比例的。德鲁克先生说“在沟通中最重要的事情就是听到没有说出来的话”.一个项目经理很重要的工作就是沟通，必须在正确的时间以正确的方式向正确的人沟通。“永远不要让发起人从别人那里得知你该给他的信息”,与发起人通常会有三种其他类型的沟通：突发事件沟通、非正式的沟通、正式的沟通。

项目经理是沟通的核心，做好项目的沟通计划是必需的，使用沟通矩阵核查沟通问题，选择合适的语言模式。管理干扰，降低工作被打断的高昂代价。创造和使用项目工具是项目组织优秀与否的本质区别，知识工具化、工具可视化是核心竞争力。同时，不解决问题的实质，仅依赖于工具是难以取得实效的。项目组每个成员需要时常提醒自己“沟通、沟通、再沟通”并天天反省。

管理和控制变更，避免进度游戏

唯一不变的是变化，频繁变更时项目管理的最大难点。每个项目都有诸多限制和制约因素——范围、质量、进度、预算、资源等，项目管理团队应对此加以关注。项目计划制订时，人们倾向于乐观，因为项目的不确定因素导致实际过程却是复杂的。必须面对的现实是，要素完备、可以完全按照理论来实施的项目几乎不存在。项目经理的价值就是在要素不完备的情况下寻求可行解。项目计划应注重实效，估算准确而非精确。“恰到好处的规划”随项目进展不断进行规划和重新规划——渐进明细、滚动式计划，认识“计划、计划、再计划”的重要性！

把握问题关键，提升项目团队绩效

人是最宝贵的资源，又是最靠不住的资源。激励不能使团队的智商提高到120,但是，不进行有效的激励，团队的智商可能会变得比62还要低。激励技术人员是令管理者头痛的事，重视跨项目团队协作存在的问题。提高项目团队的执行力，管理并化解文化冲突，让员工深信工作的价值，管理者需要发挥导向作用。及时表扬、真诚激励，让员工参与项目管理，帮助员工成功、拓展晋升途径。

激励是比惩罚更有效的措施，让员工获得激励，培养和保护员工的成就感。好的激励应该建立在公正和公平的考核与评价体系基础上，而且考核与评价体系本身也是影响成本的重要因素。项目奖金从哪里来？项目奖金从减少项目的浪费中来，这样不仅不会增加成本，还会增加效益。体系合理，项目成本就能很好地控制，从而大大节约成本开支。那些考核与评价体系不合理的公司，无一例外地发生了项目成本大量浪费地现象。

提升能力、管理自己、影响他人

干系人管理最体现项目管理者的水平，管理发起人和客户并远离是非，加强自我修炼。项目成功需要称职的职能部门，让干系人为项目“付出”.项目经理需要获得各部门对项目投入的承诺，避免混乱，有效项目治理和知识管理是保证，做知行合一的项目管理者。项目经理需要提升能力，让自己真正在“领导”,并做好压力情绪管控。

切实总结是提升项目管理水平的正路，将项目经验教训传授给后来者。对于事业部现在的项目里程碑达成率情况，加强项目阶段性工作检查和经验教训总结是可以立即见效的一步。

第三篇：《做项目，不得不这么干》读后感（fwsir推荐）

《做项目，不得不这么干》读后感1000字

李竹华

沟通，是讲话，是相互的讲话，也就是交流。做好沟通需要具有主观能动性，具有一定的沟通技巧。

《PMBOK指南》将沟通管理作为一个专门知识领域，其认为项目经理应该花75%以上的时间用在沟通上，由此可见沟通在项目管理中的地位。

其实从现实情况来看，沟通的地位貌似显得比专业的技术更为重要。分析当前软件项目开发、实施和运维过程中产生的问题，其中绝大部分属于沟通存在问题造成的，几种典型的症状包括：需求不明确造成开发成果走样；一个问题多次交互、反复确认才能得以解决；现场实施发现系统缺陷、开发人员不认可，相互推诿等等，这些问题分析到最后，其根本原因往往是相互之间没有沟通清楚，从而造成如此状况。

那么在项目管理的过程中，怎么做好沟通管理？首先，增强员工沟通的意愿，强化主管能动性，这一点可能是最难的。

作为软件企业的员工，我们的同事普遍不善于沟通，应该说是不喜欢沟通。每个人习惯于沉浸在自己的技术世界里，去钻研、去想象、去猜测，而不愿意去分享、去表达、去交流。很多时候我们都认为这跟每个人的性格有关，但可能更大的原因是我们没有营造一个良好的、表达自我的氛围。当一个人长期处于一种压抑交流的环境中时，积极的心态就会受到影响。这种良好氛围的营造，需要考虑多方面，比如：提供便于交流的办公场所、鼓励发表个人言论的有效形式（会议、演讲）等等。记得有篇文章曾经说过，办公室里面普遍存在的独立的卡座或隔间，可能是限制人员友好交流的障碍，或许可以考虑优先进行改变。同时，交流需要好的心态，尤其是项目经理，必须懂得倾听团队成员的声音。在项目建设过程中，我们应该创造一个良好的交流环境，一个好的交流环境可以激发人的思维，一个差的交流环境会抑止交流的欲望。而在沟通环境中，项目经理的心态是比较重要的。

其次，沟通需要一定的规划和有效的方式。我们在做项目的过程中，通常会有制定项目实施计划的习惯，但尚未形成制定沟通计划的习惯，沟通往往在项目的开展过程中随机进行。按照书中所讲，除了普通的聊天，项目过程中通常有三种类型的沟通：正式沟通、非正式沟通、突发事件沟通。不同类型的沟通对应不同的内容和形式，为了达到好的沟通效果，在一个项目中往往需要相互结合。而由于我们开展沟通的随机性，实际的沟通类型往往都是突发性质的沟通，这种沟通在缺少规划的情况下，容易缺少沟通准备，只是把问题简单的抛出来给其他人，从而陷入沟通障碍。

有些项目可能涉及许多团队和大量的干系人。当业务范围较广泛时，确保业务团队、项目团队、管理团队的信息准确性、一致性和及时性，是成功的关键因素。书中对项目沟通规划列举了20项关键事项，每一项在项目进展过程中，项目经理都需要不断的审查有效性，使用沟通矩阵，及时处理沟通计划存在的执行问题。这些工作是我们在做项目管理中缺失的，值得借鉴推广。

第四篇：做项目，不得不这么干读后感

做项目，不得不这么干读后感

读完一本书以后，相信大家都积累了属于自己的读书感悟，是时候静下心来好好写写读后感了。但是读后感有什么要求呢？下面是小编收集整理的做项目，不得不这么干读后感，仅供参考，大家一起来看看吧。

人是宝贵的资源，又是最靠不住的资源。对研发人员来说，这个话还该加上一段：人是最难伺候的资源。

一、激励研发人员是核心

“外行领导内行”备受国人批评，但对项目导向型组织来说这种情况却难以避免——没有人能把多个专业都变成内行，而项目又常是跨专业的复杂工作！事实上，无论项目经理是否具有专业背景，项目中总有一些技术问题他们不明白。在专业技术人员心中，在技术方面是外行的管理者仍然是他们从心理上、潜意识中不愿意接受的。

研发人员挖起“坑”来，恐怕真够老总们难过的。研发项目存在大量的不确定性，在这些外行的管理者面前，技术专家们可以随意拿出几个技术问题（甚至技术术语）说事，估计这些“老外”们只能干着急。

“创新嘛，总有很多不确定性，计划不如变化！”

“牛顿能够预知他何时能够发现万有引力吗？”

“爱迪生能事先知道何时能够发明灯泡吗？”

“技术问题”成了研发人员的免死牌。如果老板本身就是技术高手，这些问题可能少一些，但企业也可能面临更大的问题。

“技术问题”就成了项目中常见的挡箭神器，其效力之大、使用面之广令人叹为观止！

二、只有情怀是会饿死人的

由于商业环境的快速变化，企业的寿命越来越短，猝死率越来越高，企业难以向研发人员提供职业安全的保障。

十年来，柯达、诺基亚、黑莓、夏普、松下、LG、悍马等明星企业等纷纷衰落，而Google、三星等企业则迅速崛起。“江山代有才人出，各领风骚数百年”的场景已改为"商场代有人才出，各领风骚能几年？乔布斯尸骨未寒，苹果公司的iPhone6S就不再风光。面对挑战，苹果又能支撑几年？

获得研发人才对企业的忠诚度越来越难，而高薪是吸引人才流向的一个主要因素。

在工资总额没有较大增长的情况下，企业可以调整薪酬结构，即调整固定部分与浮动部分的比例来激励研发人员。可以适当增加固定收入的比例，月度收入不与考核挂钩，使研发人员的当期收入与行业水平保持一致，以满足研发人员注重当期收人比较的心理。

在研发人员的薪酬结构中，固定收入和浮动收人的比例表明了风险由谁承担。固定收入占总收入的比例越高，说明风险由企业承担的额度越大，反之则说明风险由研发人员个人承担的额度越大。

三、未来有良好的预期是关键

卡内基-梅隆大学软件工程研究所的调查表明，有75%的项目组处于混乱级，其重要原因在于管理人员不注意去建立好的流程。尽管大多数软件人员不是流程的拥护者，但在有明确流程的团队中，有60%研发人员的'士气极佳或良好，而在没有明确流程的团队中，这个比例只有20%。

如果不了解企业的运作体系，会误认为改善人们的积极性、改善人们的敬业精神就等于改善他们的业绩。事实上，企业运作的系统及系统与人的互动，可能占绩效的90%或95%。

总之，人员的管理是公司目前的核心也是难点，口头上需要人才，行动上把把人当民工，才是公司需要警惕的事情。

第五篇：《做项目，不得不这么干》读后感1500字

《做项目，不得不这么干》读后感1500字

徐煜

按照事业部的要求，抽时间阅读了郭致星的《做项目，不得不这么干》一书。虽然大道理都是CMMI、项目管理所必须的，但书中有很多活生生的案例，能给我们更多的启发。本书从实用出发，系统介绍了项目管理中的难题和建议的处理方法，根据大量的实践经验，尤其是从失败中得到的经验教训，总结出现不确定和可变的项目管理过程中，造就卓有成效的项目经理所需的关键因素及技巧，是一本实践性和指导性都很强的项目管理工具书。我们的项目管理者真应该静下新来仔细体会，并选择合适的内容在项目管理中进行实践，逐步提高项目管控能力。

“在沟通中最重要的事情就是听到没有说出来的话--彼得德鲁克”;

“分析痛点，也就是表现出来的最担心的方面，重复的就是痛点”;

这些都是项目管理的重要过程—需求获取时的真知灼见。我们都提到要打开客户的需求，但要真正做到谈何容易。需求获取准确性的问题，需要理解客户的需求，弄清需求背后的真实业务，重视干系人潜在或者隐含的需求，是项目最终成功的关键因素之一。书中提到的一个观点：“避免出现选择性知觉，获取真实需求，挖掘痛点”感觉在需求过程中尤其重要。可能我们是某个领域的专家，但客户的真实意图并一定跟我们潜意识理解的一致，因此“需求调研的核心是澄清而不是说服”就显得尤其重要了。

书中提到：研发包括研究和开发两种不同的活动：前者指对新技术、新工艺、新方法的研究，后者是对新产品、新服务等的开发；前者主要是创造性活动；后者是研究成果的集成性、应用性活动。没有研究，企业就没有未来的竞争力，没有开发，企业就难以生存。研发项目的根本是“开发”,没有开发出产品的研发项目就是失败的项目，因此研发的项目要以市场为导向，能尽快地应用到实际开发项目中，为企业创造价值。仔细回想一下我们的平台研发项目，贴近需求并保证适当的前瞻性才是重要的，我们推出的产品与技术是为兄弟部门服务的，也就是要切实解决他们的“痛点”问题，只有这样的开发技术和工具才能够得到迅速的推广并在使用过程中不断完善。前瞻性是我们技术研发人员必须具备的技能，并不是推动平台研发的必要条件，因此平台项目在进行研发时，需要贴近开发需求，瞄准项目开发过程中的痛点，在开发效率与可测试性等方面持续提升。

“高素质复合型人才”是难以自拔的陷阱，当项目的执行效率不那么令人满意时。“员工素质不高”是管理者常挂在口头的词汇，实际上，过渡依赖高素质复合型人才会是组织忽视积累属于组织的知识和技能，反过来又会使企业更加依赖这些高素质的复合型人员。当企业没有属于自己的核心知识和技能时，“缺乏高素质人才”是我们最好也是最没用的借口。

尽管大量的统计结果表明，项目失败的原因大多来自组织、管理方面，单纯由于技术原因造成的项目失败的比例很低，但是在大量的项目实施过程中，技术问题却是大家最常用以说明问题的理由，因此“技术问题”成为了档箭神器，当然参与的技术人员也自然地背起了黑锅。书中提到的这些真是说出了开发人员的心声，於我心有戚戚焉。

读完这本书，心中不禁产生一个疑问：书中讲的内容我们在CMMI规程规范中都能找到相关的影子，为什么实际项目在执行中总有这样那样的问题呢？回顾一下我们公司的CMMI研发管理的过程文件，从最初的生命周期模型选择、项目立项过程中的过程裁剪、项目计划、需求获取与需求开发、设计有敏捷开发、测试与发布、直到项目实施过程，都有比较详细的指导方法，是这些内容和措施水土不服？估计有这方面的原因，更多的原因则是意识形态上的问题，认为过程管理是一个付出远大于收益的过程，除了一些大项目，在项目过程中发挥不了多大的作用。另外缺少必要的项目总结和经验积累、并根据经验教训不断完善过程文件，使之运行更加高效。

再分析一下部门的研发项目，项目经理更多是技术层面的领导者，在项目立项目标确立、项目评审和计划实施中并不尽科学和严格，另外开发内容也没有贴近公司或者事业部的痛点，开发人员费大力气做出的产品在技术上虽然有竞争力，但由于很难在公司内推广，造成一定的技术浪费，同时开发人员也没有获得应有的成就感，必然会产生一定程度的挫败感。我们的研发经理需要多掌握项目管理知识，理论联系实际，分析自己的短板，明确团队和项目的目标，认真审视和对待项目计划，使得研发工作更加科学和高效。