質量問題不是不爆,時候未到

沒有質量,哪來效率,談什麼成本;


01


最近大半年,團隊以極其曲折的方式,將一個支離破碎的應用從重構的邊緣給拉了回來,最終項目回到了正常迭代的節奏中;

年初的時候,運營系統相關人員離職,然後經過決策層考量之後,統籌到一個業務線維護;

問題的關鍵在於,這套運營系統剛開發完成,還沒有全面進入使用階段,到底有多少坑在前面悶着誰都不知道;

以維護的定調將任務安排過來,通常意味着既不能影響負責的業務線開發,同時還要保證這套新的運營系統正常運轉;

還好隊友對此事都能勉強理解,沒有過多評論,不然會顯得沒禮貌了;

再來回顧這件事本意並不在於吐槽,而是覆盤一下這套系統從垮掉到最終支棱起來的全過程,總結一下複雜問題的解法;


02


運營系統進入使用階段後,符合預期成功垮掉,短短半個月的時間,產品和項目經理就收到了過百條的使用問題,優化迫在眉睫;

經驗老道的隊伍中:輕易不提系統級的重構二字!老底掀翻了也說是優化;

好消息,運營系統名義上已經開發完成了;壞消息,運營系統剛開始進入全面的使用階段;

好消息,沒有突破隊伍剛接手時的心裏預期;壞消息,運營系統名義上確實開發完成了;

跳坑不問原因,如果能繞開誰都不跳;挖坑不看深度,挖的人知道自己不走回頭路;問題已經明顯的擺出來了,最好的辦法就是儘量一次徹底的解決它;

那麼矛盾點就來了,在不過度影響主線業務的前提下,用什麼方式來解決運營系統的問題,這就很考驗管理和協作的流程;


03


顯然在開發主線業務的同時,隨意穿插運營系統的問題,這樣很容易導致兩邊都喫力不討好,整個隊伍會更加被動,先看看應對方式;

首先使用方將問題全部對接給產品和項目經理,做好問題的優先級定性,並且在優化池文檔中做好主流程與模塊化維度的分類管理與場景描述;

然後將問題交由測試人員進行開發環境的復現,並簡單輸出一些問題的原因和異常日誌,同樣需要在優化池中做好整理記錄;

最後由開發同學進行問題解決,再提交到測試驗收的環節,問題解決後發佈上線,上述流程中問題已經有了一份比較詳細的描述文檔,所以協作的效率很高;

從整體的流程看,與常規的協作差異並不明顯,那是如何處理過程中的矛盾與時間衝突的,此時就很依賴管理策略了;


04


解決運營系統主流程的問題會集中在一個週期相對較短的高強度版本中,人力投入也很全面,以此保證系統前期的穩定和可用性;

需要優化但相對邊緣的問題,採用寬鬆的方式推進,主線業務的研發週期中,安排在開發和測試相對空閒的時間段內;

如果出現流程中斷的問題需要緊急處理時,會將主線的排期時間適當推後;解決完再回歸到主線開發,並且會佔用晚上和週末的時間來儘量避免延期;

因爲運營系統而額外加班的隊友,空閒節奏中會安排休假;過度忙碌會導致隊伍的狀態和情緒低落,部門經費上給到福利傾斜,畢竟人間煙火氣最撫凡人心;

當然,在問題解決的過程中,並沒有再次引起關聯的問題,這與隊伍的整體素養偏高有最直接的關係;

最終在歷時六個月之後,整個運營系統實現服務的穩定可用,並且沒有對業務主線產生明顯的進度影響,後續的維護和開發落到版本排期即可;


05


有個三五年開發經驗的同學都會遇到類似問題,躺平的老六以離職的方式甩出一個坑坑窪窪的系統,接手的隊友秒變大冤種;

站在項目管理的角度來看,質量、時間、成本是需要平衡的,但從實踐經驗所得,沒有質量,時間與成本確實無解;

對於產品研發部門來說,到底如何定義質量的標準,在原則上退好多步來說:穩定、少出錯;

有幾年開發經驗的同學,尤其是後端,都深刻的知道系統的穩定和少出錯,在實際研發中是多麼有難度的要求;

很多隱藏的問題,或者邏輯不嚴謹,雖然在當時沒有顯露,但是這些麻煩就像水杯中的沉澱物,稍微晃一晃,就會原地起飛;

問題輕則甩鍋大戲,問題重則離職一片,在質量問題上有多少挖坑的老六,那埋起來的大冤種只會遠大於挖坑的老六;

質量問題隨着產品迭代的推進,是會產生裂變的,如果出現數據層面的問題,那就是核裂變,而且不會挑選爆發的時間;


06


版本求快可以理解,因爲很多業務都是有時效性的,即要快又要高質量也能接受,畢竟需要所謂的競爭力;

追求質量的門檻並不高,團隊可以多碼點人或者排期多給點時間,流程把控嚴謹是可以實現的;

但是成本與時間都不想付出,這就多少有點不懂理了;時間、質量、成本的三角形想要實現真正平衡,這絕非易事;

在研發管理中,經常出現排期緊急,應付式的開發一下,等出現關聯問題時,再考慮下個應付的方法,持續性挖坑,間歇性擺爛;

等到問題多到無法應付時,可以換個地方接着玩,這可能或多或少都成爲過職場生涯的跳槽原因,最終結果是沒有贏家;

被迫躺平擺爛的搬磚者,主動或被動的在各個平臺和產品線中不斷橫跳,頓悟後就會發現,哪裏的代碼都一樣並不分高低貴賤;

任何工程中的代碼出現問題,都會快速的從使用端傳遞到研發端,解決完還要再次通知使用端,這其中的成本完全是可以計算的,原因是可以分析的,能否避免是值得反思的;


07


很認同的一個觀念是:把事情一次性做好,就是最低的成本和最高的效率;所以需求再多,也要質量爲王;如果因爲產品的體驗差影響業務,那麼用戶、平臺、研發誰纔是真正的大冤種?

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章