安靜的等待

在開始做http://133.newsky.cn之前，我已經明白網站的開發與產品開發沒有什么不同。不過在2004年離開微軟中國研發中心Office組的時候，我對網站開發仍一無所知，這主要是因為我之前沒有任何互聯網研發的背景。雖然對傳統軟件產品的研發管理比較有經驗，但從未接觸過Internet相關的項目。

 

從零開始與網站開發親密接觸

去年我接手第一個網站項目http://www.okooo.com開發時，并沒有做網站的經驗，只能試著按照以前我參與做Microsoft Office時的方法來做：

首先是打造一個便于公司內部溝通交流的內部網，其中包含“傳統軟件”研發需要的三個工具：文檔庫（存放公司各項目的文檔）、CVS（保存項目的各種源代碼）、BugFree（記錄項目的各種缺陷）；

然后，抓住“需求、開發、測試”三個環節：

l         要做好規劃、明確需求。為什么要做這個網站、要達到什么目標？特別是需求，要詳細到每個頁面的每個區域放置什么內容。網站需求應該由對業務最熟悉的人來定義，他負責按照我要求的規范（詳細程度）來寫出每一部分需求文檔，并放入文檔庫中。每完成一個頁面定義，我就召集開發、測試人員來閱讀、討論，這樣全部需求寫完的時候，項目組成員對整個網站就有了一個清晰的認識。

l         需求明確才進入開發階段。首先是定義數據庫——有多少張表、每張表中有多少個字段。我和開發組長反復討論，搞清楚這些表定義能否涵蓋全部需求，這是最關鍵的一步，決定著下面編碼能否順利進行。數據庫定義后，就是網站后臺管理的編碼實現，也就是對一張張表進行管理（增、刪、改）。當后臺管理完成時，項目的大部分就大功告成了。用戶看到的前臺頁面僅僅是內容展示——把一張張表中的數據取出來按照最初的需求放置到頁面的各個位置。所有的代碼都用CVS管理起來。

l         網站測試和開發同步進行。后臺管理每完成若干張表的管理，測試人員立即開始測試。這就像流水線，開發完一部分，立刻測試；同樣的，網站前臺展示開發時也一樣需要測試人員跟進。發現的每一個Bug都用BugFree記錄下來跟蹤處理過程。

l         數據統計跟上。網站后臺各個表的任何改動要準確記錄，決不允許出現不知道誰修改了數據庫內容的情況。其次，網友訪問網站的日志要做好統計，每天結束的時候就能準確的看到當天的用戶訪問數據。這些數據對網站運營極其重要。

 

四個月后，我的第一個網站項目順利上線。所有參與該項目的同事感覺都很新鮮，因為以前他們在做網站時，基本上是一個人“包干”一個頻道，簡單構思一下就開始寫程序、邊寫邊想、相互獨立。后來，我跟一位曾在某門戶網站工作過的高級工程師朋友介紹了上面的做法，他非常認同和贊賞，得到他的認可我也很興奮。

隨后接觸到的很多網站技術人員，讓我發覺作坊式做法同樣存在于互聯網公司，網站在重復多年前傳統軟件的老路：一個“大蝦”很厲害，搞定一個頻道或一個網站的方方面面，離開他誰都玩不轉；代碼中處處留著他的靈感，人走了，網站維護就成了大難題：沒有文檔、沒有統一的編碼規范、沒有測試記錄。

其實無論傳統軟件、網站、還是游戲等等軟件產品/項目，都是程序員用一行行代碼敲出來的，只要像微軟軟件研發那樣抓住需求、開發、測試這三個環節，其管理都極其類似。因此當我進入http://133.newsky.cn網站項目的時候，信心十足：我能把它管好！

 

打造一個網站開發的品牌項目

05年2月18日：項目啟動，開始整體規劃

在我加入金環天朗的時候，這個網站就已經存在了，而最開始的計劃也只是對原有的網站進行局部改版。但是等我深入了解后，大吃一驚：

u       規劃／需求：原有網站沒有經過認真規劃就匆忙上馬，只有部分的簡單示意圖，對于每個頁面具體區域的功能描述和邏輯過程還是依賴口頭溝通。沒有獨立的后臺管理，依賴于WAP業務的后臺，內容展示力不從心。

u       頁面設計：美工因為還有其它工作所以有一定程度的拖延，沒有時間觀念，整個設計方案沒有經過整體評估，導致后來許多細節沒有按照計劃實現，頁面設計先后由兩人分頭獨立完成，導致部分風格不一致。

u       開發：技術實現一直處在救火的狀態，沒有規劃，沒有步驟，沒有主次之分，沒有時間觀念。代碼的結構非常散亂，沒有可用的文檔查詢，開發人員走了，給以后接手的人帶來極大的麻煩。代碼沒有規范、沒有注釋。歸結起來就是可讀性很差。

u       測試：沒有任何測試，開發人員簡單試一試就直接上線了！

u       內容：網站內容維護沒有專人負責，逐漸處于無人答理的狀態。

總之，原來的網站有太多不盡人意之處，和同類網站比起來差距較大，市場人員無法推廣，技術人員很難維護，動不動就出錯。只能另起爐灶，推倒重做一個全新的網站。

 

對一家SP公司而言，做網站是打通讓用戶消費的通道。從常遠看，內容為王，但短期內通道為王：就是讓用戶很容易找到公司提供的內容。因為WAP業務非常依賴于運營商的門戶排名，一個業務放在運營商WAP門戶上，第一屏和第二屏有著本質的不同，愿意翻到第2屏上的用戶可能少一半或更多！所以SP要想盡一切辦法來擺脫對門戶的唯一依賴，必須能用別的通道讓用戶很方便的找到你的業務。而網站就是最好的宣傳通道，是公司產品最重要的展示平臺。網站研發的目標就是盡快打通聯通、移動用戶的消費通道，把公司生產出來的產品（圖、鈴、文字）方便地展示給更多的手機用戶。

