2019-11-25老师您好，在统计指标的时候我们一般会以人的纬度或者以部门的纬度来进行统计，比如会统计一个部门的前置时间，一个小组的前置时间，一个人的前置时间。那我们在做系统设计时这些数据是如何与组织架构关联呢，特别是这个人在组织机构中产生了变化又如何保证数据的准确呢？作者回复: 你好，虽然已经线下回复过了，为了其他同学参考，我再汇总下要点。第一、不是每个指标都能对应到人的，也没有这个必要，比如个人前置时间，我觉得意义不大，现在企业做度量体系普遍还没有细化到度量个人效率的程度。第二、指标需要分类分级，区分不同的维度，满足不同受众的视角，比如领导者视图，里面肯定只有最大的指标结果，然后可以拆分为部门级的数据，指标是层层拆解的，底层数据可以支撑上层结果，这个指标的层次关联很重要。第三、抓住核心坐标，比如需求就是其中之一，度量需求的时候可以站在需求提出方和需求受理方两个角度来度量，至于具体研发是否调整部门，其实并不重要哈。其实，没有度量个人指标，主要是不希望指标跟个人绩效挂钩，影响个人的行为，这一点也是设计度量的初衷哈。
1
2019-11-23老师您好，当前业界有比较流行好用的度量平台的开源工具或者开源框架吗？作者回复: 你好，坦率的说：没有，不过业界有一些开源方案，你可以拿来参考，但我确实没见过有公司直接使用的，比如Hygieia, MirrorGate等，像商业工具那就相当的贵啦，比如tableau，土豪公司可以考虑哈，还集成了AI的能力。
1
2019-11-23请问老师“交付吞吐量”是否可以辅助团队敏捷开发时设置每个冲刺的任务点数？避免出现工作量闲置或者产生过多挤压？作者回复: 你好，你说的特别正确！可以参见精益看板的章节，对于WIP的合理值就可以使用吞吐量作为参考的主要依据哈。
1
2019-11-23感谢老师的分享，对于我们正在建设DevOps度量指标阶段受益匪浅，还是应该回归本质，宜少不宜多，宜精不宜烂，达成共识，构建多维度视角的可视化，才能使度量变得真正有效。作者回复: 恩恩，道理很简单，还需要不断实践呀，有问题欢迎继续留言，我们一起探讨，谢谢！
1
2019-11-23正向管理：觉得老师今天的课程就是在讲项目管理。<落地实践篇>开始就明显的感觉到了，故而在老师开始的其实就去补充了其相关的课程强化自身。
老师的今天的课程中这块其实完全体现了DevOps其实就是一个项目一个产品：想有效发挥DevOps就必须让其贯穿整个过程，早期的进销存去替换全手工记账同样如此。做好一个DevOps可以大幅提升软件内部的效率，就像上次DevOps大会时网易的于旭东曾经做的分享更让我感受到这点。
软件是一把双刃剑，诸多的关键环节同样如此：用好了大幅提升效率，过于刻板的为了规范而规范，可能受伤害的不只是软件本身，而是整个企业。谢谢老师今天的分享，期待后续的课程。作者回复: 每次看到你的留言都让我感慨颇深，可能是在大公司时间长了，有太多这种一言难尽的故事，比如集成代码需要VP审批这个事情，就已经不知道掰扯过多少次了，试问哪个VP能够知道代码改了什么呢，所以我始终认为，效率提升就是要打破现有流程，如果不改变流程想实现效率提升，能做的也只有表面一层了吧。
1- 2020-01-18有的需求很大，有的需求很小，那开发前置时间是否就没有意义了
作者回复: 没错，你发现了一个关键的问题，就是需求的颗粒度，如果颗粒度不平均，那么统计数据就没啥意义。所以在我们的实际经验中，会将需求颗粒度（开发交付时长）作为交付周期的重要参考依据，甚至对于需求颗粒度，配置化需求比例都会有明确的KPI要求。
2019-12-09关于数据的准确性这段时间很有感触。公司今年新上了一个缺陷管理系统，用来替换原先的老系统。新系统功能和使用习惯和老系统差异很大，大家都很不习惯，经常出现代码已经部署到生产环境了，但是对应的ticket还是显示正在开发的状态。我的应对方式是，一看到错误就追踪落实到个人，确保他意识到问题出在哪里，我们制定的新规则是什么，还有也要解释为什么我们制定这样的规则（我觉得规则的制定还是要以效率为准，没缘由的规则自己都说服不了自己，更不要想着让别人遵守）。然后总结一些常见的问题，以checklist的形式附加给所有程序员，作为提醒。感觉现在的自己就像个老母亲，一遍又一遍教导纠错，心累…作者回复: 如果流程依赖于人的自觉性来保障，那么这个流程本身可能就有问题哦，流程和规范都有一定的强制性，最好的方式还是在某些节点进行卡点，比如状态不对不允许发布，提测等等，通过这些卡点来培养人的意识，再辅助以自动化的方式来简化流程执行的成本才是正道吧。
2019-11-23这些指标需要区分阶段嘛？ 如开发阶段是在开发环境，测试阶段是在测试环境作者回复: 这个好像没有必要哈，测试环境是要度量什么呢？
1