我是一名專案經理，在過去的四個月裡，我把乙個專案帶崩了（上線後頻出問題，使用者無法使用）。在最近的幾天，我每天都在反思自己，我都在問自己以下幾個問題：
1.我做錯了什麼？
2.我在其中占有多重的因素？
以下內容，我將回答以上問題，並在最後說一下我的補救措施。
1 專案和團隊背景
首先給大家說明一下專案背景，以便各位對此專案有更清晰的了解：
1.該專案是乙個二次開發專案，第乙個基礎版本（列印申報系統）也由我帶領開發。
2.系統是需要和國家系統對接，有三條主流程。
3.需求頻繁變化，由於系統需要對接國家系統，需求方對需求也不甚了解。曾在5月份乙個月內需求變更超過8次，都是主流程變更。
4.專案大小按照最初需求估算，約在100人天左右。
5.專案兩條主流程無法測試，依賴於外部u盾，但開發過程中並沒有u盾。
6.客戶現場使用u盾除錯和開發時間約為20天左右。
7.我當時同時負責大大小小4個專案，沒有進入開發，僅管控進度。
8.團隊成員共3名，其中兩名是當時開發基礎版本的專案成員，他們對此專案較為熟悉。
9.專案推進過程中，需要多次去現場除錯測試，由團隊中的兩名工程師共同前去。
2 我做錯了什麼
在專案的開發初期，我制定了乙份詳細的開發計畫，用於指導整個開發過程。開發計畫交付與了客戶，而答應了的事情就要做到，所以在整個專案過程中，我對進度管控很嚴。我定期檢查功能是否完成，定期和客戶匯報情況，保證了開發進度順利推進。但也由此埋下了禍根，僅僅看需求是否完成，而未關注完成的質量如何。
專案質量出現了許多細節性問題。比如：
1.上線後，客戶那邊發現其中一條主流程都走不下去
2.其中申報功能，系統提示成功。但實際上並沒有真的申報成功，申報後在國家系統無法查詢到
3.列印功能小問題較多，列印獲取的資料錯誤
4.同步資料的功能無法同步或者同步的資料錯誤
5.執行時間過長的功能，資料庫會強制斷開連線
等等問題，就不一一枚舉
2.2 反思：
1.進度和開發速度固然重要，但以質量換速度不可取
2.如果開發時間和質量衝突，優先保質量，畢竟你埋下的坑，總是要坑你自己的
3.再困難的情況下，也要保證基本測試
4.時間極其不允許的情況下，也要保證主線功能順利執行
專案中的三名成員，都是合格的開發，對使用的框架非常熟悉。其中兩名還是基礎版本開發成員，對需求也很熟悉。所以專案中，我放心的把整個專案交給了他們。基於對他們的放心，加上其他專案事情繁雜，對此專案關注度，對他們的關注度就不夠了。
我在專案中給予了他們非常充分的信任，信任他們可以把一切事情都做好。但我沒有在正確的時候給予他們正確的指引，專案**現的困難點，我也沒有幫助他們解決，甚至於沒有給出思路。所有的一切，都靠他們自己完成。我在這個專案裡做的，就是對接客戶，催進度。再無第三件事。
2.4 反思：
1.不論什麼原因，都要關注到專案成員的狀態
2.給予信任沒錯，但也要適當保持警惕，他們多少會因為經驗問題疏忽遺漏一些問題
3.給予信任，也要給予幫助，不以時間為理由推脫你應該對他們進行的指點和幫助。畢竟現在剩下來一分鐘，以後要花乙個小時去彌補
這是我在專案中做的最錯誤的地方。
由於種種原因，我無法掌握到專案的每個要點和細節。而專案中有三個開發。我並沒指明其中某乙個來負責整個專案，所有事情都讓他們自己商量。從客戶對接來的問題，我也是僅告知對應的開發。整個專案中，沒有乙個人對專案中的每個要點瞭如指掌。
2.6 反思：
1.手裡捏著管理的權利，卻沒有做到管理的事情。是我在這個專案裡最大的問題
2.授權！授權！授權！如果自己無法親力親為投入專案管理工作，就授權給團隊某個成員管理許可權，讓他代替你去做管理工作
3.管理一人，總比管理多個人輕鬆，也更有效
專案是二次開發、成員對專案很熟悉、專案工作量不大、時間緊。
基於以上原因，我掉以輕心，沒有在專案初期進行專案的設計和規劃，未指定任何開發規範。僅僅告訴開發的同事要多復用，也未檢查他們是否真的復用了。
專案開發中的需求變更，客戶反饋意見，我我都僅僅是告知他們一聲，未做詳細的修改規劃，所有事情都靠嘴說，所有變動都放在了我和他們的腦子裡。
對專案上心程度不夠，未對客戶的需求變更做控制和管理。所有變更都壓押給了開發的同事。
整個專案以及其不規範的方式在執行，我也未在其中起到控制作用，專案開發一團亂麻。
2.8 反思：
1.不做設計，不進開發
2.以管理工具指導開發進行，開發過程中所有變更、反饋做記錄
3.控制需求變更，拒絕不合理的需求
4.需求變更規範化操作，統一變更，而不是直接壓給開發
整個專案過去了幾乎四個月，我僅僅花了兩個多小時簡單看了下**，未指出**的任何問題。這也導致出問題後來我花了成倍的時間來處理code review的工作，並且專案成型後的**修改困難。
專案開發過程中，也未讓開發間互相進行**review，也沒有進行**評審會。
其實****現了很多問題，最後檢查**的時候，發現各種命名不規範、**復用不到位、簡單邏輯複雜寫等等。而這些問題，很大一部分都是早期未做規定，未指定人負責專案、未進行早期code review造成的。開發各自為戰，難免造成**問題。
**質量的問題，淋漓盡致的體現的在專案中，專案中的諸多bug，都是因為**不規範引起的。甚至於開發人員自己對自己寫過的東西，都有些拎不清了。
2.10 反思：
1.**質量非常重要，**越規範bug越少
2.**互評能讓開發更注重自己**的質量
3.code review非常有必要，越早期的code review越能有效的節省後期的時間
我在其中占有多重的因素
100%
我怎麼填坑的
專案上線，問題頻出，使用者不滿。花了8天時間來處理這個問題。幸虧專案不大，我乙個人也能夠挽回。
目前暫時解決完畢，我簡單說一下我是怎麼填坑的：
1.和開發主流程的同事詳細熟悉了所有需求要點
2.基於我對專案需求的熟悉，我花了三天把所有主流程的所有**分析完畢，做出了我認為應該的修改，並實施部署到生產環境測試（這是在給開著的飛機換引擎，但需要u盾才能測試，僅有生產環境的機器有u盾，別無他法）
3.每天花超過12個小時來進行code review 和修改，幾乎每天code review + 修改到凌晨2點多（僅修改了問題較大且影響較小的地方。小問題未修改、牽涉面較廣的地方未修改）
4.每次上班時間的修改讓開發同事坐在旁邊和我一起進行，我進行修改，開發同事在一旁監督。確保我不出錯
5.優化功能點，把我發現的提示問題，和優化點都同步修改進**中，確保使用者體驗不要太糟，以期能挽回一些使用者心態
我所吸取的教訓總結
1.先設計，後開發
2.管理權下放，專案中必須有人全身心負責
3.無論什麼情況都要進行code review
4.壓縮質量得到的進度保證不可取，開發周期不合理決不答應客戶。否則坑了自己坑了同事，更坑了客戶
山貓案例分析
上面這個真實的專案案例，我們可以看到該專案經理梳理總結的還是比較細緻，我暫且以乙個旁觀者角度再提煉下從這個專案中發現的最大的三個問題：
1）需求變更頻繁
「由於系統需要對接國家系統，需求方對需求也不甚了解。曾在5月份乙個月內需求變更超過8次，都是主流程變更。」
看到沒，如果遇到這麼頻繁且影響到核心流程的變更，在正常專案管理過程中是不應該出現的。那麼遇到客戶對需求不懂的情況，作為專案負責人應該如何做？
首先可以找公司懂這塊業務或者熟悉此類系統業務流程的人去把關，來引導客戶對需求的理解，確保大家對需求理解一致，且確保需求能夠解決到當前系統需要解決的問題。這個非常重要，否則如果我們自身對需求把握不到重點，那麼被客戶牽著鼻子做需求變更就會很頻繁了。
然後是要有變更控制審核的，儘管說這是乙個不大的專案，但是發生主流程變更，是應該要求客戶出具書面變更申請的，如果專案有監理，則需要拉上監理一起蓋章簽字確認。
愛情不是你想買想買就能買，需求也不是你想變就能變的。
2）身兼數職，把自己累成狗，也沒法很好兼顧
「我當時同時負責大大小小4個專案。。2.基於我對專案需求的熟悉，我花了三天把所有主流程的所有**分析完畢，做出了我認為應該的修改，並實施部署到生產環境測試（這是在給開著的飛機換引擎，但需要u盾才能測試，僅有生產環境的機器有u盾，別無他法）
3.每天花超過12個小時來進行code review 和修改，幾乎每天code review + 修改到凌晨2點多（僅修改了問題較大且影響較小的地方。小問題未修改、牽涉面較廣的地方未修改）」
這讓我想起了自己之前在某個公司，有的時候真的是這樣，能力越強，公司給你的任務就越來越多，我最高紀錄也是同時負責5個專案，還要身兼大部分的需求工作，好在這幾個專案有部分關鍵節點是錯開的，而且相比這個哥們我也不用參與具體的技術研發這塊。
有的時候要適當學會拒絕，對於專案負責人如果參與專案過程落地環節中的各種細節，會造成一葉障目，看不到專案全域性的重點，而且會導致在關鍵節點上失控。
而一旦失控，專案的問題就會越來越多，長時間把自己身體搞到極度疲憊也會讓自己很難長期繼續下去。專案經理應該專注於專案整體態勢的把控，發現問題及時採取糾偏措施。
3）信任和檢查
當你同時負責多個專案時，意味著你必須做出選擇，你首先要幹的是和專案管理相關的重要事情，其他事情需要盡量信任安排其他的人協助你來處理，哪怕這個人幹某件事沒你幹得好，你也得接受這種現實情況。
試想一下，如果你不給他人機會去犯錯成長，靠你一人累死累活能幹出多大的事情？即便人力資源再緊張，你也要適當學會放手，信任他人，什麼**review，修改**讓兄弟們自己幹，你做好相應的指導和結果檢查即可。
招投標軟體專案管理實戰分享
一名IT經理是如何把專案帶崩的。。。
一名it經理是如何把專案帶崩的。我是一名專案經理，在過去的四個月裡，我把乙個專案帶崩了 上線後頻出問題，使用者無法使用 在最近的幾天，我每天都在反思自己，我都在問自己以下幾個問題 1.我做錯了什麼？2.我在其中占有多重的因素？以下內容，我將回答以上問題，並在最後說一下我的補救措施。1.該專案是乙個二...
一名IT經理是如何把專案帶崩的。。。
我是一名專案經理，在過去的四個月裡，我把乙個專案帶崩了 上線後頻出問題，使用者無法使用 在最近的幾天，我每天都在反思自己，我都在問自己以下幾個問題 1.我做錯了什麼？2.我在其中占有多重的因素？以下內容，我將回答以上問題，並在最後說一下我的補救措施。首先給大家說明一下專案背景，以便各位對此專案有更清...
乙個專案經理是如何把專案帶崩的
我是一名專案經理，在過去的四個月裡，我把乙個專案帶崩了 上線後頻出問題，使用者無法使用 在最近的幾天，我每天都在反思自己，我都在問自己以下幾個問題 1.我做錯了什麼？2.我在其中占有多重的因素？以下內容，我將回答以上問題，並在最後說一下我的補救措施。專案和團隊背景 1 該專案是乙個二次開發專案，第乙...