一、對一個估計撐不了多久的項目的抱怨（原文）

　　項目概況

　　甲方：A公司

　　乙方：本人所在公司 （稱B公司）

　　項目：X項目是A公司外包到B公司的電子商務項目。

　　人物：A公司M先生，X項目組，主管、G、Q、P成員

　　項目狀況 

      X項目當前狀況不太好，可以說后果比較嚴重。

      1. 幾乎處于停滯狀態。現在的需求獲取方式可以稱之為“擠牙膏”；在現有功能完成，而A公司聯系人M先生，提出新需求之前，開發人員完全不知道下一步是什么。并不是需求調研沒跟上，而是跟上了M先生無話可說（講不出需求）。另一方面，項目當前實現功能跟合同寫的又有很大落差，不可能截止。這個矛盾就導致了項目幾乎停滯。

      2. 項目本身質量也堪憂。X項目組，組成非常簡單，1個主管，1個高級程序員（下面簡稱G成員），1個北大畢業的程序員（少“青鳥”2字，簡稱Q成員），1個美工皆程序員（簡稱P成員），ZERO測試。X項目組的需求調研、項目管理，程序設計，技術攻堅外加運維全皆在那個可憐的G成員(就是那個高程)身上。

      3. 上個月美工皆程序員撤退了，這無疑又是給項目雪上加霜。 

　　原因分析

      造成項目如此慘淡的原因，也是多種多樣。

      1. A公司的M先生，是在X項目開始的時候才進入A公司的，而M先生原來是寫過代碼的。G成員心想M先生有程序員的前身，好溝通，還暗暗偷笑。可沒料到的是，M先生原先是個半吊子程序員，只寫過幾個asp頁面，而心里卻甚是得意，大有編程不過如此之氣勢。就是這樣的程序員前身，給項目帶來數不盡的壓力。順便摘幾句就可以管中窺豹：“這個簡單了吧，只要數據庫這樣這樣，然后讀出來就行了”，“這個有這么難嗎？不就是加2個頁面的事”。如此等等就不列舉了。但這其實還是能應付的，最大的問題是啥呢。之前講了他是項目開始進的A公司，或者說是A公司專門挑的給給X項目組跟A公司牽線的。這是好事啊。可也是壞事，壞哪了？X項目作為一個電子商務外包，現在卻要跟一個不熟悉業務，跟X項目組成員一樣的現學現賣的M先生調研需求。如此，我想“項目停滯”恐怕也是能夠想象的了。

      2. 項目組成員組成問題也很多。G成員身皆多職，但一個人的精力畢竟是有限的，如果這么多的工作要8個小時內完成，幾乎是不可能的，就算完成恐怕也是偷工減料了。于是整個項目周期經常出現這樣情形：G成員忙的焦頭爛額，而其他2個人就聊聊QQ看看新聞。并不是G成員不舍得把工作交給別人，而是另2個成員，非設計好的功能不做，P成員畢業才不過半年也就請有可原，而Q成員，自“北大”畢業，工作也已經一年多了，這就有點說不過去了。Q成員的事，還是事實為依據：有這么個功能，1個主表1個從表，依據主表當前選中記錄，顯示并修改從表的內容，這功能，就這么簡單一個功能，G成員估摸著熟悉需求加表設計加功能也就是2天時間的事，可Q成員愣是給整了一個星期，結果一發布出去，還一堆問題，挨M先生一堆說。這樣的組成和水平，我想代碼質量不能保證也是在所難免了，更別提還沒有測試人員。

      3. 基于2的問題，很多看官肯定要說了 ，這樣的情況，還不趕緊跟領導提意見換人嘛？提啊，G成員可沒少提。G成員要求也不高，就提這樣個要求：請領導給我們再加個美工或者程序員。如果加美工呢，讓P成員轉程序開發（這個是P成員自己提的，他一直不想做美工，而且人也機靈，轉程序員也行），麻煩再把那個Q先生給換下去，你說拿著3000的工資，干著這個活，我也是為公司節省成本啊。如果加個程序員呢，質量要稍微高點的，另外就要把P成員的思想工作好好做做，讓他當個全職美工。

      可領導說了，我們這個小公司小項目，這樣哪行呢，這成本太高了，我看你們也不是很忙，先這樣吧。 G成員聽著郁悶，這人家QP成員的確不是很忙... G成員當時就差說：你不換他們那就把我換了吧。畢竟還是飯碗要緊，就吞回去了。得......這一來一切照舊。

      4. 這項目組里都講到了就差個主管，主管我就不給取外號了，比較是主管，咱得尊重。主管呢，是領導派下來的，其實不負責管理，也不負責開發，人家是搞delphi的牛人，但對C#是一竅不通，可是這人偏偏啥都愛插一手。

