这是2021年第50篇随笔，全文958字。
5月的第4篇。
5月计划9篇，随笔4/9篇
彼得德鲁克说过“如果你不能衡量它，就不能管理它”。
从概念上看：
Lead Time作为精益里面的概念，
- Lead Time = 从一个Idea交付上线给用户使用为止 - 提起
- Lead Time = 商机投放市场 - 洞察到
从视角上看：
Lead time 作为效率度量的价值交付效率度量首要度量指标，中文翻译为周期时间。
也是客户可以感知道德水岸，LT越短，用户感受越好。
反映了企业对于客户的响应速度。
不同于管理者的内部视角，常看效率，迭代完成多少规模点，是否延期，velocity是否提升。
Lead Time，从视角上而言，是客户视角，客户不关系你一个迭代发了多少功能，只关心，从我提出问题，到得到解决方案这条价值流上花了多长时间。
从度量上看，
Lead Time = Cycling time + 步间WIP等待时间
当LT跟CT时间约接近，等待时间越少，那效率越高。
从实际工作而言，
遇到几个问题
- Cycling time(从商机到上线)中有多少个步骤？每个步骤的time box如何获取。是否有人或者有公共的地方可以看到全部价值流。
- 据观察，SM和研发，甚至产品都不知道如何平衡需求和客户要求谁的优先级高。甚至不知道哪些是客户需求。所以价值优先级的排序真的很紧急重要，有没有公共地方可以看。公司有没有去推，客户价值优先，产品需求和客户价值需求谁更重要？
- 目前从DataOS运行这么就来看，发版延期的原因，还有一个就是，没有按照迭代的time box 来。是计划会塞入的需求卡，做完才行。一问可不可以挪到下个迭代，都说夏虎总要要。
- 目前DataOS延期还有个问题，就是每次都是67个团队多个小产品一起发版，每个团队的速度不一样，步间WIP的等待时间很久。才会造成挤压。比如这次2.2.0，数据中心，桌面组dev达到合并master标准已经1周了，然后应用中心，认证中心云市场还有很多缺陷要改。所以一直等待，一起走。这也造成了发版周期很长。迭代交叉运作。
从问题上我发现一个点，用精益的思想，快速相应客户，减少WIP等待时间，提升LT，是否可采用看板+SAFe的方式。
每个团队每个迭代情况不一样，无需等着一起走。
比如，以3个月为cadence，SAFe每3月的PIplanning，就要求产品把要及时给客户的项目发版，产品正常的发版，feature开发，MVP都规划好，全员都清晰这3个月需求和feature的优先级。
然后各个产品线，或者train 按照自己的节奏开发，彼此的dependency梳理清晰。
3个月的时候几个train合并一起发版。
这样就各自有各自的节奏。
有些团队完成了，可以自由接项目工作。不会团队一直在产品迭代上，还接项目工作。
网友评论