這個http://133.newsky.cn網站是面向中國聯通用戶的，其設計目標是：

Ø         1~3年內不需要改動大框架

Ø         公司業務內容的精美展示、銷售平臺

Ø         在同行中有很強的競爭力

Ø         老板可以拿出來給投資人演示

 

為了達成這個設計目標，我和項目組花了近一個月的時間來制定完整規劃。

 

	規劃	需求	美工	開發	測試	運營
2005-2-18	收到老板Email，項目啟動
2005-3-22	完成規劃	啟動前臺展示需求的定義
2005-4-04		開始后臺管理需求定義
2005-4-12		完成需求定義。確定后面的時間進度：6/15正式上線運營！	開始后臺管理頁面設計	開始網站數據庫的設計
2005-4-15				完成“后臺管理詳細設計”的文檔
2005-4-16				開始后臺管理的編碼
2005-4-21			開始前臺展示頁面設計
2005-4-26				完成后臺管理的編碼
2005-4-28					引入測試組，開始后臺管理的測試
2005-5-10				兩名新人到崗，開始前臺展示的編碼
2005-5-23						確定運營組成員及分工
2005-5-31				主要編碼結束
2005-6-08					測試完畢	開始錄入內容
2005-6-12						內容全部上線
2005-6-15	http://133.newsky.cn正式上線運營，向公司全體同事通報！
2005-6-22	完成Postmortem(項目總結)，為下個移動網站項目做準備

 

明確的研發流程應該是一個開發團隊的固定資產，從這點上，我建立了一套項目研發流程，并為其提供工具支撐：

Ø         認識老網站的現狀、確定新網站的設計目標；對新網站的總體設計圖紙進行反復討論，確定網站研發的四個總原則（靈活的后臺、以專題為網站細胞、豐富的資訊、翔實的內容）；明確人員分工、并預告項目執行的幾個關鍵點。

Ø         在沒有公司內部網的情況下，我先搭建兩個工具：用于保存各種文檔和源代碼的TortoiseCVS(客戶端)+CVS(服務器端)，用于缺陷管理的BugFree。為每個項目搭建一個CVS模塊，其中都有四個子目錄：Spec(需求文檔)、Design(設計文檔)、Code(源代碼)、Test(測試文檔)。

 

 

示意圖：網站項目的CVS目錄

 

然后是人力資源，我在規劃中提出了非常明確的人力資源需求：

Ø         前臺需求定義：1人（蔡志宏）

Ø         后臺需求定義：2人（劉振飛、朱偉波）

Ø         美工設計制作：1人

Ø         開發：3人

Ø         測試：5人

Ø         運營：5人

然而，當時的情況卻是項目組人員遲遲無法到位：美工只有一個兼職的、時間無法保證；只有一個開發組長；沒有測試人員；網站運營人員不能確定。針對這樣的情況，我的任務還包括了招聘相關人員及時到位。

在整體上完成上述工作以后，時間已經是3月22日了，事實上，在整個項目啟動初期的準備階段是一個非常重要的工作，清晰的項目規劃也為后來的工作掃清了很多障礙。這就是俗話說的“磨刀不誤砍柴工”。

 

05年3月22日：開始定義網站需求

網站需求特別難以確定，為了解決這個問題，我將整個需求定義劃分為三個主要的部分：

 

1．網站前臺展示的定義

我首先和負責定義需求的蔡志宏確定了需求Spec文檔模板，然后他根據首頁、二級、三級頁面逐個頁面、逐個模塊的去定義：展示什么內容，大概的模樣（最終樣式由美工負責）。這樣每個頁面都被分解成一塊塊的“部件”，一個“部件”由一份Spec描述，比如下面是“首頁公告欄區域需求定義”Spec的示意圖。

 

 

示意圖：首頁公告欄區域的需求定義Spec

 

每完成若干相關聯的Spec，我就召集美工、開發人員開會討論（本應該也叫上測試和運營人員，但當時還沒有人），大家站在不同的角度去看看有無問題，并最終確認下來。

 

2．聯通用戶消費流程的定義

用戶消費流程涉及到收費問題，必須把每個細節都要搞清楚。這個需求由我負責，先形成一份PPT文檔，在大范圍內征求大家的意見，然后細化每個細節：從用戶訪問我們的首頁開始，如何登錄，如何轉向聯通網站，如何扣費等每個細節必須想到。

 

3．網站后臺管理的定義

       根據網站前臺的需求，我和開發組長朱偉波來設計數據庫定義，確定多少張表、每張表中有什么字段。然后從運營人員的登錄頁面開始設計，用PPT把每張頁面的示意圖以及邏輯關系都展示出來，然后把需求、開發、美工召集起來一起討論，看看是否符合運營人員的習慣、是否有遺漏的地方。

 

需求文檔要想清楚后再寫下來，讓別人讀得懂。定義好的需求Spec是整個項目開發的“合同”，馬虎不得。在需求定義的3周中（其中前臺展示的需求用了2周、后臺管理的需求用了1周），每寫出來若干相關的需求文檔，就在項目組內討論一次，最終明確下來。需求文檔一旦成型以后，就必須嚴格按照需求文檔編寫設計代碼，盡量控制需求的變化。這不但要求我們在最開始的需求分析階段做好最充分的準備工作，而且還需要作為項目經理的我，頂住一些來自各方意見的壓力。幸運的，我們團隊還是非常好的堅持下來了：

 

 

