我們會在哪些地方耗費大量的時間
壓縮需求確認時間的矛與盾
做項目的時候，一方面我們希望能夠快速明確需求，開始投入開發，使產品能夠盡快上線；另一方面，我們又深知需求會隨着時間的推移越來越明確，就下意識的拖長這個流程。
需求細節的確認
需求應該確認到多細才合適？如何把握這個粒度？
方案優與劣的選擇
這是最難的一個環節。目前僅靠個人經驗和記憶力來做出判斷，其實是很不保險的。因為有時候自己會不了解自己的局限性，給出的選擇在另一方面就會出現問題。
外部接口的測試和溝通
需要注意兩個地方： 第一是和其他部門溝通的方式：批量溝通+郵件交流+文明禮貌+嚴格自檢 第二是自己這邊，需要做好詳盡的單元測試
程序框架、技術的選擇
這個相對來說比較容易，只需要開發人員對於框架技術足夠了解，知道其優劣，就能快速的做出選擇。
搭建新項目的程序框架
直接拷貝已准備好的程序框架
新技術的學習
新項目，千萬千萬不要輕易嘗試新技術。務必要在熟悉掌握之后，才將新技術加入正式項目中。
一些可以幫助明確需求和方案的方法
寫分解文檔
這個經過自己實踐，是非常非常好的一個方法，在寫分解文檔的時候，你能拾遺補缺，發現細節上的問題，還能整理產品的流程，讓自己思路更清晰。 如果是多人開發，那么建議每個人都寫一個分解文檔，然后匯總核對下，這樣能發現很多被遺漏的東西。
講出來
試想你是產品經理，將自己的理解，講給產品經理聽，或者講給你的合作開發者聽。講述的過程，涉及語言文字的整理，同樣會加深你對需求的理解。
設計數據庫
這有助於理清楚數據結構和對象模型
名詞定義
先定義好名詞，能在交流的時候節省不少時間，這就像設計模式，一個詞語就能包含很多信息。
一些常見問題
新事物
總之一句話：凡是涉及新事物，就必須謹慎考慮(新項目、新接口、新同事、新部門) 以新項目為例： 新項目的時間估算不能只看工作量，因為新項目還有很多其他的隱藏工作 比如方案設計、程序結構的設計、數據庫的設計、和其他部門打交道等等 無中生有比優化改進要費事得多