通信與互聯網行業軟件項目運做的一些不一樣

最近在工做中體會到了互聯網行業在軟件開發項目運做中與我以往在通信行業時的一些不一樣，特此分享。

首先，二者在需求捕獲方式上有很大的不一樣。在通信行業中，初始需求是由象3GPP這樣的標準化組織所制定的，但通信產品在各版本中所實現的需求是由各運營商向通信企業提出而得以肯定的。產品經理（Product Manager，通信行業的叫法）與系統架構師在需求的肯定過程當中起着重要的做用。與之不一樣的是，互聯網行業因爲產品離最終用戶很是近，用戶能夠經過在線反饋系統提出本身的須要，產品經理（Product Designer， 互聯網行業的叫法）根據各須要的反饋量和競品的情況肯定其是否最終成爲開發需求。兩個行業雖都存在項目經理這個概念，但所起的做用與管理水準相差懸殊。

其次，兩個行業的項目評估過程存在較大差別。通信產品的每個版本大多涉及多個通信子設備的開發工做，所以存在這裏須要重點關注的兩大步驟：一，系統架構師根據需求進行系統設計並造成系統架構文檔和各種通信子設備間的接口文檔；二，各通信子設備開發團隊根據步驟一的輸出文檔進行後續軟件開發工做。這兩大步驟也代表，項目開發時間的評估也存在兩個階段。第一個階段是，全部部門根據feature粗略的技術文檔給出一個評估時間，該階段系統工程部的評估時間要求較準，而開發部的評估卻能夠很粗。第二個階段是，系統工程部完成設計工做並輸出相關文檔後，開發部需根據該文檔從新評估開發時間，因爲此時的信息較前一階段更爲詳細，因此對評估精度的要求也更高，且該評估時間最終用做項目開發計劃。

回到互聯網行業，因爲系統間的耦合性不如通信產品那樣強，加上可能不存在架構師這個層級的系統設計工做，於是項目的評估更加直觀。但也由於架構師的缺失，使得項目的評估工做徹底由開發人員去完成，在開發人員水平良莠不齊的狀況下項目風險每每更高。象Motorola這樣的通信企業，她能作到項目的開發如期所至與存在高水平的架構師不無關係。

再次，設計評審在兩個行業的做用和重視程度也有別。通信行業中，系統工程部在完成系統設計後，將對系統設計的各種文檔進行評審。評審人除了包含系統工程部的系統架構師外，還包括來自各通信子設備開發部的開發架構師。這一評審過程有助於保證系統設計方案最終能被開發部所實現。當開發部着手開發工做時，必定存在概要設計評審和最終的代碼評審工做，這是爲發佈高質量產品所強制的步驟。

反觀互聯網行業，因爲產品離用戶的距離很短，加上產品出現缺陷後能夠快速進行線上修復，於是對產品缺陷率的要求天然不那麼高，結果就是開發團隊對軟件開發的規範性認識要差些，給人的感受更象是「手工做坊」，在質量保證上也談不上運用「系統性的方法論」。

另外一個想借此機會與你們分享的內容是，兩個行業的開發工程師在面對需求不明時的工做習慣也（應）有所不一樣。在通信行業中，開發工程師一旦面臨需求不明這類問題時，一般直接向系統工程部（的系統架構師）尋求幫助。以後，系統架構師會與產品經理仍至客戶進行溝通加以明確並回復給開發工程師。然而，在互聯網行業中，因爲開發工程師直接與產品經理合做（由於不存在系統架構師這一層級的緣故），且很容易由於產品經理經驗的不足使得所提出的需求不清晰，甚至在技術上很難實現。在這種情形下開發工程師因主動承擔起幫助產品經理澄清需求的責任，且在必要的狀況下說服產品經理變動需求。