軟體專案管理之文件化程式

什麼樣的人適合看這篇文章？

　　1、專案經理
　　2、希望改進團隊現狀的技術人員
　　3、學習軟體工程覺得是一紙空文的大學生

如果您並不覺得軟體專案管理是一項管人的藝術，請閱讀我剛無意收集到的一篇文章《一個敏捷教練中止越軌列車的故事》眾所周知，軟體的開 發離不開技術，但是也同樣離不開管理。雖然這只是簡單的一句話，但是不同的人卻對其有不同的理解，有的人將重點放在“技術”，有的人則將其放在“管理”。 當然這樣的判斷都是全然無效的，首先二者都是必備的，再者由於不同專案的具體細節所導致的技術和管理的比例不盡相同，因此我們只能因地制宜地去創造我們的 軟體，締造一個又一個的人月神話。

不知道您是通過什麼途徑瞭解軟體專案管理的呢？以下列出幾種我覺得可能的情況：

1、大學課本，很多大學計算機專業都必開軟體工程一門課，其中就對軟體專案管理大張旗鼓過。當然據我所知，同學們往往一無所知地完成了學業，因此這門課所給他們帶來的意義遠不及生產實踐。

2、大學課本，（重複？NO）很多大學的管理學系同樣也開設同樣的課程，當然他們的重點是專案管理，但是也涉及到一些軟體專案管理的項。

3、IT經理，也許你認識一些IT經理人，他們總告訴你他們的團隊的種種故事，也許你不一定聽得到“軟體專案管理”幾個字，但是你一定能將他與本條途徑對上號。

4、程式設計師，也許你的朋友正在從事軟體行業，因此他們對他們團隊所發生的事也給出了種種說法。

5、圖書，當然了，這一點很明顯，因為軟體行業是個巨大的市場，也有很多的學者投入其中。很可觀的實際情況告訴我們這類圖書通常依託於一些現實場景進行描述。
　……
　不再一一列舉。

軟體專案管理，究竟是一門什麼樣的學問？

軟體專案管理，究其本質其實是一項管理，它應該被描述為一項管理軟體人員協同工作的職責。

現代軟體的特徵表明，一個成功的軟體的開發將不是或至少通常不是一個人所能夠完成的，而是由軟體團隊協同完成的。如何組織協調軟體團隊 有序有效地協同開發軟體是軟體專案管理的偉大職責。我們有理由相信沒有良好的軟體專案管理的團隊是無法高效地適應現代軟體行業競爭的。因此，軟體專案管理 的重要性一直被看作軟體工程中的至關重要的成分而被列入專案經理的必修課。

經常聽說，大公司/外企所擁有的是一個有效的管理團隊，從大公司出來的人，之所以吃香，是因為他們所耳濡目染的管理經驗能夠帶來對新公司生產力的一種提高，或者說，這層“管理能力”將成為他們夢寐以求所鍍的金。

軟體專案管理，不是管技術的技術，而是管人的藝術。

說說我得到的關於一些外企工作方式的一些例子。一個知名的外商獨資跨國公司軟體部，接受該公司在中國大陸的軟體業務的承接，並完成 70%以上的海內專案。他們的工作生活在明確的分工之下，從承接專案開始後，順序完成軟體專案的需求，設計，製作研發，測試等任務。期間包括從專案稽核開 始的各項流程，完成這些前期工作的時間佔用了整個軟體專案開發60%以上的時間，之後才開始程式碼的編寫。當然設計肯定不是完美的，期間的修改也是圍著主幹 道，八九不離十。再經過嚴格的測試才有最後的軟體產品。這些和我們所得之的許多軟體專案管理書中所提及的比例分配也不謀而合。

國內的情況呢？我們可以說現在軟體公司的數量參差不齊，大小規模更是另人詫異。我不能一棒敲死所有人，但是我相信很多公司總是這樣：項 目經理得到專案之後就開始思量著怎麼開始這個軟體的設計，於是很快召集人馬把資料庫先架起來，然後也寫了一份還算能用上滾動條的word文件，招來手下， 開始給他們講解這個專案的各個模組，之後的工作可想而知，就是進入coding。專案很快就落戶VSS了，上面也能找到×××專案需求文件。

