服務級別協議

服務級別協議是指提供服務的企業與客戶之間就服務的品質、水準、性能等方面所達成的雙方共同認可的協議或契約。

典型的服務級別協議包括下列內容：

參與各方對所提供服務及協議有效期限的規定；服務提供期間的時間規定，包括測試、維護和升級；對用戶數量、地點以及/或提供的相應硬體的服務的規定；對故障報告流程的說明，包括故障升級到更高水平支持的條件。應包括對故障報告期望的應答時間的規定；對變更請求流程的說明。可能包括完成例行的變更請求的期望時間；對服務級別目標的規定；與服務相關的收費規定；用戶責任的規定(用戶培訓、確保正確的桌面配置、沒有不必要的軟體、沒有妨礙變更管理流程等)；對解決與服務相關的不同意見的流程說明。

服務級別協議體系：服務級別管理的“導航圖”

為了明確業務部門和IT服務部門各自的責任，服務級別管理人員需要針對雙方已達成共識的服務級別需求，簽訂服務級別協議。同時，為保證完全履行服務級別協議，IT服務部門還需要分別與內、外部供應商簽完運作級別協議（Operation Level Agreement）和支持合同（Underpinning Contract）。這三份協議構成了支持服務級別管理流程運作的服務級別協議體系，是明確各方主體權利和責任的書面依據。因而也構成了服務級別管理流程順利運作的“導航圖”。

服務級別協議，是IT服務部門與客戶就服務提供與支持過程中，關鍵服務目標及雙方的責任等問題協商一致后所達成的協議。服務級別協議應當使用業務部門和 IT服務部門都理解的語言，而不宜採用技術化的語言。這樣可以便於業務部門和IT服務部門之間的交流溝通，減少雙方之間的摩擦，同時也有利於後期的評審與修改。

運作級別協議，是指IT服務部門和組織內部某個具體的IT職能部門或崗位，就某個具體的IT服務項目（如郵件系統的可用性、傳真服務的可用性等）的服務提供和支持所達成的協議。IT服務部門作為一個整體與業務部門簽訂服務級別協議后，為了保證能夠達到約定的服務級別目標，需要將客戶的業務需求轉化成具體的服務項目，並針對這些服務項目和相應的內部IT職能部門或崗位簽訂運作級別協議。

支持合同，則是指 IT服務部門與外部供應商，就某一特定服務項目的提供與支持所簽訂的協議。如IT服務部門為了達到服務級別協議中所確定的有關通信系統的可用性級別目標，往往需要租用外部供應商的通信線路和設備等。此時，為了保證通信服務的穩定性和可靠性，IT服務部門需要與外部供應商簽訂相應的支持合同。

需要說明的是，服務級別協議和運作級別協議通常只是IT服務部門內部以及業務部門之間明確各自責任和服務目標的一個書面說明，而不屬於正式的法律合同，而支持合同則通常是IT服務部門與外部供應商之間簽訂的具有法律約束力的正式合同。

在建立服務目錄后，必須設計最合理的服務級別協議構架，以確保覆蓋所有的服務和所有的IT系統的用戶。構建SLA的方法有三種主要方法：

制定的每一個服務級別協議針對一個服務，除非不同的用戶對同一個服務有各不相同的特殊要求。在這種情況下，同一個服務級別協議下需要設立不同的指標體系。簽署服務級別協議的時候，需要考慮到用戶範圍，讓不同的用戶範圍代表簽署。或者可以採取分開簽署不同的協議來加以避免一些不必要的麻煩。

確保一個服務級別協議只針對內部一個單獨的用戶群后，那麼這個協議將包括用戶使用的所有服務，能夠包含所有的服務和所有的用戶。

從用戶的角度來說，他們可能會傾向這種協議，其所有的需求都被包含在同一份文件里。一般只要一次簽字就可以了，這種比較簡單，但是對服務級別管理項目推動小組來說，可能工作量會有所增加。

在服務級別協議初步穩定實施一段時間后，可以根據需要選擇採用多層次SLA結構。比如類似以下三層結構：

1.公司層面：包含適合所有用戶的大類服務級別管理問題。適用於比較穩定的服務，系統不會頻繁更迭和升級。

2.用戶層面：包含所有與個別用戶群體有關的服務級別管理問題，不管這個用戶組使用什麼樣的服務。

3.服務層面：針對中國移動通信內部某個特殊用戶群體，以及與這個用戶群體相關的某個特殊服務。

服務級別協議定義了開發人員和客戶之間正式理解和溝通的基礎。Simon Jackson探討了為什麼你的項目需要一個服務級別協議。

服務級別協議（Service Level Agreement，SLA）

用來管理服務的表現。儘管它可能還不能成為你的開發項目的一個常見部分，但是SLA可以用來提高開發過程的質量，減少項目失敗的風險，加強與客戶之間的關係。SLA體現的是專業性——發表和依賴可接受的標準表明公司了解其業務和客戶。本文將探討軟體開發里的服務級別協議：為什麼你需要用它，以及創建這樣一個協議的訣竅。

