發(fā)表在《程序員》雜志2005年第8期58~62頁的原文
編者按：本文作者劉振飛曾在《程序員》今年第1、2、3期上連續(xù)發(fā)表了訪談文章《Bug管理的經(jīng)驗和實踐（上、中、下）》。不僅Bug管理，劉振飛認(rèn)為微軟公司軟件研發(fā)成熟的產(chǎn)品（項目）管理經(jīng)驗可以推而廣之，應(yīng)用在IT產(chǎn)品研發(fā)的各個領(lǐng)域。他離開微軟后，先后就職于國內(nèi)兩家中小IT公司，直接主持過兩個網(wǎng)站項目的研發(fā)，取得了成功的實踐。本文將他今年的網(wǎng)站項目http://133.newsky.cn作為一個學(xué)習(xí)的典范，以饗讀者。
網(wǎng)站項目成功管理實踐（上）
文/劉振飛
在開始做http://133.newsky.cn之前，我已經(jīng)明白網(wǎng)站的開發(fā)與產(chǎn)品開發(fā)沒有什么不同。不過在2004年離開微軟中國研發(fā)中心Office組的時候，我對網(wǎng)站開發(fā)仍一無所知，這主要是因為我之前沒有任何互聯(lián)網(wǎng)研發(fā)的背景。雖然對傳統(tǒng)軟件產(chǎn)品的研發(fā)管理比較有經(jīng)驗，但從未接觸過Internet相關(guān)的項目。
從零開始與網(wǎng)站開發(fā)親密接觸
去年我接手第一個網(wǎng)站項目http://www.okooo.com開發(fā)時，并沒有做網(wǎng)站的經(jīng)驗，只能試著按照以前我參與做Microsoft Office時的方法來做：
首先是打造一個便于公司內(nèi)部溝通交流的內(nèi)部網(wǎng)，其中包含“傳統(tǒng)軟件”研發(fā)需要的三個工具：文檔庫（存放公司各項目的文檔）、CVS（保存項目的各種源代碼）、BugFree（記錄項目的各種缺陷）；
然后，抓住“需求、開發(fā)、測試”三個環(huán)節(jié)：
l 要做好規(guī)劃、明確需求。為什么要做這個網(wǎng)站、要達到什么目標(biāo)？特別是需求，要詳細(xì)到每個頁面的每個區(qū)域放置什么內(nèi)容。網(wǎng)站需求應(yīng)該由對業(yè)務(wù)最熟悉的人來定義，他負(fù)責(zé)按照我要求的規(guī)范（詳細(xì)程度）來寫出每一部分需求文檔，并放入文檔庫中。每完成一個頁面定義，我就召集開發(fā)、測試人員來閱讀、討論，這樣全部需求寫完的時候，項目組成員對整個網(wǎng)站就有了一個清晰的認(rèn)識。
l 需求明確才進入開發(fā)階段。首先是定義數(shù)據(jù)庫——有多少張表、每張表中有多少個字段。我和開發(fā)組長反復(fù)討論，搞清楚這些表定義能否涵蓋全部需求，這是最關(guān)鍵的一步，決定著下面編碼能否順利進行。數(shù)據(jù)庫定義后，就是網(wǎng)站后臺管理的編碼實現(xiàn)，也就是對一張張表進行管理（增、刪、改）。當(dāng)后臺管理完成時，項目的大部分就大功告成了。用戶看到的前臺頁面僅僅是內(nèi)容展示——把一張張表中的數(shù)據(jù)取出來按照最初的需求放置到頁面的各個位置。所有的代碼都用CVS管理起來。
l 網(wǎng)站測試和開發(fā)同步進行。后臺管理每完成若干張表的管理，測試人員立即開始測試。這就像流水線，開發(fā)完一部分，立刻測試；同樣的，網(wǎng)站前臺展示開發(fā)時也一樣需要測試人員跟進。發(fā)現(xiàn)的每一個Bug都用BugFree記錄下來跟蹤處理過程。
l 數(shù)據(jù)統(tǒng)計跟上。網(wǎng)站后臺各個表的任何改動要準(zhǔn)確記錄，決不允許出現(xiàn)不知道誰修改了數(shù)據(jù)庫內(nèi)容的情況。其次，網(wǎng)友訪問網(wǎng)站的日志要做好統(tǒng)計，每天結(jié)束的時候就能準(zhǔn)確的看到當(dāng)天的用戶訪問數(shù)據(jù)。這些數(shù)據(jù)對網(wǎng)站運營極其重要。
四個月后，我的第一個網(wǎng)站項目順利上線。所有參與該項目的同事感覺都很新鮮，因為以前他們在做網(wǎng)站時，基本上是一個人“包干”一個頻道，簡單構(gòu)思一下就開始寫程序、邊寫邊想、相互獨立。后來，我跟一位曾在某門戶網(wǎng)站工作過的高級工程師朋友介紹了上面的做法，他非常認(rèn)同和贊賞，得到他的認(rèn)可我也很興奮。
隨后接觸到的很多網(wǎng)站技術(shù)人員，讓我發(fā)覺作坊式做法同樣存在于互聯(lián)網(wǎng)公司，網(wǎng)站在重復(fù)多年前傳統(tǒng)軟件的老路：一個“大蝦”很厲害，搞定一個頻道或一個網(wǎng)站的方方面面，離開他誰都玩不轉(zhuǎn)；代碼中處處留著他的靈感，人走了，網(wǎng)站維護就成了大難題：沒有文檔、沒有統(tǒng)一的編碼規(guī)范、沒有測試記錄。
其實無論傳統(tǒng)軟件、網(wǎng)站、還是游戲等等軟件產(chǎn)品/項目，都是程序員用一行行代碼敲出來的，只要像微軟軟件研發(fā)那樣抓住需求、開發(fā)、測試這三個環(huán)節(jié)，其管理都極其類似。因此當(dāng)我進入http://133.newsky.cn網(wǎng)站項目的時候，信心十足：我能把它管好！
打造一個網(wǎng)站開發(fā)的品牌項目
05年2月18日：項目啟動，開始整體規(guī)劃
在我加入金環(huán)天朗的時候，這個網(wǎng)站就已經(jīng)存在了，而最開始的計劃也只是對原有的網(wǎng)站進行局部改版。但是等我深入了解后，大吃一驚：
u 規(guī)劃／需求：原有網(wǎng)站沒有經(jīng)過認(rèn)真規(guī)劃就匆忙上馬，只有部分的簡單示意圖，對于每個頁面具體區(qū)域的功能描述和邏輯過程還是依賴口頭溝通。沒有獨立的后臺管理，依賴于WAP業(yè)務(wù)的后臺，內(nèi)容展示力不從心。
u 頁面設(shè)計：美工因為還有其它工作所以有一定程度的拖延，沒有時間觀念，整個設(shè)計方案沒有經(jīng)過整體評估，導(dǎo)致后來許多細(xì)節(jié)沒有按照計劃實現(xiàn)，頁面設(shè)計先后由兩人分頭獨立完成，導(dǎo)致部分風(fēng)格不一致。
u 開發(fā)：技術(shù)實現(xiàn)一直處在救火的狀態(tài)，沒有規(guī)劃，沒有步驟，沒有主次之分，沒有時間觀念。代碼的結(jié)構(gòu)非常散亂，沒有可用的文檔查詢，開發(fā)人員走了，給以后接手的人帶來極大的麻煩。代碼沒有規(guī)范、沒有注釋。歸結(jié)起來就是可讀性很差。
u 測試：沒有任何測試，開發(fā)人員簡單試一試就直接上線了！
u 內(nèi)容：網(wǎng)站內(nèi)容維護沒有專人負(fù)責(zé)，逐漸處于無人答理的狀態(tài)。
總之，原來的網(wǎng)站有太多不盡人意之處，和同類網(wǎng)站比起來差距較大，市場人員無法推廣，技術(shù)人員很難維護，動不動就出錯。只能另起爐灶，推倒重做一個全新的網(wǎng)站。
對一家SP公司而言，做網(wǎng)站是打通讓用戶消費的通道。從常遠(yuǎn)看，內(nèi)容為王，但短期內(nèi)通道為王：就是讓用戶很容易找到公司提供的內(nèi)容。因為WAP業(yè)務(wù)非常依賴于運營商的門戶排名，一個業(yè)務(wù)放在運營商WAP門戶上，第一屏和第二屏有著本質(zhì)的不同，愿意翻到第2屏上的用戶可能少一半或更多！所以SP要想盡一切辦法來擺脫對門戶的唯一依賴，必須能用別的通道讓用戶很方便的找到你的業(yè)務(wù)。而網(wǎng)站就是最好的宣傳通道，是公司產(chǎn)品最重要的展示平臺。網(wǎng)站研發(fā)的目標(biāo)就是盡快打通聯(lián)通、移動用戶的消費通道，把公司生產(chǎn)出來的產(chǎn)品（圖、鈴、文字）方便地展示給更多的手機用戶。
這個http://133.newsky.cn網(wǎng)站是面向中國聯(lián)通用戶的，其設(shè)計目標(biāo)是：
Ø 1~3年內(nèi)不需要改動大框架
Ø 公司業(yè)務(wù)內(nèi)容的精美展示、銷售平臺
Ø 在同行中有很強的競爭力
Ø 老板可以拿出來給投資人演示
為了達成這個設(shè)計目標(biāo)，我和項目組花了近一個月的時間來制定完整規(guī)劃。
規(guī)劃
需求
美工
開發(fā)
測試
運營
2005-2-18
收到老板Email，項目啟動
2005-3-22
完成規(guī)劃
啟動前臺展示需求的定義
2005-4-04
開始后臺管理需求定義
2005-4-12
完成需求定義。確定后面的時間進度：6/15正式上線運營！
開始后臺管理頁面設(shè)計
開始網(wǎng)站數(shù)據(jù)庫的設(shè)計
2005-4-15
完成“后臺管理詳細(xì)設(shè)計”的文檔
2005-4-16
開始后臺管理的編碼
2005-4-21
開始前臺展示頁面設(shè)計
2005-4-26
完成后臺管理的編碼
2005-4-28
引入測試組，開始后臺管理的測試
2005-5-10
兩名新人到崗，開始前臺展示的編碼
2005-5-23
確定運營組成員及分工
2005-5-31
主要編碼結(jié)束
2005-6-08
測試完畢
開始錄入內(nèi)容
2005-6-12
內(nèi)容全部上線
2005-6-15
http://133.newsky.cn正式上線運營，向公司全體同事通報！
2005-6-22
完成Postmortem(項目總結(jié))，為下個移動網(wǎng)站項目做準(zhǔn)備
明確的研發(fā)流程應(yīng)該是一個開發(fā)團隊的固定資產(chǎn)，從這點上，我建立了一套項目研發(fā)流程，并為其提供工具支撐：
Ø 認(rèn)識老網(wǎng)站的現(xiàn)狀、確定新網(wǎng)站的設(shè)計目標(biāo)；對新網(wǎng)站的總體設(shè)計圖紙進行反復(fù)討論，確定網(wǎng)站研發(fā)的四個總原則（靈活的后臺、以專題為網(wǎng)站細(xì)胞、豐富的資訊、翔實的內(nèi)容）；明確人員分工、并預(yù)告項目執(zhí)行的幾個關(guān)鍵點。
Ø 在沒有公司內(nèi)部網(wǎng)的情況下，我先搭建兩個工具：用于保存各種文檔和源代碼的TortoiseCVS(客戶端)+CVS(服務(wù)器端)，用于缺陷管理的BugFree。為每個項目搭建一個CVS模塊，其中都有四個子目錄：Spec(需求文檔)、Design(設(shè)計文檔)、Code(源代碼)、Test(測試文檔)。
示意圖：網(wǎng)站項目的CVS目錄
然后是人力資源，我在規(guī)劃中提出了非常明確的人力資源需求：
Ø 前臺需求定義：1人（蔡志宏）
Ø 后臺需求定義：2人（劉振飛、朱偉波）
Ø 美工設(shè)計制作：1人
Ø 開發(fā)：3人
Ø 測試：5人
Ø 運營：5人
然而，當(dāng)時的情況卻是項目組人員遲遲無法到位：美工只有一個兼職的、時間無法保證；只有一個開發(fā)組長；沒有測試人員；網(wǎng)站運營人員不能確定。針對這樣的情況，我的任務(wù)還包括了招聘相關(guān)人員及時到位。
在整體上完成上述工作以后，時間已經(jīng)是3月22日了，事實上，在整個項目啟動初期的準(zhǔn)備階段是一個非常重要的工作，清晰的項目規(guī)劃也為后來的工作掃清了很多障礙。這就是俗話說的“磨刀不誤砍柴工”。
05年3月22日：開始定義網(wǎng)站需求
網(wǎng)站需求特別難以確定，為了解決這個問題，我將整個需求定義劃分為三個主要的部分：
1．網(wǎng)站前臺展示的定義
我首先和負(fù)責(zé)定義需求的蔡志宏確定了需求Spec文檔模板，然后他根據(jù)首頁、二級、三級頁面逐個頁面、逐個模塊的去定義：展示什么內(nèi)容，大概的模樣（最終樣式由美工負(fù)責(zé)）。這樣每個頁面都被分解成一塊塊的“部件”，一個“部件”由一份Spec描述，比如下面是“首頁公告欄區(qū)域需求定義”Spec的示意圖。
示意圖：首頁公告欄區(qū)域的需求定義Spec
每完成若干相關(guān)聯(lián)的Spec，我就召集美工、開發(fā)人員開會討論（本應(yīng)該也叫上測試和運營人員，但當(dāng)時還沒有人），大家站在不同的角度去看看有無問題，并最終確認(rèn)下來。
2．聯(lián)通用戶消費流程的定義
用戶消費流程涉及到收費問題，必須把每個細(xì)節(jié)都要搞清楚。這個需求由我負(fù)責(zé)，先形成一份PPT文檔，在大范圍內(nèi)征求大家的意見，然后細(xì)化每個細(xì)節(jié)：從用戶訪問我們的首頁開始，如何登錄，如何轉(zhuǎn)向聯(lián)通網(wǎng)站，如何扣費等每個細(xì)節(jié)必須想到。
3．網(wǎng)站后臺管理的定義
根據(jù)網(wǎng)站前臺的需求，我和開發(fā)組長朱偉波來設(shè)計數(shù)據(jù)庫定義，確定多少張表、每張表中有什么字段。然后從運營人員的登錄頁面開始設(shè)計，用PPT把每張頁面的示意圖以及邏輯關(guān)系都展示出來，然后把需求、開發(fā)、美工召集起來一起討論，看看是否符合運營人員的習(xí)慣、是否有遺漏的地方。
需求文檔要想清楚后再寫下來，讓別人讀得懂。定義好的需求Spec是整個項目開發(fā)的“合同”，馬虎不得。在需求定義的3周中（其中前臺展示的需求用了2周、后臺管理的需求用了1周），每寫出來若干相關(guān)的需求文檔，就在項目組內(nèi)討論一次，最終明確下來。需求文檔一旦成型以后，就必須嚴(yán)格按照需求文檔編寫設(shè)計代碼，盡量控制需求的變化。這不但要求我們在最開始的需求分析階段做好最充分的準(zhǔn)備工作，而且還需要作為項目經(jīng)理的我，頂住一些來自各方意見的壓力。幸運的，我們團隊還是非常好的堅持下來了：
示意圖：上線后的首頁公告欄區(qū)域——完全根據(jù)Spec中的需求定義來實現(xiàn)
然而，另外的一個問題是，需求文檔很容易“老舊”、跟不上最新的變化，需求定義人也懶得去更新，因為開始編碼后誰都不去注意需求文檔了。為了解決這個問題，我就在后臺管理的每一張表的維護頁面上，增加一個“Spec”按鈕，點擊后就可以看到相關(guān)的需求文檔Spec列表了。這樣做有兩個好處：一方面運營人員可以很方便的看到最初是怎么設(shè)計這塊功能的；另一方面也把需求定義者的工作暴露在全體同事面前，文檔寫的好壞是一目了然。
示意圖：每個后臺表管理頁面上都有個Spec按鈕，指向?qū)?yīng)的需求文檔列表
充分的需求定義保證了整個項目能夠準(zhǔn)時完工，這也是我們這個項目能夠取得圓滿成功的原因之一。需求確定之后，后面開發(fā)、測試的時間就基本明確下來了。
05年4月12日：數(shù)據(jù)庫設(shè)計，正式編碼開發(fā)
有了完整的需求文檔后，接下來就進入開發(fā)階段。如同前面提及的，首先需要完成的是數(shù)據(jù)庫的設(shè)計。其實早在需求定義期間，我和朱偉波就已經(jīng)開始數(shù)據(jù)庫定義，確定多少張表、每張表中有什么字段。我們花費了三天左右的時間來對后臺數(shù)據(jù)庫進行詳細(xì)的設(shè)計，并產(chǎn)生出設(shè)計文檔。
示意圖：新天地網(wǎng)站2005版后臺數(shù)據(jù)庫定義.doc
然而，光有需求和詳細(xì)設(shè)計文檔還不夠，開發(fā)團隊需要保持要一種一致的風(fēng)格，這一點要求所有的程序員對代碼有責(zé)任感。因此在這個階段之前（3/16~4/12），我就讓公司所有的Java工程師多次討論，并最后確定一份“編碼規(guī)范”，這樣網(wǎng)站真正開始寫代碼的時候，就有一個明確的規(guī)范來約束代碼的書寫。
對于軟件項目來說，經(jīng)常會有一些出乎意料的情況發(fā)生。比如，本來計劃有兩個開發(fā)人員做后臺管理，結(jié)果因為沈陽聯(lián)通的一個合作項目需求緊急配合，只好臨時抽調(diào)一個人去支援，畢竟網(wǎng)站是公司內(nèi)部可以控制的，導(dǎo)致后臺開發(fā)只有朱偉波一個“光桿司令”，那一段他連續(xù)十余天加班到晚上11:30！這樣高強度、高壓力的工作狀態(tài)，不是每個程序員都能承受的。經(jīng)過朱偉波的努力，終于在十天時間內(nèi)將所有的后臺編碼全部完成（4月16日至4月26日）。
緊接下來，從5月10日開始，專門為網(wǎng)站開發(fā)配備的兩個Java程序員到位，朱偉波首先給他們介紹后臺管理和Struts技術(shù)。隨后分工：首頁、3個鈴聲二級、3個圖片二級、雜志、熱門推薦、精彩專題等，每人承擔(dān)幾個頻道的實現(xiàn)，分頭閱讀對應(yīng)的需求文檔并隨時找蔡志宏討論不清楚的地方。當(dāng)理解需求之后，由朱偉波協(xié)調(diào)，三個人分頭開始進行前臺展示頁面的編碼工作，加班加點，在5月31日基本結(jié)束。
05年4月28日：與開發(fā)并行的測試
在這個項目之前，整個公司是沒有測試人員的！這不得不讓我大為驚訝，一個SP公司沒有測試怎么行！所以在這個項目進行的同時我啟動測試人員招聘工作，最終成立了一支5人組成的測試組，負(fù)責(zé)所有業(yè)務(wù)的測試。
當(dāng)網(wǎng)站后臺管理編碼完成后，4/28立即啟動測試工作：后臺管理中的首頁管理、動畫、聲音、彩圖、專題、資訊由專人負(fù)責(zé)測試，發(fā)現(xiàn)一個問題就在BugFree中記錄一個Bug。通過BugFree的跟蹤和記錄，可以讓某些問題不必累積到最后才解決。隨著網(wǎng)站前臺展示開發(fā)在5月中旬啟動，測試工作也在并行跟進：每個頻道、每個頁面都有專人負(fù)責(zé)檢查，這樣盡可能的把各種潛在的問題揪出來，免除后患。
示意圖：用BugFree來管理網(wǎng)站項目中的Bug
很遺憾的是，因為測試組搭建的比較晚、測試任務(wù)又比較重，他們需要花費很長時間去熟悉公司的各種業(yè)務(wù)，所以在這個網(wǎng)站項目中，對測試文檔部分（比如測試用例）我并沒有要求，只要把問題發(fā)現(xiàn)出來上Bug就好了。這就是項目管理中的Trade-Off：抓住主要矛盾、抓大放小。這個項目結(jié)束后，測試組已經(jīng)逐步成熟、磨合好了，我才開始強調(diào)測試文檔的重要性，每個業(yè)務(wù)測試時一定要同步完成相關(guān)的測試文檔（計劃、用例、測試結(jié)果等），測試時就按照相關(guān)的測試文檔進行。這樣以后復(fù)測就能省掉很多時間，換個人測試也很方便上手。
經(jīng)過一個多月的努力，測試組的同事基本上完成了網(wǎng)站所有頻道、頁面的檢查工作（6月8日）。
05年5月23日：遲到的運營組開始運轉(zhuǎn)
研發(fā)人員做出來的網(wǎng)站只是一個空空的框架，沒有實際的內(nèi)容填上去，網(wǎng)站就無法上線——打個比方，研發(fā)人員把“大樓”蓋好了，還需要運營人員把“內(nèi)部裝修”做好。然而面對人員的稀缺和內(nèi)部調(diào)整，一直到5月23日才確定運營組長及組員分工，他們匆匆進入角色，一面熟悉網(wǎng)站后臺管理，一面準(zhǔn)備內(nèi)容。6月8日才開始正式的網(wǎng)站內(nèi)容錄入。
在此期間，整個項目組都進入了最后的沖刺階段。為了確保6月15日網(wǎng)站能夠上線，我開始將工作日往后倒推，每一周甚至每一天，需求、美工、開發(fā)、測試、運營等環(huán)節(jié)需要到達什么狀態(tài)，必須做到心中有數(shù)；每天都要盯著進度，一旦有了延誤，必須立即找到原因和補救方法。如果實在忙不過來，我就要做出決定砍掉哪些可以延緩的功能模塊。
示意圖：項目最后突擊的日志
05年6月15日：網(wǎng)站正式上線！
值得慶祝的日子到來了。6月15日凌晨我正式向全公司同事報告這個網(wǎng)站正式上線。這是我自己主持研發(fā)的第二個網(wǎng)站，也是我非常用心管理的一個項目。我想留下一個參考樣板，為公司其他項目的管理摸索經(jīng)驗。我認(rèn)為這是一個成功的項目是因為：
ü 做出來的網(wǎng)站符合最初的規(guī)劃和需求定義；
ü 按照需求定義完成的時候(4月12日)確定的進度向前推進，6月15日上線是兩個月前就確定的；
ü 整個項目執(zhí)行過程中，規(guī)劃、需求、開發(fā)、測試等環(huán)節(jié)均按照預(yù)定軌道前進，沒有出現(xiàn)大的紕漏。
整個項目組成員在網(wǎng)站上線后都非常興奮，這應(yīng)該是公司到目前最成功的一個項目管理實踐。公司領(lǐng)導(dǎo)對這個項目的研發(fā)表示非常滿意?，F(xiàn)在的情況是，休整2周后，7月4日按計劃我們又啟動了第2步移動網(wǎng)站的研發(fā)；另外對歷史遺留的眾多WAP業(yè)務(wù)的整理開始提上議事日程。我需要更多時間、耐心和細(xì)心，和需求、開發(fā)、測試等各個環(huán)節(jié)的同事們密切配合，把公司各個業(yè)務(wù)的項目都理出頭緒來、讓研發(fā)部為公司業(yè)務(wù)的不斷成長做出貢獻，也讓技術(shù)人員工作“累身不累心”，不要總是“救火”，要能看到辛苦工作的成效。
網(wǎng)站和產(chǎn)品開發(fā)沒有什么不同！
按我整理的時間表和項目計劃，對照微軟的流程，你會發(fā)現(xiàn)，我完全是按照微軟“傳統(tǒng)軟件”的研發(fā)流程去管理這個網(wǎng)站項目，略有不同的地方是，這個網(wǎng)站項目的時間跨度比較小（只有4個月），而且人力資源有限，美工、開發(fā)、測試三個環(huán)節(jié)我只能是并行處理、流水作業(yè)，以盡量縮短項目的整體時間。
規(guī)劃和需求階段
開發(fā)階段
測試階段
發(fā)布階段
主參與人
Planner與PM驅(qū)動
開發(fā)人員推動
測試人員推動
PM，產(chǎn)品經(jīng)理，運營管理等執(zhí)行
階段成果
目標(biāo)描述 (Vision)
詳細(xì)需求文檔 (Spec)
日程進度表
M1, M2, …
Code Complete
集成測試
Bug-Fix, Check-in
Dogfood
Beta1, beta2, … (Triage)
Zero Bug Release
Show-Stopper bug
Release Candidate(RC)
Sign-off
RTM (Ready To Release)
我也算是“把微軟先進的軟件研發(fā)理念和中國中小企業(yè)的具體情況相結(jié)合”吧，其中最難的是把項目研發(fā)流程的理念灌輸給全組同事以統(tǒng)一認(rèn)識，并能有效的執(zhí)行下去。很多時候要靠我不斷的去PUSH各個環(huán)節(jié)，做的比較累，但在完成之后，很有成就感，尤其是針對一個團隊不斷發(fā)展和成熟，所做的努力是顯而易見的。（未完待續(xù)）
