我是一名項目經(jīng)理，在過去的四個月里庆捺，我把一個項目帶崩了（上線后頻出問題古今，用戶無法使用）。在最近的幾天滔以，我每天都在反思自己捉腥，我都在問自己以下幾個問題：
1.我做錯了什么？
2.我在其中占有多重的因素你画？
以下內(nèi)容抵碟，我將回答以上問題，并在最后說一下我的補救措施坏匪。
一拟逮、項目和團隊背景
首先給大家說明一下項目背景，以便各位對此項目有更清晰的了解：
1.該項目是一個二次開發(fā)項目适滓，第一個基礎(chǔ)版本（打印申報系統(tǒng)）也由我?guī)ьI(lǐng)開發(fā)敦迄。
2.系統(tǒng)是需要和國家系統(tǒng)對接，有三條主流程凭迹。
3.需求頻繁變化罚屋，由于系統(tǒng)需要對接國家系統(tǒng)，需求方對需求也不甚了解嗅绸。曾在5月份一個月內(nèi)需求變更超過8次脾猛，都是主流程變更。
4.項目大小按照最初需求估算朽砰，約在100人天左右尖滚。
5.項目兩條主流程無法測試，依賴于外部U盾瞧柔，但開發(fā)過程中并沒有U盾漆弄。
6.客戶現(xiàn)場使用U盾調(diào)試和開發(fā)時間約為20天左右。
7.我當時同時負責大大小小4個項目造锅，沒有進入開發(fā)撼唾，僅管控進度。
8.團隊成員共3名哥蔚，其中兩名是當時開發(fā)基礎(chǔ)版本的項目成員倒谷，他們對此項目較為熟悉蛛蒙。
9.項目推進過程中，需要多次去現(xiàn)場調(diào)試測試渤愁，由團隊中的兩名工程師共同前去牵祟。
二、我做錯了什么
1
除了監(jiān)控進度抖格，還要管理質(zhì)量
在項目的開發(fā)初期诺苹，我制定了一份詳細的開發(fā)計劃，用于指導(dǎo)整個開發(fā)過程雹拄。開發(fā)計劃交付與了客戶收奔，而答應(yīng)了的事情就要做到，所以在整個項目過程中滓玖，我對進度管控很嚴坪哄。我定期檢查功能是否完成，定期和客戶匯報情況势篡，保證了開發(fā)進度順利推進翩肌。但也由此埋下了禍根，僅僅看需求是否完成殊霞，而未關(guān)注完成的質(zhì)量如何摧阅。
項目質(zhì)量出現(xiàn)了許多細節(jié)性問題。比如：
1.上線后绷蹲，客戶那邊發(fā)現(xiàn)其中一條主流程都走不下去
2.其中申報功能，系統(tǒng)提示成功顾孽。但實際上并沒有真的申報成功祝钢，申報后在國家系統(tǒng)無法查詢到
3.打印功能小問題較多，打印獲取的數(shù)據(jù)錯誤
4.同步數(shù)據(jù)的功能無法同步或者同步的數(shù)據(jù)錯誤
5.執(zhí)行時間過長的功能若厚，數(shù)據(jù)庫會強制斷開連接
等等問題拦英，就不一一列舉
反思：
1.進度和開發(fā)速度固然重要，但以質(zhì)量換速度不可取
2.如果開發(fā)時間和質(zhì)量沖突测秸，優(yōu)先保質(zhì)量疤估，畢竟你埋下的坑，總是要坑你自己的
3.再困難的情況下霎冯，也要保證基本測試
4.時間極其不允許的情況下铃拇，也要保證主線功能順利執(zhí)行
2
既要給予信任，也要保持警惕
項目中的三名成員沈撞，都是合格的開發(fā)慷荔，對使用的框架非常熟悉。其中兩名還是基礎(chǔ)版本開發(fā)成員缠俺，對需求也很熟悉显晶。所以項目中贷岸，我放心的把整個項目交給了他們×坠停基于對他們的放心偿警，加上其他項目事情繁雜，對此項目關(guān)注度唯笙，對他們的關(guān)注度就不夠了螟蒸。
我在項目中給予了他們非常充分的信任，信任他們可以把一切事情都做好睁本。但我沒有在正確的時候給予他們正確的指引尿庐，項目中出現(xiàn)的困難點，我也沒有幫助他們解決呢堰，甚至于沒有給出思路抄瑟。所有的一切，都靠他們自己完成枉疼。我在這個項目里做的皮假，就是對接客戶，催進度骂维。再無第三件事惹资。
反思：
1.不論什么原因，都要關(guān)注到項目成員的狀態(tài)
2.給予信任沒錯航闺，但也要適當保持警惕褪测，他們多少會因為經(jīng)驗問題疏忽遺漏一些問題
3.給予信任，也要給予幫助潦刃，不以時間為理由推脫你應(yīng)該對他們進行的指點和幫助侮措。畢竟現(xiàn)
在剩下來一分鐘，以后要花一個小時去彌補
3
若無法全局掌控乖杠，就指派專人負責
這是我在項目中做的最錯誤的地方分扎。
由于種種原因，我無法掌握到項目的每個要點和細節(jié)胧洒。而項目中有三個開發(fā)畏吓。我并沒指明其中某一個來負責整個項目，所有事情都讓他們自己商量卫漫。從客戶對接來的問題菲饼，我也是僅告知對應(yīng)的開發(fā)。整個項目中汛兜，沒有一個人對項目中的每個要點了如指掌巴粪。
反思：
1.手里捏著管理的權(quán)利，卻沒有做到管理的事情。是我在這個項目里最大的問題
2.授權(quán)肛根！授權(quán)辫塌！授權(quán)！如果自己無法親力親為投入項目管理工作派哲，就授權(quán)給團隊某個成員管理權(quán)限臼氨，讓他代替你去做管理工作
3.管理一人，總比管理多個人輕松芭届，也更有效
4
要控制需求储矩，更要控制流程
項目是二次開發(fā)、成員對項目很熟悉褂乍、項目工作量不大持隧、時間緊。
基于以上原因逃片，我掉以輕心屡拨，沒有在項目初期進行項目的設(shè)計和規(guī)劃，未指定任何開發(fā)規(guī)范褥实。僅僅告訴開發(fā)的同事要多復(fù)用呀狼，也未檢查他們是否真的復(fù)用了。
項目開發(fā)中的需求變更损离，客戶反饋意見哥艇，我我都僅僅是告知他們一聲，未做詳細的修改規(guī)劃僻澎，所有事情都靠嘴說貌踏，所有變動都放在了我和他們的腦子里。
對項目上心程度不夠窟勃，未對客戶的需求變更做控制和管理哩俭。所有變更都壓給了開發(fā)的同事。
整個項目以及其不規(guī)范的方式在運行拳恋，我也未在其中起到控制作用，項目開發(fā)一團亂麻砸捏。
反思：
1.不做設(shè)計谬运，不進開發(fā)
2.以管理工具指導(dǎo)開發(fā)進行，開發(fā)過程中所有變更垦藏、反饋做記錄
3.控制需求變更梆暖，拒絕不合理的需求
4.需求變更規(guī)范化操作，統(tǒng)一變更掂骏，而不是直接壓給開發(fā)
5
無論什么情況下轰驳，都要進行code review
整個項目過去了幾乎四個月，我僅僅花了兩個多小時簡單看了下代碼，未指出代碼的任何問題级解。這也導(dǎo)致出問題后來我花了成倍的時間來處理code review的工作冒黑，并且項目成型后的代碼修改困難。
項目開發(fā)過程中勤哗，也未讓開發(fā)間互相進行代碼review抡爹，也沒有進行代碼評審會。
其實代碼中出現(xiàn)了很多問題芒划，最后檢查代碼的時候冬竟，發(fā)現(xiàn)各種命名不規(guī)范、代碼復(fù)用不到位民逼、簡單邏輯復(fù)雜寫等等泵殴。而這些問題，很大一部分都是早期未做規(guī)定拼苍，未指定人負責項目笑诅、未進行早期code review造成的。開發(fā)各自為戰(zhàn)映屋，難免造成代碼問題苟鸯。
代碼質(zhì)量的問題，淋漓盡致的體現(xiàn)的在項目中棚点，項目中的諸多bug早处，都是因為代碼不規(guī)范引起的。甚至于開發(fā)人員自己對自己寫過的東西瘫析，都有些拎不清了砌梆。
反思：
1.代碼質(zhì)量非常重要，代碼越規(guī)范bug越少
2.代碼互評能讓開發(fā)更注重自己代碼的質(zhì)量
3.code review非常有必要贬循，越早期的code review越能有效的節(jié)省后期的時間
三咸包、我在其中占有多重的因素
100%
四、我怎么填坑的
項目上線杖虾，問題頻出烂瘫，用戶不滿∑媸剩花了8天時間來處理這個問題坟比。幸虧項目不大，我一個人也能夠挽回嚷往。
目前暫時解決完畢葛账，我簡單說一下我是怎么填坑的：
1.和開發(fā)主流程的同事詳細熟悉了所有需求要點
2.基于我對項目需求的熟悉，我花了三天把所有主流程的所有代碼分析完畢皮仁，做出了我認為應(yīng)該的修改籍琳，并實施部署到生產(chǎn)環(huán)境測試（這是在給開著的飛機換引擎菲宴，但需要U盾才能測試，僅有生產(chǎn)環(huán)境的機器有U盾趋急，別無他法）
3.每天花超過12個小時來進行code review 和修改喝峦，幾乎每天code review + 修改到凌晨2點多（僅修改了問題較大且影響較小的地方。小問題未修改宣谈、牽涉面較廣的地方未修改）
4.每次上班時間的修改讓開發(fā)同事坐在旁邊和我一起進行愈犹，我進行修改，開發(fā)同事在一旁監(jiān)督闻丑。確保我不出錯
5.優(yōu)化功能點漩怎，把我發(fā)現(xiàn)的提示問題，和優(yōu)化點都同步修改進代碼中嗦嗡，確保用戶體驗不要太糟勋锤，以期能挽回一些用戶心態(tài)
五、我所吸取的教訓(xùn)總結(jié)
1.先設(shè)計侥祭，后開發(fā)
2.管理權(quán)下放叁执，項目中必須有人全身心負責
3.無論什么情況都要進行code review
4.壓縮質(zhì)量得到的進度保證不可取，開發(fā)周期不合理決不答應(yīng)客戶矮冬。否則坑了自己坑了同事谈宛，更坑了客戶
