軟件外包項目管理指引

　　若是不去親身經歷幾個外包項目，讀者是不可思議這種「焦油坑」的恐怖。外包項目由於規模較大，涉衆較多，在管理上每每更爲複雜。本文，闡述外包項目的特色以及筆者的管理經驗，但願能便幫助讀者管理好外包項目。

1 項目中常見的問題

常見問題	現象
範圍	需求難以凍結，處於「變動-修改-測試-變動」的死循環中。
質量	文檔質量問題，如：關鍵文檔缺失，沒有能按照統一要求編寫文檔；文檔內容先後不一致，有歧義，預期讀者沒法理解，文檔版本與代碼版本不一樣步等。 編碼質量問題，如：不遵照編碼規範，可讀性差難以維護魔數氾濫，關鍵代碼無註釋，代碼檢查出現大量警告，濫用語法致使性能瓶頸等。 系統質量問題，如：不寫驗證，安全漏洞，異常頻發，內存泄漏，日誌缺失，不支持大量用戶，運行緩慢等。
成本	前期成本估算偏差較大，缺少足夠依據。 後期沒有對成本進行量化分析。
進度	項目常常延期或者是匆匆上線。

 

外包項目中凸顯的一些問題	現象	解決方法
前期準備不足	需求質量問題，如：遺漏需求，需求不明確，需求描述先後不一致，需求存在歧義等。 開發環境問題，如：配置管理、開發、測試、Bug跟蹤、項目管理等環境搭建沒法知足工做須要。 流程問題，如：是否已經創建了周知的工做流程，是否已經具有了相應的範本、檢查標準和公約。	儘快梳理需求，搭建環境，創建項目所需的最基本的生存環境。 制定計劃時，充分考慮到這種狀況，識別潛在風險，預留足夠的風險儲備。
人際關係複雜	干係人數量龐大，其需求各有不一樣，可能存在需求之間的衝突。 涉及多個供應商、提供商，項目進行中會有開發團隊之間的矛盾衝突。 在人員混編團隊中，會發生外部人員難以管理甚至罷工的可能。	必須明確掌握核心干係人的職位、職責和角色，增強溝通，作好乾系人關係維護。 遇到問題要協調多方負責人協調解決，不要帶感情色彩。
資源問題凸顯	人員儲備不足，開發用機器配置較低編譯緩慢等。 外部人員能力良莠不齊，且難以管理。 人員離職頻繁，資源嚴重不足。	儘可能參與到人員招聘中，對能力不達標的在職人員進行培訓，儘可能不要勸退。 磨刀不誤砍柴工，必要時，申請合理的硬件資源。 在進度計劃裏安排單點技術的交叉培訓，以應對該人員離職時的衝擊。
PM沒有足夠權利	受制於多個上級領導，對甲方決策無力抗爭，對項目組內的甲方人員難以管理。	和領導搞好關係，增強溝通，本身權限外的找負責人解決。
地域和文化差別	封閉開發時的伙食問題，如：上海人不愛吃辣的，回民不吃豬肉等，這些問題他們都會找PM。 溝通問題，不一樣地區語言文化差別，尤爲是遠程會議時，可能會在理解上有阻滯。	及時和甲方溝通團隊成員的合理訴求，要勇於維護團隊的利益。 認識到理解上有疑惑時，及時溝通，不要礙於面子不去張口。
加班	加班致使離職。 加班致使士氣低下。 加班致使消極怠工。 加班致使代碼質量低下，Bug頻發。 加班會致使疾病甚至過勞死。	合理的安排趕工，對不合理的要求說「不」。 儘可能爲加班程序員爭取利益。 一馬當先。 合理安排計劃，預覽風險儲備，儘可能作到在節假日不加班。
須要PM參與設計和開發	PM想要扮演架構師和程序員的角色。	優先完成關鍵路徑任務，利用碎片時間參與其餘非關鍵任務。

　　

2 項目管理經驗總結

