周二參加了中心的部門經理會，在會上瞭解和Review了項目R下周一上線投產的準備情況，除了項目組的開發、修複Bug的計劃和人員安排外，我們主要在風險、服務層面對項目組R和部門經理T提出一些需要考慮的問題。
項目R除了我們開發服務方，還有業務監理方、業主方以及終端使用者，根據合約的安排，項目的培訓、部署和實施服務由監理方負責，我方定位在開發服務，所以各個方面的工作需要安排協調妥當。
具體的風險、服務層面的需要進一步細化安排的如下：
- 技術功能層面，資料許可權漏洞以及資料授權的傳遞要求，是在本周最後的業主方測試才發現出來的問題，在此階段發現問題是風險很高的要素。要求部門經理和項目組R馬上和業主使用者達成共識，安全問題具有一票否決權，資料許可權的問題是系統部署上線的終止條件。一個系統不怕有功能上的Bug，但是怕的是業主和終端使用者對系統喪失信心，看到自己不應該看到的資料，只會讓終端使用者擔心自己管轄的資料是不是也讓其他人窺視。另一方面，如何加大項目組的自我裝載，保證在上線前對許可權的檢查到位，避免再次發生類似狀況。
- 資料品質層面，系統涉及舊系統的資料移轉，系統遷移的工作由監理方來完成，但是資料品質的檢驗和校正工作方面，監理方會負責對資料移轉資料的總數校正，但是沒有對資料單項和屬性要素的準確性驗證，我們應該提出這個方面的風險並且達成共識，雖然遷移資料已經做過了幾次演習，但是資料校正和檢驗工作不能停留在抽查的層面。如果需要，可以參考我們公司的另一個項目的具體做法，涉及金額和數量的生產系統，就應該這樣謹慎。
- 服務流程層面，因此項目組R和監理方達成共識，我們的項目組只從內部維護系統接受監理方的服務單。對應這一方面，我們覺得有兩點需要考慮和達成共識，第一，根據以往經驗，業主的終端使用者會通過電話/QQ/內部維護系統提出服務需求，只落實了一個渠道，還欠缺其他兩個渠道；第二，我們服務完畢後，是否由我們直接進行業主終端使用者的反饋。
- 服務記錄層面，詢問服務記錄的情況，項目組R和部門經理的回答是，通過內部維護系統的服務單，已經在IT系統內部體現，通過電話/QQ發起的服務記錄，則由監理方負責記錄。我們在這個方面，要求項目組R必須進行服務記錄，好比將錢存在銀行，銀行有一本賬，你也會有一本賬，不是信任不信任監理方的問題，是必須這樣做。
- 我們做好服務記錄的必要性，能夠在上線後有效地分析負責服務工作同事的工作量負荷，也能在上線後分析出我們產品、系統的穩定程度，同時如果需要我們進行反饋終端使用者，這個記錄也是重要的基礎，而且更能夠在以後配合管理中心的客戶滿意度調查的要求提供終端使用者列表，甚至也能夠在以後進行監理方和我方服務品質的差異性分析。
- 服務人員組織安排層面，上線最壞的情況不是上不了線，開發與修複Bug項目組R不欠缺這方面的能力，最壞的情況是上線後發現系統不穩定，有故障，類似“死機”。哪些同事負責Bug定位和修複，哪些同事負責協調，哪些同事負責對IT系統進行健康監控，上線的關鍵前幾天，時間安排如何，在業主現場還是在公司進行服務等等這些組織安排工作要求部門經理和項目組R必須落實。
- 心態上，雖然系統的培訓、部署和服務由監理方負責，但是我們要和監理方互相補位，系統雖由監理方進行安裝和部署，但是假如出現故障或者系統問題，一定還是我們雙方要去解決的，去努力做到雙贏的局面，避免雙方雙輸。
- 小插曲，為了檢驗項目組R是否做好服務準備，通過詢問，瞭解到由項目群組成員C負責跟進監理方的安排部署，我在會後抽查了項目群組成員C，問的問題如下：“假如現在系統出現故障，我需要找到系統的訪問日誌和錯誤記錄檔，請你從伺服器上給我在5分鐘內找出這些日誌！”。答案是，C無法做到，告訴我監理方安裝程式安裝在那裡還不知道！我們將情況反饋部門經理，要求他進行整改。
看來，系統實施層面不是解決說的問題，還要下好功夫解決做的問題，說到了無法做到，一切都歸零。QA只能做好一個抽檢的工作，隊伍在服務意識上、心態上，離職業的道路還有不少要走的，而且管理中心還需要在實施中加大管理、抽檢的力度，將防範能力進一步擴大。
最近從不少接觸的同事瞭解到，業主的其他服務提供者，其實在服務意識上以及服務品質上都有比我們高的地方，我後面會讓同事寫下來他們的故事，向我們的夥伴學習，向我們的業主客戶學習，向我們的競爭者學習，只有打心裡從心態上擺正位置，這樣的團隊才有可能成為業主、夥伴和對手都尊敬、佩服的團隊。
