通訊與互連網行業軟體項目運作的一些不同

最近在工作中體會到了互連網行業在軟體開發項目運作中與我以往在通訊行業時的一些不同，特此分享。

首先，兩者在需求捕獲方式上有很大的不同。在通訊行業中，初始需求是由象3GPP這樣的標準化組織所制定的，但通訊產品在各版本中所實現的需求是由各電訊廠商向通訊企業提出而得以確定的。產品經理（Product Manager，通訊行業的叫法）與系統架構師在需求的確定過程中起著重要的作用。與之不同的是，互連網行業由於產品離終端使用者非常近，使用者可以通過線上反饋系統提出自己的需要，產品經理（Product Designer， 互連網行業的叫法）根據各需要的反饋量和競品的狀況確定其是否最終成為開發需求。兩個行業雖都存在專案經理這個概念，但所起的作用與管理水準相差懸殊。

其次，兩個行業的項目評估過程存在較大差異。通訊產品的每一個版本大多涉及多個通訊子裝置的開發工作，因此存在這裡需要重點關注的兩大步驟：一，系統架構師根據需求進行系統設計並形成系統架構文檔和各類通訊子裝置間的介面文檔；二，各通訊子裝置Team Dev根據步驟一的輸出文檔進行後續軟體開發工作。這兩大步驟也表明，項目開發時間的評估也存在兩個階段。第一個階段是，所有部門根據feature粗略的技術文檔給出一個評估時間，該階段系統工程部的評估時間要求較准，而開發部的評估卻可以很粗。第二個階段是，系統工程部完成設計工作並輸出相關文檔後，開發部需根據該文檔重新評估開發時間，由於此時的資訊較前一階段更為詳細，所以對評估精度的要求也更高，且該評估時間最終用作項目開發計劃。

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

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

反觀互連網行業，由於產品離使用者的距離很短，加上產品出現缺陷後可以快速進行線上修複，因而對產品缺陷率的要求自然不那麼高，結果就是Team Dev對軟體開發的規範性認識要差些，給人的感覺更象是“手工作坊”，在品質保證上也談不上運用“系統性的方法論”。

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

本文出自李雲的部落格，請務必保留此出處：http://blog.csdn.net/hzliyun/article/details/9028263。