本文轉載自iOS開發（ID：DS3589）

[[271964]]

我是一名技術總監，在過去的將近一個月的時間里，我把一個項目帶崩了（上線后頻出問題，客戶無法使用）。
在最近的幾天，我每天都在反思自己，并且在不停的問自己：

我做錯了什么？
我在其中占有多重的因素？
復盤，以后如何避免這些坑？

一、先說下我們的項目和團隊背景

首先給大家說明一下項目背景，以便各位對此項目有更清晰的了解：

1.該項目是一個二次開發項目，類似于商城系統，需要有分銷功能。

2.系統是需要和公司內部產品客戶數據接口進行對接。

3.需求頻繁變化，由于系統需要對接公司內部系統，我們對公司的內部產品系統也不甚了解，導致在一個月內需求變更超過3次，都是主要程序流程變更。

4.項目大小按照最初需求估算，約在8人左右（4人開發，3人設計，一人產品）。

5.項目兩條主流程，一個是前端開發，一個是后臺開發，但是我的注意力過于集中前端看到的。

6.總共開發周期為20天左右。

7.我當時同時負責公司大大小小4個項目，沒有及時進入開發，僅管控進度。

8.團隊成員共8名，其中兩名是做過類似開發的項目成員，他們對此項目較為熟悉。

9.項目推進過程中，需要多次調試測試，但主要由項目中兩名工程師完成。

二、我做錯了什么？

1.除了監控進度，還要管理質量。

在項目的開發初期，我制定了一份詳細的開發計劃，用于指導整個開發過程。開發計劃交付與了公司領導，而答應了的事情就要做到，所以在整個項目過程中，我對進度管控很嚴。我定期檢查功能是否完成，定期和領導匯報情況，保證了開發進度順利推進。但也由此埋下了禍根，僅僅看需求是否完成，而未關注完成的質量如何。

項目質量出現了許多細節性問題。比如：

1.上線后，用戶那邊發現其中一條主要流程都走不下去

2.其中分銷功能，系統提示成功。但實際上并沒有真的數據結算成功，后在系統無法查詢到。

3.打印功能小問題較多，打印獲取的數據錯誤。

4.同步數據的功能無法同步或者同步的數據錯誤。

5.執行時間過長的功能，數據庫會強制斷開連接。

等等問題，就不一一列舉

反思：

1.開發的進度和開發速度固然重要，但以質量換速度不可取，最終速度和質量都沒有提高。

2.如果開發時間和質量沖突，優先保質量，畢竟你埋下的坑，總是要坑你自己的，最后還得你自己去填。

3.再困難的情況下，也要保證基本測試。

4.時間極其不允許的情況下，也要保證主線功能順利執行，很重要。

2.既要給予信任，也要保持警惕

項目中的四名后端成員，都是合格的開發，對使用的框架非常熟悉。其中兩名還是對此系統非常有研究，對需求也很熟悉。在整個項目周期中，我放心的把整個項目交給了他們。基于對他們的放心，加上其他項目事情繁雜，對此項目關注度，對他們的關注度就不夠了。

我在項目中給予了他們非常充分的信任，信任他們可以把一切事情都做好。但我沒有在正確的時候給予他們正確的指引，項目中出現的困難點，我也沒有幫助他們解決，甚至于沒有給出思路。所有的一切，都靠他們自己完成。我在這個項目里做的，就是和領導溝通細節，催進度。再無第三件事。

反思：

1.不論什么原因，都要關注到項目成員的狀態，看是否有開發過程中的異常。

2.給予信任沒錯，但也要適當保持警惕，他們多少會因為經驗問題疏忽遺漏一些問題。

3.給予信任，也要給予幫助，不以時間為理由推脫你應該對他們進行的指點和幫助。畢竟現在省下來一分鐘，以后要花一個小時或者更長時間去彌補。

4.若無法全局掌控，就指派專人負責，至少需要一個臨時負責人和你進行對接。

3.手里捏著管理全局的權利，卻沒有做到管理的事情

由于種種原因，我無法掌握到項目的每個要點和細節。而項目中有好幾個開發人員。我并沒指明其中某一個來負責整個項目，所有事情都讓他們自己商量。從領導對接來的問題，我也是僅告知對應的開發。整個項目中，沒有一個人對項目中的每個要點了如指掌，當然我也沒有進行充分的溝通。

反思：

1.手里捏著管理全局的權利，卻沒有做到管理的事情。是我在這個項目里最大的問題，這里面也有懶的心理因素。

2.授權！授權！授權！如果自己無法親力親為投入項目管理開發工作中，就授權給團隊某個成員管理權限，讓他代替你去做管理工作。

