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