要讓項目計劃貼近現實，首先我們需要把項目中所有的工作都羅列出來，然后把每一個步驟地工作進行細分，以致細分到“原子級”，也就是不能再分的程度，從軟件項目來看，就是分到“文件”，分到“類”甚至分到“函數”級別。然后對這些“原子級別”的工作進行評估時間，累計綜合，最后乘上一個系數（一般是2），就是最終項目所要花費的時間了

　　說起來容易，做起來難！光是要求把工作細分到原子級，就已經足以讓一大批項目經理當場暈倒了。

　　我們再回來看例子2，如果解題的人忘記了這個求解的公式的話，前面估算的進度是否需要調整呢？回答是肯定的。這樣的時間計算就需要考慮尋找資料的時間，只要找到公式，計算出結果就不是問題了，而找公式所花費的時間，在有通暢的網絡連接情況下，包括網絡搜索、詢問同事等等方法，一個小時足矣！

　　如果說光是找一個公式就需要額外的一個小時的話，把例子2的題目修改成計算“傅立葉”

變換（非編程計算）又需要多少時間呢？顯然跟解二元一次方程又不是一個數量級的工作了，我們除了尋找資料之外，大部分人還需要學習，沒有高等數學基礎的人恐怕更需要加入“研究”了。

　　從例子2就可以總結出如下幾個現象：工作與工作之間可以有層次關系的，一個看似很簡單的工作，很可能會隱含著巨大的工作量，在某些先決條件沒有或者準備不足的情況下尤其如此。要準確估算一個工作所用的時間，首先我們就要把“折疊”起來的“工作樹”盡可能完全“展開”，其次就必須要遏制工作中的“學習”、“研究”甚至“查詢搜索”的工作量。總之，在實際項目開展的時候，就要盡可能讓所有的工作都是單純的，可以預測的，并且盡可能排除那些不可控、不可靠的因素。

　　換句話說，項目的每一個工作與時間的關系都必須是“線性”的。如果實在不能排除“非線性”的工作，也必須在“可控”的范圍內，項目內部不允許有“不可控”的“非線性”因素存在。

　　一句話： 腦筋動得越多，事情做得越慢！

　　到底項目中究竟有多少因素是屬于“不可控”呢？哪些又是屬于“可控”的？哪些屬于“線性”因素？要回答這個問題，我們首先來看一下我們目前的軟件開發方式和流程吧：

（一）接單簽訂合同

（二）需求調研、分析

（三）架構設計、概要設計

（四）詳細設計

（五）編碼、測試

（六）交付、維護

　　大致六個步驟，其中三四五是和我們談得開發過程相關聯（其他部分我會在以后的系列文章中討論）。首先我們看第三點和第四點，他們統稱為“設計”，參考文獻2中給出的“設計”階段的目標是解決四方面的問題：數據結構，軟件體系結構，過程細節，接口性質。

　　有經驗的讀者我想已經看出來了，傳統的“設計”所解決的問題，有相當一部分應該歸納為現在的“架構”范圍內。軟件架構涉及的范圍主要包括如下：

（一）應用程序的層次劃分（比如界面層，存儲層等），

（二）部分應用程序模塊的劃分（比如初始化模塊，配置模塊，權限模塊等），

（三）部分應用程序模塊的實現（權限、用戶、組織機構管理等），

（四）函數庫的實現，

（五）各模塊、層之間的相互關系和通訊機制，

（六）相關的部分數據結構定義。

　　如此可見，上文中的第三和第四點最重要和最基礎的工作基本就在“架構”范圍內，剩下的工作，基本就是跟具體業務相關的了。