就說，項目剛開始，G成員思量著上個ORM，就跟主管打個報告，列了幾個ORM的優勢。人家主管就是牛：第二天給回話，不要上什么ORM 了，你看這個sql多好。這不看還好，一看就嚇倒。人家的sql全是寫在 frm上的，直接調用一個公用方法連接到數據庫。看樣子跟他光用講的不行。

　　于是G成員重新整理了一遍ORM的優缺點，又認認真真寫了個demo，再交上去。這次主管2天沒給信，以為有點效果。那天正吃完飯，主管就把G成員給喊過去了，這主管能啊，真是愛學習，電腦上整理一個vs2005：G啊，ORM這個問題，我不是很懂，但我問了幾個朋友，他們說沒啥必要，如果非要上呢，就用這個吧，你看看這是我朋友寫給我的。G成員心里一顫，看來這事要完。一看代碼果然是頭涼到腳。這這這也是orm？ 這寫個sql讀個datatable，再給他賦值給一個對象，然后這對象再給頁面控件賦值，就算OOORRM了？真是 尼瑪的有木有！！！！！！！！！！

　　看官跟你講，這事還沒完。ORM這事是沒戲了，那咱就上個 微軟企業庫，這總行吧。企業庫剛搭建完那天，主管就來了，說，這么長時間了，讓我看看成果。這事沒的說，領導看下工作成果，合情合理。可偏又看出個事。 ExecuteScalar 這個方法，常寫sql連數據庫的人都知道，獲取單值。主管就問了ExecuteScalar這個奇怪的方法是啥意思，G成員就給他解釋：這個是從數據庫獲取單值的。看看主管迷糊，又加一句：就是獲取第一行第一列的那個值。這不加估計迷糊迷糊也就過去了，可這話一出口，主管就笑了（得意的笑，我得意的笑….），這他在行啊。主管說：這個方法以后不要用了，這個跟ExecuteDataSet重復了，你就取DateSet第一行第一列就行了。G成員當時就怒了，XX的，這有完沒完。經過幾回合的較量，終究姜還是老的辣，告到領導那被批回來了。G成員這次算是徹底服了。于是以后有什么東西該藏藏，大氣不出一個，他說他的，我干我的。可這又何苦呢？唉～～～ 一聲哀嘆盡千愁啊！

      5. 對美工P的出走也交待幾句。這美工呢，畢業沒多久，但人好學，所以進步也快。進項目之前就是講好了，等他把C#掌握得能完全參與項目了，他就不干美工了，想寫代碼。這領導也是同意的，結果一直干干干，從去年干到今年，提也提過幾次，也沒聽到什么時候能找美工來替他。而且人家乃是蛟龍，能被這小水潭給困住？就另覓明主去也。這一換工作，工資直接翻番。

　　二、一個估計撐不了多久的項目的發展歷程（原文）

　　之前發了一個抱怨文，把X項目前前后后幾個人全給抱怨了。后面也有很多看管給我回復，有表示哀悼的，表示同情的，也有提意見，送安慰的，甚至還有搶占廣告位的。不管怎么，本人在此表示感謝。

　　抱怨完了，也該反思下項目的歷程和帶來的教訓。此文就先簡述下項目的歷程：估計還是以抱怨為多。望各位諒解。

　　一個估計撐不了多久的項目的

　　發展歷程

　　記得去年的仲夏時間，天氣正是當熱，三十五度算涼快的，三十七八很正常，還經常能串到40的高溫，當然40度往上天氣預報是不敢報的，但明白人都知道，一個鐵皮碗放太陽底下曬個兩分鐘，雞蛋往里一敲，一個五成熟的煎蛋就出爐了，讓人不得不佩服太陽核聚變的威力。

