ASK MO第76期 | 如何给研发产品测试UI定度量指标
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
创新实干派
扫码关注公众号
扫码阅读
手机扫码阅读
ASK MO 时间 76 期摘要
本期 ASK MO 时间由 MO 老师主持,主题围绕 IT 团队的量化问题展开。MO 老师针对传统企业内部 IT 团队如何量化并证明价值,以及如何为研发、产品、测试和 UI 定度量指标,提供了详细的分析和建议。
领导对 IT 团队的量化需求
许多传统企业的领导要求 IT 团队进行量化评估,常用的量化指标包括每千行代码的 BUG 率、文档的 BUG 数和每天的代码行数等。然而,这些过程指标往往难以真正评估团队价值,且收集过程既费时又费力。
困难与解决方案
与销售或运营团队不同,研发、产品、测试和 UI 团队的业务指标较难量化,因为它们通常被视为成本部门。公司倾向于使用“多快好省”的方法衡量这些部门的绩效。“好省”可以通过财务方法较为容易地衡量,但效率则难以评估,因为软件开发是智力活动,不同于标准化的生产线工作。
绩效度量指标
MO 老师提出,通过以下绩效度量指标可以综合性地得出 IT 团队的价值:
- 速度:包括需求响应能力和发布能力,如业务需求前置周期、用户故事交付周期、集成测试周期、发布频率及解决发布问题的平均时长。
- 质量:涵盖内部质量和外部质量,包括单位周期的遗留缺陷数、用户故事的缺陷数及系统年平均故障率。
- 价值:包括需求吞吐量和交付有效性,反映单位时间内交付的业务需求数以及业务需求的价值。
注意事项
MO 老师强调,这些度量指标应综合考虑,单一指标可能导致结果偏差。例如,仅关注发布频率可能导致团队发布时仅完成最低要求的功能,从而失去度量的本意。
总结与互动
文章最后,MO 老师邀请读者留言讨论其他可能的度量项,并提供了联系方式,鼓励加入“创新实干派”讨论群,共同进步。
创新实干派
创新实干派
扫码关注公众号
用例,Bug一团乱麻?
用统一平台打通用例、缺陷与测试执行,告别碎片化管理。
查看测试管理方案
创新实干派的其他文章
PMBOK 第七版解读 项目管理原则 1
PMBOK第七版解读(项目管理十二原则)本章节,我们将学习到类似敏捷十二原则的项目管理十二原则,直接进入正题
ASK MO第69期 | 魔鬼循环之"项目延期/不可控/老板催/士气低"
• 请问:Kick off是在计划会开展?\x0a• Deskcheck的建议开展方式?\x0a• 魔鬼循环之\x26quot;项目延期/不可控/老板催/士气低\x26quot;\x0a• 如何管理项目集,保证项目目标达成?\x0a• 如何快速切入大型/小瀑布/多特性项目团队?
ASK MO第55期 | 产品经理需要具备哪些「思维模式」?
• 产品经理需要具备哪些「思维模式」?\x0a• B端的产品经理对「业务熟悉程度」要求高吗?\x0a• 如何让员工得到尊重、认可,获得成就感?\x0a• 如何让客户信任项目经理?\x0a• 如何能让大家更主动同步信息状态?
ASK MO第61期 | 聊聊未来五年,哪些技术「最有前途」?
• 聊聊未来五年,哪些技术「最有前途」?\x0a• 市面上的项目工具会不会让团队角色复杂化?\x0a• “半路”产品经理希望快速系统性提升,求支招!\x0a• 如何开好会议,避免沦为吐槽/批斗/夸夸大会?
ASK MO第34期 | 如何巧妙引导产品经理少提反人性的需求?
• 请问,什么叫“阿米巴”?\x0a• 如何巧妙引导产品经理少提反人性的需求?\x0a• 请问,日报建议要写成什么样呢?\x0a• 等到现场实施时,才发现需求只是停在表面..\x0a• 督导团队,如何有效切入业务单元?\x0a\x0a__敬请关注ASK MO第三十四期
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线