淺析軟件項目管理中的文檔化進程
什么樣的人適合看這篇文章？
1、項目經理
2、希望改進團隊現狀的技術人員
3、學習軟件工程覺得是一紙空文的大學生
如果您并不覺得軟件項目管理是一項管人的藝術，請閱讀我剛無意收集到的一篇文章《一個敏捷教練中止越軌列車的故事》
眾所周知，軟件的開發離不開技術，但是也同樣離不開管理。雖然這只是簡單的一句話，但是不同的人卻對其有不同的理解，有的人將重點放在“技術”，有的人則將其放在“管理”。當然這樣的判斷都是全然無效的，首先二者都是必備的，再者由于不同項目的具體細節所導致的技術和管理的比例不盡相同，因此我們只能因地制宜地去創造我們的軟件，締造一個又一個的人月神話。
不知道您是通過什么途徑了解軟件項目管理的呢？以下列出幾種我覺得可能的情況。
1、大學課本，很多大學計算機專業都必開軟件工程一門課，其中就對軟件項目管理大張旗鼓過。當然據我所知，同學們往往一無所知地完成了學業，因此這門課所給他們帶來的意義遠不及生產實踐。
2、大學課本，（重復？NO）很多大學的管理學系同樣也開設同樣的課程，當然他們的重點是項目管理，但是也涉及到一些軟件項目管理的項。
3、IT經理，也許你認識一些IT經理人，他們總告訴你他們的團隊的種種故事，也許你不一定聽得到“軟件項目管理”幾個字，但是你一定能將他與本條途徑對上號。
4、程序員，也許你的朋友正在從事軟件行業，因此他們對他們團隊所發生的事也給出了種種說法。
5、圖書，當然了，這一點很明顯，因為軟件行業是個巨大的市場，也有很多的學者投入其中。很可觀的實際情況告訴我們這類圖書通常依托于一些現實場景進行描述。
……
不再一一列舉。
軟件項目管理，究竟是一門什么樣的學問？
軟件項目管理，究其本質其實是一項管理，它應該被描述為一項管理軟件人員協同工作的職責。
現代軟件的特征表明，一個成功的軟件的開發將不是或至少通常不是一個人所能夠完成的，而是由軟件團隊協同完成的。如何組織協調軟件團隊有序有效地協同開發軟件是軟件項目管理的偉大職責。我們有理由相信沒有良好的軟件項目管理的團隊是無法高效地適應現代軟件行業競爭的。因此，軟件項目管理的重要性一直被看作軟件工程中的至關重要的成分而被列入項目經理的必修課。
經常聽說，大公司/外企所擁有的是一個有效的管理團隊，從大公司出來的人，之所以吃香，是因為他們所耳濡目染的管理經驗能夠帶來對新公司生產力的一種提高，或者說，這層“管理能力”將成為他們夢寐以求所鍍的金。
軟件項目管理，不是管技術的技術，而是管人的藝術。
說說我得到的關于一些外企工作方式的一些例子。一個知名的外商獨資跨國公司軟件部，接受該公司在中國大陸的軟件業務的承接，并完成70%以上的海內項目。他們的工作生活在明確的分工之下，從承接項目開始后，順序完成軟件項目的需求，設計，制作研發，測試等任務。期間包括從項目審核開始的各項流程，完成這些前期工作的時間占用了整個軟件項目開發60%以上的時間，之后才開始代碼的編寫。當然設計肯定不是***的，期間的修改也是圍著主干道，八九不離十。再經過嚴格的測試才有***的軟件產品。這些和我們所得之的許多軟件項目管理書中所提及的比例分配也不謀而合。
國內的情況呢？我們可以說現在軟件公司的數量參差不齊，大小規模更是另人詫異。我不能一棒敲死所有人，但是我相信很多公司總是這樣：項目經理得到項目之后就開始思量著怎么開始這個軟件的設計，于是很快召集人馬把數據庫先架起來，然后也寫了一份還算能用上滾動條的word文檔，招來手下，開始給他們講解這個項目的各個模塊，之后的工作可想而知，就是進入coding。項目很快就落戶VSS了，上面也能找到×××項目需求文檔。
時間上呢？海外公司可能在項目到手的一個月內一直在寫文檔，導致程序員都不知道自己是不是應該換位叫文員，大陸團隊，程序員懷著為軟件犧牲的熱情，開始了沒日沒夜的代碼生活，寫的是他們最喜歡的代碼，而不是文檔。
一個月過去了，海外公司終于啟動了編碼進程，而大陸團隊可能已經寫完了大部分模塊了。（國內很多項目經理本身也就參與編碼工作，并且還是不可或缺的人物）項目經理開始逐一查閱成果了，項目經理還是資格比較老一點嘛，就開始和手下溝通了，
這個頁面怎么這么難看啊？你不覺得這樣很難看嗎？你就不會……于是，改。
這個功能好像不對啊，我上次應該是跟你說的很清楚了，你怎么忘了？……于是，改。
這個做的倒是還可以，不過，這里、這里、這里，你不覺得用得很不舒服么？于是，改。
這個，你參考一下我做的×××，我們現在都盡量不用圖片了，你不能跟上一個項目一樣啊，我們可以變得嘛，我都已經改了，你也改成這樣吧，（反駁：不是以前說要做成這樣么），那是領導的意思，換用文字不是更直接么？（反駁：可是以前做成這樣就被說過不行的呀），你還是聽我的，改成這樣吧！于是，改。
這個，這樣做不太好，你不覺得不方便么，而且技術上做的這么復雜，分開，為什么還沿用以前的××風格，現在這個**風格的做法不是很好用么？為什么不用？于是，改。
……
程序員一直納悶，這我也是想了好久的呀，要是換我當customer，這樣感覺很好，至少比××樣好，嗨，不過也只得改，反正按時間算錢……
根據要修改的數量，可能這樣修改的時間可長可短。但是新的問題又來了，當程序員拿著改好的程序去交差的時候，項目經理又開始指點江山了，當然了期間居然還有遺留忘記的問題未修復，當然，還經常由于修改而引入了新的問題。于是：你這個東西你自己都不用一下么？怎么會這樣！這樣要返工的啊！（反駁：我剛才沒改這里…￥……%&#）當然了，還是得改，再深究，還有好多的問題，被項目經理“追求***”的眼光所識破，于是，整個程序又經歷了長達大半個月的施工大功告成了，但處處有著未知引入的種種問題。
也許你會說改項目的時候用重構，再用測試去保證自動驗證，再……，但是現有的框架或許根本不是那塊種菜的沃土，現有的團隊，壓根就沒有所謂的測試技術予以保證。
從以上的示例中我大致抽檢成以下幾種：
用戶體驗
項目也許正朝著“良好用戶體驗”的廣告上靠攏，并高談闊論之，但實際上這些“用戶體驗”又僅僅只是某些人的主觀判斷，當然在美上，人人都有發表意見的權利，但卻不是每個人都能做出***的決定的。
規范規格
沒有明文規定的內容大有死無對證的隱患，造成的冤假錯案，更是諸多其他問題的根源。因為一直在強調是管人的藝術，而人是有思想有主觀能動性的行為體。被“冤假錯案”搞得一頭霧水的人，可能會上產生恐懼或排斥的心理，這種心理對于管人的藝術是不和諧的，但飲水思源，問題是誰造成的呢？都歸結為那個項目經理么？不盡然，更具體地說是管理策略上的不嚴謹造成的。
技術變革
有效地團隊溝通是團隊管理中必不可少的組成部分，而以上案例明顯沒有做到有效地溝通，或者也可以理解成規范規格的非標準化所導致的。
事情發展到這里，海外團隊已經開始進入年度旅游計劃了，而國內的團隊，如果沒有新項目，則在接受用戶的意見，當然可想而知，改是必然的，當然海外團隊返工的可能性也不是沒有，但問題是他們的產品已經事先和用戶達成了“一致”（由于用戶可能在需求階段也是被軟件團隊搞得一頭霧水導致也不知道定奪的方案是不是產品的效果，但這樣的成功率相對于后者，則普遍高多了……）大陸團隊呢，如果需求做得業余，則問題將會大量出現在業務邏輯和用戶體驗環節，這方面所帶來的影響對整個項目都是致命的。項目成本變得不可估計，很有哪天用戶不滿意了，一切就得從頭開始，而所有的錯誤都發生在一開始的“假設”上。大陸團隊總是假設自己的需求以及實現對用戶來說是如此地easy，大陸的用戶又經常是逆來順受的類型（見不多識不廣，再加上可能是長期合作伙伴的關系，因此更能“適應”那種糟糕的體驗），而大陸的團隊則認為他們的東西用戶都是“沒有意見”的，因此愈發他們的自大和自狂……，當然這絕不是大多數軟件公司，但起碼我相信是一部分。
大陸團隊
現在的團隊已經疲憊不堪，
項目經理認為手下都是廢物，一點小事辦不好（相反，自己做的東西則如此地美好，沾沾自喜中……）
手下：嗨，做的又都改了，高傲型的，則憤憤不平，你做的那也叫用戶體驗，落后；逆來順受型，嗨，下次多注意（開始扭曲自己的主觀判斷，并開始謹慎行事于未來的項目）
關系：本來和諧的辦公室出現了隔膜。
這也難怪人家說外國人思想比較簡單，而中國人，思路太復雜，這樣看來，社會因素是導致這一復雜關系的根源，這種不利的溝通則成為團隊中的不和諧音。而管人的藝術遇到這樣的音符將顯得死氣沉沉。
外國團隊
由于文檔化做的很好，因此在出現問題的時候，打開文檔，心服口服者了然于胸。責任不會被推卸。（記得卡耐基說過，通常的人是不會或者沒有人愿意承認自己是錯的，即使承認了，也并不是100%地這么認為……那我們又何必引入這樣一種環境去滋養這樣的細菌生長呢？既然可以讓白字黑字來撇清這種無聊的人際因素……）
文檔化也利于項目驗收，當用戶對自己拿到的產品不滿意的話，他們需要為改進而付費，而大陸團隊在這方面則沒有任何優勢，只能被告知，你做錯了。
因此在軟件項目管理中，文檔化可以作為解決軟件團隊溝通、規范等重要因素的解決方案。
這時或許能聽到大陸團隊的項目經理傳來的聲音，現在我們的團隊哪里有這么多時間去做這些功夫啊，那些文檔能當按鈕點出效果么？不能？我們要的是程序，不是文檔！再者，你這些所謂的文檔誰來寫？了解需求的就我一人，你想累死我啊？還有，就這么點大的系統一點難度都沒有，寫那些干嘛？
這些問題既然被提出，就一定有它存在的道理，的確小團隊要完成這樣的任務是需要付出風險的。
首先項目經理不愿意寫是一方面，因為很多急性子不耐于寫那些他們稱之為形式化的東西，但事實上他們是形式上的嗎？事實上它們正在潛移默化地改變我們的工作方式，并從一個側面改善程序的構造過程，使之不是被扭曲地成長起來的。或許之前的關于時間分配的規律不適合您的團隊，但文檔化總是或多或少能解決您當前的問題。
再者，要解決文檔粒度問題。曾聽朋友說他們公司的文檔細致到100px×200px這樣的粒度，對各個可見部分的長寬高都做了嚴格的設計，另外，在代碼設計上更是細化到方法體。當然這并不是我所推薦的，并且我也沒什么可推薦給您，因為這個問題從來就沒有也不應該有答案，您得根據您的團隊制定出符合您粒度的項目，細化到方法體的做法，可能會導致很多現有的軟件團隊直接瘋掉。
***，強調文檔在改善人際關系方面的作用。這方面問題最危險也最可怕，小則影響心情，再者影響工作，甚至危害到您的身心健康（別自己氣死了或者把別人給氣死了……）。人的心理是整個軟件項目管理中最復雜的部分，良好的團隊不是強調有隊員要有團隊精神的團隊，而是創造能激發人自身***團隊精神的團隊，因為發自內心的和刻意偽造的是沒有可比性的。
如果您的團隊還在口頭傳達，如果您的團隊還在為除了業務領域邏輯以外的純規范問題而爭執，如果您的團隊還在忙碌于修改代碼的痛楚之中，請嘗試本文所提及的方法，不敢保證它一定有效，但不煩一試。
原文鏈接：http://hi.baidu.com/cty901/blog/item/ecffd201289c2d19738da5c1.html
【編輯推薦】