　　X項目就是在這樣水熱火也熱的環境下啟動的。X項目啟動之初，領導只說讓G開個項目，實現這樣一個功能，然后給客戶看看。因為領導并沒有說是正式項目，就權當是原型開發，G就給順便整理個小三層，把頁面先給畫起來，數據讀出來展示，然后就給客戶看了。這個時候的還是直接跟A公司的老總直接聯系的，M先生尚未上任。然后客戶就開始提意見了，要這樣，要那樣的，G就照著做，但一直沒有正式項目的說法，就權當是按范例這樣的簡單方式都給寫了。G也跟領導提過，這個情況是不是應該正式立個項，領導說，再等等。就這樣拖拖拉拉一個多月過去了，代碼也七七八八寫了不少。

　　有一天，領導帶來個人，跟G說，你做的那個程序現在呢正式立項了，這位以后就是你們這個項目的主管，以后有什么問題就找他。G一聽心里樂呵，這個把月沒白搞。Q和P兩位項目成員也就陸續的來報道了。既然正式立項了，那不能按之前那種爛法子做啊，G就尋思著把項目重新架構下，這么大個事當然得跟主管商量下，這一來二去的還算順利（這中間有個關于使用ORM的事，見前文）。就在此時，A公司的M先生也上任了，并指定了跟X項目接頭。M先生之前興許看過原來的demo版本的程序，一聽項目調整，1到2個星期不能有功能產出（項目調整這說法是領導提的，可能是怕客戶有意見），就有點不樂意，催著X項目組趕趕工，這時間太久了。這話就由領導傳到了X項目組，既然是領導發話，X項目組只有惟命是從，G就給大家開了個小會，打打氣，加了一個星期班，連架構，帶實現，把之前一個月的事，大家給翻了個新。

　　這之后的一個月，都是領導親自去客戶調研，然后需求以口頭和少許說明的形式，轉到G這邊，G再根據自己的理解分解素材，設計程序和數據庫，把素材轉化成任務，分配到QP和G自己。我想很多看管可能都看過這樣的圖：

　　在這樣的需求調研下，程序表現往往跟客戶的需求不符。領導就把需求調研的任務干脆就直接交給G了。G兼著項目管理和設計開發，本不想再參與需求調研的事，可主管說他很忙，沒有太多時間調研寫需求文檔，公司又沒有配置專門的需求調研人員，也就只好應承了下來。也就從這個時候開始，G認識了M先生，才了解到需求為何會如此零散。M先生的事，就不過多描述了，畢竟文章還是以X項目發展為主。

　　簡單描述下X項目的組成：此項目為電子商務網站，而網站數據幾乎全依賴外部接口，這個也是由于網站業務所決定的。X項目總共前前后后開發了各式各樣9個外部接口。平均的說是一個月要針對一個接口開發。Q和P2位成員的能力，上個文章也說了，此處不再贅述。P要為X項目畫界面做圖片，尤其是M先生要求網站兼容IE678 FF 和谷歌瀏覽器，這也夠P先生忙一壺的了。而這Q就閑了，每天只等著G設計好了，告訴他功能怎么怎么做，如果這天G沒空設計新功能給他，他就聊一天QQ，聽一天音樂。

　　由此可見G要忙到什么程度。人不怕辛苦就怕比較，辛苦都是可以撐下來的，可要有個人在旁邊這么一比較，這心理真是全然不同了。G是農村出來的娃，辛苦點不怕，只是你辛辛苦苦一天忙到晚，人家坐你旁邊聊QQ，看新聞，這感覺很是不爽，最最關鍵是這閑的主還是得聽你指揮的小弟，這真是要命。于是就出現了前文中要求加人或者換人這樣的事情。無奈項目組加人不成功，G只能繼續匍匐前行。

　　轉眼就到了年底，根據初始合同需求確認書，半年過去了，卻才做完了三分之一多些的功能項，G的心中有些不安。有一次G去A公司跟M先生進行需求調研，講到了對項目目前狀況的擔憂，M先生不愧是過來人，信心滿滿的說，你放心好了，這個項目我肯定給他搞活了，不可能倒。大有一切盡在掌握中的氣勢。雖然M先生如是說，但G心中始終是放下不，就細細總結了這半年的得失，和來年的一些計劃和改進方案，交到主管手里。

　　這個文檔的主要內容這里摘一下：

