對于一個軟件公司而言，在做項目或產品的過程中，為何要應用一定的技術框架呢？相信有一定規模一定歷史積淀的軟件公司里，都存在著自己特有的技術框架，我們應用框架開發無外乎是本著提高代碼的重用性、降低開發應用模塊的技術難度，增強軟件的維護性，進爾達到提高工作效率、降低生產成本的目的。這也是技術框架存在的根本和意義所在。

本人是個對技術的推崇者或者說是有些圖騰崇拜的人，從學習和使用 java 的第一天開始，就對這種純粹的面向對象的編程語言產生了濃厚的興趣，從早期秉燭夜讀《 java 編程思想》、《 java 核心技術卷 I 、卷 II 》到《 J2EE 設計與模式》。。。《深入淺出 Hibernate 》。。?！?/span> Spring in Action 》等，切身感受到當今主流 java 應用技術的發展，也很感謝前輩們為大家開創了應用技術之先河，為我輩指明了發展的方向和前進的道路。

在當今技術潮流日新月異的時代各種各樣的技術框架林林總總，很難去評價個中孰優孰劣，個人覺得在項目開發過程中最適合的框架就是最好的，以項目的規模和特點來決定對技術框架的選型。現就個人對于框架的開發的一些體會和大家一起交流一下，前端采用類 Struts 模式做 MVC, 我覺得 MVC 的精華所在就在于請求的匯集和請求的分發，采用 filter+mainservlet 的方式，在 filter 類中可以進行對各種請求的約束和限制處理，同時可以進行對請求合法性的判定和校驗，也可以實現達到負載均衡的處理，也可以根據實際的項目需要設置多個 filter 類進行分類過濾。通過 filter 類的合法的請求全部由統一的 mainservlet 主控器接口進行分發處理，在這里可以添加對線程的約束和控制，以保證所有請求可以順利的分發。業務邏輯層采用 Action+BPO 的模式， Action 作為動作的描述， BPO 作為對于動作進行響應的業務邏輯處理。持久層部分采用 Hibernate 和 DAO+VO 兩種模式并存的方式，持久層部分之所以采用兩種模式處理，主要是考慮到業務邏輯的復雜度，對于多表及連和復雜的業務查詢處理，感覺配置 Hibernate 文件也相當的復雜（也許是本人應用 Hibernate 的深度還不夠，對 HQL 語言的認識還比較膚淺），因而還采取傳統的 jdbc 訪問模式來處理。事務處理用 Spring 框架來進行處理。在表示層的 jsp 中只進行 tag 的屬性設置和 java 的表達式的輸出，所有的 java 邏輯代碼全部用 tag 來進行封裝。有興趣的朋友可以發 e-mail 給我，來進行此框架的交流 E-mail:syangsheep@163.com, 同時也歡迎大家拿出自己應用的框架來一起進行交流和探討。

本人經歷過小到 3-4 人，大到 140 人以上的項目開發，現就個人做 PM 的一些經驗和體會與大家一起交流和探討。個人認為做為 PM 應具備如下幾個性格特點：自信、執著、果敢、細心、公正、迭代。一、自信：自信源于實踐經驗積累的寶貴財富，在一個項目進行過程中，各種各樣的問題和不可預知的困難將貫穿項目始終，身為三軍統帥的 PM 如果自己都沒有信心把項目做好，那嗎項目的最終結果也就可想而知了。二、執著：不能輕易放過任何暴露出來的問題點，這里不單指技術層面的，包含各種可利用的資源。失敗的項目或者說垃圾的項目不是一下子就被定性的，它是由于在一個個的問題點上處理不當積累起來的，最終導致項目失敗的惡果。三、果敢：當項目處在某個關鍵的三岔路口時，應該做出及時準確的方向判斷，切忌優柔寡斷，這是需要相當的勇氣的，也是敢于承擔責任的一種氣魄。四、細心：當項目達到一定規模的時候，由于精力有限，不可能細化到每個人每個點，肯定會出現管理的盲區，這樣不但需要劃分好層次、層層監督，同時也需要對個別點進行抽查抽測，不能親歷親為只靠一些小范圍的會議交流總結，往往不能準確的定位到問題的關鍵點上。五、公正：不管在什嗎樣規模的開發團隊里，維系團隊精神、使團隊更加具有凝聚力最根本的原則就是做事公正，很難想象一個人心渙散、充滿怨言的團隊能夠做出高品質的產品。六、迭代：我在這里所說的迭代不單單指程序代碼的迭代，它是一個 PM 在項目進行過程中不斷總結經驗教訓不斷完善的一種迭代。只有勇于批評和自我批評的人才能夠不斷的完善自己，不斷的進步，成為一名合格的項目經理。

