工作多年，也有一些項目管理經驗，在此總結一些自己對於項目管理的看法。
開始階段
項目啓動的時候，個人認爲最重要的是要弄清楚項目的目標和項目的範圍，包括需求範圍和時間範圍。
通常，我最怕聽到領導說：“把這個工作做一下，需求大概是balabala”，“啥時要？”，“不知道，你先做着，儘快吧。”這種場景經常會出現，由於沒有明確的需求和時間約束，有時候就會無法分解工作包，導致無法安排人去做。
這種情況相信在大多數人身上都有發生，這時候只能根據個人的經驗從有限的需求說明中推算出大致的需求，還要估算一個合理的時間，因爲雖然領導沒指定具體的時間，但不意味着無限期的時間，總是得有個大概的範圍。
關於項目需求的收集，有時候急於心切想一下子獲取全部的需求，但是大多數情況下，這是難以做到的。因此我總是確定一些大的需求方向，通過滾動規劃，漸進明細的方針，逐步細化這些需求。使得需求的細節儘量在大方向之內。如果時間允許的話，可以先構造一個原型，通過原型能更好的把握項目的需求以及面臨的風險。
關於技術框架架構的選擇
通常情況，總是選擇成熟好用的框架作爲首選。事實上，我工作過的公司，都有自己的一套框架，大多項目都遵循這套框架，這些框架都經受了生產環境的考驗，因此所面臨的風險是最小的。有時候，會覺得這個框架真土，或者太爛，而花太多的時間在修改框架上，但是這在我看來不是最重要的。框架的目的是把程序員拉到流水線上，提高生產力，越複雜的框架對性能的影響也越大，理論上說，不使用框架的代碼性能最好，但是可讀性差，不易於管理，因此不得不使用一個良好的框架來組織代碼。
舉個例子，本人曾經歷過的一個項目，覺得是過度設計了框架，有點爲設計而設計的味道，框架設計者爲了實現解耦，將系統拆分的極度鬆散，以至於調用某些類庫的時候還得依靠反射等方式，而爲了完成一個功能業務，常常要在十幾個項目中修改許多不同的文件。且不說對系統性能的影響，單單對開發人員的開發體驗就很糟糕，疲於在各個工程項中查找要修改的文件。通俗的說，解耦的主要目的之一是實現代碼複用，誠然，框架解耦的目的確實達到了，但是又怎樣呢？從來沒有後期的項目會使用這些解耦的子項目，因爲系統業務一旦複雜後，雖然竭盡全力的避免，但是還是會有功能模塊相互交織，根本不能獨立出來作爲一個DLL供給其他項目使用。事實上每到新項目開始的時候，多數情況下還是採用原始的複製代碼的方式，而不是直接採用某個dll。解耦的另一個目的是減少系統的關聯度，使得修改程序的時候能更簡單，這是書上讀到的。但是事實上，我覺得跟本不是這麼回事，任何更改，如果是簡單的代碼更改，即使耦合度高的系統，也是很快能改進，而如果出現了較爲複雜的業務更改，低耦合度也降低不了改動的規模。當然在此並不是否定解耦不好，只是說明一下，系統設計的時候，要綜合考慮，而不是書上說什麼就是什麼，在我看來，保持KISS原則會讓我省心不少。
團隊建設
項目經理的主要工作之一就是將任務分解成工作包，然後分配給個人。本人喜歡的方法是開個會，大家一起商量，評估工作時間，認領任務。個人比較喜歡自下而上的方式，即項目成員各自確定各自的任務和時間後，彙總給我，然如有必要，稍做一下微調。自下而上的方式比較民主，大家也樂意接受。相對而言，自上而下的分配工作，有點“閉門造車”的感覺，不清楚團隊成員的情況。關於開發模式，本人也經歷過多種方式，比如瀑布模式，迭代式等等，個人覺得比較死板，尤其是當年做日本項目的時候，瀑布式開發使得我寫了一堆沒有實際價值的文檔。
個人喜歡目前流行的方式——敏捷開發。因爲其快速響應，隨時應對變化，注重實用性而不是文檔，選擇敏捷開發模式，最好是在團隊成員個個都水平較高的時候採用，如果團隊成員一堆應屆生，一問三不知，那麼怎麼也敏捷不起來的。因此，對於這種情況下，我通常會採用結對編程的方式。實踐出真知，個人感覺結對編程的效率是非常的高，而且可以互相學習技術，互相瞭解業務，個人非常推薦這種做法。選擇怎樣的開發模式和管理方法，就會建設出怎樣的團隊。
風險和變更範圍
通常情況下，在做準備工作的時候，儘量的預估一下風險，風險包括技術上可實現性，人力資源的可用性和項目變更的預判。這點是經常會忽略，技術不是萬能，面對有些苛刻的場合不一定能實現，這個風險要儘早的發現，考慮生成一份備選方案，最好做出原型來證明方案的可用性。而項目的變更對於開發者來說是家常便飯，但是最好把變更權控制在自己的手中，領導的旨意常常是不能拒絕的，但是也要以理力爭，儘量通過郵件，IM聊天記錄等確認變更，因爲這可以作爲變更證據，而不用通過口頭敘述，儘量避免範圍蔓延和“項目鍍金”，不然到時時間來不及背黑鍋的就是你了。
最後，對每一個項目都總結一下經驗校訓，無論是技術上的和非技術上的，對於以後的項目也是大有裨益的。以上是本人的一些經驗分享。