但他們沒有意識到，軟件跟他們想象的不一樣。當一個不懂技術的人試圖對軟件開發時間進行評估時，有兩個很基本的直觀指標在輔助他們：以體積為指標的復雜度和以速度為指標的復雜度。這種情況下，大腦會辨別每秒鐘演奏的東西。
為了回答這個標題題目，讓我們來認識一下我們的大腦如何估計事情的。然后，我把總時間加起來，這就得到了完成整個項目需要的大致時間。于是很自然的，他們傾向于使用體積指標進行評估。
這些是沒有經驗的人在評估復雜度時不會理解的。即使一個人從來沒有學過建筑學，他也能告訴你通常設計和建造一個帳篷會比設計和建造一棟公寓要簡單。為什么？因為我們天生的會使用物理體積作為事物復雜性的一個指標。有些事情對于一些沒有經驗的人也很等閑預估正確，但有些事情則不然。要么是根據描述文檔的頁數，要么是根據軟件的功能用例數或特征數。
我時不時的就會收到這樣的Email。
。上面說的這兩種邏輯分析并不是總是100%的有效。想想把一個帳篷和一棟公寓放在一起對比。同樣，當觀看了有人演奏D大調的《卡農（Pachabel’s Canon）》后，你也很等閑推測出，這很復雜，需要很長時間的練習才能演奏的出來。
當然。但是，通常情況下，對于軟件開發，體積并不能真實有效的反映復雜度。它的極小的組成部分可能會時不時的在電腦屏幕上閃現。作為一個程序員，我知道，根據我之前開發過的相似的功能特征，我可以估計出現在的這些功能特征各自要多少開發時間。
我們還有另外一個天生的推測依據：體積。我們的大腦有一些現成的模式來完成這些事情，首先一個就是根據速度。根據每秒鐘演奏了多少東西，我們很等閑有一個直觀的判斷曲子的復雜度。
正因為如此，當面對開發一個web應用時（或任何類型的軟件），我們的基本直觀感覺失效了。他們不明白在其他事情上都很靈的方法，為什么放到軟件開發上就不靈了。作為開發人員，我們經常會發現，在軟件開發的標題題目上，一個外行人會很自然的把復雜的事情估計的很簡單。但這引起了另外一個有趣的標題題目：為什么我們天生的預測復雜性的能力在遇到編程標題題目時會失靈？
現在讓我們來談談軟件。起初，當聽到人們這樣的話，我總是十分的惱怒。所以，下一次當你聽到有人說“我想你幾天時間就能把它開發出來”時，不管是誰說的，都不要懊惱。標題題目在于他們竟然認為自己可以做出正確的估計。沒有體積和速度。這些瓶頸會肆意的消耗程序員的大量時間，你在遇到它們之前根本不會有所預見。
有時候，這種評估手段確實有效！當面對一個靜態網站，沒有特別的設計要求，外行人很等閑用這種方法估計出開發時間。因為用吉他演奏一首歌是一種物理過程，一種感官上的活動，我們的大腦很等閑依此來推測速度，繼而轉換成復雜度。
真正讓我郁悶的不是他們預估的錯誤。然而，事實情況中，每個項目在開發過程中都遇到二、三個瓶頸。即使你從來沒有彈過吉他，在觀看了一場彈奏《瑪麗有只小羊羔（Mary had a Little Lamb）》的吉他表演后，你也能大概推測出這很簡單，一個人不需要太高的技術就能演奏出來。但大多數情況下，人們就是這樣干，而且很成功。而且還不是時時都好用。他們在跟誰辯論軟件開發所需要的時間？但后來我意識到，即使我自己對自己的項目預測要花去多少開發時間，我也是一籌莫展。寫這些郵件的人幾乎都是跟技術不沾邊的人，或正在研究他們的第一個產品。大多數情況中，我們在對物理過程評估時，我們的大腦會對物理事物進行有效的關聯，不需要依賴之前的經驗。它們會拖住整個項目，致使工期延后數周甚至數月。
【 微信掃一掃 】