時間上呢？海外公司可能在專案到手的一個月內一直在寫文件，導致程式設計師都不知道自己是不是應該換位叫文員，大陸團隊，程式設計師懷著為軟體犧牲的熱情，開始了沒日沒夜的程式碼生活，寫的是他們最喜歡的程式碼，而不是文件。

一個月過去了，海外公司終於啟動了編碼程式，而大陸團隊可能已經寫完了大部分模組了。（國內很多專案經理本身也就參與編碼工作，並且還是不可或缺的人物）專案經理開始逐一查閱成果了，專案經理還是資格比較老一點嘛，就開始和手下溝通了，

這個頁面怎麼這麼難看啊？你不覺得這樣很難看嗎？你就不會……於是，改。

這個功能好像不對啊，我上次應該是跟你說的很清楚了，你怎麼忘了？……於是，改。

這個做的倒是還可以，不過，這裡、這裡、這裡，你不覺得用得很不舒服麼？於是，改。

這個，你參考一下我做的×××，我們現在都儘量不用圖片了，你不能跟上一個專案一樣啊，我們可以變得嘛，我都已經改了，你也改成這樣 吧，（反駁：不是以前說要做成這樣麼），那是領導的意思，換用文字不是更直接麼？（反駁：可是以前做成這樣就被說過不行的呀），你還是聽我的，改成這樣 吧！於是，改。

這個，這樣做不太好，你不覺得不方便麼，而且技術上做的這麼複雜，分開，為什麼還沿用以前的××風格，現在這個**風格的做法不是很好用麼？為什麼不用？於是，改。
　……

程式設計師一直納悶，這我也是想了好久的呀，要是換我當customer，這樣感覺很好，至少比××樣好，嗨，不過也只得改，反正按時間算錢……

根據要修改的數量，可能這樣修改的時間可長可短。但是新的問題又來了，當程式設計師拿著改好的程式去交差的時候，專案經理又開始指點江山 了，當然了期間居然還有遺留忘記的問題未修復，當然，還經常由於修改而引入了新的問題。於是：你這個東西你自己都不用一下麼？怎麼會這樣！這樣要返工的 啊！（反駁：我剛才沒改這裡…￥……%）當然了，還是得改，再深究，還有好多的問題，被專案經理“追求完美”的眼光所識破，於是，整個程式又 經歷了長達大半個月的施工大功告成了，但處處有著未知引入的種種問題。

也許你會說改專案的時候用重構，再用測試去保證自動驗證，再……，但是現有的框架或許根本不是那塊種菜的沃土，現有的團隊，壓根就沒有所謂的測試技術予以保證。

從以上的示例中我大致抽檢成以下幾種：

使用者體驗

專案也許正朝著“良好使用者體驗”的廣告上靠攏，並高談闊論之，但實際上這些“使用者體驗”又僅僅只是某些人的主觀判斷，當然在美上，人人都有發表意見的權利，但卻不是每個人都能做出最後的決定的。

規範規格

沒有明文規定的內容大有死無對證的隱患，造成的冤假錯案，更是諸多其他問題的根源。因為一直在強調是管人的藝術，而人是有思想有主觀能 動性的行為體。被“冤假錯案”搞得一頭霧水的人，可能會上產生恐懼或排斥的心理，這種心理對於管人的藝術是不和諧的，但飲水思源，問題是誰造成的呢？都歸 結為那個專案經理麼？不盡然，更具體地說是管理策略上的不嚴謹造成的。

技術變革

有效地團隊溝通是團隊管理中必不可少的組成部分，而以上案例明顯沒有做到有效地溝通，或者也可以理解成規範規格的非標準化所導致的。

事情發展到這裡，海外團隊已經開始進入年度旅遊計劃了，而國內的團隊，如果沒有新專案，則在接受使用者的意見，當然可想而知，改是必然 的，當然海外團隊返工的可能性也不是沒有，但問題是他們的產品已經事先和使用者達成了“一致”（由於使用者可能在需求階段也是被軟體團隊搞得一頭霧水導致也不 知道定奪的方案是不是產品的效果，但這樣的成功率相對於後者，則普遍高多了……）大陸團隊呢，如果需求做得業餘，則問題將會大量出現在業務邏輯和使用者體驗 環節，這方面所帶來的影響對整個專案都是致命的。專案成本變得不可估計，很有哪天使用者不滿意了，一切就得從頭開始，而所有的錯誤都發生在一開始的“假設” 上。大陸團隊總是假設自己的需求以及實現對使用者來說是如此地easy，大陸的使用者又經常是逆來順受的型別（見不多識不廣，再加上可能是長期合作伙伴的關 系，因此更能“適應”那種糟糕的體驗），而大陸的團隊則認為他們的東西使用者都是“沒有意見”的，因此愈發他們的自大和自狂……，當然這絕不是大多數軟體公 司，但起碼我相信是一部分。

