軟體開發中的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，這是一個非常自然的過程，是一個摸著石頭過河，發現問題、解決問題的過程，
   是承擔著巨大的生存壓力的公司的一個較優的選擇，也是公司對軟體開發認識逐步深刻的體現。但是，這樣一個過程，也需要為轉變
   付出相當多的代價，背負相當多的曆史債務。
   （待續）