示意圖：上線后的首頁公告欄區域——完全根據Spec中的需求定義來實現

 

然而，另外的一個問題是，需求文檔很容易“老舊”、跟不上最新的變化，需求定義人也懶得去更新，因為開始編碼后誰都不去注意需求文檔了。為了解決這個問題，我就在后臺管理的每一張表的維護頁面上，增加一個“Spec”按鈕，點擊后就可以看到相關的需求文檔Spec列表了。這樣做有兩個好處：一方面運營人員可以很方便的看到最初是怎么設計這塊功能的；另一方面也把需求定義者的工作暴露在全體同事面前，文檔寫的好壞是一目了然。

 

 

示意圖：每個后臺表管理頁面上都有個Spec按鈕，指向對應的需求文檔列表

 充分的需求定義保證了整個項目能夠準時完工，這也是我們這個項目能夠取得圓滿成功的原因之一。需求確定之后，后面開發、測試的時間就基本明確下來了。

 05年4月12日：數據庫設計，正式編碼開發

有了完整的需求文檔后，接下來就進入開發階段。如同前面提及的，首先需要完成的是數據庫的設計。其實早在需求定義期間，我和朱偉波就已經開始數據庫定義，確定多少張表、每張表中有什么字段。我們花費了三天左右的時間來對后臺數據庫進行詳細的設計，并產生出設計文檔。

 

示意圖：新天地網站2005版后臺數據庫定義.doc

 

然而，光有需求和詳細設計文檔還不夠，開發團隊需要保持要一種一致的風格，這一點要求所有的程序員對代碼有責任感。因此在這個階段之前（3/16~4/12），我就讓公司所有的Java工程師多次討論，并最后確定一份“編碼規范”，這樣網站真正開始寫代碼的時候，就有一個明確的規范來約束代碼的書寫。

 

對于軟件項目來說，經常會有一些出乎意料的情況發生。比如，本來計劃有兩個開發人員做后臺管理，結果因為沈陽聯通的一個合作項目需求緊急配合，只好臨時抽調一個人去支援，畢竟網站是公司內部可以控制的，導致后臺開發只有朱偉波一個“光桿司令”，那一段他連續十余天加班到晚上11:30！這樣高強度、高壓力的工作狀態，不是每個程序員都能承受的。經過朱偉波的努力，終于在十天時間內將所有的后臺編碼全部完成（4月16日至4月26日）。

緊接下來，從5月10日開始，專門為網站開發配備的兩個Java程序員到位，朱偉波首先給他們介紹后臺管理和Struts技術。隨后分工：首頁、3個鈴聲二級、3個圖片二級、雜志、熱門推薦、精彩專題等，每人承擔幾個頻道的實現，分頭閱讀對應的需求文檔并隨時找蔡志宏討論不清楚的地方。當理解需求之后，由朱偉波協調，三個人分頭開始進行前臺展示頁面的編碼工作，加班加點，在5月31日基本結束。

 

05年4月28日：與開發并行的測試

在這個項目之前，整個公司是沒有測試人員的！這不得不讓我大為驚訝，一個SP公司沒有測試怎么行！所以在這個項目進行的同時我啟動測試人員招聘工作，最終成立了一支5人組成的測試組，負責所有業務的測試。

當網站后臺管理編碼完成后，4/28立即啟動測試工作：后臺管理中的首頁管理、動畫、聲音、彩圖、專題、資訊由專人負責測試，發現一個問題就在BugFree中記錄一個Bug。通過BugFree的跟蹤和記錄，可以讓某些問題不必累積到最后才解決。隨著網站前臺展示開發在5月中旬啟動，測試工作也在并行跟進：每個頻道、每個頁面都有專人負責檢查，這樣盡可能的把各種潛在的問題揪出來，免除后患。

 

示意圖：用BugFree來管理網站項目中的Bug

 

很遺憾的是，因為測試組搭建的比較晚、測試任務又比較重，他們需要花費很長時間去熟悉公司的各種業務，所以在這個網站項目中，對測試文檔部分（比如測試用例）我并沒有要求，只要把問題發現出來上Bug就好了。這就是項目管理中的Trade-Off：抓住主要矛盾、抓大放小。這個項目結束后，測試組已經逐步成熟、磨合好了，我才開始強調測試文檔的重要性，每個業務測試時一定要同步完成相關的測試文檔（計劃、用例、測試結果等），測試時就按照相關的測試文檔進行。這樣以后復測就能省掉很多時間，換個人測試也很方便上手。

經過一個多月的努力，測試組的同事基本上完成了網站所有頻道、頁面的檢查工作（6月8日）。

 

05年5月23日：遲到的運營組開始運轉

研發人員做出來的網站只是一個空空的框架，沒有實際的內容填上去，網站就無法上線——打個比方，研發人員把“大樓”蓋好了，還需要運營人員把“內部裝修”做好。然而面對人員的稀缺和內部調整，一直到5月23日才確定運營組長及組員分工，他們匆匆進入角色，一面熟悉網站后臺管理，一面準備內容。6月8日才開始正式的網站內容錄入。

在此期間，整個項目組都進入了最后的沖刺階段。為了確保6月15日網站能夠上線，我開始將工作日往后倒推，每一周甚至每一天，需求、美工、開發、測試、運營等環節需要到達什么狀態，必須做到心中有數；每天都要盯著進度，一旦有了延誤，必須立即找到原因和補救方法。如果實在忙不過來，我就要做出決定砍掉哪些可以延緩的功能模塊。

 

示意圖：項目最后突擊的日志

 

05年6月15日：網站正式上線！

