我是一名項目經理,把一個項目帶崩了--案例分析

​ 這是山貓的第61篇原創html

今天來給你們看個真實案例分析(如下爲案例故事):數據庫

我是一名項目經理,在過去的四個月裏,我把一個項目帶崩了(上線後頻出問題,用戶沒法使用)。在最近的幾天,我天天都在反思本身,我都在問本身如下幾個問題:框架

1.我作錯了什麼?
2.我在其中佔有多重的因素?ide

如下內容,我將回答以上問題,並在最後說一下個人補救措施。工具

1 項目和團隊背景測試

首先給你們說明一下項目背景,以便各位對此項目有更清晰的瞭解:
1.該項目是一個二次開發項目,第一個基礎版本(打印申報系統)也由我帶領開發。
2.系統是須要和國家系統對接,有三條主流程。
3.需求頻繁變化,因爲系統須要對接國家系統,需求方對需求也不甚瞭解。曾在5月份一個月內需求變動超過8次,都是主流程變動。
4.項目大小按照最初需求估算,約在100人天左右。
5.項目兩條主流程沒法測試,依賴於外部U盾,但開發過程當中並無U盾。
6.客戶現場使用U盾調試和開發時間約爲20天左右。
7.我當時同時負責大大小小4個項目,沒有進入開發,僅管控進度。
8.團隊成員共3名,其中兩名是當時開發基礎版本的項目成員,他們對此項目較爲熟悉。
9.項目推動過程當中,須要屢次去現場調試測試,由團隊中的兩名工程師共同前去。優化

2 我作錯了什麼設計

2.1除了監控進度,還要管理質量
在項目的開發初期,我制定了一份詳細的開發計劃,用於指導整個開發過程。開發計劃交付與了客戶,而答應了的事情就要作到,因此在整個項目過程當中,我對進度管控很嚴。我按期檢查功能是否完成,按期和客戶彙報狀況,保證了開發進度順利推動。但也由此埋下了禍根,僅僅看需求是否完成,而未關注完成的質量如何。調試

項目質量出現了許多細節性問題。好比:
1.上線後,客戶那邊發現其中一條主流程都走不下去
2.其中申報功能,系統提示成功。但實際上並無真的申報成功,申報後在國家系統沒法查詢到
3.打印功能小問題較多,打印獲取的數據錯誤
4.同步數據的功能沒法同步或者同步的數據錯誤
5.執行時間過長的功能,數據庫會強制斷開鏈接
等等問題,就不一一列舉code

2.2 反思:

1.進度和開發速度當然重要,但以質量換速度不可取

2.若是開發時間和質量衝突,優先保質量,畢竟你埋下的坑,老是要坑你本身的

3.再困難的狀況下,也要保證基本測試

4.時間極其不容許的狀況下,也要保證主線功能順利執行

2.3 既要給予信任,也要保持警戒
項目中的三名成員,都是合格的開發,對使用的框架很是熟悉。其中兩名仍是基礎版本開發成員,對需求也很熟悉。因此項目中,我放心的把整個項目交給了他們。基於對他們的放心,加上其餘項目事情繁雜,對此項目關注度,對他們的關注度就不夠了。

我在項目中給予了他們很是充分的信任,信任他們能夠把一切事情都作好。但我沒有在正確的時候給予他們正確的指引,項目中出現的困難點,我也沒有幫助他們解決,甚至於沒有給出思路。全部的一切,都靠他們本身完成。我在這個項目裏作的,就是對接客戶,催進度。再無第三件事。

2.4 反思:
1.不論什麼緣由,都要關注到項目成員的狀態
2.給予信任沒錯,但也要適當保持警戒,他們多少會由於經驗問題疏忽遺漏一些問題
3.給予信任,也要給予幫助,不以時間爲理由推脫你應該對他們進行的指點和幫助。畢竟如今剩下來一分鐘,之後要花一個小時去彌補

2.5 若沒法全局掌控,就指派專人負責
這是我在項目中作的最錯誤的地方。

因爲種種緣由,我沒法掌握到項目的每一個要點和細節。而項目中有三個開發。我並沒指明其中某一個來負責整個項目,全部事情都讓他們本身商量。從客戶對接來的問題,我也是僅告知對應的開發。整個項目中,沒有一我的對項目中的每一個要點了如指掌。

2.6 反思:
1.手裏捏着管理的權利,卻沒有作到管理的事情。是我在這個項目裏最大的問題
2.受權!受權!受權!若是本身沒法親力親爲投入項目管理工做,就受權給團隊某個成員管理權限,讓他代替你去作管理工做
3.管理一人,總比管理多我的輕鬆,也更有效

2.7 要控制需求,更要控制流程
項目是二次開發、成員對項目很熟悉、項目工做量不大、時間緊。

