放下SLA，敏捷开发是一场无限制格斗

Posted 2021-04-25 敏捷之美

本文约2800字，建议阅读5分钟。

编者案：

SLA是开发团队和客户为项目设定的套路，但是面对满目疮痍的现实道路，开发团队只有放下套路，以客户满意而不是SLA为锚点和目标，才能发挥敏捷的最大威力，跳出太极拳般的流程黑洞和泥沼，逆转不利局面。本文作者是位资深软件工程师，与大家分享了一个他职业生涯中利用敏捷的方法实现戏剧性反转的案例。但我认为最精彩的部分在文后的问答中……

2012年的时候我在美国分公司。B公司（化名）是Ralph Lauren（拉夫尔·劳伦，世界知名时装品牌，以下简称RL）的一个供应商，替RL做一些关键性应用，涉及到从供应商到RL全球商店的货物采购和运输。为了降低成本，他们联系到我们，将技术支持外包给了我们。

我们做好了项目开始所需要的一切准备

开始，我们并不了解所做应用的重要性，直到事情“反转”之后，我们才意识到，这个应用中任何一个微小的错误都可能会导致RL货物装船和运输时间的变化，物流、仓储、运输的相应成本会大不相同。但最初，我们只被当成“技术工具”，B公司给我们的培训就是了解技术细节，了解软件的架构等。

为此我们和B公司的项目成员一起，花了近2个月的时间，制定了完善的SLA(service level agreement)，包括详细的支持、开发、报告、应急等一系列严谨且可行的流程，期望分清楚哪些是业务问题，哪些是技术问题。我们负责解决技术问题，业务问题是RL的BA（Business Analys，业务经理）负责的事。而在整个培训阶段，我们没有跟任何一位BA沟通过。

努力工作却换来一塌糊涂的结果

这个应用是由别的供应商开发的，我们做技术支持，从技术角度，这个项目非常简单，并不难。然而，紧接着到来的实践却不如预期的那样一帆风顺，尽管我们和B公司严格按照约定好的流程来执行，合作不可谓不默契。

在2013年4月这个应用正式发布上线后，我们发现用户提出来的问题远多于我们的想象，于是开始了长达半年多的加班维护。这表面看起来是应用的质量有问题，但实际背后的真正原因是我们只关注技术，用户到底需要什么，我们并不知道。甚至不知道一个PO（PURCHASE ORDER，订单）错误会给RL带来多少损失。

事实上B公司的项目经理更不了解业务，甚至比我们程序员离业务还要远，我们的所有动作都是按SLA来的，从执行合同的角度，我们做的无懈可击。RL再不满意也找不到我们违反合同的地方的，况且我们的服务态度也是超级好的。

然并卵！尽管我们很努力地工作，几乎每天都要加班2小时以上，客户的抱怨仍有增无减，从统计数据来看，平均Ticket（客服反馈问题）解决时间和月Ticket数量也确实都没有减少的趋势。

终于，在8个月后，客户对我们的服务忍无可忍，派出了检查小组分别到B公司和我们公司来检查，目的是重新定义支持工作的团队组织结构，甚至重新选定支持供应商。

经过激烈的撕B大战（此处省略2000字），我们险胜——成为唯一的技术支持团队。我猜，检查结果是B公司作为项目主导的工作是不合格的；我们在这个过程中发挥的作用有限，但至少技术能力还算可以，考虑到该应用很重要，总要有人来维护，所以RL去掉了B公司，直接跟“性价比更高”的我们合作。

当然，这并不意味着客户对我们之前的工作是满意的，但是又有什么办法呢？很多客户在面对软件供应商时不都有相同的困境吗？

角色转变，所有问题都奇迹般地消失了

项目“重新”开始，经过一周几乎完全是浪费时间的业务培训之后，团队又整理心情重装上阵。说是浪费时间，因为又是制定与业务毫不相关的SLA，后来的事实证明，这种培训确实没什么价值。

唯一有意义的是，在此期间，我们仔细地讨论了为什么之前的服务存在问题，讨论结果是我们做的所有的事情理论上都是“对”的，那也就意味着我们其实是永远不承担责任的，所有的问题解决方案、问题产生的原因、技术分析结果都要与客户确认。换句话说，反正我都跟你说清楚了，不能再透明了，你同意了我才这么做的，出事了可不能怪我咯。

