需求质量保障
通过需求评审、发布前演示评审全面保障需求一次做对、做好。
需求评审(一次做对)
- 利益相关方参加评审:需求提出人、相关研发人员、业务专家等利益相关方均参加评审,保证大家对需求达成一致
- 评审问题闭环管理:评审问题得到有效解决,达到评审目的
发布前演示评审(一次做好)
需求利益相关方评审:从实际使用的角度,确认实现的功能是否符合预期
复盘总结
- 推诿责任:都是别人的错,我没问题
- 众说纷坛:对原因无法达成一致意见
- 流程正义:该做的都做了
- 原因太多:找不到突破点
- 屡教不改:以为找到了根因,但问题还会重现
- 缺乏闭环:措施没有落地固化
复盘方法
从感觉到事实,从形容词到量词
定性分析 | 定量分析 | 原因优先级 | 直接原因或根本原因 |
---|---|---|---|
开发人员新进入项目,对业务不熟 | 项目组有多少人?有多少是新进入? | 4 | 直接原因 |
使用公司级代码编写规范,不够细致 | 什么叫不够细致呢?这种形容词能否用数字刻画? | 1 | 根本原因 |
需求理解不充分不准确 | 不充分,不准确有无数字可以证明呢 | 2 | 根本原因 |
人员变动频率高 | 单因素方差分析:缺陷密度和人员经验有关 | 3 | 根本原因 |
刻画事实,而非主观判断
用数据刻画事实
量化分析的方法
案例
交通事故的80-20分析
对原因的分80-20分布分析
多层80-20分析定位原因
如果不服从80-20分布怎么办呢
案例
相关性分析
综合案例
案例1:工作量偏差率比较大
某客户存在的现象是:项目成本偏差大。
案例1:返工工作量占比的分布分析
案例1:对原因进行汇总排序分析
问题复盘的可选流程
原因的分类:PPT
技术分析
管理分析
原因反洗的注意事项
- 先事实,再原因:把问题定义清晰,再去找原因,不要南辕北辙,方向有误。
- 先感性,再理性:基于经验有个大概的假设,再通过数据验证及假设。
- 先细化,再量化:把问题拆分细化,定位问题,通过数据刻画事实。
- 先技术,再管理:先考虑技术上的原因,再考虑管理上的原因,两条线都要思考原因。
- 先广度,再深度;先全面思考原因,避免思维盲点,再找到主要原因进行深挖。
- 先体系,再个体:先找体系、流程、制度的问题,再说人员的问题。
- 先自己,再他人:先讨论本作业环节的原因,再识别去其他环节的合作协同问题。
- 先原因,再措施;找到原因后,再识别措施,不要不加分析就给出解决方案。
- 先简单,再复杂:先从简单原因和易行着手,再从复杂的原因和高难度的措施着手。
- 先纠正,再固化:先定义出来纠正措施,再思考如何将这些措施固化为习惯。
- 先近期,再远期:先识别距离结果时间最近的影响因子,再识别时间较久的影响因子。
养成定量思维的习惯
评论