平時大家做研發的過程中，肯定經常遇到需要自己做決策的時候。不管是技術決策，還是團隊管理上的決策。有時候爲了追求完美經常遲遲難下決定，導致實際工作反而難以推進。
前幾天團隊就遇到一個這樣的問題：
項目中有個技術難題交給同事A，並且項目進度非常緊急，結果過了兩天遲遲沒有開展。所以就詢問了一下情況。原來A同事爲了方便後續擴展，一直苦思冥想方案的兼容性。然而考慮的擴展功能可能很難規劃到產品中。另一方面是迫在眉睫的deadline。
所以我就建議他考慮一下另一種方案，先把目前的問題解決。雖然最後採用了這個建議，但是說服過程相當困難，還有點不愉快。事後我也有一點自我懷疑，我的決定真的正確嗎？好在後來我找到了答案。
極客時間的《研發效率破局之道》專欄“Facebook的10x程序員效率心法”提到一個快速迭代的原則：
不要追求完美，不要過度計劃，而是要儘快實現功能，通過不斷迭代來完善。優秀的架構往往不是設計出來的，而是在實現過程中逐步發展、完善起來的。
Facebook 有一條常見的海報標語，叫作“Done is better than perfect”，意思就是完成比完美要重要。要實現快速迭代，我們在設計和實現功能時都要注意簡單化。
有些開發者過於追求技術，投入了大量時間去設計精美、複雜的系統。這樣做沒有問題，但一定要有一個度，切忌殺雞用牛刀。因爲複雜的系統雖然精美，但往往不容易理解，維護成本也比較高，修改起來更是不容易。
所以，在 Facebook 進行開發的時候，儘量使用簡單實用的設計，然後快速進行版本迭代。
亨利·明茨伯格《寫給管理者的睡前故事》有一章《決策：與你的想法不同》寫的很有意思，下面是部分節選，祝開卷有益。
我們是怎麼做決策的？很簡單。首先診斷，接下來設計（可能的解決方案），然後決定，最後執行（把選擇付諸行動）。換句話說，我們是先思考後行動，我把這個叫作思考先行。
你一生中最重要的決策可能是：尋找伴侶。你是思考先行的嗎？我們以一位男性尋找女性伴侶爲例，使用下面這個模式：首先列出你希望未來伴侶擁有的一些品質，如聰穎、漂亮、羞澀；接下來列出所有的可能人選；然後進行分析，根據上述標準給每位候選人打分；最後把分數加起來看誰勝出，並告知這位幸運的女士。
可是，她卻告訴你：“你在忙活這些的時候，我結婚了，現在已經有幾個孩子了。”看來，思考先行還是有缺點的。
所以，你可能會用其他方式來尋找伴侶，就像我的父親那樣。有一天，他跟我的奶奶說：“今天，我遇到了一個我想跟她結婚的女孩！”我跟你保證，這個決策裏面真的沒有多少分析，不過它的結局很圓滿。我父母的婚姻長久而幸福。
我們把這稱爲“一見鍾情”。作爲一種決策模式，我稱之爲視覺先行。如果你知道有多少重要的決策是這麼來的，可能會大喫一驚。比如，面試不到兩秒鐘就決定聘用某人，或者購買某設備的原因僅僅是你看上了這個地方。這些決策不一定是一時心血來潮，有可能是真知灼見。
但是，不要倉促下結論：還有另外一種更明智的決策方式，我稱之爲行動先行。你可以想象如何用這種模式來尋找理想的伴侶。這麼說吧，不管是做大決策還是小決策，當你不確定該怎麼做的時候，你可能需要先行動後思考，而不是先思考後行動。你先進行小幅度的嘗試性行動，看看是否奏效，如果沒效果，就換另一種方式，直到找到有效的方式，再放開手去做。也就是摸石頭過河。
當然，這種方式也有它的弊端。研究決策的特里·康諾利教授對此曾有妙語：“核戰爭和生孩子這樣的事情就不適合用‘摸石頭過河’的戰略。”但是，在衆多決策方式中，這種決策方式應該是一種完美的方式。例如，你本來打算把一個產品染成藍色，但最後，你可能賣出的是彩虹色的產品。
你現在需要做一個重要的決策嗎？好，先不要想了，明天四處看看！然後乾點兒什麼！到那個時候，你可能就會發現你的想法完全變了。
大師幽默的口吻在其它章節也處處可見，大家感興趣可以看看，微信讀書就有。
大家如果有啓發，可以關注鐵柱，大家進羣交流一下日常開發中遇到的問題。
