艾偉也談項目管理，軟體架構引言之項目管理的問題

　　軟體架構引言之項目管理的問題

　　很多朋友都有過或者正在管理一個或者多個軟體項目，那麼我的文章就從這個問題開始：如果單純從表象來說，軟體項目管理過程中暴露的最大問題是什麼？

　　不同的人的會有不同的答案，但是大緻這樣的答案我想大部分人都是會認可的，那就是“進度拖延”。進度拖延當然是表象之一了，其他諸如品質不過關、功能不完整等等，我覺得都是和進度拖延密切相關的。很多項目經理都想去做那些認為是十分必要的事情，比如計劃、測試等，但是“沒有時間”。為什麼會沒有時間？等到項目總結的時候，我們總會羅列出一大堆的理由試圖來說服自己，說服公司甚至說服客戶。但是如果限定項目經理隻從自己身上找原因的話，我想問題就不難找了。

　　這裡，我用“豐田”的“五次為什麼”方法來問這個問題，以及我覺得可能的回答：

一、為什麼項目進度會拖延？因為沒有按照項目計劃進行！

二、為什麼不按照項目計劃執行？因為進度總會有拖延，緩沖時間總會被用光。

三、為什麼在計劃時候不規劃得更細更貼近現實一些呢？再細也總有額外的工作出現。

四、為什麼不充分評估每一個工作，讓預料之外的工作盡可能少呢？因為确實無法評估下去了，很多認為是原子級的工作都會産生出各種問題。

五、沒有可以參考的其他項目的項目計劃嗎？因為兩個項目的不同點太多，很難重用。

　　問到這裡，我想一般項目的核心問題也就顯露在我們的面前。現在先不去談論這個問題，我們用幾個簡單的例子讓他更生動一些。

　　我們用一個非軟體的事情舉例，讓大家為這個例子作一個詳細的項目計劃并評估出最精确的時間。

　　例子1：請大家評估各自把我的這篇文章重新打一遍的時間。

　　這個例子最簡單了，拿我自己來說，我打字速度為每分鐘30個漢字，是以這篇文章重新打一遍的時間就是文章的總字數3000/30=100分鐘。加上中間休息的時間，最多就是120分鐘。

　　答案相當準确，我想也不會有太多人有異議，但是下一個例子可能就有些不一樣了。

　　例子2：請大家解開下列的方程式：x2+px+q=0, p=2, q=1

　　國中的方程式阿，但是很多人可能忘記它的通用求解公式了，不過我們假設大家都知道這個求解公式：-p/2±sqrt(p2/4-q)。評估時間的時候我們首先要知道我們打開電腦的時間，輸入資料的時間，抄錄結果，并且為了保證計算準确，我們需要進行驗算。嗯，這樣估算時間的權威性恐怕不如例子1那樣令人信服了，而且我們經常需要因為算錯而重新計算，逾時恐怕很難會避免。

　　例子3：請大家按照我的引言，結合自己的項目實踐，重新寫一篇吧。

　　嚯！如果誰能準确估算這個時間，就應該是高手了。看看我們為了完成例子3需要我們作多少事情吧：制定寫作提綱，勾畫寫作内容，評估打字速度和每一個内容的量…依我看，不用計算了，計算再多，這個工作的進度依然會被拖延。

　　這三個例子有差別嗎？當然有！例子1的估算方法大家都掌握，而且執行過程中的變數最少，因為并不需要我們去做任何的探索過程（猜某個字的五筆字型不算，至少我用微軟拼音）。例子2的不同點是解題的方法需要外部因素的介入，而且這個技術并不是每個人都掌握（或者記得），最重要的特點是每一個步驟我們都需要去估算它完成所需要的時間，如果我們已經計算過一次了，當然第二次就會估算的更準确一些。可是現實生活中的項目很少會給你機會重新做一遍。當你完成項目之後，跟這個特定項目相關的各種方法也就失去了它的作用，它唯一的價值就是潛入你的記憶中，成為所謂的“項目經驗”，而這個“經驗”也常常會在下一個項目水土不服。相比而言，例子2好歹是一些看得見摸得着的動作，評估起來也會有一點依據，而例子3則幾乎是一個純粹的大腦運動，要讓大家憑空組裝成一篇好看的文章，我看這個進度要估算也太難了，誰知道為了一個内容，我們要反複推敲甚至發呆多少時間呢？！

