ZDNet Taiwan - 專案經理在系統上線要做哪些事？ - 企業應用

註冊 | 登入 | RSS Feeds

專案經理在系統上線要做哪些事？

4則回應

andycheng 2008/01/14 05:00:00

對軟體專案而言，系統上線是很重要的里程碑(milestone)，系統上線的英文是”go live”，所以我們可以說上線成功，代表整個專案”活”過來了，反之要是上線出狀況就成了”go died”，還得花費許多人力與時間去補救。雖然系統上線大部分的工作是由技術人員要負責執行，但專案經理負擔專案成敗的責任，不能把上線的事都交給技術人員全權處理。專案經理在系統上線要做哪些事，才能確保系統成功上線呢，以下分成幾個部份討論：

上線前的規劃：

上線程序(步驟)的規劃：專案管理課程告訴我們，事前的計畫很重要，在上線前針對上線程序做好規劃(先和專案成員開會討論)，上線時按照上線程序一步步的執行，以免遺漏了重要步驟。另外也要請專案成員提出上線時應注意的事項(例如production環境要額外做什麼設定)。

上線程序的演練：找一個系統環境(盡量要跟production一樣版本的環境)，把規劃好的上線程序重頭到尾演練一變，當中如果發生問題，記得回去修正上線程序。

萬一production環境和開發環境(例如作業系統、軟體版本)不一致，要事先想好程式上到production環境會有什麼影響，或要額外做哪些設定。如果專案經理的技術知識不足，多找資深工程師討論是必要的。

事先規劃上線時專案成員的工作分配，例如誰要部署程式、誰要做設定、誰要做上線後的功能測試等。如果上線時間很長(例如資料轉檔可能需要好幾天)，建議視狀況在不同時段指派專案成員在現場stand by(有問題再電話on call)，好讓其他人可以回家休息養精蓄銳。

決定上線日期：通常系統的上線時間會選擇非上班時段，建議最好選擇週末假日的白天，不要用晚上的時間，因為人在夜晚長時間工作，精神不際的情況下較容易出錯，萬一真的出了狀況，還得熬夜找問題，況且週末假日的白天時間也比較充裕。過去的經驗中，如果系統上線從晚上九點開始，常常要搞到凌晨三四點，萬一有問題，弄到白天都是有可能的事。

聯絡user配合上線後到現場參與測試：請user在系統上線後即刻做功能測試 (盡量找key user)。通常user都不會願意配合，此時就得看專案經理的溝通能力(或平常的交情)跟user喬好。有user參與測試的好處是，萬一上線時一切正常，但是後來系統出了問題，你可以證明上線後user都已經做過功能測試，有user幫你背書，當然也要事先準備test case給user測試。

上線時

專案經理在上線當時要做的事，就是按照先前的規劃依程序執行，以及分配工作。

萬一上線時遇到狀況切記先暫時一下，大家討論後再決定下一步的動作，切勿貿然下決定。

記得買點零食、飲料、或宵夜，可以提振士氣。

如果程式放在version control系統裡，上線的程式要抓對版本，萬一抓錯就糗大了。

上線後的檢討

專案經理在上線後的第一件事，發一封感謝信給所有參與上線的人員，記得cc給他們的老闆，相信大家都會感激你的，假如下次還有合作機會，也會很願意繼續合作。

上線後通常有一兩週的上線觀察期，屆時專案團隊可能都忙著解bug，或回答user的問題。建議可以找時間開個內部檢討會議，專案成員可以針對上線的狀況，做經驗分享與lessons learned。好的部份下個專案繼續保持，有缺失的部份再求改善。

待系統穩定後，專案經理可找個時間請所有專案相關人員(包括你的主管、專案團隊、user、user主管)吃飯，或是開個celebrate party，一方面是維繫客戶關係，一方面可以凝聚團隊士氣。

X　X　X　X　X　X　X　X　X　X

本[網路部落格]文章僅反映作者個人意見，不代表ZDNET立場，並已獲作者同意以CC授權轉載。原文請見：作者部落格。

--[網路部落格]系列持續招募中，也歡迎您來信加入我們的行列。--

加入網路書籤>

相關新聞

對本則報導有任何意見或看法嗎?歡迎留言

4.泰拳於 2008/02/20 22:27 回應
難得看到這麽精彩的文章，感謝分享！

3.Trouble Sniper 於 2008/01/23 13:56 回應
很教科書化的一篇文章....
1. Production如果與testing不同，這對專案是一個隱性風險，PM在規劃階段就不應該同
意這樣的事情發生。有個案例是因為API不相容造成無法上線，這是專案時程上無謂的
浪費。
2. Production的準備必須要在系統進行部署前就完成，通常在SIT(System Integration
Testing)時就要開始準備，甚至有kick-off就已經先準備好的例子。這樣也可以驗證軟
硬體設備是不是夠穩定，PM不會希望在軟體部署完之後看到硬體故障吧~~~
3. 準備Configuration Table(組態表)，確保所有人都知道正確的環境資料，不然會變成
"一人一把號，各吹各的調"。我碰過專案成員連伺服器IP都搞錯的烏龍事件。
4. 如果成本許可，上線程序應該由具備系統管理經驗的人來制定，不要找系統開發人員，
因為系統管理員對這方面的經驗絕對比系統開發人員多，會寫程式不代表對系統有絕對
的熟悉度，對不起，我不是貶抑程式開發人員，因為我檢討過的專案上線失敗原因，其
中有一半是程式設計師兼任系統管理員，他們無法分神同時對付兩個不同領域的問題。
5. 如果到了上線還在解bug，那UAT(User Acceptance Testi)到哪邊去了??客戶對軟體品
質這麼有信心令我害怕。

另外，在很有IT制度的客戶單位裡，開發商別想碰到production，教育客戶的管理員該如
何進行，會成為上線的重要工作。