構架淺析
李寶劍 libaojian@sina.com
從廣義方面來理解構架，在自然世界中到處都是。作為一個好的構架概念最終會形成模式。這里筆者僅從軟件工程的領域將自己的一些淺薄認識進行分析整理，以求獲取通用的可控制其風險的構架模式。
從靜態視角分析，構架涉及了公司，部門，團隊，涉眾等。從動態視角分析，構架涉及了產品創造過程以及圍繞此過程發生的各種事件。從軟件技術的視角分析，構架涉及了需求，設計，程序，用例等。不同視角看到不同的構架，這些構架彼此相互聯系，相互制約。
對于一個構架的組成，我暫稱其為元素，元素會有關系，關系包括了控制，協作，支持等。
從以上分析，你的頭腦里應該會有一個模糊的構架view展現。
我們的目標是借助諸多構架支持完成某些構架的實現，在這個過程中，會發生一些阻礙事情進展的情況。那好，事情就變的有目的了，我們的目的就是解決這些阻礙，對癥下藥，盡大可能的解決這些問題，權衡利弊，使最終的利益最大化。
構架可抽取，可形成模式，而具體到一個項目構架模式就變成了構架實例，有了動作動態這個元素來打破了構架的一些常規。作為項目的控制者需要合理的處理和控制常規的可預見的風險和突發的風險。在不同的場景中，構架中的元素所擔任的角色就不同，其屬性和行為也會動態的進行變化。例如你在公司構架下是一個員工，在部門構架下是一個設計師，在項目構架中是一個設計組長，在涉眾中是一名設計人員，在過程中是一名團隊成員，在需求構架中是一個需求的翻譯者，在設計構架中你就是大師，等等。
分析抽取了初始的構架模型如下
下面我將根據初始的構架模型，進行具體的項目分析。我將從目前的項目進行此項目架構以及支持和約束此項目架構的其他架構的分析，找出僅可能多的問題和解決方案，形成一定的模式，避免重蹈覆轍。
項目背景
公司近期在電子政務方面，會面臨大量的政務信息的交互。 在此背景下，開發代號為ABC的數據交換平臺。因為某研究所已經有若干成熟的設計，將和此研究所合作進行開發。公司派3，4人進駐研究所， 同研究所的研究生團隊組成新的團隊，共同開發。
構架列表
n 公司構架（公司領導 政務部門領導 開發領導）
n 團隊構架（公司監督 項目指導 項目管理 技術管理 公司員工 研究所學生）
n 研究所構架（導師 學生（博士研究生 碩士研究生））
n 涉眾構架（公司 研究所 用戶）
n 項目構架（高層用例構架 組成人員）
n 需求構架（用例架構）
n 設計構架（系統架構）
n 實現構架（類架構）
n 過程構架（周期，里程碑）
n 技術構架
總體構架關系
下面一排都是外部約束和支持項目構架的若干構架。上面一排是項目過程中內部所要協調的構架。下面就支持架構的目標和責任以及未能達到目標的狀況進行分析。
公司構架
公司對于此項目的責任應該是約束，監督，支持。從目前的狀況來看，項目組所感受的的只是約束和監督，未能明顯的感覺支持。對于監督的力度不夠也就是過程的監督僅停留于常規的周報等紙面內容，掩蓋了事實的真相。
問題
就是監督不力，不予支持。結果是上下信息不暢，項目進展困難。這種嚴重的等級信息傳遞，造成了鏈條式的信息溝通，因為某一個環節的缺失，就會造成監督盲區和支持盲區。
參考模式
解決方案
從公司對于此項目的構架組成包括了五級，董事長，副總，政務部總，政務部開發負責，政務部項目監督員。那問題顯然出在政務部總和政務部開發負責這個點（元素）上。解決問題將從此深入。借用我黨常用的什么下鄉活動的策略，并且支持鼓勵員工的合理建議，廣開言論。
研究所構架
研究所的目的不言而預，教學為主，培養學生目的很明顯。對于項目的進展做出了很大的努力，而問題也隨著進展暴露的越來越突出。優勢，人力多。
問題
1， 經驗不足
2， 流動性大
3， 責任心不足
4， 需花費培養成本
解決方案
傳 幫 帶 ，這就要求團隊組成的格局需要按照這種方式進行重新規劃。將比較優秀的團隊成員作為產品組的領軍。人才浪費也是一個缺憾，未能人盡其用。通過一段時間的觀察和磨合，仔細分析每個組員的特點，進行團隊合理的人員分配。真正的實現1＋1》3。
團隊構架
不管是從傳統的軟件過程來講還是從rup的項目管理過程分析。團隊的組成缺失很大，也很不科學。一句話：一哄而上。
問題
1. 項目管理者位置、職權不突出，沒有獨立的協調、組織、調配權力；
2. 團隊組成人員結構不合理，往往不能按照科學的職能需要配置項目開發人員；
3. 團隊中職能交錯混亂，管理模式不確定，存在嚴重的職能重疊浪費和缺失不齊的矛盾現象；
4. 團隊精神不明確，項目目標不一致。
解決方案
在公司構架的基礎上，明確項目管理者的地位和作用；按照類比或經驗的管理模式，組建所需要的研發人員團隊，明確團隊精神和唯一奮斗目標.。
涉眾構架
沒有用戶的參與。涉眾不完全。聽不到不同的意見（或者不同的意見僅局限于內部），會形成一葉障目。
問題
解決方案
作好充分的項目前期調研，廣泛收集用戶（或業主）信息，建立項目用戶跟蹤回訪制度，最好由原軟件開發負責人牽頭。
需求構架
需求來源太狹小。
問題
導致產品規劃不太合理，盲目的靠近什么紅頭文件。連技術細節都盲目靠近。
解決方案
從其他的政務系統入手，結合其他的類似產品，進行產品規劃和需求獲取。
設計構架
概要設計階段因為產品族的規劃不到位，造成了某些概念不統一。詳細設計階段問題依舊，并且對于整體感未能有人把握。
問題
1. 設計目標不明確，設計范圍模糊，造成設計概念含混不清；
2. 設計階段劃分不清，設計深度很難把握。
3. 設計成果的校核、審查、確定系統不健全，沒有準確的把關人員。
解決方案
明確設計階段，提前作好設計溝通協調工作，給定項目設計內容，設立專人設計組，健全設計成果的審查把關系統。
技術構架
技術風險
問題
無總體感
解決方案
架構師，在那里。如果沒有合適人選，就要從團隊中培養。
實現構架
類結構比較合理，但是因為總體無人駕馭，可能造成百花齊放。
問題
許多公用類未盡其用，并且對于程序中效能都是沒有把握。
解決方案
代碼框架的確定和培訓。
過程構架
過程中的缺憾主要是周期和里程校驗，以及過程中的審查。
問題
不及時 力度不夠
解決方案
項目管理方面的資料很多，我這里就不羅索了。