沒有品質,哪來效率,談什麼成本;
01
最近大半年,團隊以極其曲折的方式,将一個支離破碎的應用從重構的邊緣給拉了回來,最終項目回到了正常疊代的節奏中;
年初的時候,營運系統相關人員離職,然後經過決策層考量之後,統籌到一個業務線維護;
問題的關鍵在于,這套營運系統剛開發完成,還沒有全面進入使用階段,到底有多少坑在前面悶着誰都不知道;
以維護的定調将任務安排過來,通常意味着既不能影響負責的業務線開發,同時還要保證這套新的營運系統正常運轉;
還好隊友對此事都能勉強了解,沒有過多評論,不然會顯得沒禮貌了;
再來回顧這件事本意并不在于吐槽,而是複盤一下這套系統從垮掉到最終支棱起來的全過程,總結一下複雜問題的解法;
02
營運系統進入使用階段後,符合預期成功垮掉,短短半個月的時間,産品和項目經理就收到了過百條的使用問題,優化迫在眉睫;
經驗老道的隊伍中:輕易不提系統級的重構二字!老底掀翻了也說是優化;
好消息,營運系統名義上已經開發完成了;壞消息,營運系統剛開始進入全面的使用階段;
好消息,沒有突破隊伍剛接手時的心裡預期;壞消息,營運系統名義上确實開發完成了;
跳坑不問原因,如果能繞開誰都不跳;挖坑不看深度,挖的人知道自己不走回頭路;問題已經明顯的擺出來了,最好的辦法就是盡量一次徹底的解決它;
那麼沖突點就來了,在不過度影響主線業務的前提下,用什麼方式來解決營運系統的問題,這就很考驗管理和協作的流程;
03
顯然在開發主線業務的同時,随意穿插營運系統的問題,這樣很容易導緻兩邊都吃力不讨好,整個隊伍會更加被動,先看看應對方式;
首先使用方将問題全部對接給産品和項目經理,做好問題的優先級定性,并且在優化池文檔中做好主流程與子產品化次元的分類管理與場景描述;
然後将問題交由測試人員進行開發環境的複現,并簡單輸出一些問題的原因和異常日志,同樣需要在優化池中做好整理記錄;
最後由開發同學進行問題解決,再送出到測試驗收的環節,問題解決後釋出上線,上述流程中問題已經有了一份比較詳細地描述文檔,是以協作的效率很高;
從整體的流程看,與正常的協作差異并不明顯,那是如何處理過程中的沖突與時間沖突的,此時就很依賴管理政策了;
04
解決營運系統主流程的問題會集中在一個周期相對較短的高強度版本中,人力投入也很全面,以此保證系統前期的穩定和可用性;
需要優化但相對邊緣的問題,采用寬松的方式推進,主線業務的研發周期中,安排在開發和測試相對空閑的時間段内;
如果出現流程中斷的問題需要緊急處理時,會将主線的排期時間适當推後;解決完再回歸到主線開發,并且會占用晚上和周末的時間來盡量避免延期;
因為營運系統而額外加班的隊友,空閑節奏中會安排休假;過度忙碌會導緻隊伍的狀态和情緒低落,部門經費上給到福利傾斜,畢竟人間煙火氣最撫凡人心;
當然,在問題解決的過程中,并沒有再次引起關聯的問題,這與隊伍的整體素養偏高有最直接的關系;
最終在曆時六個月之後,整個營運系統實作服務的穩定可用,并且沒有對業務主線産生明顯的進度影響,後續的維護和開發落到版本排期即可;
05
有個三五年開發經驗的同學都會遇到類似問題,躺平的老六以離職的方式甩出一個坑坑窪窪的系統,接手的隊友秒變大冤種;
站在項目管理的角度來看,品質、時間、成本是需要平衡的,但從實踐經驗所得,沒有品質,時間與成本确實無解;
對于産品研發部門來說,到底如何定義品質的标準,在原則上退好多步來說:穩定、少出錯;
有幾年開發經驗的同學,尤其是後端,都深刻地知道系統的穩定和少出錯,在實際研發中是多麼有難度的要求;
很多隐藏的問題,或者邏輯不嚴謹,雖然在當時沒有顯露,但是這些麻煩就像水杯中的沉澱物,稍微晃一晃,就會原地起飛;
問題輕則甩鍋大戲,問題重則離職一片,在品質問題上有多少挖坑的老六,那埋起來的大冤種隻會遠大于挖坑的老六;
品質問題随着産品疊代的推進,是會産生裂變的,如果出現資料層面的問題,那就是核裂變,而且不會挑選爆發的時間;
06
版本求快可以了解,因為很多業務都是有時效性的,即要快又要高品質也能接受,畢竟需要所謂的競争力;
追求品質的門檻并不高,團隊可以多碼點人或者排期多給點時間,流程把控嚴謹是可以實作的;
但是成本與時間都不想付出,這就多少有點不懂理了;時間、品質、成本的三角形想要實作真正平衡,這絕非易事;
在研發管理中,經常出現排期緊急,應付式地開發一下,等出現關聯問題時,再考慮下個應付的方法,持續性挖坑,間歇性擺爛;
等到問題多到無法應付時,可以換個地方接着玩,這可能或多或少都成為過職場生涯的跳槽原因,最終結果是沒有赢家;
被迫躺平擺爛的搬磚者,主動或被動地在各個平台和産品線中不斷橫跳,頓悟後就會發現,哪裡的代碼都一樣并不分高低貴賤;
任何工程中的代碼出現問題,都會快速地從使用端傳遞到研發端,解決完還要再次通知使用端,這其中的成本完全是可以計算的,原因是可以分析的,能否避免是值得反思的;