作者的观点是技术和技术管理，是两个不同的领域，需要区别对待。

技术：

源代码，测试，文档，最终产品等等，这些都是技术所包含的内容。对作者来说，这是个相对狭窄的概念。

技术管理：

监控为特定用户的需要而设计软件产品或者信息系统的过程。注意，是监控过程，并不是技术活动本身。这其中也包含参与技术活动的人的交流活动的管理问题。

而从商业的角度来看，技术管理的目的，就是使得从设计到分发的整个过程的成本小于最终产品或服务的收入。看起来很简单，废话一样。但这个是最困难的。软件公司和其他的公司是一样的，是为了获得利润，如果成本过高，技术再好，也是个失败的公司。

作者提供了几个经典的例子，同样作为整本书中作者得出结论的几个例证：

  • IBM OS/360. 庞大的项目。最终形成了很好的结构化过程。SEI传播了这个项目所获得经验。
  • 70，80年代，日本人开创了软件工厂的概念，来接决IBM OS/360这种大型系统开发所遇到的困难。
  • 微软在90年代开始使用的“同步和稳定”的方法。这个是作者最为推崇的方法。

对于创业的公司，通常能够很容易的开发出小型的原型系统。但是，当这个公司开始开发真正的面对市场的系统时，项目或者产品的复杂性会大大超出公司的管理能力。或者另外一种情况，公司的产品属于开创性的，市场的开发和销售是非常困难的，远远超出的公司的资源和能力。这个时候，正如Chris Peters所说，决定不做什么和决定做什么同样重要。

我想作者这个观点非常值得我们思考。这里面提到的问题我们都有所了解，但是作者看问题的角度值得我们借鉴。首先，作者将技术的管理从技术中分开。明确了技术管理的重要性和重要地位。其次，作者所谓的技术管理，并不是软件工程的范畴。更多的是商业相关的领域的概念。

我想很多村里面创业的公司，都是在一定的技术原型基础上，或者是市场前景的预测下开始创业的。那么，创业的团队对这里面所谓的技术管理有没有清晰的认识呢？对这个问题，团队的整体认识程度和协调能力，是衡量创业团队的重要标准。创业的公司，随时可能遇到爆发的机遇，例如能够开始一个很有前途的但是很复杂的产品的开发，或者签下一个大单。如果这个机遇超过了团队的资源和技术潜力，那怎么办呢？不做，很浪费，很痛苦。做，有可能前功尽弃。但是重要的是，团队能够就这一问题有理智的思考。决定并不重要，重要的是团队面对这种情况下的反应和形成决定的过程。