• 促成一致意見 多數外包團隊看中的是程序員編碼能力，而不是合做的能力。PM須要作兩件事情：第一，確保討論不要被一我的或一種言論所支配，固然共識的除外；第二，幫助不敢發言的人或說不清楚的人表達他們的意見。PM大多時候須要促成團隊的一致意見，如對編碼規範，周知的項目組約定等。促成一致意見須要輕度的領導，高壓政策下的一致意見，不能反映出團隊的意願。PM在促成一致意見時最重要的是保持中立。須要知道，集體的決策比從集體中的個體獨立作出選擇更具備風險傾向。若是將這種決策模式應用與軟件項目，極可能會看到這樣的結果：更復雜的結構和算法、過分的質量、過分的擴展性考慮、範圍淺變等。這是由於開發者並不會考慮項目的總體維度，而只會關心編碼。所以，對於PM促成一致意見，不等同於從衆或折中，有些時候單獨的作出決策纔是對的。所以，並不是全部決策都傾向與羣體決策，羣體決策會產生一種負面影響，即——我的貢獻和能力將降到最低。做爲PM應該，清楚這種負面影響，併爲團隊營造一種鼓勵和支持「創新」的大環境。不要讓團隊中造成小的團體對立，這樣，任何人的出頭行爲都很招致小團體成員的怨恨。這種現象在外包團隊更爲明顯，由於可能源自不一樣公司，會不一樣時間入職。不要讓這種風氣在團隊中成爲主流。另外，不要輕易的折中，由於折中每每會失去亮點。
• 明確優先級 PM必須面對現時，項目是技術和經濟結合的產物，受制於多方制約，須要綜合分析這些制約因素和用戶訴求，制定合理的優先級。
• 爲團隊爭取好的辦公環境 外包團隊的工做環境一般比較惡劣。IT業公認的：更安靜、更寬鬆的工做空間對提升編程效率有做用。若是可以讓團隊總體在一個獨立區域辦公應該是極好的了。但咱們也得面對現時，外包團隊不會有很好的待遇，由於，至少做爲PM咱們應該爭取不要讓團隊分散，由於那會提升溝通成本，和溝通中的噪音。另外，被分出去的開發者會感到孤立，進而與其餘人員疏遠，長期下去不利於團結成員間的協做。
• 讓開發人員少受打擾 編程是一種耗費腦力的持續活動，開發者不喜歡被打擾，願因很簡單，打斷思路會影響編碼。因此，不少時候你們會聽到程序員抱怨說「我不是網管」。在外包團隊中，打擾就不那麼簡單了。程序員與關鍵用戶的比例是極其懸殊的，開發者會常常被打擾，解答各類無聊問題，甚至和甲方鬧矛盾。這不是個好現象。PM須要作兩件事情：第一，明確角色職責，並讓甲方人員清楚，有問題了該找誰，不要一個問題在團隊中踢皮球；第二，明確向甲方表示，投訴直接找PM，走投訴流程，別單獨去和開發者理論，若是矛盾激化，以後很難處理。
• 管理牛仔 無疑的，牛仔程序員是能力很強的，但卻缺少團隊合做概念。牛仔程序員若是聽任無論，那麼他每每會寫出別人難以理解的代碼。他們特立獨行，不肯與人合做，而且喜歡在代碼中烙印本身的風格。雖然程序員們都有強烈的性格傾向，但牛仔顯然更加突出，他們每每不是那種喜歡與人交往的類型。牛仔程序員具備如下特色：他們反對任何形式的標準、約束和規範，不喜歡受他人的監控，也不喜歡和他人協同開發。追求創造性多過考慮軟件可用性、可靠性和成本。外包團隊中，不要去嘗試改變牛仔程序員，這不是短時間能作到的。牛仔對團隊是否有益，取決於PM。好的實踐是：第一，將整個工做分解，把相對獨立的、具備挑戰性的工做分配給牛仔。這些工做應該儘量獨立，與其餘工做之間只存在簡單的接口，不須要與其餘人員頻繁的溝通；第二，對他們的工做進行監督，不能忽略這些牛仔的存在；第三，不要用領導的口氣當衆壓制牛仔，由於他們每每執拗己見且自負，最好在私下約談。