项目管理：构建服务级别协议

项目管理：构建服务级别协议
作者/转载者: 苏苑

服务级别协议定义了开发人员和客户之间正式理解和沟通的基础。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就是解决问题的一种方法。