引言：如果標(biāo)題改成《被管理總結(jié)》的話，我可以滔滔不絕的說上個半天，但是如果是管理項目的話，我實(shí)在肚里的貨有限，因為到至今做過的最高職位不過是個“班長”而已。
但是這次《播客》項目在管理方面的確出了問題，而且是滿嚴(yán)重的問題，以至于到后來項目差點(diǎn)失控，而且最終的交付作品質(zhì)量的確讓人汗顏。如何避免下面程序員很累，但效率卻很低；上面不停的催，產(chǎn)品卻一個bug接一個bug，完全沒法交付；項目經(jīng)理累的要死，項目卻仍然處于失控狀態(tài)這樣的問題和局面？在一個差點(diǎn)失控的項目剛剛結(jié)束后，這些問題難道不值得好好的總結(jié)和反思嗎？雖然我在項目管理方面的能力有限，但是我仍然希望通過這樣的總結(jié)，讓下次的項目盡量避免和改進(jìn)這次出現(xiàn)的問題。我很高興，因為我依然走在“好好學(xué)習(xí)，天天向上”的道路上……
最近在看《快速軟件開發(fā)》這本項目管理方面的書，本來想按章按條的對照這個項目來寫出總結(jié)，但是我發(fā)現(xiàn)那樣的死書讀來又有何用呢？那樣得出的結(jié)論還是你真正實(shí)際感受到的項目方面的問題嗎？那樣的文章還會有人看嗎？那樣條目的羅列還能給別人和自己以啟示嗎？所以，最終我放棄了那種想法，而采用這種可能詞匯上很“外行”，但是卻是來自親身經(jīng)歷的感悟的方法來寫。
正文：
時間真的夠嗎？
也許是我做日本外包項目時間比較長了，所以當(dāng)我聽到這個《播客》項目需要在一個月內(nèi)從無到有的出來的時候，我很驚訝，因為這樣的“人月”資源可能只相當(dāng)于我以前在日企“人月”資源的1/5，甚至更少。也許你會說我們不需要那么多的文檔，那么嚴(yán)格的流程。所以如果把“需求分析”的時間去掉，把“概要設(shè)計”的時間去掉，把"詳細(xì)設(shè)計"的時間去掉，而且我們不需要程序員去測試，我們有專門的測試小組。所以既然去掉那么多的步驟了，所以時間縮短到1/5應(yīng)該完全是可以的吧。但是你知道嗎？項目管理不是簡單的“3-1“再"-1"那么簡單的加減運(yùn)算。當(dāng)你用3-1的時候得到的不是2，而是1，甚至更少，過于冗余的東西的確可以被精簡掉，但是很多的東西，當(dāng)你在初期認(rèn)為是可以精簡的時間而精簡掉的時候，后期會花費(fèi)2-10倍的資源來彌補(bǔ)，那將是得不償失的，例如“需求分析”。我很遺憾的看到這次項目竟然沒有“畫面遷移圖”。所以導(dǎo)致后來頁面的跳轉(zhuǎn)很亂，甚至出現(xiàn)，一些頁面雖然做出來了，但是卻沒有入口的情況。
聽團(tuán)隊里一個資歷較老的同事說，他們上一個項目經(jīng)理，從不考慮時間夠不夠，上面定的完成時間從來都不反駁。上面說一個月完成就是一個月，上面說一個星期完成就一個星期。“那能完成嗎？”，我問?！爱?dāng)然完不成了，加班呀！死加！結(jié)果加班也完成不了，然后就對上級說程序員效率低。把責(zé)任都推給下面的人?！?結(jié)果，后來整個團(tuán)隊的人心全散了。而趙就是在這樣的情況下接下了攤子，所以我聽了這個故事以后很為他捏了把汗。
參考解決方案——
時間估算是個有力的工具。在項目初期可能估算的差浮很大，但是在每個“里程碑”的階段以后再次作出的時間估算將更準(zhǔn)確一些。直至最項目完成時，時間估算將趨于精準(zhǔn)。這給予我們的啟示是——
1：項目初期，不要把時間期限限定死了，而是應(yīng)該在一個范圍內(nèi)?！皩Σ黄?，在沒有作出充分評估和分析之前，我不能回答你準(zhǔn)確的完成日期，但是初步估算，這個項目需要1個月到3個月之間。最有可能完成的時間是2個月”。這樣的回答將是比較好的。很可能上面會被你的“3個月”這個上限嚇住，但是，當(dāng)你的項目真實(shí)的是在2個月的時候完成的時候，那么最終你的評價將會更好。講個小故事：我小時候就是喜歡吃糖果。特喜歡附近小店1塊錢10個的那種硬糖，每次買一塊錢的。每次去買時，如果是老板娘，她總喜歡，