一個失敗軟件項目的思考
反思下項目的歷程和帶來的教訓。此文就先簡述下項目的歷程：估計還是以抱怨為多。望各位諒解。
一個估計撐不了多久的項目的
發展歷程
記得去年的仲夏時間，天氣正是當熱，三十五度算涼快的，三十七八很正常，還經常能串到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項目失敗的原因。
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作為一個PM的不合格：
關于你的：
“是的，PM的問題。***個問題，這個項目就沒有明確的PM。第二個問題，實際上的PM（就是G）不能行使全部的PM權力，受到主管的干擾。第三個問題，客觀上說，G也沒有全心投入PM工作的可能，他還兼著其他多個職位。關于G存在的問題，我會再寫個，估摸著明天發。”
1、沒明確的PM，項目實施難度與失敗的可能性更大，公司管理體制的問題。
2、PM無實權:說明你公司屬于職能型或矩陣型公司，員工面臨兩個直接上司，此時，PM是最無助的，唯一可做的，是先得到***領導的支持，再讓其放權讓PM對此項目放手一博。要不這樣，失敗可能性大，說得明白點，也是PM項目溝通的問題。
3、PM沒全身心投入工作，有PM的原因，也有公司體制的原因，試問，你現在公司的這種體制，一個PM無實權等于沒有PM，其實也是他很無助，沒有辦法。
說到底，要項目經理自己去爭取，要項目團隊去爭取。溝通、溝通、溝通。
原文鏈接：http://www.cnblogs.com/geckor/archive/2011/05/24/2055541.html
【編輯推薦】
