生产不每年获得这8个方面的生产指导后可进行产品生产。
（上述这段不知是否需要详细解释一下？）

研发部门应该着眼于中长期目标，开发符合明天市场的产品，应该尽量减少来自外部的影响，但也应该紧密关注市场、技术，在每个Milestone的时候看看是否有新的市场或者技术发生重大变化。
需求变更是研发过程最容易发生的问题，最容易挫伤研发人员的事情：
“昨天说好了需求是这样，今天又变了，是咋回事嘛？就不能让我好好的做一会？我CNM的烂ass!”
我个人觉得应该这样看待这个问题：
1.产品开发周期一般都比较长（1～2年）
2.在这个阶段市场和技术一定会发生变化的。
3.
（先写到这里。。。待续）

----4. 维护现有客户产品（Installed Base Mainteniance）（不包括service）----
但现实情况是，在产品销售的过程中，必然有客户新功能的诉求，尤其是大的客户，老的客户。而对于这些客户，其一是公司的样本工程（Show site），对公司的声誉和品牌有较大的影响；其二大客户和老客户会是需求的主要来源，因为这些客户熟悉公司的产品，有实际的使用经验，他们提出的需求一定会是有价值的。
针对现有用户，我们需要建立一支突击队、一些尖兵，根据用户的需求进行快速开发，暂时满足用户的新功能/要求的基本需求，提高客户满意度，同时也是让一些新的功能在这些用户那里磨合使用。

当这些新需求在老客户或者大客户那里运行一段时间后，如果觉得是一个好的功能，也是未来其他客户的需求，再将其融合会到产品中，即将这部分需求完全整合到产品中，形成新的产品基线（版本），然后正是release，并且为老用户进行升级。

对于软件来说，至于升级是否能成功，其实是比较难得。因为在新的版本出来之前，大客户那里的老版本也具备这样的功能，而且可能不一样，此时用新版本升级是存在比较大的问题。。。。
（暂时写到这里。。。。待续）

但是现实总是残酷的，情景2是最经常发生的：版本的控制其实就是防止时空错乱的控制。
作为神，你该怎么做：
将不一样的找出来，让两件事情一样。
于是，你将第一件事情的不同找出来，在最早版本的基础上升级到新产品线，然后再把第一件事情不同的地方融入到新产品线。。。。
这个逻辑是不是有一点复杂？
没错，为了确保老用户、大用户的满意度，你最后这样做。
因为这些用户是你的根据地，是你的reputation，是你的宣传队、播种机、是。。。。
反正你得维护。。。