3.管理一人，總比管理多個人輕松，也更有效，因為你只需跟他溝通。

4.要控制需求，更要控制流程

因為項目是二次開發、成員對項目很熟悉、項目工作量不大、時間緊。

基于以上原因，我掉以輕心，沒有在項目初期進行項目的設計和規劃，未指定任何開發規范。僅僅告訴開發的同事要多復用，也未檢查他們是否真的復用了。

項目開發中的需求變更，用戶反饋意見，我我都僅僅是告知他們一聲，未做詳細的修改規劃，所有事情都靠嘴說，所有變動都放在了我和他們的腦子里，僅僅是嘴說，很難形成標準，口說無憑。

對項目上心程度不夠，未對領導的需求變更做控制和管理。所有變更都壓給了開發的同事。

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

復盤：

1.不做設計（需求），不進開發。

2.以管理工具指導開發進行，開發過程中所有變更、反饋做記錄。

3.控制需求變更，拒絕不合理的需求。

4.需求變更規范化操作，統一變更，而不是直接壓給開發。

無論什么情況下，都要進行code review（輕量級代碼評審）。

整個項目過去了幾乎四個月，我僅僅花了一個多小時簡單看了下代碼，導致未指出代碼的任何問題。這也導致出問題后來我花了成倍的時間來處理code review的工作，并且項目成型后的代碼修改困難。項目開發過程中，也未讓開發間互相進行代碼review，也沒有進行代碼評審，和項目組及時溝通。

其實代碼中出現了很多問題，最后檢查代碼的時候，發現各種命名不規范、代碼復用不到位、簡單邏輯復雜寫等等。而這些問題，很大一部分都是早期未做規定，未指定人負責項目、未進行早期code review造成的。開發各自為戰，難免造成代碼問題。

代碼質量的問題，淋漓盡致的體現的在項目中，項目中的諸多bug，都是因為代碼不規范引起的。甚至于開發人員自己對自己寫過的東西，都有些拎不清了，最終結果就是推倒重寫。

反思：

1.代碼質量非常重要，代碼越規范bug越少。

2.代碼互評能讓開發更注重自己代碼的質量。

3.code review非常有必要，越早期的code review越能有效的節省后期的時間。

我在其中占有多重的因素——100%

三、我怎么填坑的

項目上線，問題頻出，領導不滿。花了8天時間來處理這個問題。幸虧項目不大，我一個人也能夠挽回。

我簡單說一下我是怎么填坑的：

1.和開發主要流程的同事詳細熟悉了所有需求要點，越詳細越好。

2.基于我對項目需求的熟悉，我花了三天把所有主要流程的所有代碼分析完畢，做出了我認為應該的修改（寫好注釋），并實施部署到生產環境測試。

3.每天花超過一半的工作時間來進行code review 和修改，幾乎每天code review + 修改到23點多（時間緊，僅修改了問題較大且影響較小的地方。小問題未修改、牽涉面較廣的地方未修改）。

4.每次上班時間的修改讓開發同事坐在旁邊和我一起進行，我進行修改，開發同事在一旁監督。確保我不出錯。

5.優化功能點，把我發現的提示問題，和優化點都同步修改進代碼中，確保用戶體驗不要太糟，以期能挽回一些用戶心態。

6.代碼已經要及時進行備注（注釋），很重要，一定要規范，方便下次你再次開放使用，最好形成文檔形式。

四、我所吸取的教訓總結

1.先設計（需求），后開發。

2.管理權下放，項目中必須有人帶頭負責。

3.無論什么情況都要進行code review。

4.壓縮代碼質量得到的項目進度保證不可取，開發周期一定要和客戶溝通清楚。否則坑了自己坑了同事，更坑了客戶。

每個技術人在走向管理的道路上都會遭遇不同的困難與問題，想要建立自己的管理方法論，除了從實踐中經歷、總結以外，還需要聆聽更多同行及導師經過時間驗證的經驗，CTO訓練營，20余位CTO導師精益分享，構筑技術管理的體系化思維及底層方法論，工具+案例+實操演練的方式保證落地實用，第七季正在報名中，歡迎加入。

招生要求：

CTO訓練營第七季，共招生40個名額，采用【申請審核】報名機制，以下條件二選一滿足的，可掃碼申請：

A類-曾任或現任公司知名企業技術管理者

B類-創業公司核心創始人、技術高管

學習時間：

2019年10月-2020年5月，每月一個模塊，每次2天，共14天

課程費用：32000元/人

學習地點：北京

報名咨詢：張瑞 18401576051（同微信）