二、产品与工艺
1 产品和工艺的区别
分清产品和工艺有助于对技术的理解。产品是就用户角度而言的，工艺是就生产的角度而言的。
以blog为例，一个blog平台，它是一个产品。而这个blog平台是怎么实现的，用什么语言实现的，后台是什么数据库，它属于工艺的选择。
产品和工艺的关系是做什么和怎么做的关系。
产品有产品的特征：
（1）功能：这个产品能做哪些事情？比如，blog和wiki的功能不一样；一个道具收费型游戏和一个时间收费型游戏它们实现的功能不一样。
（2）性能：试衣网的3D试衣环境 http://3d.41go.cn/ 试试就会有很深的感觉。
（3）价格。
（4）用户的使用方式，包括：
·接入渠道：比如，远程家庭视频监控系统，一个人出差在外，可以有哪些接入方式呢？Web啊，手机啊，IM啊等等都是可选的。
·易用性：对有些人来说 windows比linux易用，对另外一些人而言相反，这个要看目标用户。
·兼容性：包括对现有东东的兼容性和对用户习惯的兼容性。
（5）产品的传播特征：
·可尝试性
·服务……
产品的发展有两个阶段：在产品不成熟时期，主要集中于核心功能、性能等因素，是存异求同的过程。在产品成熟阶段，则是其它可产生差异化的因素，是存同求异的过程。
工艺有工艺的特征：
（1）效率：更快的做事情：比如，引入一个成熟的框架可以加快速度。
（2）质量：更好地做事情：比如，一种成熟的过程管理技术可以保证质量。
（3）成本：更省的做事情：大多数时候引入一个成熟的框架可以降低成本，也有例外的时候，比如，这东东不是免费的，要收你一千万元。
（4）再加条柔性吧：更适应变化的世界
工艺的发展有几个趋势：自动化、模块化和流程改进。自动化可以极大的提高效率和降低成本。推进模块化可以在效率、质量、成本和柔性四方面受益。流程改进也可以提高效率、质量、成本和柔性，不过具有较大的风险。
2 产品创新和工艺创新
产品方面的创新为产品创新，工艺方面的创新为工艺创新。
几个成功的产品创新的例子：
·Google初推2G邮箱
·baidu贴吧
·Apple macmini
·史玉柱的《征途》
·java
失败的产品创新例子：
·Smalltalk
·摩托罗拉的铱星计划
产品创新也可以是局部的，如：
·RIA对用户体验的改进
·魔兽世界资料片中的竞技场系统和英雄副本
产品创新的优势：
·满足用户尚未能满足的需求，用户买账。
·先发优势，领先一步，优势很明显的。
·占领细分市场，比别的产品更能满足部分用户的需求。
工艺上的创新例子：
·敏捷软件开发过程（流程上的创新）
·PC的生产网络（20世纪最成功的模块化例子）
·OO
·TPS（丰田生产系统，这个在第五节细谈，这两年，有一些人在软件开发中推崇这个）
工艺上的创新失败例子：
·N多ERP实施失败的例子
工艺创新的优势：
·可以省钱
·可以省时间
·可以更快的推出产品
3 技术的共性
技术看起来五花八门，实质有很多的共通之处。
（1）例子：书籍和雨伞。
书籍和雨伞，这两个看起来貌似不相关的东西，实质上都是通过“折叠”这一方式（方法、模式），来解决不用时空间占用过大的矛盾。泛型编程是不是也是这个道理呢？
（2）例子：模块化。
以模块化为例，汽车行业零件的模块化，PC生产领域硬件规格的模块化和软件领域的模块化，都是有很多共通之处的。
模块化的好处：
·通过解耦，来克服不确定性。这一点，西蒙的描述最精彩。手表是由上百个零件构成的，装配一只手表可以有两种方式。第一种方式是:从最基本的零件开始，一个一个零件的装配。在这种方式下，假如你的工作被中途打断或打乱，你就必须从头开始来重新装配这只手表。还可以采用另一种方式：将手表的各种零件分成不同的子系统来装配，再将子系统合成完整的手表。这样，在某个子系统的装配过程中出现混乱，不会影响其它子系统，对单个子系统的修复，也可能比对整个大系统(手表)的修复要简单得多。
·便于合作。将系统划分为模块很方便分工和合作，你做一块，我做一块，他做一块，然后集成到一起。
·柔性和可定制性。模块多了，可组配的方式就很多，很方便组合定制。
OO是模块化技术的一种。OO技术准则其实就是模块化的那些准则穿个马甲。这方面的书籍太多了，不需要详谈。在这些准则之外，还有很多很重要，却很少有人归纳的方面。如：
·接口和技术规格的演化。这一点在设计接口或设计技术规格时非常重要。
·接口和技术规格的易用性问题。这一点那本《.Net什么什么规范》书中讲了一些。
·系统对模块的依赖程度问题。这个《敏捷软件开发》中讲了一些。假如某一模块在未来的一段时间内会失效，怎么办？
（3）例子：流程改进。
超市、生产汽车、敏捷开发过程，三件事情，风马牛不相及。
先看超市，顾客从货架上直接拿走商品，上货员观察货架哪里缺了多少就补上多少。
这里注意信息传递的过程，信息是从需求方传递到供给方。
传统的生产流程，信息是从供给方传递到需求方的：根据市场调查或过去经验或拍脑袋作出计划=>进原材料=>生产=>上市。
这种信息传递方式的缺点是：
·信息是滞后的。因为作出决策所依据的信息是过去的信息或经验。
·信息是不准确的。
可能导致的结果是：
·所生产的不是用户想要的；
·所生产的过多或过少；
·大量的库存。
软件开发，很多时候也是这样：所开发的不是客户想要的；开发出很多客户用不上的东东。
上世纪60年代，丰田的大野耐一受超市购物的启发，用了几十年时间弄了一套丰田生产系统（TPS）。TPS简单的说，就是：你买一辆车，我才生产一辆，没人买，那我生产线就不动。A工序从B工序拿一个零件，B工序则补上一个零件。通过这种方法，使需求信息准确、及时的传递到生产系统的各个地方。在网上订购过dell电脑的人估计有这种体会。
后来，老美发现小日本的汽车生产效率又高，质量又好，屁颠屁颠的跑去研究，把这种方法归纳为“精益思想”。最近几年，搞敏捷的那帮人也捧起了这个词。
仔细观察敏捷方法，它实质上也是尽量在做这件事情：
·把需求信息准确及时的传递到开发过程的各个环节
·创建一个一目了然的开发现场，让问题显现出来而不是掩盖问题
拿测试驱动开发来说，下面两点是不是很相似呢？
·XUnit里的红灯、绿灯可以让人对软件的质量一目了然
·丰田生产系统之中，生产线上的每一个员工都可以停止生产线，一台车、一个零件出现质量问题，就停止生产线。
掌握技术的共性，可以使我们对技术有更深入的理解。还以测试驱动来说，如果我们不将它理解为单纯的测试驱动，而当做一种一目了然的软件开发现场，就会有更深的体会。这时，就有个问题，红灯、绿灯它创造的现场对于运行这个测试的人来说是一目了然的，但对于别的人不是一目了然的。他们要观察这个现场，必需自己运行测试或阅读测试报告。
这时，可否通过悲伤的音乐或美妙的音乐来补充红绿灯呢？这样做有几个好处：
·这个开发现场是清晰的，活跃的
·这个现场对其他人来说是一目了然的
·对于里程碑事件，通过之后，可以通过独特的音乐来提示，激发士气。
掌握技术的共性，可以来鉴别技术。可以发现，许多技术都是马甲，我们需要的是穿破宣传的迷雾，去看看这些马甲的成色和材质，看看这个马甲能否对我们的产品或工艺有促进作用。
上面讨论的技术偏向于工艺技术，产品技术的共性比较难把握，这个前苏联的TRIZ理论（第四节）可以做一个参考吧。
4 对技术和趋势的讨论
下面讨论讨论新（？）技术和新趋势。纯属个人观点，受个人视野所限。
（1）影响产品的技术和趋势
·三网融合，可能会体现在：用户群的扩大；用户使用产品的方式改变；一些新的用途。
·网络通讯技术的发展（带宽的增加）和计算机能力的提高，可能体现在：多媒体和3D技术主流化，3D孤岛的互联互通，一些新兴的带宽/CPU杀手应用
·制造成本的增加和产业升级导致很多企业改变发展策略，会加大技术投入来提高生产力，这一块会催生一些机会。
（2）影响工艺的技术和趋势
·自动化和框架/模块化的发展，提高了开发效率，降低了开发成本。
·软件开发的工厂化和组装化趋势。
单纯学习技术，可能导致价值流失。比如，做了很多年一个东东，最后自己的工作却可以由软件自动实现，岂不悲哀。要是这软件是免费的，那就更悲哀了。
单纯学习技术，可能导致价值迷失，迷茫与眼花缭乱的新技术，对未来感到没底。什么网格啊，云计算啊，猫猫的什么东东啊。对于绝大部分人，绝大部分公司的产品和工艺都不会产生影响，看它，和浪费生命有什么区别？
什么样的技术值得关注呢？是那些可能（！）影响到我们（公司）的产品或工艺的技术。到底是哪些技术，这些技术有什么特征？要清楚了解非常的难。经常会看见这样的事情：A公司和B公司为敌，斗来斗去，最后蹦出个很小的野鸡公司把两个大公司给灭了。
第三节将用几张图来介绍技术、产品和市场的演化过程，以助于从产业的角度来看待技术，分析：为什么当年的野鸡公司可以灭了大公司，为什么当年的野鸡技术可以战胜优秀技术，现在有哪些野鸡技术值得关注？
话说ajax以前就是一只野鸡……还不算，只能算一只野鸡蛋。腾讯当年也只是一只小野鸡，当时若注册个几千个五位数、六位数的QQ号，没事晒晒，也是很大的一笔财富啊。