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

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

 

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

 

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

 

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

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

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

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

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

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

 

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

 

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

 

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

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

 

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

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

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

 

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

　　嚯！如果誰能準確估算這個時間，就應該是高手了?？纯次覀優榱送瓿衫?需要我們作多少事情吧：制定寫作提綱，勾畫寫作內容，評估打字速度和每一個內容的量…依我看，不用計算了，計算再多，這個工作的進度依然會被拖延。

 

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

 

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

---