软件开发中的3P和1A

    这是过往的开发、管理经验和本次开发pspl和sea的经历的一个总结。
本次总结围绕开发管理进行，包括4个方面：项目project；过程process；产品product；架构architecture；
所以本次总结的名字就叫软件开发中的3P和1A。
    提纲大概如下：
    一.过往经历过的开发管理中的3P关系
       从project起步，总结出process，升华出product，还没抽象出architecture。

    二.这次开发采用的开发管理中的3P和1A的关系
       规划出architecture，开发出product，总结出process，推广到project

    三.process总结

    四.architecture总结

一.过往经历过的开发管理中的3P关系
       以前国内很多公司，都是接了单，然后再成立的，我所经历过的几家公司，也是这种情况。
   所以公司的工作可以分为两部分：打单；做项目。工作从打单开始，到验收结束，周而复始，再无其他。
   这是大家只有一个概念：project。
       慢慢地，公司规模大了，项目也多了，却发现有的项目做得好，有的项目做的乱七八糟的。
   怎么解决这个问题呢？这时候管理就提上议程，我们需要加强管理，上ISO9000、CMM。
   ISO9000说的是流程标准化，CMM说的是过程能力成熟度。然后成立QA、SEPG之类的机构来组织总结process。
       随着市场竞争越来越激烈，客户越来越成熟，在新的市场领域，以往仅凭关系+PowerPoint拿到单再来现做的好日子也慢慢过去了。
   客户对着不同的现成品挑三拣四，所以，需要研发部门开发出新的product，给销售去打单，给工程部门实施。
   product成为衔接市场、研发、销售、工程的一个纽带。
       而在旧的市场领域，随着项目的增多，出现了非常混乱的版本关系，并且由此带来很多问题。
   最典型的问题就是版本A因为具有典型性，成为基准版本，被后续项目广为使用，在B项目中实施，解决了某些bug，成为版本B，
   而在C项目中，且还包含着这些bug，而版本C又被继承，从而呈现出一种复杂的bug传播现象，所有人都在痛苦地与之搏斗。
   定义、维护基准版本成为一个重要的工作。
       这样，product慢慢浮现出来，作为大家开始关注的一个对象，可是如何解决，还在摸索之中。
   产品线和产品组是一个试验方向。
       而说到architecture，则还没有概念，仅仅有些萌芽，如总结技术平台。
       从project到process，再到product，这是一个非常自然的过程，是一个摸着石头过河，发现问题、解决问题的过程，
   是承担着巨大的生存压力的公司的一个较优的选择，也是公司对软件开发认识逐步深刻的体现。但是，这样一个过程，也需要为转变
   付出相当多的代价，背负相当多的历史债务。
   （待续）