什麼是服務級別協議

SLA Information Zone的Web網站將SLA描述為“定義兩者之間關係的文檔”。SLA為開發過程的要素設定了基準，這被認為對於保持開發小組和客戶之間的關係十分重要。

儘管不是一個正式的合同，但是SLA能夠被用作是正式交易的一部分。合同與SLA之間的不同之處在於文本的目的和嚴謹性。合同是為了將關係正式化，並具備法律效力；而SLA用來改善關係，並不具有法律效力。但是，如果無法實現SLA的條款，那麼你將傷害或者破壞這種關係，這與不履行合同的後果一樣。

為什麼要實施服務級別協議？

軟體開發在交付方面的名聲並不好。Standish集團公司2003年的CHAOS報告顯示，在要求和預算進行開發碰到困難時，超過一半的IT項目都會遭到“質疑”。

項目失敗的原因各式各樣，但是各種研究都表明標準對於項目的成功至關重要，例如用戶的參與和清晰明了的要求就是這樣的標準。SLA是將這些原理從書本里拿出來放到實際項目里進行實踐的工具。

同樣重要的還有加強與客戶之間的關係。編寫SLA要求對專業軟體開發的理解和對客戶的真正責任。你清楚自己的要求，並堅持這一點，給客戶以理由相信你的能力和知識。

為什麼應該囊括服務級別協議？

項目成功的主要因素包括：選擇項目、客戶的參與、正式的項目管理和要求管理。

根據項目的大小、計劃安排和風險，你還希望考慮軟體開發的最佳做法，比如質量保證和單元測試。

加入客戶認為重要的內容也很重要。你可能並不總是同意，但是如果必須的話，提問、傾聽和協商是很重要的。

要記住，SLA定義的是關係；它以協議和理解為基礎。通過獲取用戶的投入，你是在加強關係，改進整個過程。

選擇項目方法

一開始，選擇一個適合項目的項目方法似乎是不可理喻的。從本能上講，我們在尋找一個真正的途徑，也就是有效地實現項目成功的完美方法。聽夠了任何佈道者的花言巧語，你也會開始相信。嘮嘮叨叨的挑剔之語總是存在，但是——如果他們的過程這麼好，那麼那麼多其他的過程是怎麼來的呢？

忽略偽宗教者的言論而把注意力放在客戶和項目上很重要。每個客戶和每個項目都不相同——沒有哪個方法是萬能葯。

替代的方法有很多，所以你應該選擇一種適應你具體要求的方法。敏捷軟體開發方法的先鋒Scott Ambler 在他的文章《One Size Fits None》里指出，“做到這一點要求對項目的了解，以及對各種方法的優勢和劣勢的了解”。

SLA必須申明所選擇的項目方法以及相關的特性和性能標準。客戶可能不是非常關心選擇的是哪種方法，但是他們會關心它會如何影響項目。

客戶的參與

“早發布，常發布”這個格言常常是吹噓得多但實際做到的少。這裡面所隱藏的意思是客戶在項目實施過程中不應該聽到任何不利的意外：比如“我們超過了預算50%”或者是“至少還需要多花兩個星期”這樣的話。

讓客戶參與進來的策略包括會議、共享的工作空間和正式的問題管理。

會議

定期的會議，最好是每周一次，但這常常不受開發人員的重視，雖然它們可能會成為項目的支柱和救星。如果運用合理的話，它們會幫助解決問題，加強關係，加深小組對客戶要求的了解。但是如果運用不當，它們就會浪費時間並打擊信心。

SLA必須確定會議的頻率及內容才能夠讓會議產生效果。這些內容包括有一個固定的議程，指定一個主席、計時員、書記員，告知行動項目和分發會議記錄。

對於如何組織好會議，去拜訪一下你所在地的（專業）主持人。這些會議都有固定的規則；例如它們都要按時開始和結束，發言人的發言要按時間表來。這樣做的結果就是，它們不會退化變成喋喋不休的個人獨白。

共享的工作空間

項目會帶來很多信息——文檔、討論、問題記錄、聯繫信息表和事件。集中和共享是協調項目和保持用戶參與的關鍵因素。

要變得真正有效果，整個項目小組就必須能夠從可能的渠道獲得資源——從辦公室、家裡或者是現場。基於Web的企業內部網是一個好的解決方案。

問題管理

這是客戶關係管理中最重要但是實踐最少的地方。在任何項目進行的過程中，都會產生很多疑問、問題和建議。捕捉、保存、優先對待和處理這些事情對於推動一個客戶認定為成功的項目是極其重要的。交付了客戶想要獲得的內容但是仍然失敗的例子還是有的。這也許是因為項目要求發生了改變，或者是因為沒有在文檔里完整地表述出來。聽取客戶的意見，一產生問題就立即著手解決，這樣我們才能夠將成功的機會最大化。電子郵件不是完成這項任務的好工具。我常常會看到客戶關係由於對電子郵件里虛假內容而迅速惡化。應該維持單一的、集中式的問題登記，也許是在企業內部網裡。技術並不是那麼重要，但是所有人都應該能夠看到這些問題的登記信息，並經常監視和審查。