值得慶祝的日子到來了。6月15日凌晨我正式向全公司同事報告這個網站正式上線。這是我自己主持研發的第二個網站，也是我非常用心管理的一個項目。我想留下一個參考樣板，為公司其他項目的管理摸索經驗。我認為這是一個成功的項目是因為：

整個項目組成員在網站上線后都非常興奮，這應該是公司到目前最成功的一個項目管理實踐。公司領導對這個項目的研發表示非常滿意。現在的情況是，休整2周后，7月4日按計劃我們又啟動了第2步移動網站的研發；另外對歷史遺留的眾多WAP業務的整理開始提上議事日程。我需要更多時間、耐心和細心，和需求、開發、測試等各個環節的同事們密切配合，把公司各個業務的項目都理出頭緒來、讓研發部為公司業務的不斷成長做出貢獻，也讓技術人員工作“累身不累心”，不要總是“救火”，要能看到辛苦工作的成效。

 

網站和產品開發沒有什么不同！

按我整理的時間表和項目計劃，對照微軟的流程，你會發現，我完全是按照微軟“傳統軟件”的研發流程去管理這個網站項目，略有不同的地方是，這個網站項目的時間跨度比較小（只有4個月），而且人力資源有限，美工、開發、測試三個環節我只能是并行處理、流水作業，以盡量縮短項目的整體時間。

 

	規劃和需求階段	開發階段	測試階段	發布階段
主參與人	Planner與PM驅動	開發人員推動	測試人員推動	PM，產品經理，運營管理等執行
階段成果	目標描述 (Vision) 詳細需求文檔 (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)

 

我也算是“把微軟先進的軟件研發理念和中國中小企業的具體情況相結合”吧，其中最難的是把項目研發流程的理念灌輸給全組同事以統一認識，并能有效的執行下去。很多時候要靠我不斷的去PUSH各個環節，做的比較累，但在完成之后，很有成就感，尤其是針對一個團隊不斷發展和成熟，所做的努力是顯而易見的。

 《程序員》：劉振飛，你好。對于任何一個項目來說，項目經理所面臨的責任都是最大的。這尤其表現在整個項目是否有明確的目標。請你談談你當時對http://133.newsky.cn這個項目的看法，而當時明確的項目目標是怎樣一步步制定出來的？

劉振飛：明確的目標是整個項目組齊心協力努力的“指南針”。作為項目組長，首先要把Stakeholder們對項目的要求吃透、并從技術上把握可行；然后要讓整個團隊理解這個目標：做什么、為什么、怎么做、如何分工、何時做出來、分階段到達什么狀態。

我是分三步確定目標的。首先是了解舊網站的情況。經過和原來負責舊網站研發的蔡志宏以及開發和美工人員深入溝通后，我發現舊網站是個“爛泥灘”，所以把實際情況解釋給管理層，說服他們另起爐灶，推倒重做一個全新的網站。

第二步是吸取舊網站的教訓，確定新網站的總體構想、設計原則、新版“圖紙”。我、蔡志宏、朱偉波還有當時的美工形成一個“核心小組”，反復開會討論，結合公司現有的業務及人力資源情況，逐步明確圖片、鈴聲、文字這三類主要的WAP內容如何在網站上有效展示。

第三步是把“核心小組”的整體思路報告給管理層和項目組成員，聽取大家的反饋意見，逐步明確這個網站的目標和設計方案。我分別在3月9日、17日、21日召集會議，給眾人介紹我們第二步的討論成果，請大家站在不同的角度去審核，不斷吸取合理化建議并最終達成一致意見。最后明確這個項目的目標如下圖所示：

示意圖：整體規劃統一整個項目組的前進方向 

其實我還跟項目組內部講過另外兩個“非正式”但更長遠的目標：

（1）把整個項目流程管理好，給公司樹立一個“樣板工程”：項目應該這么做；

（2）通過這個項目打造有良好素養的團隊，逐步培養大家正規的項目研發意識。

示意圖：用了1個月的時間來進行規劃，確定目標、統一思想 

《程序員》：定義需求的時候統一的指導思想是什么？在項目進行中，需求的變更是怎樣管理的？你是否曾經面對來自上層的壓力，怎樣面對？需求工程師是否能理解，并按照預期的規劃工作？

蔡志宏：我們一開始就意識到網站的核心功能并不是諸如導航條擺在左邊還是右邊的問題，而是要讓公司產品能夠得到最好的展示，為此確定我們要做展示的幾個核心部分。我們犧牲掉部分美觀來換取一種整齊劃一的思路。這就像大型超市一樣，也許每一個貨物區都有自己的的貨架擺放形式會更好，但是同一個形式也有它自己的優勢。

對于SP的網站來說，關鍵是你有一張好圖吸引用戶，不是花哨的頁面來蠱惑他，蠱惑用戶將付出超出產品制作本身的很大的精力，這是實戰經驗。花哨的頁面布局形式能夠在最初上線的時候讓所有人滿意，但是在運作的過程中會發生很多的問題，因為為了花哨，長期下來是要付出技術、美工等很多精力的。

核心的展示模塊確定之后，我們也面臨了這個圖標放到右邊好看，那個文字放到左邊好看等一些需求變更建議，有些建議來自于高層，但是這都沒有影響到需求的最終定義。當然，一些細節上的建議仍然被采納，這個隊伍雖然是“武斷”的，但還是個開放的隊伍。

盡管在初期的規劃非常完善，然而限于時間要求，有些想法在該目前的項目中仍然沒能實現。 

示意圖：把網站各頁面分成模塊，分塊定義，形成需求Spec文檔 

