IT項目管理的一些心得

工作多年，也有一些項目管理經驗，在此總結一些自己對于項目管理的看法。

開始階段

項目啟動的時候，個人認為最重要的是要弄清楚項目的目标和項目的範圍，包括需求範圍和時間範圍。

通常，我最怕聽到上司說：“把這個工作做一下，需求大概是balabala”，“啥時要？”，“不知道，你先做着，盡快吧。”這種場景經常會出現，由于沒有明确的需求和時間限制，有時候就會無法分解工作包，導緻無法安排人去做。

這種情況相信在大多數人身上都有發生，這時候隻能根據個人的經驗從有限的需求說明中推算出大緻的需求，還要估算一個合理的時間，因為雖然上司沒指定具體的時間，但不意味着無限期的時間，總是得有個大概的範圍。

關于項目需求的收集，有時候急于心切想一下子擷取全部的需求，但是大多數情況下，這是難以做到的。是以我總是确定一些大的需求方向，通過滾動規劃，漸進明細的方針，逐漸細化這些需求。使得需求的細節盡量在大方向之内。如果時間允許的話，可以先構造一個原型，通過原型能更好的把握項目的需求以及面臨的風險。

關于技術架構架構的選擇

通常情況，總是選擇成熟好用的架構作為首選。事實上，我工作過的公司，都有自己的一套架構，大多項目都遵循這套架構，這些架構都經受了生産環境的考驗，是以所面臨的風險是最小的。有時候，會覺得這個架構真土，或者太爛，而花太多的時間在修改架構上，但是這在我看來不是最重要的。架構的目的是把程式員拉到流水線上，提高生産力，越複雜的架構對性能的影響也越大，理論上說，不使用架構的代碼性能最好，但是可讀性差，不易于管理，是以不得不使用一個良好的架構來組織代碼。

舉個例子，本人曾經曆過的一個項目，覺得是過度設計了架構，有點為設計而設計的味道，架構設計者為了實作解耦，将系統拆分的極度松散，以至于調用某些類庫的時候還得依靠反射等方式，而為了完成一個功能業務，常常要在十幾個項目中修改許多不同的檔案。且不說對系統性能的影響，單單對開發人員的開發體驗就很糟糕，疲于在各個工程項中查找要修改的檔案。通俗的說，解耦的主要目的之一是實作代碼複用，誠然，架構解耦的目的确實達到了，但是又怎樣呢？從來沒有後期的項目會使用這些解耦的子項目，因為系統業務一旦複雜後，雖然竭盡全力的避免，但是還是會有功能子產品互相交織，根本不能獨立出來作為一個DLL供給其他項目使用。事實上每到新項目開始的時候，多數情況下還是采用原始的複制代碼的方式，而不是直接采用某個dll。解耦的另一個目的是減少系統的關聯度，使得修改程式的時候能更簡單，這是書上讀到的。但是事實上，我覺得跟本不是這麼回事，任何更改，如果是簡單的代碼更改，即使耦合度高的系統，也是很快能改進，而如果出現了較為複雜的業務更改，低耦合度也降低不了改動的規模。當然在此并不是否定解耦不好，隻是說明一下，系統設計的時候，要綜合考慮，而不是書上說什麼就是什麼，在我看來，保持KISS原則會讓我省心不少。