大陸團隊

現在的團隊已經疲憊不堪，專案經理認為手下都是廢物，一點小事辦不好（相反，自己做的東西則如此地美好，沾沾自喜中……）

手下：嗨，做的又都改了，高傲型的，則憤憤不平，你做的那也叫使用者體驗，落後；逆來順受型，嗨，下次多注意（開始扭曲自己的主觀判斷，並開始謹慎行事於未來的專案）

關係：本來和諧的辦公室出現了隔膜。

這也難怪人家說外國人思想比較簡單，而中國人，思路太複雜，這樣看來，社會因素是導致這一複雜關係的根源，這種不利的溝通則成為團隊中的不和諧音。而管人的藝術遇到這樣的音符將顯得死氣沉沉。

外國團隊

由於文件化做的很好，因此在出現問題的時候，開啟文件，心服口服者瞭然於胸。責任不會被推卸。（記得卡耐基說過，通常的人是不會或者沒 有人願意承認自己是錯的，即使承認了，也並不是100%地這麼認為……那我們又何必引入這樣一種環境去滋養這樣的細菌生長呢？既然可以讓白字黑字來撇清這 種無聊的人際因素……）

文件化也利於專案驗收，當使用者對自己拿到的產品不滿意的話，他們需要為改進而付費，而大陸團隊在這方面則沒有任何優勢，只能被告知，你做錯了。

因此在軟體專案管理中，文件化可以作為解決軟體團隊溝通、規範等重要因素的解決方案。

這時或許能聽到大陸團隊的專案經理傳來的聲音，現在我們的團隊哪裡有這麼多時間去做這些功夫啊，那些文件能當按鈕點出效果麼？不能？我 們要的是程式，不是文件！再者，你這些所謂的文件誰來寫？瞭解需求的就我一人，你想累死我啊？還有，就這麼點大的系統一點難度都沒有，寫那些幹嘛？

這些問題既然被提出，就一定有它存在的道理，的確小團隊要完成這樣的任務是需要付出風險的。

首先專案經理不願意寫是一方面，因為很多急性子不耐於寫那些他們稱之為形式化的東西，但事實上他們是形式上的嗎？事實上它們正在潛移默 化地改變我們的工作方式，並從一個側面改善程式的構造過程，使之不是被扭曲地成長起來的。或許之前的關於時間分配的規律不適合您的團隊，但文件化總是或多 或少能解決您當前的問題。

再者，要解決文件粒度問題。曾聽朋友說他們公司的文件細緻到100px×200px這樣的粒度，對各個可見部分的長寬高都做了嚴格的設 計，另外，在程式碼設計上更是細化到方法體。當然這並不是我所推薦的，並且我也沒什麼可推薦給您，因為這個問題從來就沒有也不應該有答案，您得根據您的團隊 制定出符合您粒度的專案，細化到方法體的做法，可能會導致很多現有的軟體團隊直接瘋掉。

最後，強調文件在改善人際關係方面的作用。這方面問題最危險也最可怕，小則影響心情，再者影響工作，甚至危害到您的身心健康（別自己氣 死了或者把別人給氣死了……）。人的心理是整個軟體專案管理中最複雜的部分，良好的團隊不是強調有隊員要有團隊精神的團隊，而是創造能激發人自身最強團隊 精神的團隊，因為發自內心的和刻意偽造的是沒有可比性的。

如果您的團隊還在口頭傳達，如果您的團隊還在為除了業務領域邏輯以外的純規範問題而爭執，如果您的團隊還在忙碌於修改程式碼的痛楚之中，請嘗試本文所提及的方法，不敢保證它一定有效，但不煩一試。