SAFe6.0的收获与感悟（下）

大家好，我是rainbowzhou。续接上文SAFe6.0（上）、SAFe6.0（中）。在这一篇文章中，我想继续探讨我从这次课程中学到的敏捷的知识和技能，这篇主要围绕精益投资组合管理与引领变革这两个主题，以及互动答疑展开。

精益投资组合

为什么引入精益投资组合？

传统的投资组合管理方法不是为被数字化颠覆的全球经济而设计的。企业因此倍感压力，不仅需要在不确定性更高的环境下工作，还需要更快地提供创新解决方案。故需引入精益投资组合。

注:传统投资组合主要指根据投资者的具体情况把投资资产分配成不同的比例，投入不同的领域及投资不同的产品。

精益投资组合是什么？

精益投资组合是一种开发价值流的集合，每种价值流均可构建、支持和维护解决方案；针对不同体量的企业有不同的投资组合方法，小企业对应单个投资组合，大企业对应多个投资组合；每个投资组合可以使用投资组合画布模板表示。如下图所示：

精益投资组合管理解决了哪些问题？

引领变革

为什么要具备精益敏捷领导力？

自上而下的推动，更容易办事。组织的运营体系决定了工作如何开展，只有这些管理人员才有权改变并持续改进组织的运营体系。

以身作则

对于领导者而言，以身作则不是主要的事情，而是唯一的事情。可以从下列方面提升领导力：终身学习、对人真诚、情商能力、勇气、发展他人、去中心化决策。

如何引领变革？

1. 增强紧迫感-传达变革的需要和立即行动的重要性
2. 建立指导团队-认识到志愿团队需要有一个有效的人员联盟来协调和沟通活动并指导变革
3. 设定愿景-确定不断变化的环境提供的机会并鼓励人们采取行动
4. 感召众人-认识到只有当最佳数量的人们在一起围绕一个目标去努力时，大规模的变革才会发生。
5. 赋能行动（通过消除障碍）-动员志愿团队消除障碍，跨越筒仓开展工作，并产生真正的影响
6. 创造短期成效-尽快传达可见的成功内容，以跟踪进展并激励志愿人员坚持下去
7. 再接再厉-促进变革，直到愿景成为现实
8. 巩固成果-用新的行为和组织成功取代旧的习惯和传统

互动答疑

T代表老师，S代表学生。

S：进行用户故事大小的估算时，1个故事点等价于1人天吗？

T：不是一个概念，Story Point 不代表工作时长，只代表故事复杂度。

S：SAFe 里需求的大小是从 Strategic Themes -> Protfolio Backlog ->ART backlog ->Team backlogs 这样的顺序么？然后 ART backlog 里面的需求是叫 Feature？这里的 Feature 又会拆分为 Story和 Enabler？Story 又分为 Epic 和普通 Story吗？

T：不是，需求大小是Themes、Epic、Capability、Feature、Story；PI目标一般是Epic、Feature，而Themes基本偏Vision，Capability是Solution层的。大小是个非常模糊的概念，一般只能说epic、feature都很大。用户故事是按照Epic、Feature、Story、Task。

S：我们团队在研发某个项目的过程中间，BA使用EXCEL来记录和管理需求，但是随着时间的推移需求出现了变化，导致实际与预期不符。对此我要求BA使用项目管理软件，记录需求方便进行回溯、追踪，便于大家统一对齐达成一致，但是BA不配合怎么办？

T：你的角色凭什么要求BA使用项目管理软件呢？BA不配合你的工作，并不会对他的工作造成影响。他配合你的工作，你需要感谢他，不配合的话，是正常的现象。你有没有遇到过，你在教我做事类似的情况......

S：嗯，遇到过的。我想很多人即使没遇到过，也听到过，尤其是在跨部门沟通或需要他人协助时。

谈谈我现在的想法，不管是反问方，还是被反问方，说出或听到这句话其实已经没有站在一个平等的角度看待问题了，有点硝烟渐起的感觉。

站在反问方的角度，他处理或面对问题的方式、方法，是受多方面因素制约后，得出的最合适的方式和方法，所以当你提出“建议”时，他会认为你不够专业，不能结合实际提出好的建议。因为多数时候最好的方案，不是最合适的方案，并且谁也没有办法预测未来，给出最好的方案。

站在被反问方的角度，出于工作需要，或者有过解决类似难题、痛点的经验，再或者有了解过先进的技术方案知道其运用场景。于是提出了我们认为好建议或方案，认为它能解决问题，降本增效。但是我们陷入了一个思维误区，你以为你看到的痛点，也是对方的痛点。你想过吗？或许对方认为它不是痛点，或许它的重要程度没那么高，或许这是当前所处的环境造成的一个“妥协”结果，有太多太多你可能想不到的点了...

回到这个问题本身，那么我们如何应对这个问题？

1、确保双方就某一现象的定义达成一致，例如提交代码后，选择相应的分支，进行编译构建代码，花费时间为5分钟。身为测试的你，认为时间太长了，是个问题；但开发或运维不觉得是个问题。那么分歧点已然明了，你们对事件本身的定义不一致。

2、想想你自己的岗位职责是什么，你是管理者还是执行者，是要求其他岗位的人，按你说的做；还是你发起的一次试点，想要优化和改进一些项，号召大家一起参与。针对上面编译时间的例子，若你是管理，则可以牵头研发lead或运维lead针对测试中遇到的可改进的点，进行整体或局部的优化，由上到下去改进阻力会小很多。若你是执行，则向上反馈，说明测试的时间，因为每次发版等待时间过长，而导致大量浪费，你认为可以优化或改进的项有哪些，技术债的问题可以通过多次迭代不断改进。

3、最后，他人若愿意配合你，并且取得了良好反馈，那么双方皆大欢喜；若拒绝了你，不要气馁，你的出发点可能是好的，但是也要知道不是所有人都会对你有求必应。笑一笑没什么大不了，该吃吃该喝喝，啥事别往心里搁。

T：看公司文化，要是领导让我管，我就按死这是我的kpi，否则大家慢慢聊，想不想解决问题。

T：补充说明一个知识点，瓶颈VS阻塞

T：举个例子，把啤酒瓶横过来就更好理解了。如果瓶盖打开了，瓶颈就是那个流动变慢的地方（注意，此时流动还存在，只是慢了，我们需要团队共同解决这个瓶颈）。而如果瓶盖没打开，整个东西就彻底倒不出来，此时瓶盖就是阻塞，一般阻塞都需要外部资源（钱、权、人）才能解决。如下图所示：

小结

以前总认为会技术能解决某个问题很厉害，现在觉得会拆解问题再用合适的技术去解决才是真牛！先确保方向正确，然后使用正确的方法，不断验证不断改进，方能成功。“纸上得来终觉浅，绝知此事要躬行”，大方向了解清楚后，干就完了！

以上，有任何想法都欢迎大家后台私信我，一起探讨交流。