作為技術(shù)總監(jiān),我是怎樣把一個項目帶崩的
本文轉(zhuǎn)載自iOS開發(fā)(ID:DS3589)
我是一名技術(shù)總監(jiān),在過去的將近一個月的時間里,我把一個項目帶崩了(上線后頻出問題,客戶無法使用)。
在最近的幾天,我每天都在反思自己,并且在不停的問自己:
我做錯了什么?
我在其中占有多重的因素?
復盤,以后如何避免這些坑?
一、先說下我們的項目和團隊背景
首先給大家說明一下項目背景,以便各位對此項目有更清晰的了解:
1.該項目是一個二次開發(fā)項目,類似于商城系統(tǒng),需要有分銷功能。
2.系統(tǒng)是需要和公司內(nèi)部產(chǎn)品客戶數(shù)據(jù)接口進行對接。
3.需求頻繁變化,由于系統(tǒng)需要對接公司內(nèi)部系統(tǒng),我們對公司的內(nèi)部產(chǎn)品系統(tǒng)也不甚了解,導致在一個月內(nèi)需求變更超過3次,都是主要程序流程變更。
4.項目大小按照最初需求估算,約在8人左右(4人開發(fā),3人設(shè)計,一人產(chǎn)品)。
5.項目兩條主流程,一個是前端開發(fā),一個是后臺開發(fā),但是我的注意力過于集中前端看到的。
6.總共開發(fā)周期為20天左右。
7.我當時同時負責公司大大小小4個項目,沒有及時進入開發(fā),僅管控進度。
8.團隊成員共8名,其中兩名是做過類似開發(fā)的項目成員,他們對此項目較為熟悉。
9.項目推進過程中,需要多次調(diào)試測試,但主要由項目中兩名工程師完成。
二、我做錯了什么?
1.除了監(jiān)控進度,還要管理質(zhì)量。
在項目的開發(fā)初期,我制定了一份詳細的開發(fā)計劃,用于指導整個開發(fā)過程。開發(fā)計劃交付與了公司領(lǐng)導,而答應(yīng)了的事情就要做到,所以在整個項目過程中,我對進度管控很嚴。我定期檢查功能是否完成,定期和領(lǐng)導匯報情況,保證了開發(fā)進度順利推進。但也由此埋下了禍根,僅僅看需求是否完成,而未關(guān)注完成的質(zhì)量如何。
項目質(zhì)量出現(xiàn)了許多細節(jié)性問題。比如:
1.上線后,用戶那邊發(fā)現(xiàn)其中一條主要流程都走不下去
2.其中分銷功能,系統(tǒng)提示成功。但實際上并沒有真的數(shù)據(jù)結(jié)算成功,后在系統(tǒng)無法查詢到。
3.打印功能小問題較多,打印獲取的數(shù)據(jù)錯誤。
4.同步數(shù)據(jù)的功能無法同步或者同步的數(shù)據(jù)錯誤。
5.執(zhí)行時間過長的功能,數(shù)據(jù)庫會強制斷開連接。
等等問題,就不一一列舉
反思:
1.開發(fā)的進度和開發(fā)速度固然重要,但以質(zhì)量換速度不可取,最終速度和質(zhì)量都沒有提高。
2.如果開發(fā)時間和質(zhì)量沖突,優(yōu)先保質(zhì)量,畢竟你埋下的坑,總是要坑你自己的,最后還得你自己去填。
3.再困難的情況下,也要保證基本測試。
4.時間極其不允許的情況下,也要保證主線功能順利執(zhí)行,很重要。
2.既要給予信任,也要保持警惕
項目中的四名后端成員,都是合格的開發(fā),對使用的框架非常熟悉。其中兩名還是對此系統(tǒng)非常有研究,對需求也很熟悉。在整個項目周期中,我放心的把整個項目交給了他們。基于對他們的放心,加上其他項目事情繁雜,對此項目關(guān)注度,對他們的關(guān)注度就不夠了。
我在項目中給予了他們非常充分的信任,信任他們可以把一切事情都做好。但我沒有在正確的時候給予他們正確的指引,項目中出現(xiàn)的困難點,我也沒有幫助他們解決,甚至于沒有給出思路。所有的一切,都靠他們自己完成。我在這個項目里做的,就是和領(lǐng)導溝通細節(jié),催進度。再無第三件事。
反思:
1.不論什么原因,都要關(guān)注到項目成員的狀態(tài),看是否有開發(fā)過程中的異常。
2.給予信任沒錯,但也要適當保持警惕,他們多少會因為經(jīng)驗問題疏忽遺漏一些問題。
3.給予信任,也要給予幫助,不以時間為理由推脫你應(yīng)該對他們進行的指點和幫助。畢竟現(xiàn)在省下來一分鐘,以后要花一個小時或者更長時間去彌補。
4.若無法全局掌控,就指派專人負責,至少需要一個臨時負責人和你進行對接。
3.手里捏著管理全局的權(quán)利,卻沒有做到管理的事情
由于種種原因,我無法掌握到項目的每個要點和細節(jié)。而項目中有好幾個開發(fā)人員。我并沒指明其中某一個來負責整個項目,所有事情都讓他們自己商量。從領(lǐng)導對接來的問題,我也是僅告知對應(yīng)的開發(fā)。整個項目中,沒有一個人對項目中的每個要點了如指掌,當然我也沒有進行充分的溝通。
反思:
1.手里捏著管理全局的權(quán)利,卻沒有做到管理的事情。是我在這個項目里最大的問題,這里面也有懶的心理因素。
2.授權(quán)!授權(quán)!授權(quán)!如果自己無法親力親為投入項目管理開發(fā)工作中,就授權(quán)給團隊某個成員管理權(quán)限,讓他代替你去做管理工作。
3.管理一人,總比管理多個人輕松,也更有效,因為你只需跟他溝通。
4.要控制需求,更要控制流程
因為項目是二次開發(fā)、成員對項目很熟悉、項目工作量不大、時間緊。
基于以上原因,我掉以輕心,沒有在項目初期進行項目的設(shè)計和規(guī)劃,未指定任何開發(fā)規(guī)范。僅僅告訴開發(fā)的同事要多復用,也未檢查他們是否真的復用了。
項目開發(fā)中的需求變更,用戶反饋意見,我我都僅僅是告知他們一聲,未做詳細的修改規(guī)劃,所有事情都靠嘴說,所有變動都放在了我和他們的腦子里,僅僅是嘴說,很難形成標準,口說無憑。
對項目上心程度不夠,未對領(lǐng)導的需求變更做控制和管理。所有變更都壓給了開發(fā)的同事。
整個項目以及其不規(guī)范的方式在運行,我也未在其中起到控制中樞作用,項目開發(fā)一團亂麻。
復盤:
1.不做設(shè)計(需求),不進開發(fā)。
2.以管理工具指導開發(fā)進行,開發(fā)過程中所有變更、反饋做記錄。
3.控制需求變更,拒絕不合理的需求。
4.需求變更規(guī)范化操作,統(tǒng)一變更,而不是直接壓給開發(fā)。
無論什么情況下,都要進行code review(輕量級代碼評審)。
整個項目過去了幾乎四個月,我僅僅花了一個多小時簡單看了下代碼,導致未指出代碼的任何問題。這也導致出問題后來我花了成倍的時間來處理code review的工作,并且項目成型后的代碼修改困難。項目開發(fā)過程中,也未讓開發(fā)間互相進行代碼review,也沒有進行代碼評審,和項目組及時溝通。
其實代碼中出現(xiàn)了很多問題,最后檢查代碼的時候,發(fā)現(xiàn)各種命名不規(guī)范、代碼復用不到位、簡單邏輯復雜寫等等。而這些問題,很大一部分都是早期未做規(guī)定,未指定人負責項目、未進行早期code review造成的。開發(fā)各自為戰(zhàn),難免造成代碼問題。
代碼質(zhì)量的問題,淋漓盡致的體現(xiàn)的在項目中,項目中的諸多bug,都是因為代碼不規(guī)范引起的。甚至于開發(fā)人員自己對自己寫過的東西,都有些拎不清了,最終結(jié)果就是推倒重寫。
反思:
1.代碼質(zhì)量非常重要,代碼越規(guī)范bug越少。
2.代碼互評能讓開發(fā)更注重自己代碼的質(zhì)量。
3.code review非常有必要,越早期的code review越能有效的節(jié)省后期的時間。
我在其中占有多重的因素——100%
三、我怎么填坑的
項目上線,問題頻出,領(lǐng)導不滿。花了8天時間來處理這個問題。幸虧項目不大,我一個人也能夠挽回。
我簡單說一下我是怎么填坑的:
1.和開發(fā)主要流程的同事詳細熟悉了所有需求要點,越詳細越好。
2.基于我對項目需求的熟悉,我花了三天把所有主要流程的所有代碼分析完畢,做出了我認為應(yīng)該的修改(寫好注釋),并實施部署到生產(chǎn)環(huán)境測試。
3.每天花超過一半的工作時間來進行code review 和修改,幾乎每天code review + 修改到23點多(時間緊,僅修改了問題較大且影響較小的地方。小問題未修改、牽涉面較廣的地方未修改)。
4.每次上班時間的修改讓開發(fā)同事坐在旁邊和我一起進行,我進行修改,開發(fā)同事在一旁監(jiān)督。確保我不出錯。
5.優(yōu)化功能點,把我發(fā)現(xiàn)的提示問題,和優(yōu)化點都同步修改進代碼中,確保用戶體驗不要太糟,以期能挽回一些用戶心態(tài)。
6.代碼已經(jīng)要及時進行備注(注釋),很重要,一定要規(guī)范,方便下次你再次開放使用,最好形成文檔形式。
四、我所吸取的教訓總結(jié)
1.先設(shè)計(需求),后開發(fā)。
2.管理權(quán)下放,項目中必須有人帶頭負責。
3.無論什么情況都要進行code review。
4.壓縮代碼質(zhì)量得到的項目進度保證不可取,開發(fā)周期一定要和客戶溝通清楚。否則坑了自己坑了同事,更坑了客戶。
每個技術(shù)人在走向管理的道路上都會遭遇不同的困難與問題,想要建立自己的管理方法論,除了從實踐中經(jīng)歷、總結(jié)以外,還需要聆聽更多同行及導師經(jīng)過時間驗證的經(jīng)驗,CTO訓練營,20余位CTO導師精益分享,構(gòu)筑技術(shù)管理的體系化思維及底層方法論,工具+案例+實操演練的方式保證落地實用,第七季正在報名中,歡迎加入。
招生要求:
CTO訓練營第七季,共招生40個名額,采用【申請審核】報名機制,以下條件二選一滿足的,可掃碼申請:
A類-曾任或現(xiàn)任公司知名企業(yè)技術(shù)管理者
B類-創(chuàng)業(yè)公司核心創(chuàng)始人、技術(shù)高管
學習時間:
2019年10月-2020年5月,每月一個模塊,每次2天,共14天
課程費用:32000元/人
學習地點:北京
報名咨詢:張瑞 18401576051(同微信)