談軟體項目中的“業務”因素

寫這一篇文章的初衷來自於我從一個人blog上看到的東西，他在blog上及其堅定地說了這樣一句話：業務永遠比技術重要。而在現實中，我也總是聽到這樣的聲音，即決定一個軟體項目成敗的最大因素並不是技術問題，更多的是業務問題。有時候我們也經常看到有人以“過來人”的身份告誡後來者：不要執迷於技術細節，更多的要去瞭解各種業務。

 

 

首先我想用幾句話概括我的觀點：即

n         一個軟體項目如果能夠成功，技術因素和業務因素都是必不可少的

n         軟體項目失敗的一個重要原因，很多人簡單歸結為業務沒有搞清，卻沒有看到背後的問題是人本身在試圖搞清楚這個問題時候方法不正確

n         領域知識，也就是很多人嘴裡的“業務”並不能夠讓你的能力有長足的發展

n         方法論永遠比單純的知識更重要

 

 

什麼樣的軟體項目可以成功呢，在我看來，一個成功的軟體項目有以下特點：

n         良好的使用者反饋，使用者認為這個軟體正確地實現了他們的需求，同時可以方便地使用這個軟體

n         成本控制恰當，軟體企業獲得了所需要的利潤，使用者對自己的支出表示滿意

n         按時交付，或者說交付的時間在使用者可以接受的範圍之內

一個軟體項目如果想要成功，需要各個層面的努力，這其中有幾點尤為重要：

n         對使用者需求的充分發掘

n         高素質的開發人才

n         良好的實現方案和技術架構

n         合適的團隊管理和開發模式

這幾點都是能夠對一個軟體團隊在實施軟體開發中起到決定性作用的因素，在中型或者大型軟體Team Dev中，這些因素是缺一不可的。如果沒有對使用者需求做明確的定義，那麼軟體的開發就是南轅北轍，而缺了人才和技術，一個軟體項目是沒有辦法繼續下去的：人們會發現有那麼多的事情自己辦不到。在幾十甚至幾百人的軟體團隊裡，如何有效地協作就成為了一個令人頭疼的問題，解決這個問題，要靠開發過程的明確定義和正確的管理。

 

 

認為有些因素不如其他因素重要，將讓你的軟體團隊陷入困境。因為實際上這些因素是缺一不可的，就好比人要走路需要兩條腿一樣，是左腿重要還是右腿重要呢？結論是，無論你缺了哪一條腿，都不能夠順利的行走。

 

 

對於“業務”整個詞，我把對它的理解分為兩個方面：領域知識和使用者需求。領域知識就是你所在的這個行業，這個地區，這些客戶的一些共性。而使用者需求是什麼我就不用解釋了。

 

 

一個軟體項目失敗，可能有多種表現形式，但是如果我們考察一下那些失敗的軟體項目，可以發現有很多是因為沒有弄清楚使用者的需求就匆忙進行了開發，結果陷入了使用者不滿意，軟體被迫修改，工期延長，延長的過程中bug層出不窮最後項目失敗的怪圈。這也是很多人認為他們所說的“業務”比“技術”更加重要的原因。

 

 

但是我們要再仔細地探究一下：到底是什麼原因導致了我們不能夠清楚地發掘使用者的需求呢？相信會有很多不同的答案。關於這一點，我會寫另外一篇文章來闡述這個問題。在這裡我只想表達我自己的一個觀點：沒有良好的定義需求，大體上可以有兩個原因：1，沒有正確的方法去探索使用者的需求。2，沒有一個好的機制來對使用者需求的變化作及時反饋。

 

 

沒有正確的方法去探索使用者的需求，意味著在軟體團隊裡，需求定義人員，通常也就是系統分析師的工作沒有做到位，甚至缺乏“會”探索需求的人。沒有好的機制對使用者的需求作反饋，說明軟體開發過程的定義缺乏靈活性，我們從軟體工程的角度來看，一個良好的開發模式，應當事先如何應對使用者需求反饋的方法，如果沒有，它就不是一個好的模式，滿足不了在現代瞬息萬變的社會中大型軟體開發的需要，而這，需要有一整套的方法和制度進行保障。

 

 

如果我們審視一下我們身邊軟體Team Dev中的系統分析師這一個角色，我們就會發現，在中國，很多軟體團隊中沒有合適的人選，說得更加明確一些，沒有人有足夠的能力充任這一角色。在這種情況下，通常會退而求其次，由開發設計人員或者領域專家來作對使用者需求的定義工作。

 

 

這樣有什麼弊病呢？軟體開發人員和需求分析人員所需要的能力是不同的，一個是提出分解問題，解決問題的能力，一個是匯總問題，探索問題所在的能力。所以由軟體開發或者設計人員充任系統分析師，往往不能夠看到問題的實質。於是有了第二個選項，即由一個領域專家來充任系統分析師，但是領域專家的問題是他雖然對所處的領域很熟悉，但是他所熟悉的是這個領域的過去和現狀，而軟體系統所要解決的是如何改變現狀的問題，如果缺乏預見性和分析判斷綜合的能力，領域專家也很難代替系統分析師的角色。

 

 

系統分析是一種能力，它需要方法論的支援，需要智慧，需要交流的能力，迅速領悟的能力。但是系統分析師並不一定必須是領域專家，他可以向其他的領域專家進行諮詢，和他們討論，進而找出問題所在。

 

 

領域知識對於系統分析來說是必須的，但是我想說的是，比領域知識，也就是很多人經常掛在嘴上的“業務”更重要的是你的分析方法，是你擷取和分析領域知識的方法。沒有擷取知識的方法，你無法在面對新的事務時候仍然從容不迫，沒有分析問題的方法，你看不到使用者那些有意義或者無意義的描述後面的東西，你瞭解不了他們的心。

 

 

作為一個系統分析師來講，永遠不要被使用者或者專家嘴裡的專有名詞嚇倒，因為你有一顆睿智的頭腦可以迅速明白這些名次的含義，你有一套科學的方法論做為工具來分析他們的說法是不是有意義，你有敏銳的觀察力讓你能夠看到他們心裡所想的事情。

 

 

很多軟體公司都是在做某一個或者幾個特定行業的應用，很多軟體工程師或者剛開始從事系統分析的人會聽到別人這樣的勸告：我們所在的這個行業業務複雜如牛毛，你一定要多學習，不要執迷於技術。這些說法本身沒有錯誤，但是它忽視了一點：領域知識固然重要，但是最重要的還是發現和分析的方法。如果你只是單純的學習這些領域知識，而不去對這些知識做發掘和分析，更重要的，不去掌握髮掘知識的方法的話，你所掌握的這些知識很快就會被淘汰掉，你所已經掌握的這些知識對於你在別的領域的發展不會有大的作用，它並不能夠讓你的能力有長足的發展。而方法論則是普遍的。這就好比一個程式員，如果只是執著於某種程式設計語言的一些要素，比如這個檔案怎麼列印，那個socket怎麼串連，而不去想潛藏在背後的編程思想，不去想語言中一些共性的東西，那麼總有一天他所熟悉的語言會被淘汰掉，而這個時候，他會發現學習新技術是那麼的耗費時間，因為他只是在追逐一些片面的東西。