朱偉波：以前在別的公司做項目時就是因為需求不斷變更問題，遇到過很大的麻煩，所以這個項目一開始時我就再三強調需求的重要性。目前公司的開發模式還比較簡單。領導一句話做什么就做什么，什么需求以及文檔都是開發人員根據自己的理解來做，往往在開發中途可能由于各種原因領導的要求產生了變化。這樣導致需求不斷變更，直接影響了開發的進度。了解了這個情況后我就直接找過振飛，認真地談過這個問題，并一再強調要重視它。很高興振飛在這方面很支持我的看法，讓大家都知道不可以隨便改需求。

當然在開發過程中由于公司的業務要求，產品經理（蔡志宏）有過幾次需求的變更。我的態度還是比較強硬，大的需求一定不能隨便動（因為項目時間很緊，開發人員遲遲未能到位，需求要是不斷變更，對開發人員是致命打擊）。經常和蔡志宏溝通，盡量保持一致意見。我記得快做完后臺管理時出現了一個致命的漏洞，極大的壓力也造成了情緒上的不穩定，還好在總體設計時我就就注意到了擴展的靈活性，所以在大家的精心協助下很順利的達成一致的意見，并最終在規定的時間里完成了項目的開發。 

劉振飛：完整準確的需求定義決定著整個項目的成敗。需求對項目組的作用就像劇本對電影劇組的重要性一樣。同樣的，項目一旦進入開發實現階段時，只能做局部的小改動、最好是不要動。為什么這個項目規劃要花掉整體1/4的時間？我就是要在一開始的時候，讓大家集思廣益，把各種情況都擺出來、理清楚，把以后可能的潛在變化都消滅在這個階段。同時我一再給公司領導、蔡志宏（詳細需求定義者）灌輸這樣的理念：需求必須明確、大家討論清楚，然后就不能輕易改動了，所以多花些時間在前期規劃、書寫Spec及討論上是非常劃算的。看起來“浪費”了不少時間在文檔書寫和討論上，但卻節省了未來大量的維護時間。

       五一節后按計劃開始網站前臺展示的開發工作，我突然收到部門領導的Email，問能否停止這個第1步聯通網站項目，轉向原計劃第2步那個移動網站的研發。我立即給領導解釋：項目到這個階段就像登山到了半山腰，所有人都憋著一口氣瞄準山頂，這個時候突然告訴大家“咱們爬錯了，趕緊換旁邊那座山”吧，隊員們會是什么感覺？所謂“一鼓作氣，再而竭，三而衰”。當時那個項目還不具備啟動的條件；況且我也需要通過這個項目來磨合隊伍。還好我說服了他，這件事沒有影響到項目組。

作為項目經理，一定要從善意的角度去理解領導的“多變”和需求的變化。但作為一線指揮官，要在項目前期做規劃和需求定義時集思廣益，盡可能避免可以預測的變化。當變化來臨時，要把真實的狀況摸清楚——一些變化是必須接受的，一些是討論后可以變通接受的，還有一些是要想法拒絕的：你需要拿出負責任的決策，不能盲目服從。 

《程序員》：在項目規劃過程中，你是怎樣預測進度的？最關鍵的開發環節是如何保證進度的？采用了哪些方法來保證進度能及時有效、保質保量地執行？

朱偉波：作為開發組長，首先在項目規劃中就要根據需求明確可能用到的技術，并初步估算時間。但最重要的是需要充分的考慮環境因素，如領導的支持程度、人員的到位時間、以及需求的精確程度、甚至公司做項目的風格（取決于領導的風格）等。項目是不是會經常的變動、能否得到大家的支持，都是我要事前需要考慮的，有了這些信息，就可以大致估算項目的開發實際需要多長時間了。

為保證質量，我們事先需要認真的做總體概要設計，這樣對以后的開發起到了一個很好的指導作用。采用一個好的架構對項目成功的重要性不言而喻，對以后的擴展性、維護都起到很好的作用。在這個項目里我和振飛都重視這一點，振飛特意多給我一天的時間來做該項目的設計工作。

再一個就是上面提到的，定義需求時一定要考慮周全、把握好，不能說變就變。 

劉振飛：在3月21日完成規劃時老板問我：網站何時可以做出來？我說必須等到詳細需求明確以后才能知道。隨后的半個多月，我和幾個同事共同把需求文檔整理出來，直到4月12日的集體會議上，才非常明確地寫下各個階段的進度。并將項目最后的日期定為6月15日。這其中產生了幾十份Spec。

       當項目進度明確后，后面就是監督落實的事情了：需求不清楚時，立即請蔡志宏給出解釋；頁面制作落伍時，緊盯美工人員；開發完一塊功能，就啟動測試工作。尤其在接近尾聲的時候，一旦發現延遲的就立即找出原因，如果在Feature和時間發生沖突時，我就需要及時給開發人員做出抉擇：Cut Feature還是延遲時間？

示意圖：項目經理要每天關注各個環節推進的速度是否和預期的一樣 

《程序員》：當時你對公司申請了哪些人力資源？在人員方面的預計是怎樣計算的？打算怎樣利用這些資源？招聘過程中的標準分別是什么？

劉振飛：根據舊網站的實踐、公司現有人力資源的情況，然后我們“核心小組”依照以前各自的經驗，確定這個網站研發需要的人力資源：

Ø         前臺需求定義：1人（蔡志宏）

Ø         后臺需求定義：2人（劉振飛、朱偉波）

Ø         美工設計制作：1人

Ø         開發組：3人（組長朱偉波）

Ø         測試組：5人（組長張春艷）

