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

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

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

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

关于目标，已经做了简单描述，班子如何搭，还是要看目标是如何定。针对不同的目标，班子的架构是不同的。
举个例子，如果研发部门的任务只是正对大客户进行定制和开发，产品研发部门（小组），就没有必要存在，因为针对不同的大客户都是按照项目的方式进行，各个用户的需求差异性是比较大的，虽然可能在某些技术和模块上可以复用和借鉴，但是更多的部分是不一样的。
此时应该根据项目的目标构建队伍，PMO Office将占有绝对的重要地位。如果是按照产品来开发，则PMO Office的地位可能会消弱。
总的来说，最主要的是你要干什么，目标是什么，目标不同，组织结构则不同。