「
這個功能相當簡單，所有你需要做的就是完成x，
y，z。這個應該不難吧
」聽到這些話是，我非常氣憤，而且說這些話的人幾乎都是跟技術不沾邊的人，或正在研究他們的第乙個產品。想想他們在跟誰辯論軟體開發所需要的時間？但後來我意識到，即使
我自己對
自己的專案**要花去多少開發時間，我也是一籌莫展。如果連我自己都做不好，我何必對那些人惱怒呢？
真正鬱悶的不是他們預估的錯誤。問題在於他們竟然認為自己可以做出正確的估計。作為開發人員，我們經常會發現，在軟體開發的問題上，乙個外行人會很自然的把複雜的事情估計的很簡單、對你指指點點。
這並不是為我們的憤怒找藉口。但這引起了另外乙個有趣的問題：
為什麼我們天生的**複雜性的能力在遇到程式設計問題時會失靈？
為了回答這個問題，讓我們來認識一下我們的大腦如何估計事情的。有些事情對於一些沒有經驗的人也很容易預估正確，但有些事情則不然。
即使你從來沒有學過**，在聽到別人彈鬥、瑞、咪、發、搜、拉、希，你也能大概推測出這很簡單，乙個人不需要太高的技術就能演奏出來。同樣，當欣賞了宮崎駿的《天空之城》交響曲後，你也很容易推測出，這很複雜，需要很長時間的練習才能演奏的出來。
為什麼我們能夠很迅速準確的預估這兩首曲子的複雜性呢？這是跟我們用來判斷乙個事情簡單和還是複雜的方法有關的。我們的大腦有一些現成的模式來完成這些事情，首先乙個就是根據速度。這種情況下，大腦會辨別每秒鐘演奏的東西。根據每秒鐘演奏了多少東西，我們很容易有乙個直觀的判斷曲子的複雜度。因為用結他演奏一首歌是一種物理過程，一種感官上的活動，我們的大腦很容易依此來推測速度，繼而轉換成複雜度。
我們還有另外乙個天生的推測依據：體積。想想把乙個泥巴房和一棟通天大樓放在一起對比。即使乙個人從來沒有學過建築學，他也能告訴你通常設計和建造乙個泥巴會比設計和建造一棟大樓要簡單。為什麼？因為我們天生的會使用物理體積作為事物複雜性的乙個指標。
當然。上面說的這兩種邏輯分析並不是總是
100%
的有效。但大多數情況下，人們就是這樣幹，而且很成功。大多數情況中，我們在對物理過程評估時，我們的大腦會對物理事物進行有效的關聯，不需要依賴之前的經驗。
現在讓我們來談談軟體。當乙個不懂技術的人試圖對軟體開發時間進行評估時，有兩個很基本的直觀指標在輔助他們：以體積為指標的複雜度和以速度為指標的複雜度。但他們沒有意識到，軟體跟他們想象的不一樣。軟體本質上不是有形物質。沒有體積和速度。它的極小的組成部分可能會時不時的在電腦螢幕上閃現。正因為如此，當面對開發乙個
android
應用時(
或任何型別的軟體
)，我們的基本直觀感覺失效了。
這第一點，速度，很顯然根本不可能被外行人拿來對軟體進行評估。於是很自然的，他們傾向於使用體積指標進行評估。要麼是根據描述文件的頁數，要麼是根據軟體的功能用例數或特徵數（曾經做過乙個台灣的專案，光文件就
128m
，其實也都是對一些功能的描述，很好。但功能開發沒什麼技術難點）。
有時候，這種評估手段確實有效！當面對乙個不是很大區別的介面，沒有特別的設計要求，而且很多。外行人很容易用這種方法估計出開發時間（其實很多大致相同的介面是可以復用或公用模板的，呵呵）。但是，通常情況下，對於軟體開發，體積並不能真實有效的反映複雜度。
不幸的是，對於軟體的複雜度，唯一有效的推測方法是依據
經驗。而且還不是時時都好用。作為乙個程式設計師，我知道，根據我之前開發過的相似的功能特徵，我可以估計出現在的這些功能特徵各自要多少開發時間。所以，我把總時間加起來，這就得到了完成整個專案需要的大致時間（當然這只是我美好的想法，畢竟沒帶過專案）。然而，事實情況中，每個專案在開發過程中都遇到
二、三個瓶頸。這些瓶頸會肆意的消耗程式設計師的大量時間，你在遇到它們之前根本不會有所預見。它們會拖住整個專案，致使工期延後數週甚至數月（曾經在做
launcher
開發的過程中，對資料
ui更新介面理解欠缺，導致加班好幾個晚上。）。
這些是沒有經驗的人在評估複雜度時不會理解的。他們不明白在其他事情上都很靈的方法，為什麼放到軟體開發上就不靈了。所以，下一次當你聽到有人說
「我想你幾天時間就能把它開發出來
」時，不管是誰說的，都不要懊惱。深呼吸一下，告訴他你的理解，自己該幹什麼還幹什麼。
產品之路（一） 產品設計九步
產品設計的 九步法 第一步 產品滿足使用者的哪乙個核心需求？第一步的要點是 乙個核心需求 特別注意是 乙個 對於微博這樣的產品，讓瀏覽體驗更好，就是核心需求。系統如何載入更快，使用者如何生產優質資訊，如何摒除spam，如何提公升視覺體驗都是亟待解決的問題。pm永遠不要妄想一下子去發明，顛覆現有的產品...
軟體開發設計文件
專案名稱 概要設計說明書 v1.0 版本號 擬 制 人 審 核 人 批 準 人 一九九九年八月二十日 概要設計說明書 1 引言 1.1編寫目的 說明編寫這份概要設計說明書的目的，指出預期的讀者。1.2背景 a.待開發軟體系統的名稱 b.列出本專案的任務提出者 開發者 使用者。1.3定義 列出本檔案中...
軟考之路 軟體開發模型
軟考中涉及到的主要生存期模型 1.原型開發模型 快速原型模型 演化模型 增量模型 1 快速原型 解釋 其用途是獲知使用者的真正需求，一旦需求確定了，原型即被拋棄。主要用於需求分析階段。是一種 拋棄式 的原型化方法。特徵 簡化專案管理 盡快建立初步需求 加強使用者參與和決策。2 演化模型 解釋 應用於...