天天看點

對付時間不充足項目的一些思路

最近參與了一個十分倉促的SAP項目,無論是需求收集、功能設計、程式實作、測試、使用者教育訓練,幾乎每個環節都有不小的疏漏。最終匆忙上線,自然也導緻了悲劇性的結果:上線第二天就發現了幾百個訂單錯誤,使用者的投訴紛至沓來,後續又持續地産生其它錯誤和誤解。在接下來的一周裡面,項目相關人幾乎每天都要加班到深夜,而且每天中午都要上線一個“十分重要”的更新檔,來解決前一天發現的問題...在六七天的努力過後,風波總算漸漸平息。

客觀來說,時間不足,資源不足,是項目中的常見情況。有時是因為人的失誤造成的,有時是因為一些難以抵抗的因素。一味怨尤并不能解決問題。針對這個讓人印象深刻的失敗,我決定把相關的一些經驗和反思記錄下來,當做教訓。

本文連結:https://www.cnblogs.com/hhelibeb/p/11247004.html 

原創内容,轉載請注明

1,持續重構

每一次需求變更都有可能增加程式的複雜度,使設計變差。在時間不足的項目中,這種修改往往尤為頻繁,因為來自上遊的需求很可能是在缺少足夠思考和溝通的情況下産生的。為了對抗這種趨勢,必須要時時依據最新的情況重新思考抽象,嘗試重構代碼,以保證代碼至少不向更糟糕的方向發展。

在這個項目中,我花了大力氣對一些核心邏輯進行封裝,并且在程式因為需求變化需要修改時不斷地嘗試重構,尋找更好的命名、對齊代碼、拆分臃腫的類、去除重複代碼。結果,在上線後這部分代碼運作得相對良好,隻有2個比較輕微的代碼bug,都是上線前兩天的臨時改動造成的,忙碌導緻的開發人員頭腦混亂是bug的主因,程式的設計本身還算過關。

但在有一個“不太重要”的批處理程式發生了嚴重的翻車事故。早先,我們對這個程式的期望是用來處理一些數量極為有限的“例外”訂單,它出場的次數不會很多,即便有bug,影響範圍也應當十分有限。由于我自信在上面的核心邏輯的實作中已經取得了成功,傲慢和焦躁的我隻是草草寫完了這個程式,對後續的需求變化,也隻是簡單地找到看起來正确的程式位置,注釋重寫幾行代碼,或者插入若幹if-else之類的語句,并沒有關心重構問題。可上線之後,實際情況很糟糕。由于需求溝通的失誤,“例外”訂單的數量大大超出預期,批處理程式沒有正确地處理異常,反而因為程式bug造成了進一步的異常。通過對它的檢查,我發現,這個短短幾百行的程式中包含多個低級錯誤,各種if-else的交織遠比自己當初想象中的要複雜...我不得不把這個程式改了又改,修改多次之後才勉強保證它能正常運作。

能否持續重構是決定代碼層面成敗的關鍵因素。有兩個原因決定了這點,

  1. 人會犯錯,也會學習,持續的重構可以幫助改成錯誤、提高自己。
  2. 需求會變,變化會破壞設計,需要通過重構把被破壞了的設計改善,這樣才能保持良好的設計。

一個現實的問題是,時間不足的項目裡,可以用于重構的時間會更少,如果用于實作功能的時間都很少,還要怎樣重構代碼呢?

在這方面,我的經驗是,

  1. 時間不足的項目往往有管理不善的因素,而管理不善,通常意味着各個過程的銜接可能會有問題。工作銜接上的問題會造成溝通不足和低效等負面影響,但也很可能會在某些階段讓開發者有一些空閑時間。抓緊利用這些時間重構吧!
  2. 好的抽象是重構的基礎,在對代碼實際重構前,心中首先要有個好的抽象,而抽象是不包含很多具體細節的,這意味着開發者不一定要面對代碼才能思考重構,理論上,吃飯、走路、洗澡的時候也可以進行相關思考。當然,前提是開發者确實還要有精力做多餘的思考。
對付時間不充足項目的一些思路
對付時間不充足項目的一些思路

2,重視問題的處理順序

讓我們感到很遺憾的一個情況是,有好幾個重要問題其實在上線前就已經被部分同僚想到/發現了,但由于各種原因,它們都沒有引起足夠的重視。

在項目問題逐漸被修複的過程中,一個參與項目較晚的同僚問我:我曾經在回報過一個測試中出現的bug,為什麼你們都忽略了?結果現在導緻了很多問題。

我回憶了事情的經過,這個問題沒有引起重視的原因是多方面的,

  1. 該同僚參與項目太晚,,對很多東西不清楚,之前提出了數個錯誤的問題,導緻其它人對她的新發現信任度不高。
  2. 問題表現在外部系統,這使得大家對它的熱情很低。
  3. 時間緊迫,似乎有必要優先處理更明确的問題。

這三點都不無道理,但我們忽略了一個更重要的問題,那就是一旦這個問題确實存在,将造成嚴重的影響。相比之下,上面的三個理由都是相對主觀的理由,而僅僅是“可能造成嚴重後果”這一個理由,就應該足以引起大家的重視了。是以,在确定問題時,不應隻按照“可能性”确定,也應按照結果的嚴重性确定。我想,也許應該按照以下順序處理可能性和嚴重性不同的各種問題:

  1. 确定的、後果嚴重的:最優先處理,對其進行修複。
  2. 不确定的、後果嚴重的:次優先處理,對其進行調查。
  3. 确定的、後果輕微的:延後處理,對其進行修複。
  4. 不确定的、後果輕微的:延後處理,對其進行調查,或忽略。

下圖是我畫的一個問題管理象限圖:

對付時間不充足項目的一些思路

3,保持樂觀

在進度的重壓下,保持樂觀的心态十分重要。我是容易唉聲歎氣的類型,但是我發現一些優秀的同僚往往更能苦中作樂,在大家疲憊不堪的時候想出很多笑話,讓大家稍稍變得開心和放松起來。這在無形當中給了大家很多幫助,值得我學習。

困難總會過去,保持樂觀,也許能幫助我們更好地度過難關。

參考文章:

https://wiki.mbalib.com/wiki/Image:%E6%97%B6%E9%97%B4%E7%AE%A1%E7%90%86.png

繼續閱讀