基於以上緣由,我掉以輕心,沒有在項目初期進行項目的設計和規劃,未指定任何開發規範。僅僅告訴開發的同事要多複用,也未檢查他們是否真的複用了。

項目開發中的需求變動,客戶反饋意見,我我都僅僅是告知他們一聲,未作詳細的修改規劃,全部事情都靠嘴說,全部變更都放在了我和他們的腦子裏。

對項目上心程度不夠,未對客戶的需求變動作控制和管理。全部變動都壓押給了開發的同事。

整個項目以及其不規範的方式在運行,我也未在其中起到控制做用,項目開發一團亂麻。

2.8 反思:
1.不作設計,不進開發
2.以管理工具指導開發進行,開發過程當中全部變動、反饋作記錄
3.控制需求變動,拒毫不合理的需求
4.需求變動規範化操做,統一變動,而不是直接壓給開發

2.9 不管什麼狀況下,都要進行code review
整個項目過去了幾乎四個月,我僅僅花了兩個多小時簡單看了下代碼,未指出代碼的任何問題。這也致使出問題後來我花了成倍的時間來處理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.壓縮質量獲得的進度保證不可取,開發週期不合理決不答應客戶。不然坑了本身坑了同事,更坑了客戶

以上案例做者:r0black 原文 http://www.javashuo.com/article/p-vxjarvyv-x.html

**山貓案例分析**

上面這個真實的項目案例,咱們能夠看到該項目經理梳理總結的仍是比較細緻,我暫且以一個旁觀者角度再提煉下從這個項目中發現的最大的三個問題:

1)需求變動頻繁

「因爲系統須要對接國家系統,需求方對需求也不甚瞭解。曾在5月份一個月內需求變動超過8次,都是主流程變動。」

看到沒,若是遇到這麼頻繁且影響到核心流程的變動,在正常項目管理過程當中是不該該出現的。那麼遇到客戶對需求不懂的狀況,做爲項目負責人應該如何作?

首先能夠找公司懂這塊業務或者熟悉此類系統業務流程的人去把關,來引導客戶對需求的理解,確保你們對需求理解一致,且確保需求可以解決到當前系統須要解決的問題。這個很是重要,不然若是咱們自身對需求把握不到重點,那麼被客戶牽着鼻子作需求變動就會很頻繁了。

而後是要有變動控制審覈的,儘管說這是一個不大的項目,可是發生主流程變動,是應該要求客戶出具書面變動申請的,若是項目有監理,則須要拉上監理一塊兒蓋章簽字確認。

愛情不是你想買想買就能買,需求也不是你想變就能變的

2)身兼數職,把本身累成狗,也無法很好兼顧

「我當時同時負責大大小小4個項目。。2.基於我對項目需求的熟悉,我花了三天把全部主流程的全部代碼分析完畢,作出了我認爲應該的修改,並實施部署到生產環境測試(這是在給開着的飛機換引擎,但須要U盾才能測試,僅有生產環境的機器有U盾,別無他法)

3.天天花超過12個小時來進行code review 和修改,幾乎天天code review + 修改到凌晨2點多(僅修改了問題較大且影響較小的地方。小問題未修改、牽涉面較廣的地方未修改)」

這讓我想起了本身以前在某個公司,有的時候真的是這樣,能力越強,公司給你的任務就愈來愈多,我最高紀錄也是同時負責5個項目,還要身兼大部分的需求工做,好在這幾個項目有部分關鍵節點是錯開的,並且相比這個哥們我也不用參與具體的技術研發這塊。

有的時候要適當學會拒絕,對於項目負責人若是參與項目過程落地環節中的各類細節,會形成一葉障目,看不到項目全局的重點,並且會致使在關鍵節點上失控。

而一旦失控,項目的問題就會愈來愈多,長時間把本身身體搞到極度疲憊也會讓本身很難長期繼續下去。項目經理應該專一於項目總體態勢的把控,發現問題及時採起糾偏措施。

3)信任和檢查

當你同時負責多個項目時,意味着你必須作出選擇,你首先要乾的是和項目管理相關的重要事情,其餘事情須要儘可能信任安排其餘的人協助你來處理,哪怕這我的幹某件事沒你幹得好,你也得接受這種現實狀況。

試想一下,若是你不給他人機會去犯錯成長,靠你一人累死累活能幹出多大的事情?即使人力資源再緊張,你也要適當學會放手,信任他人,什麼代碼Review,修改代碼讓兄弟們本身幹,你作好相應的指導和結果檢查便可。

最後,這個案例是否有讓你有似曾相識的感受?從案例分析中,你有收穫到了什麼嗎?歡迎留言分享。

相關文章
相關標籤/搜索