裁员排第一的Scrum Master
内容列表
首先，这个标题没有危言耸听，这的确是部分软件公司或者类似行业的公司对SM（Scrum Master）的看法。甚至有些公司也就是真的这么做，直接在会议上问“SM价值何在？”。
说到这里，很多SM 已经泪流满面，甚至发自灵魂的拷问：我们SM 做错了什么？每天辛辛苦苦、兢兢业业的工作，到头来竟然是“干啥啥不行，被裁第一名”？
归根究底，问题出在了价值体现上。下面让我们来深入看一下这个问题。
SM 的原罪
其实，针对SM的岗位，本身就是有原罪的：
- SM 没有明确的对客户有价值的输出。除了一些培训文档外，SM 真的很难拿出一些实体的输出物。至于各种会议，更是被认为“谁都可以做”；
- SM 不是救火队员。SM工作永远是在问题出现/变大之前解决问题，而发现问题并在萌芽阶段解决同样是一个不太出彩的活儿。如果不能理解，请参考扁鹊和其大哥、二哥的故事；
- SM 看起来很闲。SM 的工作模式与研发、设计不同，更多的是在思考、观察、引导，以及协调各种外部资源。在这种情况下，SM 更容易被视为多余的人，尤其是随着团队成熟度提高，SM 干预将会越来越少，这种情况就更加突显；
- SM 在保护团队的时候，容易招（非团队内部的）人嫌，这个效应可以随着传播途径的拉长而逐步被放大；
- 部分SM 的不专业，该做的事情没有做，在被领导质疑时，无法正面回答。
看到没有，你为此辛苦奋斗的SM岗位，竟然有如此多的原罪。而要消除这些原罪，很大程度上依赖于组织的支持和领导的信任。这对不少SM 来说已经是Mission Impossible。
SM 价值何在
说完了SM 的原罪，让我们来正本清源一下，为SM 扳回一分。
- SM 与PO合作，确保需求被认真理解、并找到相应的需求管理方法，保证可以更好的进行价值交付；
- SM 对团队进行教练工作，从而形成跨职能团队、执行Scrum 标准会议、接触障碍等工作；
- SM 对组织的价值，主要来自于对Scrum的导入和理解，并与其他部门合作开发，并提升生产力。
这么一圈看下来，SM 好像能干的事情还挺多。
那么问题来了，SM 既然能干的事情这么多，为何依然会具有“第一个被裁”的命运呢？
不切实际的预期
在过去很多年的工作中，我们总结发现，凡是可以将敏捷/Scrum 成功导入的组织、部门，都有一个明显的特点，即变革负责人自身可以对敏捷/Scrum 有正确的理解与预期，而并非将其视为银弹。反之，所有将敏捷/Scrum 视为银弹的组织，都失败了，无一幸免。
究其原因，我将其归到“不切实际的预期”。
敏捷这东西，说白了是一个理念，落实到具体执行中，一般来说都会有一套与企业文化相匹配的方法论。注意啊注意，这种方法论，和过去的瀑布、门径，甚至跟企业制定的一个打卡规范一样，这都是一种实践罢了。如果你期待某个实践可以无差别的解决所有问题，那么这也就距离失败不远了。
企业常见的不切实际的预期有这么几种：
- 短时间内实现敏捷。这个是最常见的预期，甚至我见过有些企业希望可以采取一次、两次的培训就可以让全员敏捷起来；
- 万能的敏捷。开发效率低？上敏捷；质量不行？上敏捷；团队成员主动性差？上敏捷；隔壁老王天天来我家串门？上敏捷！敏捷好像是万能药，没有做不到，只有想不到；
- 敏捷出手，交付马上就快起来。我见过领导上了敏捷后，要求团队在短时间内交付过去多很多的东西。没有实现药到病除，倒是直接药到命除；
- 我的敏捷我做主。这种哑巴吃黄连，有苦说不出的情况。不少组织领导者对敏捷理解一知半解时，却又喜欢对做事方法指点江山，然后敏捷就变成了“领导喜欢的样子”，而不是“团队需要的样子”。这种情况，失败也就是肉眼可见了。
我们该怎么做？
针对这种情况，我们能做的事情其实很有限。总结下来也就是两件事情：
- 给领导洗脑
- 增加团队的曝光率
- 接受一定的不完美
第一个比较好理解——任何变革都是要自下而上与自上而下共同合作。所以，你需要获得领导的支持。获得领导的支持，除非你有非常明显的收益表给领导，否则说服领导将是一个劳神费力的事情。所以，洗脑将成为你的优先选择。
而增加团队曝光有点奇怪听起来。但也是符合逻辑。SM 本身很难有实物的输出，SM 的所有成绩都需要依赖于团队的输出来体现。所以为了更好的体现出SM 的价值，我们要做的恐怕不是展现团队多么敏捷、敏捷实践多么的好，而是团队的交付能力是否随着时间的推移而日趋稳定且有较小的上升趋势，这恐怕才是SM 体现价值最大的地方。
而接受一定的不完美，更多是与组织层面的行政命令、要求相互妥协，接受一些不那么“敏捷”的要求。只有这样，我们才能将敏捷/Scrum 等方法推行下去，否则，套用一句台词——“只有活的人才能干事”。
总结一下
最后总结一下。裁人第一个裁SM 的确是存在的，除去了SM 本身能力不行这一客观因素之外，其他的更多还是在于对敏捷的期待过分的不切实际，从而导致对该敏捷角色产生了质疑。面对这种情况，我们要做的和能做的，除了给领导洗脑，让其接受敏捷理念之外，还需要用团队的成果来为自己说话，还要为了推广敏捷而接受一些不敏捷的做法，因为那是SM的唯一道路。
善待SM，你我有责
有个问题，关于评估story point：1.前后端彼此不了解对方的技术，前端跟后端如何做到story point的评估达成一致？2.咨询过其他人，给的意见是由一个人评估，从开发开始到完成，那这个人势必应该是一个很牛掰的大神，熟悉前端，后端，测试等所有技术，就算真的有这个人存在，那这个人又如何能代表团队？所以，在实操情况下，团队如何使用story point进行评估？
SP估算是相对规模估算，当有了基础refrence故事后，其他的只需要在这个基础上去对比就行了。
这里面有一个假设就是——每个功能的各个组成部分，比如前端后端数据库的比例是差不多，因此不用考虑比例变化的前提下做估算。
另外如果过早考虑前端后端，本质就是会陷入过早的细节，也是不提倡的。
还是不是很明白，迭代计划会上或者评估SP的会议上，前后端彼此不了解对方的技术，评估也是从自身的角度出发去考虑的，也只考虑自己那一方，这样如何保证他们的评估是站在全局思维上进行考虑的？这样是不是有失偏颇？另外，如果前后端评估的SP不一样，双方又说服不了对方，因为双发无法站在对方的角度上去思考，这时候该如何处理，感觉SP在实际应用中非常难用
相对规模，不需要考虑其他内容。参照两个楼相对高度，你不需要知道内部装潢对比。
如果一个需求前端说是5个SP，后端说是8个SP，双方有都说服不了对方，这种情况怎么处理
这种情况不需要说服，看大家情况，随便选一个就行了。事后做回顾就行了。
事后怎么去回顾然后确定这个需求到底应该算是几个SP呢
这里有一个比较抽象的回答，就是“团队最终来看”，因为东西已经做出来了，所以此时就有一个比较清晰的认知。结合过去的偏差，就能知道我们哪里估算除了一些偏差。
举个例子，如果登录页面的SP是1，大家都赞同，这时候有个新需求，后端会拿这个新需求与登录对比，前端会拿这个新需求跟登录对比，结果是后端认为是5个SP，前端认为是3个SP，做完之后，后端仍认为这个新需求的sp大小为登录的5倍，前端也仍然认为这个新需求的SP为登录的3倍，我的疑点是双方都是站在自己的立场想问题评估SP，怎么做到统一，怎么落地，怎么跟他们说呢
估算故事点的目的，一方面是为了大家从不同角度思考。在一开始估算的时候，这点是能明确达到的。
再回到５还是３的问题。其实５还是３都不是重点，重点是是否能达到“基本的一致”，即是否大多数人认同某个值，这就行了。但是如果照你所说，前端与后端永远争执不下，那么大概率是不同角色之间的ｓｉｌｏｓ太明显，这就需要从团队配合度来入手了。
这个话题比较大，而且提供的信息不明，因此我无法给出非常明确的回答。但是基本逻辑是没有问题的，１. 是否在估算过程中大家都获得了一些过去不知道的信息；２. 是否最终我们努力去客观表达自己的观点和认知。
最后的防御堡垒是，如果３和５争论ux下且真的很重要，大家可以深入细节来看，将“规模”估算建模，比如与“工作量”相关也行。
但是你需要知道，规模着眼点是需求的复杂度，而工作量着眼点是代码行数，这两者并不是一个概念。