其中開發組有2人是新招聘，考慮到這個項目及未來的工作要求，對開發工程師的要求是：有較豐富的Java開發經驗，為人踏實肯干、能吃苦。我很高興把偉波招聘進來，他的Java功力很深厚，顧全大局，工作認真負責，團隊意識很強。

       測試組不僅僅為這個網站服務，而是為整個北京分公司的業務測試負責。我對測試人員的要求是：喜歡測試工作，有測試經驗，學習能力強（因為SP是個新興行業）。我也很高興招聘到春艷這樣有好幾年經驗的同事，她對測試流程、規范、測試文檔都非常熟悉，幫我扛住了“測試”這一重要環節。

       志宏比我早加盟公司，對業務非常熟悉，有很豐富的互聯網從業經驗。在項目規劃和需求定義的時候，他經常會冒出很多新鮮的創意和點子。項目結束的時候我跟他開玩笑：忙乎了四個月，其實就是我帶著一幫人把他的想法落實了。 

《程序員》：團隊其他同事最初是否對你制定的目標非常認同？大家認為這個項目與之前所做的項目區別將會是在哪里？你是怎樣維系團隊氛圍的？

蔡志宏：我們是抱有革新態度在做這個項目的，它從思想上不同于一般的網站。開發之前，振飛和公司上層有很好的溝通，使這個項目從上到下有了很好的共識，所以大目標明確，也能得到了公司的全方位支持。大家對做這個項目為公司帶來的收益和重要性有了理解，加上對公司的歸屬感，大家就都比較敬業。 

朱偉波：這個項目是我來公司不久做的第一個項目，不知道大家以前是怎樣看待項目開發的。我曾聽到了很多不同的質疑：這是內部的項目為什么要這么趕呢？為什么一定要在規定的時間里完成？這個項目并不能直接為公司帶來很多效益為什著急去完成呢等等。也許在原來做項目的思想下，大家心里有很多為什么，對這個項目還抱著一種試探，并沒有重視它。

但欣慰的是，領導對這個項目還是很重視的。我剛來公司，沒有歷史包袱，還是按我原來做項目的成功經驗按部就班。事后證明我的判斷是對的——這個項目和我原來做過的項目，其區別就是打破一家公司做項目的風格。“打破”就帶來壓力！試想，如果這個項目失敗了，說明該公司原來做項目的混亂風格未嘗不可，而我們的努力也就付之一炬了。

由于每個人的做事風格不一樣，也會有這樣那樣的問題。但是在振飛的揉和下大家還是能很好的融入到這個項目團隊中，最終解決問題，完成任務。 

張春艷：剛來公司時，分配給我的任務就是測試舊版133新天地網站、熟悉聯通WAP業務。在測試舊版網站過程中，發現問題不少如下：

1、內容不夠豐富，不吸引用戶；

2、頁面的展現力不強，感覺比較枯燥；

3、程序不夠穩定，常出現HTTP Error 500、404錯誤；

4、有些很重要的功能都沒有實現（如搜索功能）；

5、N久也不會更新一次內容（大概是因為更新一次很麻煩吧！）；

6、沒有需求、沒有目標，測試屬于沒有目的狀態，需要憑借經驗和感覺進行盲目測試。

對于測試這樣的網站，我認為沒有太大意義，早應該進行改版或推翻重做。所以對振飛制定的項目目標十分認同，并希望協助很好完成。我理解這個項目與公司其他項目區別：

1、一個不賺錢但為公司所有賺錢項目服務的一個項目；

2、是公司當時唯一有規劃的項目，讓每個人都心中有數，到了哪個時間段該做什么事。其他項目基本處于混亂的狀態，只有提交到測試這邊才知道有這么回事；

3、測試方法不同與其他項目：a、時間計劃安排上的不同：有頭有尾，且留給測試的時間足夠充裕，對測試的質量給了一個很好的前提。其他項目經常處于救火狀態，下午提交測試，下班前就要求完成，沒有思考和準備的時間；b、測試方案和方法上，在可重用的流程上首先啟動了Test Case的概念并加以執行；c、需求文檔的準備給測試做了很好的鋪墊。 

劉振飛：項目的目標不是我一個人拍腦殼想出來的，而是結合領導的要求、公司的實際情況逐步從小范圍到大范圍反復討論后確立的，項目組的每個人在規劃階段結束的時候，都非常明確兩個問題的答案：這個網站做成什么樣、為什么。

大家對整體規劃認識一致后，后面需求、美工、開發、測試、運營等各個環節的工作就可以“統一思想”，因為有了明確的共同奮斗目標。作為項目經理，我做的就是定期把各個環節的進展告訴整個項目組，做到信息透明。一個目標明確、互相信任、尊重、團結的隊伍，再把項目組的信息公開出來，就能夠保持良好的團隊氣氛 。 

《程序員》：從需求、測試和開發各方面看，是否支持你的目標？大家對這個項目有信心么？信心源自何處？你是怎樣鼓勵團隊中其他同事的？

蔡志宏：這個項目中有許多值得討論的事情。首先在各個環節上都有很突出的創新，難得的就是這一點，一是因為各個環節的負責人均是老手，有創新的實力；二是一些氣氛方面的因素，振飛的專業精神感染了我們，振飛有時候比較容易著急，但是他有一個核心的優點就是簡單，我們基本上不用過多去考慮和他溝通的方式，只要把信息傳達到了即可，這樣的一個項目經理可以節約很多的時間成本和腦細胞。

現在的一般的公司里面有許多不適合創新性思維的項目經理，對上不會溝通，對下也不會激發，天天板著個臉，這樣很難做出什么有創新的項目，我覺得程序員寫的是程序，但是程序員并不是一個程序。 

