<tr id="yjjbo"></tr>

      1. <ruby id="yjjbo"><option id="yjjbo"></option></ruby>
      2.   
        首頁>項目經理 > 正文

        一名IT經理是如何把項目帶崩的…

        2018-11-06    來源:zer0black
               我是一名項目經理,在過去的四個月里,我把一個項目帶崩了(上線后頻出問題,用戶無法使用)。在最近的幾天,我每天都在反思自己,我都在問自己以下幾個問題:
               1.我做錯了什么?
               2.我在其中占有多重的因素?
               以下內容,我將回答以上問題,并在最后說一下我的補救措施。
               一、項目和團隊背景
               首先給大家說明一下項目背景,以便各位對此項目有更清晰的了解:
               1.該項目是一個二次開發項目,第一個基礎版本(打印申報系統)也由我帶領開發。
               2.系統是需要和國家系統對接,有三條主流程。
               3.需求頻繁變化,由于系統需要對接國家系統,需求方對需求也不甚了解。曾在5月份一個月內需求變更超過8次,都是主流程變更。
               4.項目大小按照最初需求估算,約在100人天左右。
               5.項目兩條主流程無法測試,依賴于外部U盾,但開發過程中并沒有U盾。
               6.客戶現場使用U盾調試和開發時間約為20天左右。
               7.我當時同時負責大大小小4個項目,沒有進入開發,僅管控進度。
               8.團隊成員共3名,其中兩名是當時開發基礎版本的項目成員,他們對此項目較為熟悉。
               9.項目推進過程中,需要多次去現場調試測試,由團隊中的兩名工程師共同前去。
               二、我做錯了什么
              (一)除了監控進度,還要管理質量。
               在項目的開發初期,我制定了一份詳細的開發計劃,用于指導整個開發過程。開發計劃交付給了客戶,答應了的事情就要做到,所以在整個項目過程中,我對進度管控很嚴。我定期檢查功能是否完成,定期和客戶匯報情況,保證了開發進度順利推進。但也由此埋下了禍根,僅僅看需求是否完成,而未關注完成的質量如何。
               項目質量出現了許多細節性問題。比如:
               1.上線后,客戶那邊發現其中一條主流程都走不下去。
               2.其中申報功能,系統提示成功,但實際上并沒有真的申報成功,申報后在國家系統無法查詢到。
               3.打印功能小問題較多,打印獲取的數據錯誤。
               4.同步數據的功能無法同步或者同步的數據錯誤。
               5.執行時間過長的功能,數據庫會強制斷開連接。
               等等問題,就不一一列舉。
               反思:
               1.進度和開發速度固然重要,但以質量換速度不可取。
               2.如果開發時間和質量沖突,優先保質量,畢竟你埋下的坑,總是要坑你自己的。
               3.再困難的情況下,也要保證基本測試。
               4.時間極其不允許的情況下,也要保證主線功能順利執行。
              (二)既要給予信任,也要保持警惕。
               項目中的三名成員,都是合格的開發,對使用的框架非常熟悉。其中兩名還是基礎版本開發成員,對需求也很熟悉。所以項目中,我放心地把整個項目交給了他們?;趯λ麄兊姆判?,加上其他項目事情繁雜,對此項目關注度和對他們的關注度就不夠了。
               我在項目中給予了他們非常充分的信任,信任他們可以把一切事情都做好。但我沒有在正確的時候給予他們正確的指引,項目中出現的困難點,我也沒有幫助他們解決,甚至于沒有給出思路。所有的一切,都靠他們自己完成。我在這個項目里做的,就是對接客戶,催進度,再無第三件事。
               反思:
               1.不論什么原因,都要關注到項目成員的狀態。
               2.給予信任沒錯,但也要適當保持警惕,他們多少會因為經驗問題疏忽遺漏一些問題。
               3.給予信任,也要給予幫助,不以時間為理由推脫你應該對他們進行的指點和幫助。畢竟現在省下來一分鐘,以后要花一個小時去彌補。
              (三)若無法全局掌控,就指派專人負責。
               這一點是我在項目中做的最不到位的地方。
               由于種種原因,我無法掌握到項目的每個要點和細節。而項目中有三個開發,我并沒指明其中某一個來負責整個項目,所有事情都讓他們自己商量。從客戶對接來的問題,我也是僅告知對應的開發。整個項目中,沒有一個人對項目中的每個要點了如指掌。
               反思:
               1.手里捏著管理的權利,卻沒有做到管理的事情,是我在這個項目里最大的問題。
               2.授權!授權!授權!如果自己無法親力親為投入項目管理工作,就授權給團隊某個成員管理權限,讓他代替你去做管理工作。
               3.管理一人,總比管理多個人輕松,也更有效。
              (四)要控制需求,更要控制流程。
               項目是二次開發,成員對項目很熟悉,項目工作量不大,時間緊。
               基于以上原因,我掉以輕心,沒有在項目初期進行項目的設計和規劃,未指定任何開發規范。僅僅告訴開發的同事要多復用,也未檢查他們是否真的復用了。
               項目開發中的需求變更,客戶反饋意見,我都僅僅是告知他們一聲,未做詳細的修改規劃,所有事情都靠嘴說,所有變動都放在了我和他們的腦子里。
               對項目上心程度不夠,未對客戶的需求變更做控制和管理。所有變更都壓給了開發的同事。
               整個項目以極其不規范的方式在運行,我也未在其中起到控制作用,項目開發一團亂麻。
               反思:
               1.先設計,后開發。
               2.以管理工具指導開發進行,開發過程中所有變更、反饋做記錄。
               3.控制需求變更,拒絕不合理的需求。
               4.需求變更規范化操作,統一變更,而不是直接壓給開發。
              (五)無論什么情況下,都要進行code review。
               整個項目過去了幾乎四個月,我僅僅花了兩個多小時簡單看了下代碼,未指出代碼的任何問題。這也導致出問題。后來我花了成倍的時間來處理code review的工作,并且項目成型后的代碼修改更困難。
               項目開發過程中,也未讓開發間互相進行code review,也沒有進行代碼評審會。
        其實代碼中出現了很多問題,最后檢查代碼的時候,發現各種命名不規范、代碼復用不到位、簡單邏輯復雜寫等等。而這些問題,很大一部分都是早期未做規定,未指定人負責項目、未進行早期code review造成的。開發各自為戰,難免造成代碼問題。
               代碼質量的問題,淋漓盡致地體現在項目中。項目中的諸多bug,都是因為代碼不規范引起的。甚至于開發人員自己對自己寫過的東西,都有些拎不清了。
               反思:
               1.代碼質量非常重要,代碼越規范bug越少。
               2.代碼互評能讓開發更注重自己代碼的質量。
               3.code review非常有必要,越早期的code review越能有效地節省后期的時間。
               三、我在其中占有多重的因素
               100%。
               四、我怎么填坑的
               項目上線,問題頻出,用戶不滿?;?天時間來處理這個問題。幸虧項目不大,我一個人也能夠挽回。
               目前暫時解決完畢,我簡單說一下我是怎么填坑的:
               1.和開發主流程的同事詳細熟悉了所有需求要點。
               2.基于我對項目需求的熟悉,我花了三天把所有主流程的所有代碼分析完畢,做出了我認為應該的修改,并實施部署到生產環境測試(這是在給開著的飛機換引擎,但需要U盾才能測試,僅有生產環境的機器有U盾,別無他法)。
               3.每天花超過12個小時來進行code review 和修改,幾乎每天code review + 修改到凌晨2點多(僅修改了問題較大且影響較小的地方。小問題未修改,牽涉面較廣的地方未修改)。
               4.每次上班時間的修改讓開發同事坐在旁邊和我一起進行,我進行修改,開發同事在一旁監督,確保我不出錯。
               5.優化功能點,把我發現的提示問題和優化點都同步修改進代碼中,確保用戶體驗不要太糟,以期能挽回一些用戶心態。
               五、我所吸取的教訓總結
               1.先設計,后開發。
               2.管理權下放,項目中必須有人全身心負責。
               3.無論什么情況都要進行code review。
               4.壓縮質量得到的進度保證不可取,開發周期不合理決不答應客戶。否則坑了自己坑了同事,更坑了客戶。

        原文:cnblogs.com/zer0Black/archive/2018/08/13/9463206.html

        作者:zer0black





        分享到:

        免責聲明:
          1、項目經理人發布的所有資訊與文章是出于為業界傳遞更多信息之目的,并不意味著贊同其觀點或證實其描述。其原創性以及文中陳述文字和內容未經本站證實,對本文以及其中全部或者部分內容、文字的真實性、完整性、及時性本站不作任何保證或承諾,請瀏覽者僅作參考,并請自行核實相關內容。
          2、本站部分內容轉載于其他網站和媒體,版權歸原作者或原發布媒體所有。如文章涉及版權等問題,請聯系本站,我們將在兩個工作日內進行刪除或修改處理。敬請諒解!

        關于我們 聯系我們 版權聲明 隱私保護 投訴建議 卓橡資源

        Copyright ? 2021 項目經理人 版權所有 京ICP備17062359號-3 如轉載本站文章,請注明原作者和原發布媒體
        本著互聯網分享精神,本站部分內容轉載于其他網站和媒體,如稿件涉及版權等問題,請聯系本站進行刪除或修改處理
        客服電話:010-89506650 89504891 非工作時間可聯系:18701278071(微信) QQ在線:511524637
        新聞與原創文章投稿:tougao#cpmta.com 客服郵箱:info#cpmta.com(請將#換成@)
        項目經理人——我國項目經理職業發展門戶網站,隸屬卓橡公司

        久久精品99国产精品日本,欧美熟妇黑人ⅩXXXXX,两个小婕子和我做受HD
            <tr id="yjjbo"></tr>

            1. <ruby id="yjjbo"><option id="yjjbo"></option></ruby>