软 件工程这个名词，背后的「工程学隐喻」，是错误的。我现在更愿意直接称之为「研发」—— R&D 。研究与开发纠缠在一起的研发管理，较之普通的工程管理、项目管理，复杂了千百倍，也因此异常困难。从传统项目管理、工程管理中生搬硬套过来的各种方法 论，往往对于研发管理利害参半。只有在对研发活动进行深入研究的基础上，分析研发活动的本质模型，才有可能接近「真相」，才有可能找到真正的规律与适合的 方法论。
过去常说的软件项目铁三角：Time（时间）、Scope（范围）、Cost（成本），应该进化为研发管理的铁三 角：Schedule（调度）、Requirement（需求）、Profit（利润）。区别在于：我们应该从企业级的角度，而非一个孤立无援的项目组的 角度，来分析研发行为。
- 可以将Schedule分解为：speed（速度）与control（控制），通过追求一个企业的研发效率，可以提升这两个方面的能力
- 可以将Requirement分解为：feature（特性）与quality（质量），通过追求一个企业的研发能力，可以提升这两个方面的能力
- 可以将Profit分解为：reuse（重用）与innovate（创新），通过追求一个企业的研发活力，可以提升这两个方面的能力
而所谓研发管理铁三角：并非简单的非此即彼的困难选择，而是在需要做出选择时，研发企业的取舍能力。
错误的研发实践，会因为片面追求某个目标，导致对其他目标的损害。简单举两个例子：过度追求创新，可能损害项目的调度控制能力。过度追求研发速度，可能会损害项目满足需求的能力。依此类推，以上的六个方面的错误追求，都会产生种种恶果，这也是研发铁三角的另一种表现形式。
从一个整体来考虑企业的研发管理，应该注重建立一个良性的循环：
- 研发能力的提升，有助于促进研发效率的改善
- 研发效率的提升，使得研发人员可以有更多的空余时间，进而激发更多的研发活力
- 研发活力的提升，研发人员积极的交流与分享，有助于提升研发人员的总体能力
过去的软件开发方法论，往往只是注重了研发管理中的一、两个方面，缺乏整体视角。而且期望以一套方法论包打天下。事实上，真实情况下的研发管理，需要至少三套方法论：
- 提升研发能力，主要依靠经验积累，建立企业内部的知识库与传承体系（促进交流与协作，借助研发活力促进研发能力提升，也很重要）
- 提升研发效率，主要依靠科学的数据分析，建立或引进一系列的研发工具，建立合理的流程与制度（通过提升研发人员能力，激发他们不断改进效率，也很重要）
- 提升研发活力，主要多种社会化的沟通机制，促进分享与交流（给研发人员松绑，让他们有足够的空余时间，也很重要）
研发企业应该建立的一个评估、改进、调整的大循环。评估：关键在于标准的建立，包括量化的标准与非量化的标准。改进：以符合标准的方式，不断改进。调整：再次评估改进的效果，并调整评估前制定的标准是否合理。
以上就是我的这篇大文章的核心观点，我将尽快把这篇文章完成，敬请期待。