　　我們把話題拉回到篇首的五次為什麼上來。軟體項目甚至其他項目能夠按時完成的最主要一點就是要做好“計劃”，能否規劃一個符合實際的項目計劃，是項目成敗最大的晴雨表。

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

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

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

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

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

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

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

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

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

（一）接單簽訂合同

（二）需求調研、分析

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

（四）詳細設計

（五）編碼、測試

（六）傳遞、維護

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

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

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

（二）部分應用程式子產品的劃分（比如初始化子產品，配置子產品，權限子產品等），

（三）部分應用程式子產品的實作（權限、使用者、組織機構管理等），

（四）函數庫的實作，

（五）各子產品、層之間的互相關系和通訊機制，

（六）相關的部分資料結構定義。

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

　　在上文的三個“xx設計”中，架構設計的時間最難控制和估算，概要設計和詳細設計因為就是直接從需求條目演化而來，而且容易細化（以後我會有文章專門讨論），是以雖然也是屬于“設計”這種“非線性”工作，但是“可控性”要比“架構”強很多。從個人的項目維護經驗來看，維護過程中産生的問題，有相當一部分是因為使用者需求突破了原先架構的能力所緻，而正是這種問題，才是拖延時間最長，引起客戶反映最強烈，也是維護人員最痛苦最頭痛的問題。是以，“架構設計”我把它歸類到“非線性”工作中，而且是“難點”工作。

　　我看到很多的公司軟體部門都叫做“研發部”，用英文說就是research and development的部門，但是我很少看到有公司把research和development分開做兩個部門的。這有什麼關系呢？從上文我們可以看到，研究是一種非常耗費資源的工作，而且風險（尤其是技術風險）很大，很可能因為一個小技術難題不能突破而導緻整個架構推翻重來，而開發的風險則要小得多，可控得多；另外一個大的差別就是研究并不直接創造價值，而開發則跟公司的收入密切相關。基于這兩個理由，就足夠把“研究”和“開發”完全分開成兩個部門了。其他當然還有許多的差別，比如考核方式等。

　　分開之後的工作如何配置設定？很簡單，就是把“軟體架構”和其他有難度的“非線性”工作統統交給高手雲集的“研究”部門去做；具體項目相關的業務和實作（“線性”的工作）交由“開發”部門去做，因為他們對技術要求不高，而且成本較低。說到這裡，我是不是在主張每一個公司都需要專人去“研究”技術呢？恰恰相反，我主張大部分公司都不需要設立“研究”部門，至少大部分公司不要去研制甚至試圖研制所謂“自己的”軟體架構。因為軟體架構相比具體業務有一定的獨立性，并沒有一種“特别适合”于某類業務的“軟體架構”存在，即使有，它也是應該經過N個項目的M年考驗之後才會出現（N*M>10年）。我相信SAP會有這樣的架構，但是國内公司基本不會有（也許有，但是請大家了解我的懷疑）。現在市面上有很多開源的架構存在，選一個吧，然後去教育訓練你的員工，不斷地教育訓練，指導他們能夠熟練地将這個架構應用到項目中去為止，即使這樣，你的總花費也還遠遠小于請一個“高手”開發一個失敗架構的投入。

　　如何來選擇一個現成的架構已經不在文章讨論範圍之内了，因為我接下來要談的是“如何開發一個自己的架構”，不過也不用慌，如果你的開發語言是java的話，那麼恭喜你，很多好用的開源架構都是java的，比如spring MVC，struts/webwork，tapestry；如果你用的是.net平台，那麼微軟已經幫你做了一個淺層的封裝，或者幹脆用.net的petshop或者Duwamish的架構就可以了。

　　接下來的文章，我們來談一下軟體架構對項目管理的促進作用。

　　參考文獻：

二、軟體工程（楊文龍等編著）電子工業出版社ISBN7-5053-4058-1