網站項目成功管理實踐（上）

網站項目成功管理實踐（上）

文/劉振飛

在開始做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 日淩晨 我正式向全公司同僚報告這個網站正式上線。這是我自己主持研發的第二個網站，也是我非常用心管理的一個項目。我想留下一個參考樣闆，為公司其他項目的管理摸索經驗。我認為這是一個成功的項目是因為：

ü         做出來的網站符合最初的規劃和需求定義；

ü         按照需求定義完成的時候( 4 月12 日 )确定的進度向前推進， 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各個環節，做的比較累，但在完成之後，很有成就感，尤其是針對一個團隊不斷發展和成熟，所做的努力是顯而易見的。（未完待續）