2019-08-27代码行数和 bug 数量这两个无聊的指标。居然都在公司的绩效考核中出现了。无语。作者回复: 根本原因是：不知道怎么样度量开发人员的绩效。就是用了这两个指标作为Proxy。
3 8
2019-08-261.研发效能的定义和作用
研发效能的度量，从应用程序开发的生命中期中获取数据，并使用这些数据来衡量软件开发人员的工作效率。
主要为实现三点：
1.跟踪团队的表现、提高团队的绩效。
2.提高项目计划的准确度。
3.了解流程是否高效，寻找需要改进的关键领域。
达到度量目的：简化流程、发现瓶颈、帮助团队改善产品生命周期、更高效地产出质量更好的产品。
理解：关注团队的表现，团队的成长；关注项目的准确性，不要经常走弯路；关注流程的高效，实现迅速，也方便新人快速加入。
工作都是人去做的，首先关注人、团队，而不是数字。关注人，给予团队支持和信心，即使走错路了，大家会一起想办法一起努力。关注数字，人和团队就可能发生数字造假或者数字失效，比如案例1和3。
个人碰见的数字造假：
客服团队造假。某天，老板想优化下客户服务，从客服下手，根据行业标准定出了一个指标，询单转化率、回复率、回复时长、未回复数，这些指标再分解成工资。老板十分鸡贼，算了下认为这可以提高客服工资，店铺转化也可以提升，双赢。然而客服团队一算，只有达到一个高标准，才会比以前工资高，只有平均就比以前差几百。客服们很抱怨，但当面也说不赢老板，于是发明了过墙梯：对于回复率呢，以前一句话说完，拆成2-3句。回复时长使用表情大法，先来一个表情缩短时间。最后客户服务没有优化，转化率也没提升，客服团队怨声载道，当时能力有限，感觉也对不起他们。展开作者回复: 你认真学习，不断追求进步的样子真是棒！！
你讲的客服例子很有意思。我记得以前好像是亚马逊还是哪个公司的客服也出现过类似的事情。 2 7
2019-08-26写的很好，有点等不急，好想催更作者回复: 多谢支持！后面有问题建议欢迎啊 😀
4
2019-08-27我们目前是基于scrum的软件数据来粗略跟踪一些执行过程数据。包括：每个迭代的周期数据，估算与实际登记数据，线下和线上Bug数据，Bug分类数据，团队成员任务及估算、实际工时等。从这里也能看出一些信息：
1. 估算与实际操作之间耗时是否匹配，准确度是多少，基本在70-80之间，除了造假数据。造假的化可以拿每日登记情况进行粗略判断
2. 每个职级团队成员的大致行为，比如单位用时产生的Bug数量，每个迭代的平均任务数，Bug等，包括大致每个任务的平均估算时间。有的大概在3-6小时一个任务，拆分越小越容易把控进度。有的团队平均是8小时一个，时间会比较“充裕“
3. 随着质量团队和研发团队质量意识的提高，月度Bug或线上Bug有减少，质量在提升。临界点尚未得到，到时再观察任务数、估算等数据
总的来说，数据可以来自多方面，至于如何去用，还需要更多的研究和分析展开作者回复: 我的经验是这些数据可以用作参考，帮助团队改进，但是不要跟绩效直接挂钩。
“随着质量团队和研发团队质量意识的提高，月度Bug或线上Bug有减少，质量在提升。”这个就是度量可以用来参考，它显示出来一个趋势。👍👍 （不过要注意单个指标有的时候可能不全面。比如bug减少，会不是因为功能减少等其他原因？当然这只是随便的一个例子。） 3
2019-08-27我们公司现在受制于客户，每月要求1000行代码量达标，我作为基层管理，主要代码都有团队成员编写，而我除了客户对接，需求分析和算法设计之外则主要编写关键点和优化点代码，每个月代码量都无法达标，给领导各种解释啊。而且公司严管外网访问，我作为团队首领也是没有外网权限，只能有手机查看需要的资料。这样的开发环境很难高效开发。作者回复: > 每个月代码量都无法达标，给领导各种解释啊
领导能理解吗？1000行代码量是客户要求的吗？如果你能说服你领导你的工作提供了足够的价值，问题只是客户那边不理解的话，那就比较好办。说服客户，或者可以把一行分成两行写。如果你不能说服你的领导，就比较麻烦了。
> 只能有手机查看需要的资料。这样的开发环境很难高效开发。
这个的确是麻烦。可以花点时间研究一下手机上学习的工具。同步手机和电脑的工具应该是比较有用。比如：Pocket(https://getpocket.com)用来记住感兴趣的URL，Evernote，Mac Note，OneNote，等等用来记笔记，讯飞输入法可以记录有声笔记，等等。 3 2- 2019-09-03常见研发效能度量失败的案例应该归属量化的绩效考核，为了追求较好的绩效指标，采取以绩效指标为目的的工作方式，导致忽视了本职工作，也间接伤害了那些以团队利益为出发工作的员工。
对于度量，没有经验，但个人觉得团队度量会比个人度量更好一些，促进团队的成长，也促进了个人发展，同时增加一些个人奖项，激励某方面能力突出的员工。作者回复: > ...但个人觉得团队度量会比个人度量更好一些，促进团队的成长
说的非常对！ 1 
2019-09-02请教老师：实际工作中有的「需求」简单改几字就可以交付花个几分钟，有的「需求」要修改很多地方，耗时可能上月，这时如何评价效能？假如有的尽是前一类需求，有的团队都是后一种，组织层面如何公平的来度量不同团队的效能？作者回复: 这种情况，如果指望客观的数据是行不通的。我的经验是只能考管理者主观的判断。组织层面必须要能够给做脏活累活的团队足够的认可。
1
2019-08-27指定流程、标准、考核指标以及选择适合的工具，搭配好了可以爆发出巨大的效能
只可惜很多时候，是自上而下的管理，不懂基层真正需要什么，而做了错误的决策，导致一系列问题作者回复: 这种情况，如果管理者心态开放，能接受改变和改进，还有一些办法，比如在底层做出一些东西，让管理者看到能解决关注的问题，会有一些正面的效果。如果管理者自认为自己懂，那就比较难了。
1
2019-08-26
大概的准确胜过精确的错误，放任不管，让团队自由发挥，如果是BAT这种大厂的自有研发人员，OKR当然没问题，反之，就肯定行不通。期待接下来的课程。作者回复: 肯定不能放任不管。如果工作跟团队方向不对，产出达不到预期，Facebook这些公司砍人是很果断的。专栏最后一个模块，我会介绍一些绩效考评相关的内容。
1- 2019-08-26问题复杂之后方法需要使用完全不一样的工具了，比如今天的深度学习使用了完全不同于传统算法的办法，虽然说可解释差，但是还是有一些好和坏的准则的。就像现在提倡okr而不是kpi，鼓励共同成长，相互尊重，分享收益等都是很积极的应对措施，还有更用心的过程控制不可缺少
作者回复: 👍👍
1 
2019-12-27能效=有效工作/单位时间+偏差
有效工作可以是用户故事点衡量的任务（需求，架构，开发，测试等）
单位时间单位为人日（根据能力，有些人可以是5小时，有些人可以是10小时）
偏差可以是 用户价值，生产品质等
完美。哈哈作者回复: 👍👍👍
2019-10-27那到底该如何考核程序员，效能组成员呢作者回复: 在Facebook度量开发人员东公司的贡献度（impact）。具体度量主要是采用360度绩效考评系统。我在最后一模块“管理和文化”中会介绍。
2019-09-24度量如果是基于成功OKR的，会发生什么？作者回复: OKR的使用。也有一个重要的原则是不要把它的度量和绩效强挂钩。
我的理解，OKR更是一个目标对齐的工具。 1
2019-09-11pmp十年了还是工时随意填，凑够上班时长，且必须大于等于上班工时的填报率才不会扣团队绩效。
小组长为了自己的业绩，开发一堆功效demo。但对规范的推广却望而却步。一心为了自己业绩和升职的领导对于公司研发的积极性压制很大。往往是抓住芝麻丢了冬瓜。而这一切在考核里却看不到，可悲作者回复: 考核系统需要改进。应该增加收集成员反馈的机制。
- 2019-09-03尝试在前端团队中推行Code Review，每个项目分配一名同事和一名主管负责审核，主管还是比较负责，能够提出一些问题，另一名同事则比较敷衍，整体的Review效果并不理想，但如果强制要求每次Review必须提出问题，又有点过于死板，不知道有没有比较好的方式方法，可以借鉴
作者回复: 后面会有两篇文章专门讨论代码审查。敬请期待 ：）
针对你的描述，我觉得比较有效的代码审查不应该是集中式的，而应该是p2p的。也就是说，开发人员之间互相审查，而不是有专门的人来审查。 
2019-08-29突然想到了那个用代码量来评KPI的梗了作者回复: 再讲一遍！
2
2019-08-29接手前人的代码，不断补坑，bug修复的多，没有新需求作者回复: 我的一个好朋友，在Google工作10年，技术过硬。关于维护别人的代码，他推荐这本书：
英文版：
Working Effectively with Legacy Code https://book.douban.com/subject/1428943//
中文版：
修改代码的艺术
https://book.douban.com/subject/2248759/
2019-08-26销售导向型的公司，根据项目成本和利润进行度量。项目赚钱，技术人员按不同比例获得利润。但存在一个问题，项目合同额度不是项目组技术人员可直接决定的，而是销售人员决定的，所以技术人员只是被动的接受项目利润或者因为合同额度降低引起的裁员问题。作者回复: 所以，具体的问题是技术人员觉得项目额度估计的非常不准确，导致不公平吗？
2019-08-26效能到底高不高，确实很难度量，当效能和绩效挂钩时，那效能的度量标准就不能随便定了，否则很容易伤到团队。能否这样，开发一个标准功能，我们把这个功能的工作量定为1，然后在评估其它功能的时候，就以这个标准定好工作量为几，比如5，这个由大家投票，取平均值。以这种方式来度量，老师觉得怎么样。作者回复: 这种方式感觉要花比较多的时间去做。工作中常常会出现新的工作，那是不是每个任务都要评估呢？另外这种评估本身就是一个大家主观的评价，需不需要做的那么频繁？能不能绩效考评的时候，通过同事之间的互相反馈，收集大家的贡献度呢？
2019-08-26公司采用任务驱动开发，度量的目标是考核程序员的效能，后来发现对互相协作带来的很大影响，后来改为针对团队，再后来就取消了。失败的原因是从影响个人或团队的收益出发而不是从提高效能出发。现在尝试要求团队在冲刺完成后提交改善意见和上次改善意见实施情况，慢慢试验中。作者回复: > 公司采用任务驱动开发，度量的目标是考核程序员的效能，后来发现对互相协作带来的很大影响
这个“任务驱动开发”中使用的度量具体是什么度量，能解释一下吗？ 2