??? 小結：上述是我就本人在擔任PM過程中的一些心得和體會，至于具體的運作模式則是仁者見仁、智者見智了，在此不再贅述了，歡迎大家一起來交流和探討。

這里定義的項目經理是狹義的，單指軟件項目經理。既然說到軟件行業的項目經理，當然就不得不說一下軟件行業，個人認為當今的軟件行業公司大體可以分為三類：一流軟件公司開發標準如 Sun 公司、微軟等（開發當今主流的語言如 java 、 C# ）；二流軟件公司在遵循標準的前提下開發規范、定制流程如 IBM 、 BEA 等（開發各種中間件，定制業內遵守的流程規范）；三流軟件公司在遵循標準、依托規范的前提下做應用，如。。。（太多了不贅述了）。當然我的這種劃分單指就軟件領域而言，并不代表公司的綜合實力及財富排名的位置。（大家不要用雞蛋扔我哦，要扔就用人民幣吧，嘿嘿）

下面進入正題，談談我對項目經理（ Project Manager 以下簡稱 PM ）的認識和看法。本人在軟件行業摸爬滾打了 6 年，在 PM 的位置上茍活了 2 年，記得有位國外的軟件大師（名字記不得了）曾經說過：“沒有寫過 10 年程序的人就不要說自己是一名程序員?！蔽液?，勉強只能算半個程序員了。咦，咋又跑題了呢，不好意思哦。個人認為， PM 大體可以分為三類：一、即懂技術又懂管理的 PM ；二、不懂技術懂管理的 PM ；三、懂技術不懂管理的 PM 。第一種我相信是任何軟件公司都渴望的，也是比較難求的人才，當然也是本人最為推崇的。它對于一個人的綜合素質要求比較高，要有縝密的邏輯思維，準確的判斷力、果敢的決策力，卓識的大局觀，對編程的濃厚興趣等等。它應該是多種職業的綜合體：軟件架構師、軟件工程師、測試工程師、風險評估師、會計師、律師、理財師、人力資源師、培訓師、翻譯、心理咨詢師等集大成者，我認為可以定義為刷子型人才（多專多能，哇噻，公司豈不是賺大了）。第二種我相信也是在相當規模的軟件公司普遍存在的，往往公司的意圖和出發點很好，希望 PM 專管協調組織，控制項目整體進度，不做具體事情，殊不知一個不懂技術的人談何控制項目進度，在我供職的公司里曾經發生過這樣一件真實的事情，測試人員提交的 bug 單， PM 整理后分發給具體負責的開發人員，一個開發人員在對一個 button 屬性的修改的工時描述單上注明需要半天的時間修改， PM 不加任何思索的回饋給測試人員，引為笑談。項目經理對承擔項目個體職責如果不夠了解，將很難控制項目進度，很難把握項目進展過程中的瓶頸，很難就項目進展過程中出現的問題做出準確地判斷并制定出合理的解決方案。第三種我覺得更準確地應該定義為主管開發的 PM 比較合適，這樣的人普遍是編程高手，可以解決技術問題，攻克技術難關，但由于個人思維的局限性難以對項目整體進行把控，協調好各個環節的資源，這樣的可以成為不錯的將才，但難以成為帥才。（待續）