對幾次通宵加班發版的覆盤和思考

將帥無能,累死三軍

在一個技術團隊中,至少要有一個人具備對團隊的整體的技術架構和所涉及業務高度理解和敏感的人,或者說要從宏觀上掌控全域性的人。

只有掌控全域性,才能保持隨時頭腦清晰地做一些合理的決策,而合理地決策才是保障團隊工作高效開展地基石。

這個最適合的人選就是團隊負責人。

大版本迭代上線發版絕對是檢驗一個技術團隊負責人是否合格的試金石。

不懂拒絕臨時增加的需求

懂得拒絕是一門藝術。

技術人不是一個沒有靈魂的程式碼工具。"這是產品大大提的,我沒法拒絕"。當出現問題的時候,我們經常聽到技術同學這樣說。

不合理的需求,對使用者不友好的需求,低收益,高投入的需求,要敢於拒絕。當然,拒絕也是一門藝術,這就是與人溝通的藝術。如果經過深思熟慮,你能夠給出比較合理的解釋或者提出更有建設性的方案,我想這樣才會更加容易讓人接受。

在最近幾次發版的當天，竟然還有新的需求增加。

需求必須被管理起來,拒絕口頭需求。

隨意增加需求,卻不增加研發時間和延遲發版,最終壓力都會轉向研發,這也將影響發版的進度,是導致加班的一個因素。

不可偵錯的程式碼

確保寫的程式碼是可調式的。

如何保障程式碼的質量? 那就是自測試。在這麼多年的職業生涯中,我逐漸摸索出一個確保程式碼質量的笨方法——單步偵錯。

比如,介面提供給前端或者第三方系統使用,我一般會寫一些測試用例,對程式碼進行單步偵錯。這種方法非常有效,也確實避免了上線之後產生重大bug的出現。

但是上一次迭代,在接手的專案中,為一個函數新加了一個引數,沒有做單步偵錯,結果在上線的之後,在一種特定場景下出現非預期的狀況。

經過一步一步地增加紀錄檔分析,才發現這個引數在執行的階段出現了null的情況。

帶來的直接後果就是,多花了兩個小時排查問題。

多麼痛的領悟!

值得注意的是,對於一些跨系統或者接入第三方的對接中,可能很難做到全流程地偵錯。這種情況,可以分段偵錯,保證最終結果正確性。

偽資訊共用

分工導致資訊不對稱。

在一個團隊中,因為分工的差互斥或者組織架構的層級問題天然會導致一些資訊差異。

儘管我們大量使用IM工具,通過拉群的方式來減少溝通的成本,這也依然無法避免。

同時即便是針對同一件事情,再加上團隊成員參差不齊,認知上本身也存在差異。

在我們日常開展研發中,有些需求或者方案的變更,很多時候不會以郵件的方式通知到每個干係人,也不會將列印成文,對相關人員進行宣導。

這種情況,一般我會建立一個UI檔案和專案方案檔案,這個檔案是團隊成員貢獻地,並且都可以編輯。

通過這種方式,充分調動團隊成員的智慧,圍繞這個專案,進行資訊補充和共用。

當然,這裡依然需要人來負責推進和落地。否則,也是空談。

檔案和文字依然是溝通的最佳途徑,不容易產生歧義。

技術債務

軟體和教堂非常相似——建成之後我們就在祈禱。

有時候我真的很佩服的我們的測試同學,因為每次上線一個新的功能,他們總是能測試早期的迭代版本中的一些問題。

這是典型的技術債務,可能之前有些功能迭代時間比較緊張,臨時採取了一些不夠優雅的方案,亦或是出現了一些問題這是臨時修復了一下資料,沒有深究根本原因。

這些技術債務就像一顆定時炸彈一樣,指不定在哪一次版本上線之後爆發出來。

對於程式設計師來說,真正好的工作氛圍應該是每個人都在很安靜地各司其職,而不是大夥兒忙著救火。

對於我們這種專案制的團隊,團隊人數少,但卻承擔著比較多的專案。

我們只有非常努力地保障每一個專案的每一次迭代是高質量的,上線之後沒有大的缺陷,也沒有頻繁的反饋問題,才能勉強讓團隊能夠正常運轉。

