《播客》項目總結(jié)之項目管理

申請免費試用、咨詢電話：400-8352-114

引言： 
　　如果標題改成《被管理總結(jié)》的話，我可以滔滔不絕的說上個半天，但是如果是管理項目的話，我實在肚里的貨有限，因為到至今做過的最高職位不過是個“班長”而已。 
　　但是這次《播客》項目在管理方面的確出了問題，而且是滿嚴重的問題，以至于到后來項目差點失控，而且最終的交付作品質(zhì)量的確讓人汗顏。如何避免下面程序員很累，但效率卻很低；上面不停的催，產(chǎn)品卻一個bug接一個bug，完全沒法交付；項目經(jīng)理累的要死，項目卻仍然處于失控狀態(tài)這樣的問題和局面？在一個差點失控的項目剛剛結(jié)束后，這些問題難道不值得好好的總結(jié)和反思嗎？雖然我在項目管理方面的能力有限，但是我仍然希望通過這樣的總結(jié)，讓下次的項目盡量避免和改進這次出現(xiàn)的問題。我很高興，因為我依然走在“好好學習，天天向上”的道路上…… 
　　最近在看《快速軟件開發(fā)》這本項目管理方面的書，本來想按章按條的對照這個項目來寫出總結(jié)，但是我發(fā)現(xiàn)那樣的死書讀來又有何用呢？那樣得出的結(jié)論還是你真正實際感受到的項目方面的問題嗎？那樣的文章還會有人看嗎？那樣條目的羅列還能給別人和自己以啟示嗎？所以，最終我放棄了那種想法，而采用這種可能詞匯上很“外行”，但是卻是來自親身經(jīng)歷的感悟的方法來寫。 
　　正文：  
　　時間真的夠嗎？ 
　　也許是我做日本外包項目時間比較長了，所以當我聽到這個《播客》項目需要在一個月內(nèi)從無到有的出來的時候，我很驚訝，因為這樣的“人月”資源可能只相當于我以前在日企“人月”資源的1/5，甚至更少。也許你會說我們不需要那么多的文檔，那么嚴格的流程。所以如果把“需求分析”的時間去掉，把“概要設(shè)計”的時間去掉，把"詳細設(shè)計"的時間去掉，而且我們不需要程序員去測試，我們有專門的測試小組。所以既然去掉那么多的步驟了，所以時間縮短到1/5應(yīng)該完全是可以的吧。但是你知道嗎？項目管理不是簡單的“3-1“再"-1"那么簡單的加減運算。當你用3-1的時候得到的不是2，而是1，甚至更少，過于冗余的東西的確可以被精簡掉，但是很多的東西，當你在初期認為是可以精簡的時間而精簡掉的時候，后期會花費2-10倍的資源來彌補，那將是得不償失的，例如“需求分析”。我很遺憾的看到這次項目竟然沒有“畫面遷移圖”。所以導致后來頁面的跳轉(zhuǎn)很亂，甚至出現(xiàn)，一些頁面雖然做出來了，但是卻沒有入口的情況。 
　　聽團隊里一個資歷較老的同事說，他們上一個項目經(jīng)理，從不考慮時間夠不夠，上面定的完成時間從來都不反駁。上面說一個月完成就是一個月，上面說一個星期完成就一個星期?！澳悄芡瓿蓡?？”，我問。“當然完不成了，加班呀！死加！結(jié)果加班也完成不了，然后就對上級說程序員效率低。把責任都推給下面的人?！?nbsp;結(jié)果，后來整個團隊的人心全散了。而趙就是在這樣的情況下接下了攤子，所以我聽了這個故事以后很為他捏了把汗。 
　　參考解決方案—— 
　　時間估算是個有力的工具。在項目初期可能估算的差浮很大，但是在每個“里程碑”的階段以后再次作出的時間估算將更準確一些。直至最項目完成時，時間估算將趨于精準。這給予我們的啟示是——
　　1：項目初期，不要把時間期限限定死了，而是應(yīng)該在一個范圍內(nèi)?！皩Σ黄穑跊]有作出充分評估和分析之前，我不能回答你準確的完成日期，但是初步估算，這個項目需要1個月到3個月之間。最有可能完成的時間是2個月”。這樣的回答將是比較好的。很可能上面會被你的“3個月”這個上限嚇住，但是，當你的項目真實的是在2個月的時候完成的時候，那么最終你的評價將會更好。講個小故事：我小時候就是喜歡吃糖果。特喜歡附近小店1塊錢10個的那種硬糖，每次買一塊錢的。每次去買時，如果是老板娘，她總喜歡，抓一小把先放到我手里（大約5個），然后再一個一個地加到10個。而老板的話，他卻喜歡抓一大把放在我手里（大約15個），然后再一個一個地拿走，直到我手里還剩10個。不知道何故，我超喜歡老板娘，卻恨死了老板。 
　　2：每次進行到一個“里程碑”的工作之后都要重新進行時間估算，以提供更為準確的時間范圍。同時也便于總結(jié)為什么上一個階段花費了那么多的時間。 
　　到底做成什么樣子？ 
　　作出時間估算的最基本的依據(jù)就是需求分析。到底要做成什么樣子？到底在什么環(huán)境下使用？到底需要哪些功能？到底有多少頁面？各個頁面之間到底是如何跳轉(zhuǎn)的，這個頁面的是從什么地方進來的，又可以從什么地方出去？……有多少項目是在真正搞清楚這些需求后才開始的？還是更多的是——“差不多就是做成那個樣子”，“先做著，一些功能反正以后可以再加”，“策劃部說，現(xiàn)在能不能把這個功能也加進去？”……需求不明確就開始動工的危害我就不多說了，但是有個數(shù)據(jù)我還是要列舉一下——“初期花費1個資源單位能夠解決的雛形問題，如果發(fā)展到后期將需要2-10個資源單位來解決”。
　　參考解決方案—— 
　　如果真的時間很緊的話（畢竟對于軟件或者網(wǎng)站來說，特別是商業(yè)軟件或者商業(yè)網(wǎng)站來說，發(fā)布時間、搶占市場是第一位的），我認為像詳細設(shè)計這樣的東西的確可以精簡一些，但是需求分析，畫面遷移圖這樣的東西還是要求嚴格一些比較好。其實項目的初期，很多的人都是很閑的，一些東西完全可以先由比較空閑的人來完成，然后大家討論然后定論一下來完成。這樣不僅可以完成這些至關(guān)重要的東西，而且對于團隊的熱身和保持活力很有益處。不會出現(xiàn)“閑的時候閑死，忙的時候忙死”的現(xiàn)象。
　　注意，這些東西都需要文檔，而不是口頭上的決定。 
　　壞蘋果 
　　因為就如同我面所提到的，上個項目經(jīng)理把這個隊伍帶散了，整個人心都亂了，所以這個團隊根本沒有什么團體文化而言。甚至出現(xiàn)了“拿工資混日子”的“bad apple”。但是如果僅僅是“拿工資混日子”那樣的話危害好像還不是很大，如果出現(xiàn)這樣的“worse apple”的話，整個項目將危如累卵了——
　　對自己的代碼極為不負責任，垃圾代碼過多，對自己的代碼從來不進行測試，以程序跑通為最高準則。  
　　從來不考慮代碼的運行效率，用最簡單的方法完成功能即可。  
　　對于bug從來都是抵觸，推托責任，甚至對自己的bug拒絕修正。 
　　獨立獨行，不服從上級安排。  
　　蠱惑人心，以盡可能的破壞團隊文化為樂趣。  
　　拒絕與上級配合，甚至與上級爭吵。  
　　更多危害項目開發(fā)的行為……  
　　其實很多的人也并不是很樂意做壞蘋果，也許是因為上一個項目經(jīng)理太讓人寒心，也許是上個項目經(jīng)理把整個團隊帶散了，也許是項目制度出現(xiàn)了問題，也許……，有太多的也許，但是事實是——我們的團隊真的出現(xiàn)了壞蘋果。 
　　參考解決方案——  
　　也許對壞蘋果最快速和有效的解決方案是——開掉！但是那真的是最好的辦法嗎？有沒有想過是什么土壤滋生了這些“壞蘋果”？我就在我們的公司中發(fā)現(xiàn)了2個很不好的問題—— 
　　1：沒有明確的獎勵制度。就如同以前文革的時候吃“大鍋飯”一樣，干好干壞一個樣，反正每個月就是那么多的工資。如果每個人真的都那么想的話，那么惰性就出來了。 
　　2：只有不合理的懲罰措施，雖然技術(shù)中心還沒有這樣的措施，但是聽說編輯那邊，上傳的文章如果出現(xiàn)了錯別字是要扣錢的。我最反對的就是“扣錢”這樣的措施。因為特別容易激起員工的“抵觸情緒”。也許你會說，如果上班遲到不扣錢的話，那么大家都遲到要怎么辦？其實，扣錢和獎錢是相對的。將本來應(yīng)該給予的錢抽出一部分（當然下面的員工是不知道的）。然后做的好就在全額發(fā)下去，如果有違規(guī)就去掉一部分，然后將余下的發(fā)下去。就如同很多企業(yè)所謂的“全勤獎金”一樣。沒有什么深奧的東西，心理策略而已。 
　　所以雖然“開掉”是最有效和快速的方法，但是如果很多滋生壞蘋果的土壤不改善的話，再怎么開也沒有用，壞蘋果還是會一個接一個的冒出來。建立良好的團隊文化，合理的公司制度，一個積極向上的團隊才是最根本的解決方案。