沉思錄:IT專案產品化過程中的問題雜談（二）

專案背景可參見：沉思錄:IT專案產品化過程中的問題雜談（一) 空降兵 本人就恰逢是“空降”到另一個部門，來負責一個子系統的開發； 空降者不得不面對這些問題： 團隊根基不好； 團隊成員的“特徵”不瞭解； 團隊的工作經驗和水平不瞭解； 這些實際存在的因素，必然會導致實際中存在著的問題 專案團隊整體的技術力量沒有預期的好，專案中期進行模組整合時，發現程式碼和設計存在不少的問題，這些問題的累積對專案的進度和質量有一些影響 專案中期核心成員離職，對專案有了很大的影響 （純屬管理上的嚴重失誤，專案前期就應該瞭解專案成員的“去向”） 專案核心團隊雖然已經組建，但後續陸續加人，專案整體合作出現問題 雖然面臨不少的問題，但也沒有辦法避免這種“空降”的情形，實際中，始終都堅信這樣思想：只有團隊的支援和互相合作，專案才會成功； 但實際中應該如何解決這些問題呢？依靠個人魅力？專家能力？還是正式賦予的權利？ 簡單介紹一下實際做法： 整體的思想 靜觀其變（前期沒有太大的動作，群眾基礎不好，可能會有很大的牴觸） 變革（中前期，根據不同的問題進行不斷地慢慢改革） 融合（漸進式的改革，慢慢可以被人接受和信服） 合作/表現 (Team 已經步入了正式軌道，成員能夠積極地“表現”，從而保證專案順利地完成) 整個專案開發過程中，更多的是“專家的能力” +“個人魅力”，很少使用“正式的權利“　（個人始終覺得，對於小規模的團隊，這兩種權利的綜合會比“正式權利”好很多） 藉助工具（JIRA）來做任務跟蹤和管理 能保證了資源的有效利用; 利於任務交接（尤其是團隊不是很穩定的情況下） 任務控制更簡單（視覺化的系統跟蹤) 採用“嚴格”的程式碼REVIEW來做“團隊建設” 使用更多的“軟”技巧來進行專案管理: 以個人發展為切入點，積極地引導正確的做法或糾正不是很恰當的行為 根據個人特點進行任務分配 技術能力/經驗比較豐富的，直接提供需求點即可； 技術能力/經驗稍欠缺的，需求再次細分，直到可以程式碼實現的粒度； 新人/或者技術能力一般，需要提供簡單的程式碼結構和設計思想 總之，無論是否是不是“空降”，專案管理要做的始終是：為團隊服務…… 團隊的力量 現實中總會遇到類似的狀況： 需求總是在變化，哪怕最後一刻 時間總是不夠用，無論週期多麼地長 資源總是那麼地少 問題總是在不斷地增加…… 但無論如何，最終總是會完成的…… 回首一下，會不會覺得這是個奇蹟？　是不是應該享受如此“混亂”的奇蹟？想想為什麼能夠完成？ 這就是團隊合作的力量：互相鼓勵；彼此信任；合作；風險；堅持…… 從而，“如何有效地發展團隊”也是專案管理中比較重要的任務之一。 責任 專案編碼很亂，很不規範，誰的責任？個人能力的問題？培訓機制的問題，PM/PL 的問題? 產品業務知識不瞭解，誰的責任？ 這些問題看似很簡單，但針對不同的情形，執行起來都不容易，但無論如何做，無論誰來做，都可能演變為“責任”的問題，每個人踏踏實實地去做，真正地去做，把每一件事都當作最重要的事來做…… 或許會懷疑，沒有人指導，沒有正確的方向，沒有一個有效地規範，如何才能夠承擔“責任”？ 雖然可能如此，但不去嘗試，不去努力，基本的“責任”都已經丟失了…… 可我憑什麼要有“責任”？這將會是另外的一個令人深思的話題…… PMP 專案管理知識體系提供了專案管理框架和九大知識領域的介紹，能夠給專案很大的幫助，但僅僅通過PMP 是遠遠不夠的，如何把PMP的理論知識切實地落實到專案之中，如何運用好PMP理論中的哪些工具和方法？這才是我們應該去思考的。

Link URL: http://www.lifandong.com/management/105

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