朱偉波：在同一個目標下，我就只有一個想法是要按時按質的完成項目。很多老員工對公司原來開發的模式感覺不是很好，都希望能換一種模式。在這種心理下都希望能很好的完成項目，來證明自己；同時也可以在規范法下學到很多新的做法，所以大家的熱情都比較高，希望通過正規的開發流程學到很多以前學不到的規范，這對參于項目的人員來說是一個很好的經歷。

當遇到困難時，我們都能坐下來很好的商量、討論。再有就是領導的大力支持，讓我們對這個項目看到了很大的希望，讓大家都能把熱情投入到項目里。 

張春艷：從完成這個項目的測試來說，信心源自明確的目標、合理的計劃及各部分之間的配合。對測試組來說，蔡志宏需求的配合和朱偉波開發部的配合都不錯。測試組提出的疑問及Bug會及時得到開發組的回復，或是解決或是經振飛確認可以延期解決或可以不解。不會出現有一個問題沒人搭理的情況。 

劉振飛：經過2004年第一個網站的實踐，我非常有信心，可以把在微軟Office組學到的產品研發流程和項目管理方法移植到網站項目中。每個環節的同事在每個階段應該做什么事情，要讓每個人都非常清楚；項目組的任何信息都是公開透明的。同時作為項目經理，不要有任何“官架子”，大家在人格上都是平等的；出了意外情況的時候我要第一個及時做出反應，給出經過認真討論、協商后的可接受的解決方案。

某個環節、某個人做的好，要在整個項目組及時提出表揚，特別出色的要爭取申請公司的獎勵；某個環節、某個人做的不好，私下里要及時批評，找出原因和解決辦法，避免重復同樣的錯誤。當然，關鍵時候某個環節比較勞累的時候，要請相關的同事撮頓飯、緩口氣，搞研發的人既是理性的，又是感性的，大家都需要得到認可。 

《程序員》： 我們看到你的項目管理依賴大量的文檔。目前這種文檔化的方法似乎在開發人員中不受理解和歡迎，而且在理論界也受到了不少批評，大家怎么看待這個問題？以團隊成員的親身體驗來說，文檔的作用是什么？如何恰當地使用文檔？

蔡志宏：這個項目在嚴格的時間控制下完成的，振飛為每一個小的環節設置了一個Deadline，包括一個小圖標的制作，我很佩服他可以這么精確的統計到工作量，做那么多的Excel表格和PPT來管我們。網站上線之后，我吃驚的發現在服務器的CVS目錄里面居然有上百個這樣的文檔，這些文檔中的有許多是用來記錄每次開會的情況和隨之而來的工作分配，事無巨細！我想如果微軟的Office要是這樣做出來的話，那肯定要拿好幾個電腦來裝這些文件。 

朱偉波：文檔是軟件生命周期必不可少的東西。為了讓項目能有一個清晰且強壯的結構，就要做總體設計，具體到運用什么技術，使用該技術對我們日后有什么好處、要承擔那些風險，以及采用什么樣的結構來開發等等，這些都一一記錄下了，為下一步的開發做好準備。

在開發前我們還寫了一份詳細的概要文檔，這份文檔主要記錄了日后開發的細節，比如包路徑、代碼的規范、需要的輔助類、每個包下放什么東西、公用類的簡介、用法等等。這些文檔為日后我們查詢起到了舉足輕重的作用，為后續補充進來的人員起到了很好的引領作用。在開發過程中依據這些詳細的文檔能衡量代碼、判斷思想是否一致、風格是否統一等等。

文檔的作用主要是規范行為和風格，讓大家有一標準，避免在開發過程中走一些不必要的彎路。當然，在制定文檔時需要全面考慮——要可實施。如果事先在寫文檔時不能考慮周全，那么可能直接導致項目失敗。 

張春艷：文檔是主要的工作產品之一，好的文檔可以推進后續的工作順利執行。如：好的測試用例，第一、可以作為執行測試的依據和參考資料之一；第二、如果公司的測試人員流動，新來的測試人員不會無從下手；第三、文檔也是公司的財富之一。 

劉振飛：不要去寫那些走形式、對項目沒有實質意義的文檔，比如變了味的所謂ISO9000或CMM認證的那些文檔、極其復雜混亂的UML文檔：每個人心里都很清楚那種文檔沒有用處，但還不得不寫，勞民傷財，非常可笑。

文檔的作用就是把問題想清楚、記下來，讓別人能夠看懂、能接手進行維護。比如需求Spec的作用是幫助需求定義人把需求細節真正想清楚，對該模塊進行詳細定義：功能描述、邏輯、界面、如何使用，就是站在用戶的角度去細化、去說明。需求Spec首先要自己想明白、并以別人能夠理解的文字記錄下來，作為開發的“合同”。Spec要及時更新，反映最新的狀態。

當然在實踐中，中小企業的項目研發進度都趕的比較急，把文檔細化到什么程度、如何保持更新，都是比較頭痛的事情。

示意圖：項目有幾十份各種格式的文檔，有效的文檔對項目成功極其重要 

《程序員》：除了文檔，還有那些制度是你在這個項目中新建立起來的？如何保證這些制度的被理解和被執行？

 蔡志宏：除了文檔，就是無所不在的Bug Free（http://bugfree.1zsoft.com/）系統了，這讓我想到一句話，“體制化是這樣一種東西，一開始你排斥它，后來你習慣它，直到最后你離不開它。”開始的時候大家都比較討厭那個叫BugFree的那東西，實在是麻煩，感覺一個很小的事情都要發一個Bug，覺得純粹是在浪費時間。后來發現這東西有它不可替代的好處，一個問題從出現開始到最后解決都有它跟蹤，效率反而提高了許多，盡管在后來對哪些問題應該發Bug進行了一些爭論并做了調整，但是BugFree系統在這個項目中起到了很重要的作用。 

