影響團隊交付速度的那些問題

03-01

1. 對業務方的實際需求調研不夠充分，造成需求頻繁變更

之前的文章「我只是想在頁面上加個鏈接」中描述過這個問題，本篇不展開。

2.1. 團隊契合度

當接手一個需求時，如果需求方是可以講道理的，那麼我通常會問「滿分 100，這東西我們要做到多少分？」

也許有人會覺得奇怪，明明能做到 100 分，為什麼不做到？你們這不是消極怠工嗎？說好的品質為王呢？

其實可以這麼想，考試有那麼多科目，如果把所有精力都投入一個科目確實可以拿高分，但是其它科目就要掛了。不如儘可能地讓所有科目都及格來得實際。

說白了就是一個局部最優與全局最優的問題。但是這和交付速度有什麼關係呢？

不知大家有沒有遇到這種情況。項目的 deadline 馬上就要到了，還有很多功能沒完成，然而卻有人在給已經完成的功能調優。比如「那個控制項在 Android 4.4 的垂直居中問題我調整了一早上」、「那個動畫太生硬了，我調了一下貝塞爾曲線」等。

而且不光是在臨近 deadline 時才會有這種現象，整個項目的開發過程中都充斥著這種現象，只是臨近 deadline 時容易觀察到。於是整體算下來，我們浪費了很多時間。

當然，每個人心中對事物的評分標準是不同的，不可能有統一的標準。比如你可能認為 60 分的產出必須沒有那種垂直不居中的問題，而我可能認為這是可以容忍的。在一個團隊內，大家的評分標準越接近，這個團隊的契合度就越高，交付速度也會越快。

2.2. 關於「倒排期」

項目開發有個這樣的守恆定律：

(時間, 資源, 質量) = 1

當資源固定時，我們能夠掌控的只有時間和質量，根據實際項目需求，找到一個平衡點就行。

此處的「根據實際項目需求」有個非常典型的例子就是「倒排期」項目。正常的項目是資源固定，由開發人員來預估質量和時間。而所謂「倒排期」項目就是時間維度固定。

所以「倒排期」項目對開發人員而言就是調整預期的質量以趕上交付時間。當質量維度無法再降低時，就需要動到資源維度，那可能就需要加班。

降低質量和加班都會造成其它負面影響。降低質量會導致那些真正追求品質為王的開發人員不愉快，而加班則會導致所有人不愉快。這也是為什麼長期「倒排期」的團隊離職率高的原因。

如果團隊的人員變動頻繁，團隊的契合度又怎麼能高？那麼交付速度只會進入越來越低的惡性循環。

作為提需求的那一方也應該反思這一點。實際上很多「倒排期」都是為了裝逼給老闆看的而已。不如干點實事？裝逼誤國，實幹才能興邦嘛。

3.1. 自測是本職工作

很多團隊都存在這樣的問題，聯調需要的時間和開發需要的時間幾乎一樣。為什麼？溝通有這麼困難？

實際上這不是溝通的問題，是工作方式的問題。只要看看聯調過程大家都在幹什麼就知道問題出在哪兒。

一個項目如果前端先開發完畢就會是這樣：

前端：頁面寫好了，給個介面造點數據我試試

為什麼不自己 Mock 數據給自己測，一定要等到聯調？即便 Mock 數據，為什麼只測主流程，分支和異常流程呢？

而如果是後端先開發完畢會變成這樣：

後端：介面寫好了，頁面給我，我測一下

為什麼不自己 curl 一下？為什麼只看成功還是失敗，不看裡面的欄位名和數據對不對？為什麼不測一下異常？

然後到聯調階段就會這樣：

前後端都沒有充分自測，這個原本可以各自並行消化掉的時間被串列地疊加在聯調階段。

「閉門造車」這個詞我想大家應該都很熟悉（一般是用來罵人的）。但那是斷章取義的解釋，完整的應該是「閉門造車，出門合轍」，意思是按照統一規格，即使關起門來製造車輛，使用起來也能和路上的車轍完全相合。說白了就是只要大家按照文檔來，那就根本不需要聯調。

3.2. 通過增加「適配層」的方式提升交付速度

但是「閉門造車，出門合轍」是一種理想狀態，實際很難實現。不過還有一些其它方式也可以提高交付速度，比如我自己經常使用的增加「適配層」的方式。

這個「適配層」通常以攔截器的形式實現，可以放在前端也可以放在後端（根據團隊的優勢約定好）。並且這個「適配層」只處理數據結構的映射，沒有業務邏輯，所以不需要花太多時間就能寫完。