有時候，慢即是快

閱讀本文大概需要 3.9 分鐘。

一

從我住的地方到公司，有兩條路。

一條要經過一個天橋，路程稍微遠一點，好處是可以安全放心的過馬路。

另一條路程稍微近一點，但是要等過馬路的紅綠燈，如果剛好是綠燈，就會很快。

我一直習慣走天橋的這條路，但是路上我經常看到更多的人是去走紅綠燈那條路，剛開始不是很理解，為此我特意用地圖對比了兩條路線，發現紅綠燈那條路近一些，這個應該是主要原因吧，另外不用爬橋，應該也有一定的關係。

反觀我自己為啥要選擇天橋這條路呢？主要原因就是不想等紅綠燈。

沒有紅綠燈，我感覺一路通暢，路上聽一些音頻時，也不用擔心過馬路的危險。

沒有紅綠燈，我省去了等待紅綠燈的焦躁，心情會好很多。

沒有紅綠燈，我可以隨時調整自己步伐的快慢，不用想著去搶綠燈的時間點，時間在我自己把控。

沒有紅綠燈，雖然路稍微遠一點、陡一點，但我努力一下還是能更快的到公司。

這時候，慢就是快。

二

我記得高中數學試卷的第一部分是選擇題，有 12 道，每題 5 分，一共 60 分，在 150 分中佔比 40%，所以是每次考試必爭分之地，多錯或少錯一道選擇題的差距會很大。

大家當然都知道選擇題的重要性，但是因為時間的原因，又不可能每道選擇題都去實際推演出最後的結果，所以當時比較流行的做法是「排除法」，具體啥意思就不用我解釋了吧，相信大家都用過。

但是我比較笨，總是擔心這種方法不靠譜，還有一個擔心是排除法做出來的題，就算結果是正確的，也並不代表自己會做這道題，那麼就是自己欺騙自己，如果真正高考時候的選擇題不適用排除法該怎麼辦呢？

我沒有去找別人尋求答案，我只是默默的在每次做選擇題的時候，繼續使用推演法，至少要保證我會的確實是會了。

這樣造成的問題就是我的時間分配要做調整了，我在選擇題上花費的時間會更多，但好處是我所有的題都是推演出來的，相對來說我比別人做題的數量也更多，久而久之鍛煉的機會也更多，在選擇題上面的準確度也更高。

有時候還會出現很多人把時間放在最後的大題上，結果大題太難沒做出來，我呢，剛好沒時間做大題，但是前面題的準確率又更高，總分反而就更高了。

這時候，慢就是快。

三

我一直給組裡面同學強調，長期項目的品質把關要更嚴格一些，用例顆粒度要更細一些，哪怕多花一點時間，也一定要做到每次的項目都不要留坑。

主要是因為我們之前經歷過爬坑的痛苦。

如果一個項目，本次測試只覆蓋了必要的測試點，滿足了主要功能訴求，但是對於設計不合理，甚至用戶操作稍微變更一下就滿足不了需求的情況都放過了。

那麼可預見的未來是，後續的項目迭代就不是新功能的迭代了，而是一方面不斷去填補用戶新的操作路徑的需求覆蓋（每次都只考慮用戶當前的需求，沒有擴展，其實就是沒有解決用戶的根本訴求），另一方面就是不斷在不合理的設計上繼續打上更多的不合理設計的修補程式。

久而久之，這個項目就會千蒼百孔，隨便一個修改都是牽一髮而動全身，每個參與項目的人都會身心俱疲。

如果同樣的項目，每次的合理性考慮都很充分，所有操作路徑都有完整覆蓋，那麼每次的關注點都可以集中到本次修改的需求，以及很少的關聯影響範圍上，這樣就是良性迭代，項目不會因為迭代次數增加而身陷囹圄。

雖然這樣做，每次迭代的項目時間會拉長，但是整體來看，節省的時間卻是大把大把的。

這時候，慢就是快。