有兩種方法可以用五週時間，做完十週的專案。
《工作隨筆》系列
轉眼間，我已經在矽谷待了四年，從一名剛畢業的菜鳥工程師，變成團隊裡的老屁股。四年也正好是在香港唸大學的時長，這兩段四年的時光對我來說，都是我很珍惜的成果過程。
如果說我在香港唸大學的期間學到了「獨立生活」、「自己的個性」，還有「我討厭會計，喜歡寫 code」這些對於現在的我來說，非常核心的價值與想法。那麼，我在矽谷工作的前四年就讓我接觸到了世界上一流的人才，體會到厲害的人有一百種、一千種他們厲害的原因與方法。
而我則是非常榮幸地，有這個機會在他們身邊觀察，偷學個幾種。
小心地，慢慢地，我也在培養屬於自己的那一種。
這系列，我想偶爾提起筆，去紀錄一些工作上的小故事與頓悟。
假如軟體工程師是楓之谷裡的職業，我就是把力量跟敏捷點滿的那傢伙。
「遇到一面牆？只要我撞得夠用力，夠快，那面牆總會倒下來的。」
這種心態在我做為 IC3 - IC4 的前三年非常有用，也幫助我快速升職了兩次。反正在一個做產品的團隊裡，我們也不大會遇到什麼太硬的牆。一旦決定要做什麼之後，剩下的寫 code 反而會是最簡單的工作。
於是，在花了幾年混熟了我們團隊的 codebase 之後，我解鎖了第一種把十週長的專案用五週搞定的方法。
也就是，超有效率地寫 code。
然而，在幾週前，一個專案計畫的會議裡面，我看見了一個資深工程師使用另一種方法。
很簡單，只要說：「不，為什麼要做這個？」
他在會議裡質疑設計師與 PM 提出的不同功能——當然，是很有道理與語氣尊重地說。在這個會議之前，我就已經先讀過議程，而且大概把設計師與 PM 提出的所有功能都評估過。整個專案大概需要十週去做。
但是，他完全打亂了我準備好的這些，也打開了我的視野。
他快刀斬亂麻地在會議裡說服所有人某些功能並不重要，不做既不會影響使用者體驗，也不會影響我們最後想要得到的 A/B 實驗數據。甚至，做了這些看似有用，實則沒用的功能，還會讓團隊需要去承擔更多寫出 bug、與未來還要維護的風險與開銷。
半個小時過後，代辦事項剩下一半。
雖然這個結論聽起來直觀得有點白癡——但，把專案用一半的時間就做完的第二種方法，就是只做一半的事情。
有用的那一半。
透過說「不」，或者說，真正地做為團隊的腦袋，帶有批判性思維地說不，替團隊去發現有一半的工作並不重要，並不需要去做，他簡簡單單就讓我們只要用一半的時間，就能做出最核心的使用者體驗，並且取得實驗結果去儘早更迭專案。
而我則大開眼界，找到一條我原本沒想到的成長道路。
就算我能夠比別人快的寫 code，但要是我寫出來的 code 是沒用的，那也是白搭的。現在仔細想想，過去四年我確實寫出了不少最後還是要刪掉的 code。笑死。
如果你喜歡這系列的話，請不要忘記訂閱這個部落格，你會第一時間收到我的新文章，而我也會很快樂的XD