對微型專案管理的思考

　　這段時間由於複習考試，看了一些ＲＵＰ、ＸＰ的開發方法。在學習的過程中，我都結合著工作中的實際問題來思考，看看是否有什麼方法是可以解決工作中的所有問題。最後，我發現，事實上是沒有任何一個方法可以解決一個具體專案中所有的問題。所以，我就考慮，其實每個專案都是獨特的，都應該根據實際情況來進行專案管理和從各種開發方法中取適用的部門來組合。

　　我所涉及的專案都比較小。一般１－２個程式設計師開發１個月左右就能完成，主要針對公司內部核心系統的補充。下面列個清單，方便理解：

前提：１）專案規模小；

　　　２）專案組成員：team leader（同時負責方案、設計、技術支援、專案進　　　　　度控制）、１－２名程式設計師；

　　　３）程式設計師都是經驗非常少的，常常還有一點經驗都沒有的。

步驟：１）方案（ＴＬ）

　　　２）討論（ＴＬ）

           (3)  架構設計 （新加的，詳細介紹見下回復）

　　　３）設計（ＴＬ）

　　＊以上三步都形成文件；

　　　４）開發（程式設計師）

　　　５）階段性交付（程式設計師）

　　　６）需求變更（客戶、ＴＬ）－>需求變更文件（ＴＬ）

　　　７）評審、結束

說明：

　　１）－３）是team leader和業務部門人員討論形成。我在之前考慮過讓開發人員一起參與討論（事實上，我認為這才是正確的做法），但在操作起來，如果讓開發人員參與討論，並且由於我們的開發人員非常缺乏經驗，不但缺乏技術經驗，還缺乏業務經驗。這樣就會造成每次討論時間拖長，但效率降低，效果並不好。因為我還是傾向於在討論詳細設計之前的工作，不讓程式設計師參與（除非程式設計師是有經驗的程式設計師）。

　　在這個階段的工作中，我認為是比較好控制的。唯一的疑問是：

　　Ｑ：如何將設計文件寫的即能控制住專案的功能，又留有餘地給程式設計師發揮？

　　我自己認為，這需要看程式設計師的熟練程度，越有經驗的程式設計師越可以留更多的空間給他發揮；缺乏經驗的程式設計師，就應該將設計文件寫的詳細。但問題又出現，越缺乏經驗的程式設計師，對工作認識越不深，越希望不受束縛。

　　４）－５）我把它定義為開發過程。主要是程式設計師進行開發工作。這個階段的問題比較多：

　　Ｑ：（１）程式設計師之間的交流？

　　　　（２）程式設計師與team leader之間的交流？

　　　　（３）程式設計師與客戶之間的交流？

　　　　（４）team leader與領導之間的交流？

　　　　（５）team leader與客戶之間的交流？

　　　　（６）進度控制？

　　　　（７）進度調整？

　　　　（８）關鍵功能的控制？

　　＊對於我們這種小專案，我不贊成太多文件，尤其在開發過程中，最好不要程式設計師產生文件。但沒有文件，該如何解決以上這些問題呢？在ＸＰ中交流就是來解決這些問題的。但放在具體專案中，也是有問題。如果程式設計師之間沒有交流意識，是很難控制。程式設計師，尤其是缺乏經驗的程式設計師很少會主動給team leader報告他的工作情況。甚至，team leader去問，都問不出問題，我聽到最多的就是：在做！沒什麼問題！快做完了！更有甚者，問程式設計師做完沒，他告訴我：還是前兩天那個問題。我暈，放了兩天的問題，不說話，不解決，我不問，他不說。（為了防止把這篇東西變成訴苦篇，我就此打住）

　　在程式設計師不善於交流的時候，team leader就只能主動去過問了。而且，問的問題要很明確，比如：你完成了那些功能？某某功能完成沒有？現在正在做哪一個部分？

　　總之，我覺得跟缺乏經驗又自負的程式設計師交流，比跟熟悉業務的客戶交流要困難的多。

　　（希望大家有什麼好的提議）

　　５）階段交付，是根據敏捷開發方法中提高，不斷給使用者提交可使用的產品。將專案階段劃分小一些，儘量使每一階段完成的功能都能單獨使用，然後提交給使用者使用。並收集使用者反饋資訊，若影響到原有設計的進行需求變更。

　　為了解決team leader與客戶和領導之間的交流，team leader應該每週或每兩週提交一份進度報告和問題給客戶和領導。（目前我對客戶是沒有反饋，每個月給領導一份報告，現在覺得時間間隔應該縮小）

　　６）需求變更，由team leader收集，寫成新的需求、設計文件。這是因為如果寫進原文件中，容易被忽略掉。但要在原設計文件中增加提示：在這裡變更了需求，參考文件。。。（這是跟飛機手冊的改版學的。呵呵）然後反饋給程式設計師進行開發，或修改程式碼。

　　最後，全部功能開發完畢後，進行一次評審。事實上，前面不斷提交產品給使用者，最後的評審應該問題不大。

　　最後，要求程式設計師提供兩份文件：程式清單和使用者手冊。

－－－－－－－

１、該過程中產生４份文件（不算team leader給客戶和領導的週報）：方案、設計、程式清單、使用者手冊。

２、這個過程中，所有壓力都在team leader身上。這是因為程式設計師都缺乏經驗。當有有經驗的程式設計師時，有部分工作應該轉移到程式設計師身上。

３、對程式設計師的培訓。不是指技術培訓。而是讓程式設計師意識到專案管理中的知識，以及工作方式。

－－－－－

這個過程是我想出來的。我的專案管理經驗很少。因此在不斷地摸索。不斷地嘗試各種辦法，將專案管理好。我將在下兩個專案使用上述方法。也將根據專案的進展不斷反饋到這裡，也檢驗我的方法是否可行。祝我成功吧。

　　　

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/13353915/viewspace-244147/，如需轉載，請註明出處，否則將追究法律責任。