　　1. 確定項目驅動因素，不能由M先生帶領大家擠牙膏，必須要進行項目遠景定義和功能集合的詳細定義。

　　2. 項目風險總結，將近半年的各種問題進行一個簡單匯總，并請求主管對項目組外的風險提出相應的處理方案。

　　3. 延遲發布周期為1周（原來是，M先生說個需求和修改意見，然后馬上開動，做完就發布給M先生審查，幾乎是一個星期要發布2到3次）,而且一周內已經定好在做的功能，不接受任何修改。

　　4. 提出項目缺陷管理。對項目問題進行統一管理，這中間引起的客戶和開發時間問題，希望主管能夠幫助協調。

　　5. 每日會議的召開。（原來只有1到2周有次項目總結會議），隨時捕獲風險。

　　6.望主管能夠部分接收G手中的項目管理工作，減輕G的工作負擔。

　　也主要摘下主管對這個文檔的回應：

　　1. 明年會跟客戶進行有效溝通。

　　2. 明年會跟領導報告，盡量解決。

　　3. 同意一周發布一次，但也要盡量滿足客戶要求。

　　4. 缺陷問題很重要，要管理，但還是要以客戶發布時間為第一位。缺陷可以后期修改。

　　5. 每日會議，有這個必要嗎？如果沒啥必要就不要開了，大家都比較忙。

　　6. 明年再定，看明年能不能抽出時間來。

　　再主要寫下年后的實際執行情況：

　　1. 不知道主管有沒溝通，反正M先生照舊。

　　2. 好像匯報了，但沒有相應反饋動作。

　　3. 被G強制壓為一周一次發布。M先生起初不滿，但不發布他也無奈，就算是默認了。

　　4. 幾乎是直接就丟下了。原因：主管再次表示要以客戶發布時間為第一位。而G照舊被壓著這么多的活，再來一個缺陷管理完全是自討苦吃，也就放棄了。

　　5. 這個倒是堅持了3個多月，效果還不錯. 本來Q在表達方面就有些問題，就是話說不明白，每次都要被G追問很多遍才能說出點頭緒來。而這導致了Q對G的一些不滿和抵抗。于是美工P一走，就剩下G跟Q2個人，每日會議干脆停掉了。

　　6. 看到4就知道，這個沒戲了。

　　回到去年年底，客戶對項目總體上表示滿意，G估摸著這里面有M先生很多功勞。而公司領導以業績不好為由，讓每人領了200塊的過節費就匆匆回家團聚去了。當年后G從M先生那里了解到年前公司已經拿了X項目絕大部分款項時，已經離過年甚遠，追悔莫及了。而這事也在X項目組3個成員的心里埋下了許多的怨憤。連G先生在內的成員也少不了在閑聊時間，發泄一些對公司的不滿。這也一定程度上，導致了P的出走。有句話叫兵敗如山倒，這P一走，Q也開始緊鑼密鼓的找新單位，終于這個月公司也接到了Q的離職申請。本就人丁不旺的X項目組就剩下2個光桿司令：G和主管。其實Q的離職對項目影響并不大，而P的離職相對來說大的多，P這一走，美工就沒了，而多功能的M先生重操就業兼職做美工，這是G也得佩服的事，說啥來啥，都能上。

　　項目晃晃悠悠的走到了今天，眼看著也要到頭了。而G站在項目的邊緣不知何去何從。

　　三、從G犯的錯誤來看X項目如何失敗的（原文）

　　下面做個簡單分析，從G犯的錯誤來看看X項目失敗的原因。

　　1. G兼著項目管理和設計開發，本不想再參與需求調研的事，可主管說他很忙，沒有太多時間調研寫需求文檔，公司又沒有配置專門的需求調研人員，也就只好應承了下來。 

　　G本身已經兼著太多的職位，導致工作不能做好了，還要去接下一個本可以不搭的事情。這就導致時間更不夠用。時間不夠用將輻射出更多的問題：

　　1) 因為很有多工作壓著，為了能夠按時完成，必然胡亂瞎搞，能省則省，最終的結果就是質量完全不到位。

　　2) 沒有辦法進行有效的總結回顧

　　3) 長此以往，必將導致心理失衡，產生厭煩心理，從快樂工作變成了趕鴨子上架。

