from http://ck101.com/forum.php?mod=viewthread&tid=2633358&extra=page%3D1
「這個網站相當簡單,你要做的就是完成X、Y、Z。你看起來技術很好,所以,我相信,你不需要花費太多時間就能把它做出來。」
我不時的就會收到這樣的Email。寫這些信的人幾乎都是跟技術沾不上邊的人,或正在研究他們的第一個產品。一開始,當聽到人們這樣講,我總是十分的惱怒。他們以為是在跟誰討論軟體開發所需時間?
但後來我發覺,即使我自己對自己的計劃預測要花多少開發時間,我也是沒那麼有把握。如果連我自己都做不好,我何必對那些人惱怒呢?真正讓我覺得悶的不是他們預估的錯誤。問題在於他們竟然認為自己可以做出正確的估計。作為開發人員,我們經常會發現,在軟體開發的問題上,一個外行人會很自然的把複雜的事情估計的很簡單。
這並不是為我們的憤怒找藉口,但倒是提醒了我們另外一個有趣的問題:為什麼我們天生預測複雜性的能力在遇到程式開發時會失靈?
為了回答這個問題,讓我們來認識一下我們的大腦如何評估事情的。有些事情對於一些沒有經驗的人也很容易預估正確,但有些事情則不然。
我們來想想,觀看某人演奏吉他。即使你從來沒有彈過吉他,在看了一場彈奏「瑪麗有隻小羊(Mary had a Little Lamb)」的吉他表演後,你也能大概推測出這很簡單,一個人不需要好的技巧就能演奏出來。同樣,當觀看某人演奏D大調的「卡農(Pachabel's Canon)」後,你也很容易推測出,這很複雜,需要很長時間的練習才能演奏的出來。
為什麼我們能夠很迅速準確的預估這兩首曲子的複雜性呢?這跟我們用來判斷一個事情簡單和還是複雜的方法有關。
我們大腦有一些現成的模式來完成這些事情,首先一個就是根據速度。這種情況下,大腦會辨別每秒鐘演奏的東西。根據每秒鐘演奏了多少東西,我們很容易有一個直觀判斷,來決定曲子的複雜度。因為用吉他演奏一首歌是一種物理過程、一種感官上的活動,我們的大腦很容易依此來推測速度,繼而轉換成複雜度。
我們還有另外一個天生的推測依據:體積。想想把一個帳篷和一棟公寓放在一起對比。即使一個人從來沒有學過建築學,他也能告訴你通常設計建造一個帳篷會比設計建造一棟公寓要簡單。
為什麼?因為我們天生的會使用物理體積作為事物複雜性的一個指標。
當然。上面說的這兩種邏輯分析並不總是100%有效。但大多數情況下,人們就是這樣做,而且很奏效。大多數情況中,我們在對物理過程評估時,我們的大腦會對物理事物進行有效的關聯,不需要依賴之前的經驗。
現在讓我們來談談軟體。當一個不懂技術的人試圖對軟體開發時間進行評估時,有兩個很基本的直觀指標在輔助他們:以體積為指標的複雜度和以速度為指標的複雜度。但他們沒有意識到,軟體跟他們想像的不一樣。軟體本質上不是有形物質。沒有體積和速度。它的極小的組成部分可能會時不時的在電腦螢幕上閃現。正因為如此,當面對開發一個網路應用程式時(或任何類型的軟體),我們的基本直觀感覺失效了。
這第一點,速度,很顯然根本不可能被外行人拿來對軟體進行評估。於是很自然的,他們傾向於使用體積指標進行評估。要嘛是根據需求描述的文件頁數,要嘛是根據軟體的功能範例數或功能數。
有時候,這種評估手段確實有效,面對一個靜態網站,沒有特別的設計要求,外行人很容易用這種方法估計出開發時間。但是,通常情況下,對於軟體開發,體積並不能真實有效的反映複雜度。不幸的是,對於軟體的複雜度,唯一有效的推測方法是依據經驗。而且還不是每次都好用。
作為一個程式開發者,我知道,根據我之前開發過的相似的功能,我可以估算出現在的這些功能各自要多少開發時間。然後,我把總時間加起來,這就得到了完成整個計劃需要的大概時間。然而,事實情況中,每個計劃在開發過程中都會遇到二、三個瓶頸。這些瓶頸會肆意的消耗開發者的大量時間,你在遇到它們之前根本不會料想到。它們會拖住整個計劃,使得開發時間延後數週甚至數月。
這些是沒有經驗的人在評估複雜度時不會理解的。他們不明白在其他事情上都有效的方法,為什麼放到軟體開發上就不靈了。所以,下一次當你聽到有人說「我想你幾天時間就能把它開發出來」時,不管是誰說的,都不要懊惱。深呼吸一下,給他這篇文章的連結,然後繼續做自己該做的事。
2013年1月25日 星期五
訂閱:
張貼留言 (Atom)
0 意見:
張貼留言