到这里，问题似乎出来了，症结就在于我们做的一切都太“正确”了，我敢肯定不是客户想要的服务。于是我们勇敢地提出了要转变角色，我们自己变成了系统的所有者，提供所有相关的服务，对一切负责。

在RL问我需要哪些条件来做好技术支持的时候，我提了一个条件：给我们指定专门的BA可以随时跟我们沟通。之后，大“反转”就开始了！

从我一接手，就扔掉了以前SLA所有的条条框框，按自己的方式，跟BA约定了每天固定时间开会，制作了Hotlist（其实就是Kanban），这样我们总能很快地解决最重要的业务问题。

虽然我跟RL提过敏捷，但明显感觉他们并不感冒。其实客户并不需要知道敏捷是什么？我们也不必向他们解释用敏捷方法会怎样怎样，只要他们知道我们做的好，能解决问题，就够了，他们自然会遵从我们的方式。事实上我们的团队就是应用了敏捷的模式。

这带来的变化就是我们的工作从流程上的透明升级到业务层面上的透明，我的精力从解释技术方案转到了与用户讨论需求和如何解决。由我们来制定发布计划，通知用户什么时间解决哪些问题。

仅仅3个月过后，我们的Ticket数量就变成了原来的三分之一；六个月过后，与我们一起工作的三个客户同事都因为这个重要系统的重获新生得到了升职（至少我认为是这个原因）。

合作至今，同样的ODC合同条款，报价变了，角色变了，服务也变了。而且，后来跟项目的时间长了，我对业务已经很熟练了，RL跟我一起工作的BA几年内要么换岗要么离职，最后只有我最了解这些业务，于是我还多了项兼职——为RL培训新上任的BA。RL甚至考虑过要我去日内瓦或者香港工作，但被我拒绝了。

问：这个项目开始时与业务脱节的状况，是不是行业内常见的通病？

答：我并不认为是通病，以我当时的经验，可以很容易地找到症结所在。只是我们是被当成“工具”， 如果整个过程一开始就是由我们来主导，也会有这个阵痛期，但是会很短。

问：很多人重视SLA，你为什么认为SLA并不重要？

答：SLA其实就是供求双方提前约定一些双方遵守的条款。我的经验是这些约定一定要精简到最少，多了就会形式化。比如在这一项目开始的时候SLA约定了很多东西，每天、每周、每两周的工作流程应该是怎样的，确认流程等等。

事实上这里面生产性的东西很少，大部分是管理人员的和风控所需要的。而我接手后抛开这一切，风控和流程这些事，我全包了，定期给你看结果就好，将95%以上的工作放在生产活动里面。大概2个月后，我们每天只要10分钟的会，就能解决问题了。

问：故事的后续，你成了项目的核心人物，自信、收入、成就感是不是都大大提升了？

答：是的，这是自然的。但我觉得这不是最主要的，重要的是做好事情的锚点不同。

问：你说的“锚点”指？

答：锚点是固定的那个点，做的所有工作都是朝这个目标去做的。对B公司来说是执行好合同；对很多程序员来说做好项目是完成分配的任务；我们做好项目的锚点是要让用户满意。

问：你从业多少年了？从什么时候开始成为一个“敏捷”的工程师的？

答：我工作12年了，接触敏捷多少年我也说不好，我不是一个传统敏捷方法的follower。例如典型的敏捷站会、code review、单元测试、还有xp等等，这些我都实践过，但我并不觉得这些东西有魔力。真正的敏捷就是一种精神或价值观。我觉得如果把敏捷形式化本身就是不敏捷的。

虽然我在几年前也曾认为敏捷就是一种方法，一种形式，但在业务的压力下，随着不断尝试不同的做法，不断地实践，我发现价值观才是做好事情的那个内核，转变是一点一点逐步形成的，一旦真的理解了敏捷，能让工作简单高效，事半功倍，这种价值观也就形成了。

问：你自己总结过敏捷给你带来的变化还有哪些吗？

答：我觉得最主要是做事不那么功利了，这和敏捷是相关的。如果你是以功利的心态去对待一件事，那基本跟敏捷的价值观是冲突的，那个“锚点”就是有问题的。

   

   

敏捷之美 ∣在这里发现    

                   

感觉有用敬请关注，交流投稿后台留言。

深度切磋请发邮件至[e-mail]。