微信公众号： 且把金针度与人
作者微信：cindynan77
作为敏捷的追随者，我相信你对敏捷所能带来的好处已经可以倒背如流；作为敏捷的实践者，我相信你对敏捷过程实施也已经熟烂于心。
但是所谓万事开头难。敏捷的发起不是单纯的自上而下，也不是单纯的自下而上。而是两者结合，既需要下层有改变的意愿，也需要上级强有力的支持和参与。所以"我想我能我可以"还远远不够，怎么引导上下级都能有发现问题的意识，再产生解决问题的渴望，从而变成"我们想我们能我们可以"。这其实考验的是每一个实践者的思维方式。
今天我用"云—雨—伞"理论跟大家说说怎么引导一个实践的开始。
image
云—雨—伞理论
先来给你介绍下什么是"云—雨—伞"理论。
"天上出现乌云，眼看就要下雨，带上伞比较好。""
这句话分解来看，其实是对事实、分析和行动三者的比喻。怎么区分？
云代表"事实"。是用眼睛实际观察到的情况。谁都能看出来天上有没有乌云。
快要下雨，是从现状推测出来的"分析"。也就是说从出现乌云这个事实引出可能会下雨这个分析。
最后是雨伞。也就是说从"快要下雨"这个分析得出带上雨伞这一"行动"。
进一步整理如下：
（事实）"天空出现乌云。"
（分析）"因为有乌云，可能会下雨。"
（行动）"因为要下雨，所以带雨伞。"
这里最重要的就是区分"事实""分析""行动"。如果将三者混淆或遗漏而得出结论的话，那么结论就会不合逻辑。下面我就说一下在引导敏捷的有哪些常见的失败。
image.gif
仅把"乌云"提交上去
这种情况比较少见，但是还是需要避免。如果一开始你只是收集了各个部门反馈给你的数据和问题就轻易得出结论反馈上去，收到的可能只是推诿和抱怨，并不是真正问题的所在。因为根据"基因归因错误"理论，看待自己的错误，我们通常只会去找外因，而看待别人的错误，我们往往追究其内因。
我们常说产品需要"移情"，站在用户的角度想问题。需求被形容成冰川，露出海面的只是冰山一角。其实作为管理者，我们同样需要"客户思维"，挖掘问题暴露出来的本身进行分析。
image
比如说，你去医院检查血液。一周后，检查结果出来了。结果上写着丙氨酸转氨酶、血球容量计、GGT等一些让你摸不着头脑的数据。然后就听到医生说："这是血液检查结果，你看看，考虑考虑。"你会怎么想？
我们往往想要知道的是，这些数据说明了什么？是说明身体已经患病，还是没有毛病？应该注意什么问题？如果有问题的话，问题是大还是小？你想要的正是"数据背后的结论"。
当 PO 跟你抱怨研发总是逾期交付，你要了解是什么原因导致的逾期，是需求本身不理解价值所在，还是需求颗粒度太大?
当 PO 抱怨最终发现开发出来的产品不是他们想要的,你要分析是一开始 PO 就没有澄清清楚，还是对于验收标准不明确。
当研发抱怨每天加班的时候，你要抛开现象看本质，是本身需求估算不合理，还是交接带来的等待时间过长。
拿"云—雨—伞"的例子来说的话，就是只向上报告现在有乌云（相当于报告中的数据或收集到的内容），根本就没意义。
不提供依据
另外一个常见错误是只提交建议。用"云—雨—伞”"做比喻的话，"带上伞"就是行动。如果只是提交行动计划，别人就不知道这么做的理由是什么。就是缺少"WHY SO"，也就是"为什么这么做"。
image
在做敏捷提案时，不能只提出行动计划。要将现状和分析也一并提出。出现乌云，说明要下雨（现状分析），要是带上伞就好了（行动）。
比如作为敏捷教练，比如你经过分析得到了团队的问题有：逾期交付；超支；很难变更需求；最终发现开发出来的产品不是他们想要的；贻误战机，丢失市场机会等。
然后这个时候你直接说"让我们来实施敏捷吧，这些问题都可以解决。"可能所有人都不会买账，因为你只是为了"做敏捷"而去做敏捷。
专业的敏捷教练会去说明"要下雨":
传统的项目开始的时候，只有预算和目标交付时间是确定的，下面的所有因素都存在不确定性：
1.范围与具体需求；
2.可能的需求变更；
3.人员（中途有人会放假甚至离职等）；
4.估算的准确性；
5.对现有系统的影响；
6.服务器环境的搭建（需要什么配置、何时能到位）。
最后才转向敏捷。什么是敏捷开发？它和瀑布模型最大的区别在哪里？具体解决方法和价值观是怎样的？
image
混淆现状、分析、建议
最后一个错误是将现状、分析和行动建议混为一谈。特别要区分现状事实和意见建议。明确回答"结论"和"依据"。这就是所谓的逻辑性思维的基础。
如何才能迅速掌握这个技能呢？最简单的方法就是添加标题：
事实、现状;
我的解释分析;
推荐的行动方案;
这样的话，自己脑中就有一个清晰的结构了。
比如，引导敏捷实施框架如下：
- 事实、现状：
PO 部门的问题有：
1.逾期交付；
2.超支；
3.看到成品时项目已接近尾声；
4.缺乏透明度，不知道具体进度；
5.很难变更需求；
6.最终发现开发出来的产品不是他们想要的；
7.贻误战机，丢失市场机会。
研发部门的问题有：
1.过度承诺；
2.难以一次性消化所有需求；
3.惧怕需求变更；
4.不断重做；
5.后期压力巨大；
6.加班
- 我的解释分析：
而在项目开始的时候，只有预算和目标交付时间是确定的，下面的所有因素都存在不确定性：
1.范围与具体需求；
2.可能的需求变更；
3.人员（中途有人会放假甚至离职等）；
4.估算的准确性；
5.对现有系统的影响；
6.服务器环境的搭建（需要什么配置、何时能到位）。
敏捷对解决 PO 的问题：
1．不再需要一次性解释所有的需求；
2．可随时提出需求变更；
3．进度透明；
4．确保最重要的需求能在目标交付日期获得；
5．确保得到正确的产品。
敏捷对解决研发部门的问题：
1．不再需要承诺一个未必能实现的计划；
2．更早地开工和交付；
3．为当前迭代进行更精确的计划；
4．适应需求变化；
5．适应不确定性；
6．开发正确的产品；
7．与业务人员的争执更少。
- 推荐的行动方案：
针对性选出能解决以上问题的时间，比如：
1.围绕已知的范围和需求定义用户故事和建立 Product Backlog；
2.为用户故事排优先级；
3.商定Sprint的长度；
4.商定Spring计划会议和评审会议的日程；
5.商定发布计划；
6.准备相应的辅助工具。
小结
任何提案如果没有以上三项内容，那么它就没有太大的说服力。很容易被对方质问"你真正的意思是什么？""为什么要这么做？"
领导变革本来就是一件很难的事情，引导变革开始更是难上加难，但是只要学会思考问题的逻辑方法，很多事情就会迎刃而解。最后在强调一遍"云—雨—伞"理论的要点：
·提案中的现状（云）
·分析研究（雨）
·行动方案（伞)
更多原创推荐阅读：
image.gif
image
网友评论