在以往的開發和管理中遇到很多問題,以至於我對理想中的技術團隊有了一些想法。其中有兩點經過實踐證明有很強的可操作性,值得拿出來討論一下:

  1. 能用規則解決的問題就不要靠人解決
  2. 能用機器完成的任務就不要用人處理

這兩點都反映了我的一個妄念,就是相信規則和機器,不相信人。人是最不靠譜的生產者,你永遠無法保證團隊中的每個人都處於很好的狀態、擁有相近的技術水平和情商,這也是為什麼我不覺得結對編程有什麼可操作性。但如果有簡單可行的規則,用來規範開發過程中的行為,那麼解決開發過程中的衝突就不需要人為地和稀泥,生產效率也會得到提升。此外,機器最適合用來做重復性的任務,很多花大量的人力、物力、時間都沒做得很好的事,交給機器來做恰恰是最好的解決辦法。

這些以往都只是我自己的想法,雖然在團隊裡有過很好的實踐效果,但是並不指望和別人有所共鳴。國內的技術團隊大多靠堆人、堆時間,很少有團隊會把健康的世界觀和可操作的方法論放在重要的位置,技術和技術從業者都是芻狗。當然這也無可厚非,畢竟先要解決生存問題,在模式創新為主的國內互聯網行業,更新換代如此之快,產品早一天上線就多一分生存的可能。但是有沒有可能既解決生存問題,又做出一個有榮譽感的團隊呢?世間安得雙全法,這是個值得持續討論的問題。

最近和別人聊天,竟然聽到相同的想法,在具體的方法論上還得到很多補充。

對於第一點。一個項目按業務線劃分開發組、按功能模塊劃分開發任務本來是個很好的模式,但是接口的對接往往會有很多問題,例如術語使用的不嚴謹導致高昂的溝通成本、問題處理方法的不規範導致扯皮、衝突和低效。

在我的團隊裡,用wiki維護著一套術語詞典,開發過程中所有的文檔、溝通都必須使用既定的用語,例如「退單」包括「退款單」和「退貨單」,這三個術語分別表示不同而精確的概念,如果因為自己造詞產生歧義或錯用術語導致開發事故,責任是清楚的,問責對象也沒有怨言。讓有責任的人承擔責任,比和稀泥對解決問題更有利。

再比如,問題在流轉過程中很容易出現接口人之間的扯皮甚至衝突,問題的根源並不是別人說你的代碼有問題導致你不爽,而是別人做得不夠專業讓你覺得對方不負責任。在我的團隊裡,大家約定處理問題的規則是:

  • 誰接手,誰處理
  • 轉交問題時必須提供四項信息:復現問題的環境、完整的接口名、傳遞的實參和返回結果

首先當一個問題被反饋過來的時候,分配人會有一個初步的判斷,指派給誰,誰處理,不能踢皮球。處理人如果界定問題發生在別人的接口裡,應該把上述四項信息連同問題移交給相關責任人。這樣做的好處是,一來可以避免誤判給別人造成不必要的麻煩,二來讓下游接口人可以馬上復現並解決問題,而無須考慮上游的業務邏輯。這個規則的效果很好,團隊裡從來沒有因為接口問題出現不愉快。

對於第二點。代碼質量是日常開發中最讓人頭疼的問題之一,出現頻率高而且代價昂貴。不管是靠開發人員的經驗,還是測試人員的工作,都對人的依賴很大,既不穩定又低效。以下這些方法能很好地解決這樣的問題:

  • 使用Git,先進的生產關係需要更好的生產資料才能帶來更高的生產力
  • 提交代碼時自動檢查語法錯誤和代碼規範
  • 高覆蓋率、自動化的單元測試
  • 用模擬工具給單元測試供給測試數據
  • 用腳本測試網頁交互
  • 用腳本給網頁截圖,用圖片diff工具比較某次修改給網頁帶來的變化