　　4) 以上3點連在一起，必然出現惡心循環，最終要么人崩潰，要么項目崩潰。

　　目前想來，解決方法只能是，積極主動而又耐心的反復溝通，對主管和領導進行主動勸說，讓公司安排個人來專門調研需求以及分擔G的其他工作，讓G能夠專心與程序設計開發或者項目管理。上文回復中，有很多人提到了PM的重要性和存在的問題，而G身兼PM在內的多職，必然導致了項目問題，偏偏這么重要的問題，被領導主管和G在內的X項目組成員所忽略。

　　2. 人不怕辛苦就怕比較，辛苦都是可以撐下來的，可要有個人在旁邊這么一比較，這心理真是全然不同了。G是農村出來的娃，辛苦點不怕，只是你辛辛苦苦一天忙到晚，人家坐你旁邊聊QQ，看新聞，這感覺很是不爽，最最關鍵是這閑的主還是得聽你指揮的小弟，這真是要命。

　　這個是心理因素，說明G這個人心理不夠淡定。合理的解決方案之一興許跟1中的一樣，讓人分擔G的工作，使G專心與自己的所長。再者，就是人員合理流動，對于不能達到崗位需求的員工，要及時更換或補充，一方面不至于引起其他成員的不滿，另一方面也是項目成功的必要條件。敏捷開發的中心思想就是以人為本，如果人心渙散，項目想成功都難。黎叔說了，人心散了，隊伍不好帶了，于是黎叔也被抓了。

　　 3. Q在表達方面就有些問題，就是話說不明白，每次都要被G追問很多遍才能說出點頭緒來。而這導致了Q對G的一些不滿和抵抗。 

　　這是對人的管理不善，帶來的嚴重后果之一，G明顯缺乏那種讓人家為他或者為公司賣力的領導能力。此點在2中已經有表現。

　　4. 連G先生在內的成員也少不了在閑聊時間，發泄一些對公司的不滿。

　　G在一定意義上是X項目的負責人，而他帶頭在成員面前表示對公司的不滿，這必將給項目組成員帶領極壞的影響。這個舉動說明了G在管理這個崗位上的不成熟，沒有從大的方向進行考慮問題，而只是一泄心中怨氣。致使人心動搖。 

　　5. M先生提出需求和修改，然后馬上開動，做完就發布給M先生審查，幾乎是一個星期要發布2到3次（此處的發布指，將程序發布到測試服務器，供客戶試用和審查） 

　　這個就是明顯的沒有做好項目管理，簡直就是把項目交給客戶來管。程序發布，還是比較消耗精力的，而發布后，客戶發現的各種錯誤異常，會要求馬上更正，就導致了有時候一天中多次發布的情況出現，就因為幾個很小的錯誤，導致時間消耗在 修改-發布-修改-發布 上。

　　解決方法：

　　1) 按照較長的時間周期進行發布，但不宜過長，比如1周或者2周。并且跟客戶協商好，當前發布版本的錯誤，推遲到下個版本修改。

　　2) 每周邀請客戶代表到公司來參與項目進展會議。讓客戶每星期都能了解到項目在進展，放寬他的心。約定好，每個月發布一次測試版本，讓客戶測試體驗，相關問題，放到后續版本中修復。

　　3) 對需求的獲取和變更進行控制，比如要求客戶形成書面文字，進行需求提交等。

　　6. G照舊被壓著這么多的活，再來一個缺陷管理完全是自討苦吃，也就放棄了。

　　G因為手里活來不及而放棄了缺陷管理，這是可悲的。缺陷管理可以說產品質量的保障之一，缺陷管理那長長的列表尖叫著提醒項目存在的問題。這是一個項目出現質量問題，最顯眼的警報器。沒有缺陷管理，幾乎很難進行項目質量的監督。缺陷管理一開始的缺少和后來提出又放棄，很大程度上決定了項目的失敗的必然，一個不注重質量的項目，談何成功？即使功能全部完成，你敢放到公網上讓黑客轉悠2圈嗎？

　　綜上所述，凸顯出G項目管理能力上的匱乏和心理的不成熟。這是項目走向失敗一個很大的原因所在。在此希望各位看官，能更多的提出G的問題所在，也希望能提供相應的改正建議。在此感激不盡。