正式的項目管理

一般來說，項目管理要求具有不同的軟體開發技能。儘管如此，高級開發人員經常被要求除了領導開發之外還要管理預算、規劃資源、負責人員招收、管理客戶關係和其他事務。這不僅僅是不合理，這對於客戶關係常常是致命的。

項目管理需要額外的代價，這包括客戶有的時候不願意開會，尤其是如果他們過去的項目管理成績不佳。定義項目管理成果和標準的SLA將在某種程度上有助於減輕他們的憂慮。

要求管理

理解客戶需要什麼是交付價值的重要部分。這很複雜，因為在某些情況下，客戶可能只有對他們想要什麼的一個未成型的想法。在所有的情況下他們都需要依賴開發小組的技術專家來給他們建議。進行要求管理的方法是軟體開發方法的基礎。例如，敏捷軟體開發方法通常都假設客戶對需要什麼沒有一個完整的理解。所謂的瀑布開發方法則是從一個正式和靜態的且定義良好的要求開始。要求管理因此與項目方法的選擇密切相關。

SLA必須推薦要求管理的方法，以及如何處理項目實施過程中要求的變化。這包括一個變化控制過程，從而對整個項目的第二次發布或者重新報價提出了功能上的要求。

軟體“最佳做法”

軟體開發有專門的做法；正確地使用這些做法能夠提高軟體質量和生產效率。這些做法包括每晚構建、功能審查、缺陷計量跟蹤、代碼註釋、編寫文檔、質量保證、變更、同事評估、單元測試和用戶認可度測試。

不是每個SLA都需要用到上述所有的做法；這要由項目、客戶和項目小組的技術、經驗和創造力來決定。不要害怕做事情的新方法——成功就是一個創新的過程。

實踐中的服務級別協議

就像大多數的性能測定一樣，SLA應該是SMART的：具體（Specific）、可測定（Measurable）、可實現（Achievable）、現實的（Realistic）和受時間限制的（Time-bound）。我將使用一個用於功能測評的基準作為說明上述內容的實際例子。基準測試的第一部分相當簡單：“我們將測評軟體的功能。”

上述說法會帶來一些顯而易見的問題：功能測評是什麼，為什麼需要它？由誰來進行測評？如何進行測評？什麼時候來測評？所以它肯定是不符合SMART標準的——因為它從中傳達出來的信息過多。

要改進它，首先要做的就是讓這個說法更加具體，申明要實現什麼，為什麼，以及如何實現。“功能測評用來檢查軟體的完整性，看它是否滿足既定的要求，是否滿足商業需要。這就能夠保證發布的軟體可以滿足客戶的預期。

“在進行第一次測評之前，提供商要以一小點一小點的形式將要求總結出來，接受客戶的檢查，並得到客戶的認可。

“功能測評包括整個項目小組的一次會議——也就是說，包括開發小組和業務小組。在會議中，開發小組將陳述每個要求是如何在軟體里實現的，這要用軟體最新的開發版本來說明。

“客戶負責確定每個功能是否已經被正確地實現。”這就要明確得多。將要求具體化還可以讓開發小組檢查標準是否是可實現的和現實的。

這些測定在很大程度上取決於開發小組的能力——技術、知識、經驗和時間。上面這種說法仍然不能完全滿足SMART的標準：它沒有一個時限，也無法為性能的測定提供一個基礎。還需要更多的細節：

“將進行三次功能測評：第一次是在代碼完成50%的時候，第二次是在完成75%的時候，而最後一次測評是在軟體進入正式測試（formal testing，QA）之後。在要被解決的功能里，90%將被客戶認可為被完成。”

在這種情況下，計劃安排要以構建階段里的里程碑為基礎。更加具體的日期可以通過這些點提供給項目規劃。我們還需要表述出一個清晰的、可測定的標準。如果做不到這一點，就可能在開發過程中，在規範或者溝通過程中出現問題。

現在這就是項目的目標，也是一個早期預警系統。它將再次確保客戶了解它們將被問到是否已經滿足了項目要求，並給予他們你將向他們交付物有所值的軟體的信心。使用它，你就可以表明自己知道軟體開發里的常見問題——不完整或者不連貫的要求——並表明自己有決心解決這一問題。

每天都要應用服務級別協議

你當然會“得到你測定的東西”，但是SLA不僅僅是簡單地用作是一種測定方法。通過設定可實現的和現實的基準，它成為了一個用來改善軟體開發和增強客戶管理的工具。儘管軟體開發的質量在過去十年裡得到了提高，但是要改進的地方還有很多；SLA就是解決問題的一種方法。