三年前，我見證了一家互聯網電子商務公司從創業開始到最終結束的整個過程，這家公司失敗的根源問題是沒有做好產品的推廣（money不足）。不過，在整個創業過程中，我也學到了很多東西。離開這家公司后，我想在鄭州重新找一家可靠的互聯網公司工作，但結果並不理想。后來，我又嘗試了傳統軟件開發行業的工作，可幾個月下來，讓我認識到的問題是，當前的工作不是自己想要的，更遺憾的是，在上個公司一年多的工作積累也沒有用武之地。轉而在今年3月初，通過朋友的推薦並面試來到現在這家公司，很高興自己又重新回到了互聯網公司工作，而且也是創業型公司。
現在這個公司主要經營親子門戶網站，致力於育兒資訊、電子商務、社區交流等多元化網絡服務。目前，公司項目主要由“內容區(資訊)”和“SNS(社區)”組成，我主要負責內容區的功能分析和架構設計，以及后台的開發工作。
本系列文章主要是想和大家分享一下發生在技術部門的那些事兒，以及自己在實踐過程中，所學知識的總結。
聲明：本系列文章總結只代表人個觀點，請誤對號入坐！
1.1 團隊介紹
1.1.1 產品部
接收：完成網站產品所有功能的設計，接收運營部和所有人員提出的有效建議。
交付文檔：《產品原型說明文檔》、相關需求說明書
崗位職能：網站的每個功能都是由他們設計（原型）出來的，並根據運營部（或策划）的需求設計產品，最終把產品需求轉化為原型圖和配套的原型說明文檔。每個需要交付的產品原型文檔都要通過需求評審會議才能發布，需求評審會議需要技術小組的相關負責人參加，評審會議結束后《產品原型說明文檔》需要發布到技術部各技術小組的負責人手中。
1.1.2 美工組（設計）
接收：《產品原型說明文檔》
交付：產品效果圖、產品所需的各種設計圖（標志、ICON等）
崗位職能：憑借藝術細胞把產品原型文檔轉化為領導能欣賞的網頁圖片...
1.1.3 前端組
接收：《產品原型說明文檔》、效果圖（美工）
交付程序：靜態頁面、資源文件（圖片/樣式表/腳本）、API 調用示例和前端架構說明文檔、第三方插件資料等。
交付文檔：《內容區前端資源處理標准化(SOP)流程文檔》
內部文檔：《html&css前端開發規范》、《javascript前端開發規范》
崗位職能：根據美工提供的效果圖並參考產品部的原型說明文檔進行布局，分析頁面結構、提取公共模塊、設計並開發樣式及腳本框架。在分析和開發過程中，為了能達到更科學的效果（重用、交互體驗等），有時需要和美工及產品經理溝通並修改部分效果圖的布局和交互效果。在實現某些需求和服務器交互的腳本時，需要和開發人員約定相關接收和返回值的接口。
1.1.4 開發組
接收：《產品原型說明文檔》、前端組交付的程序
交付程序：各個產品可運行的網站程序、特定業務自動作業處理程序、公共模塊的測試程序、統一架構的代碼生成模板、程序相關配置說明文檔。
交付文檔：《內容區技術架構》、《內容區開發規格說明書》、《內容區全文檢索解決方案》、《內容區安全測試標准化(SOP)流程文檔》、《內容區各產品配置部署標准化(SOP)流程文檔》
內部文檔：《編碼規范（C#版）》
崗位職能：接收產品部提供的產品原型文檔，並編寫《內容區技術架構》和《內容區開發規格說明書》，根據特定功能分析並編寫解決方案，比如《內容區全文檢 索解決方案》。把前端組所提供的靜態文件，轉換成動態網頁，在功能分析和開發的過程中，同樣也避免不了需求變更，這時需要大家共同協商並解決問題。在網站 程序開發完成並通過測試后，需要編寫相關標准化流程文檔，有關開發組的具體細節會在后幾章為大家分享！
1.1.5 數據庫組
接收：《產品原型說明文檔》、參考開發組的交付文檔
交付文檔：《內容區數據庫結構說明書》、《內容區數據庫配置部署標准化(SOP)流程文檔》
交付程序：內容區相關數據庫腳本
內部文檔：《數據庫管理規范》
崗位職能：分析產品部提供的原型文檔，和開發人員共同協商數據庫的設計，指導開發人員編寫高性能的SQL語句和存儲過程，設計數據庫訪問權限和數據庫物理架構設計，以及數據庫運維工作（部署、備份、安全等）。
1.1.6 測試組
接收：《產品原型說明文檔》、靜態效果圖、網站所有產品的發布程序、前端組和開發組交付的開發說明書和相關配置文檔。
交付程序：經過測試的網站程序
交付文檔：《內容區后台使用說明文檔》、《測試流程管理標准化(SOP)流程文檔》等
內部文檔：《Bug流程管理》、《Bug管理工具說明》、《測試申請單》等
崗位職能：根據產品部提供的產品說明文檔編寫測試用例，並依據以上小組提供的文檔對網站產品進行測試，並按照《Bug流程管理》處理Bug。網站產品測試結束后需要依據《產品發布作業標准化(SOP)流程文檔》進行產品發布，並編寫相關測試總結文檔。
1.1.7 運維組
接收：經過測試的網站程序和相關部署配置文檔。
交付文檔：《托管機房IDC部署文檔》、《IDC機房網站內容區運維標准化(SOP)流程文檔》
崗位職能：公司內部和IDC機房的硬件及網絡運維工作（硬件采購、賬戶分配、網絡維護、硬件及系統環境搭建等），包括服務器系統及相關環境的搭建，按照《產品發布作業標准化(SOP)流程文檔》對網站程序進行部署。
注：以上只是簡單介紹了技術部內部各小組的工作內容，在實際工作環境中還要和產品部門、運營部門、編輯部門進行協作溝通。
1.2 團隊協作
在團隊介紹中已經簡單描述了每個小組的工作內容，從每個小組的“接收”和“交付”內容中可以看出一些工作流程，我根據以上內容簡單地畫了一張“團隊協作流程圖”。
在團隊協作的過程中，有很多環節需要注意，如果前期不進行良好的溝通，各種問題就會越來越多，就如雪球會越滾越大，等到問題暴露出來，甚至會造成項目重頭再來的局面。接下來我會列出項目中幾個比較典型的問題和大家分享。
1.2.1 產品文檔評審會議
首先產品經理需要在《產品原型說明文檔》中，把產品的所有功能描述清楚，因為美工會按照產品原型文檔去設計效果圖。在會議上產品經理需要依據 《產品原型說明文檔》來講解產品所包含的功能，此時參加的組員都可以發表自己的建議。這個環節很重要，開發人員（開發組長或項目經理）必須要理解清楚產品 所包含的每一個功能，因為要依據這些功能來設計產品的技術架構，如果開發人員誤解了需求，有可能會導致階段性工作重來。同樣，測試人員（測試組長或測試經 理）也需要理解每個功能在頁面中的表現，並且，確定《產品原型說明文檔》對功能的解釋足夠詳細，因為后期測試組需要拿着這個文檔來對項目進行功能性測試， 如果前期不確定清楚，在測試時會和開發人員、產品經理發生爭論。總之，每個技術小組的負責人都要理解《產品原型說明文檔》，這樣才能設計和開發出產品經理想要的產品。
1.2.2 需求變更
在這個公司，需求變更可以分為兩種，一種是如果我們犯了上面的錯誤，也就是說，開發人員根本沒有弄清楚需求，這樣就會導致項目在開發過程或內部 測試時，各小組意見不一致，此時，就會請產品經理確認需求，修改相關文檔和程序。另一種則是產品經理在設計時沒有考慮周全，在內部測試時，客戶代表（編輯 人員或負責人）發現不是當初想要的，這時產品經理不得不重新設計需要修改的功能，然后按照流程執行修改。需求變更在傳統瀑布開發模型中是不允許的，而在敏 捷開發方法中，需求變更是常見的事情，所以，在競爭激烈的互聯網行業中，擁抱變化，才能快速迭代發布產品來搶占市場。
1.2.3 架構統一
當網站產品原型和開發文檔都完成后，就進入了實現階段，美工會按照原型來設計網頁效果圖，而前端會根據效果圖來編寫前端代碼，后台也是同樣。這些看似簡單的流程，想要做到持續簡單的同時，還要保障團隊成員在今后有個良好的合作平台，就需要提前定義架構，統一架構。比如，各技術小組都是由多個成員組成的，而公司的發展還會有新成員加入，為了確保新員工加入團隊后，能夠快速適應項目的開發，或者是當老成員離職后，其他團隊成員能夠更快地接手他的任務。在第二章，我會介紹各小組必需要建立的一些內部文檔，但是除了這些文檔，在開始編寫代碼前，還需要各小組分析產品功能、編寫統一的架構設計和案例代碼，並要求整個開發團隊都按照這個流程和代碼結構來編寫代碼，這樣團隊中的每個成員都能有效地閱讀其他人的代碼，同時也方便開發組長（項目經理）進行代碼審查。如果沒有按照以上方法來執行，那么很多開發人員都有過這樣的經歷，在修改團隊其他人，或者在修改離職員工編寫的功能模塊時，寧願自己再重新編寫，也不願審閱他人的代碼。關於架構統一，應該由公司的架構師和團隊中資深開發人員進行具體實現，這樣也可以達到提高團隊成員技術水平的效果。
1.2.4 有效溝通
在團隊協作過程中，建立一個良好的溝通環境很重要，但是很多時候大家是為了溝通而溝通，這樣就會浪費大量的項目時間。前兩天，在看《軟件架構師應該知道的97件事》時，收集了一些關於有效溝通方面的建議：
- 不要把對話當成對抗
- 不要帶着情緒與人溝通
- 嘗試通過溝通設定共同目標
- 以溝通為中心，堅持簡明清晰的表達方式和開明的領導風格。
- 讓溝通事半功倍，起立發言是簡單、有效的方法！
- 必須和執行該決策及會直接或間接受其影響的人進行過溝通，達成共識。
本系列目錄：2011 年終項目總結