朱偉波：在這次開發過程中使用了CVS作為我們的版本控制，我們規定在上傳代碼到CVS時一定需要寫注釋，以便事后能很快的查詢。在開發組內部開了一個會議，我重申了上傳代碼時寫注釋的重要性，并當場上傳了一些不帶注釋的代碼，讓大家來恢復到我所需要的版本——在這種情況下大家很難一下就恢復到自己想要的版本。通過這種方法讓大家意識到自己原先的不規范的地方，統一認識，為保證下一步的研發打下了堅實的基礎。

還有就是寫程序時要符合公司的代碼規范，其實就是在符合Sun公司的規范前提下統一我們代碼的規范性。做到這一點其實是很難的，大家來著不同的環境，以前接觸的人也是不同。這就要求大家都堅持一個共同認可的標準，并嚴格的執行這一標準。我很慶幸的是大家都能很好的堅持我們公司制定的代碼規范，并且在我們公司的代碼檢查中順利的通過了考核。 

張春艷：公司在測試這一環節的起步較晚，基本上是在今年的3月份才組建起了一只測試團隊，還有很多人認為測試是一個可有可無的過場。還好有領導的支持與認可，我們測試組努力把工作做得漂亮，證明自己存在的價值。用我們的實戰來告訴大家，測試不是隨隨便便就能完成的，而是一件有始有終、有流程、有規范、非常嚴謹的一項保證產品質量的工作。

在133網站的測試中，我們就是這樣證明了測試組存在的意義：

1、根據振飛制定的規劃，我們按時完成了測試進度，沒有拖延錄入及上線時間。

2、首次采用Test Case的方法完成下載流程的測試，并且取得了很好的效果。此次的Test Case還可以移植到以后網站的日常監控測試中。

3、測試效果體現。（1）保證后期錄入人員在錄入時不出基本錯誤；（2）利用邊界值的測試方法，提前測試出錄入后前臺展示可能不美觀的情況，便于在錄入前給出提示或硬性規定（如輸入的專題名的長度等），來保證前臺的展示效果和錄入的效率；（3）為了使大數據量的用戶訪問情況下不出問題，我對首頁進行了100人同時訪問的壓力測試。

4、在6月15日上線前，做最后的回歸測試，保證上線產品的質量。通過此輪的測試，至今還沒有得到公司內部或外部對網站出錯問題的反饋。 

劉振飛：除了要求需求、開發、測試文檔外，我逐步建立了如下制度：

★ 嚴格的進度控制，每個環節都要遵守自己同意的進度

★ 用CVS來管理文檔和代碼

★ Java編碼要有規范

★ 每一個功能模塊都必須經過測試

★ 項目進展情況定期通報給全組同事

★ 有延遲的時候要立即提出來，及時找到補救辦法

★ 項目完了要及時總結，驗尸報告不是走過場

       當然我不可能在短短四個月中通過這一個項目把這些制度都打造的很完美。關鍵是通過這個項目給大家灌輸這些意識，通過以后的工作實踐不斷強化，真正形成好習慣。這些制度其實都是研發中的基本素質、本來就該這么做，所以面對這么多人、這么多事，我一個人有時難免有疲累、孤獨的感覺，很多時候只能抓住大的方面，一些細節只能忽略了，是很無奈的事情。 

《程序員》：盡管133項目的完成已經非常不錯了，但在你的項目中仍然會再次提到“驗尸報告”這個詞，你認為項目還有哪些不足之處。

蔡志宏：我是第一次參與“驗尸報告”，感覺很新鮮。的確在最后結束的時候，大家和振飛面對面的單獨總結了各個環節的工作，對整個項目的運作有了更宏觀的視野，大家都站在一個更加高的角度來看待我們完成的工作。 

朱偉波：我覺得一個人的成長是在一件事即將結束的時候。在做項目時我沒時間過多的考慮去用什么新技術、用什么新概念、會有什么不足等等。這些都是在項目結束階段時我們總結所得，回顧項目過程時能發現有那些不足，這樣就有時間來考慮在下一個項目里用什么東西來彌補不足的地方。

我們開發組和振飛一起總結出來項目的不足有：（1）美工的工作進度緩慢，在很大的時間里直接影響到開發的進度。（2）我們不應該讓美工的開發和代碼的開發并行的來完成，使得很多的代碼重復。（3）代碼的開發和測試的同步也是一個不可取的做法，在測試組前期測出的大量Bug，可是當研發繼續往下走后這些Bug就不存在了。（4）還有一點就是當我們完成這個項目研發后，網站營運人員遲遲不能到位，內容跟不上。這是我們事先沒有考慮到的。 

張春艷：任何一個項目都不會十全十美，就像一個再好的軟件也不會沒有Bug一樣。不是只有做得不好的項目才需要“驗尸報告”。我覺得“驗尸報告”是這個項目中很好的一個環節。不僅可以把好的東西繼承下來，還把不足的地方提出來，給以后的項目作為經驗。 

劉振飛：Everything that has a beginning has an end. 項目總結最重要作用的就是“承前啟后，繼往開來”，表揚與自我表揚相結合、批評與自我批評相結合，不能走過場。不僅要在以后的工作發揚光大成功的地方，更要解決這個項目中曾經存在的問題，真正做到“吃一塹長一智”。

示意圖：133網站項目的“驗尸報告” 

       通過我這一年多的實踐，痛感研發管理不僅僅是某個項目內部管理的事情，它涉及到整個公司的發展戰略、領導層素質、員工能力、薪酬體系乃至企業文化的建設，僅僅從項目管理的層面去解決問題的成效將是非常有限的，這是一個系統工程，靠一人之力來完善是不現實的。