所以,每一次的方案都會反覆斟酌和驗證,然後小步快跑,而不可冒進。

同時,針對反饋的每一個問題都會抱著打破沙鍋問到底的精神去尋找根本原因。

專案時間評估隨意

如果PO說這是個很小的改動，你不要信他。——《一個輸入框你要做一週?》

每次開完產品原型評審會,就到了專案研發工期評估時間。

我們知道任務的拆分越細化,評估時間越準確。

一般我們會讓團隊各端的研發人員根據原型來拆分各自的任務,並給出一個評估時間。

多年的工作經驗告訴我們,原型中一定存在缺失的邏輯或者隱含的邏輯。

在這個階段多花一點功夫,對需求充分挖掘,充分和產品溝通,才能做好任務拆分,最終減少評估時間的誤差。

但是,我見過太多拍腦袋的方式產生的評估時間，最終導致實際時間和預估時間大相徑庭。

這樣帶來的直接後果就是,加班趕進度,測試不充分,上線當天bug比較多或者還存在漏做的需求,導致加班發版。

不明確的釋出清單

發版是一件很嚴肅的事情。

就像火箭發射任務一樣,軟體專案的釋出也是有自己的流程。而這種流程也需要整理成發版清單,公之於眾。這樣做的目的是,建立大家的共同目標,同時知曉目前的進度。

團隊成員忙閒不均

在技術團隊裡面，如果一項工作長期都依賴一個人，這樣對團隊高效共同作業不太有利。

這種現象在網際網路公司普遍存在。

舉個栗子，有個專案是前後端分離的，後端人員富餘，前端只有一個人。那麼這個專案的交付時間大概率有前端同學開發結束時間而定。

在釋出版本的時候，遇到專案中不同模組出現的bug數量不均勻時，這種尷尬就出現了。

當bug都集中在一個人身上，而團隊的其他成員只能乾著急。

比較推崇的做法，就是安排至少兩個人蔘與一項工作,或者至少有兩人對這項工作比較熟悉。

BUG處理不分級

發版的主動權應該牢牢地掌握在研發手裡。

任何時刻,研發同學必須保持清醒,主動權應該牢牢掌握在自己手裡,不能被bug牽著鼻子走。

在進行bug修復的過程中，研發人員很容易陷入與bug的糾纏之中，但是值得注意的是，時間在一分一秒流逝。

管理大師德魯克說過,"卓有成效的管理者總是把重要的事情放在前面做(first things first),而且一次只做好一件事(do one thing at time)。"

通過四象限法則,我們將bug列表按照重要程度的優先順序進行歸類。

專案管理者必須勇敢站出來,要對bug列表進行識別和優先順序劃分，避免在一些不太重要的bug上浪費太多時間。

經過梳理,會發現實際上有一些無關痛癢的Bug完全可以延遲處理。

聯調不充分

軟體產品研發是一項系統而複雜的工程。

覆盤這次的產品迭代,由於缺乏統籌協調,加上時間緊張,聯調的環節被大大縮水。

在微服務,前後端分離日益流行的當下,很多時候完成一個專案往往需要多個團隊的共同作業。換句話說,我們的專案對外依賴很重。

值得注意的是,不同團隊和服務並不是同時開展的。所以,每一次大跌代的專案干係人牽扯較多,但是各自都有自己的任務在推進。

除了埋頭寫程式碼,研發同學還是要發揮自己"一不怕苦,二不要臉"的精神去主動爭取資源,主動去"搭訕"。

一切只為充分實現介面和服務的聯調,溝通的過程是曲折的,但是最終保證了聯調的暢通。

結語

我們都在奔跑,但是短暫地停下來思考,是為了更好地再出發。

管理者都喜歡對工作進行量化。

最近在思考,有沒有一種方法對發版進行量化。哪些指標可以反映是高效的發版?

有沒有一套智慧的bug系統,自動分析和預判出專案發版上線的一些缺陷並生成上線預測報告。

這份報告可以將一些重大問題提前暴露出來,並對問題進行自動分級,給研發人員一個參考,從而將發版的關口前移。

這裡筆者只根據個人多年的工作經驗,一點點思考和分享,拋磚引玉,歡迎大家怕批評和斧正。