背景
对《软件研发改进中如何定义出让人信服的问题 》做了补充和修订，特别是补充还原案发现场和回溯确认部分，更易于问题定义的落地。
软件研发改进过程中或日常工作中，经常会碰到许多待解决的问题，特别是棘手问题。
为了更好解决这些问题，需要做减法，聚焦重点问题。
其实更重要的是定义问题和设定改进目标。
只有清晰定义出问题，才能真正有的放矢，从而达成共识、共同协调相关资源来解决问题；
只有定义好问题，才能设定靠谱的改进目标，进而才能真正达到预期效果，而不是脚踩西瓜皮滑到哪里算哪里。
笔者经常在开发团队中组织大GoSee（全面系统深入对项目全面诊断、根因分析、找到杠杆解、给出解决方案并进行落地穿刺），出综合方案时第一步也是最重要的一步就是定义问题和设定改进目标，看似简单，其实也是最容易出现偏差和让项目不能信服的地方。
这里把相关经验进行提炼和总结，供大家参考。
问题定义的问题
开始之前，我们先看一个问题定义不清晰的例子。
这是一个研发改进大Gosee中实际定义问题的案例，当然这个版本是个中间版，文章最后会给出该问题的优化版，大家也可以根据文章分析思路自己尝试进行优化该问题的定义，并和优化版(见文尾)做下对比。
这个案例中问题定义有以下不足点：
解决思路
当我们收集问题的时候，用户给我们反馈的原始诉求我们一般叫用户voice。
用户都是成年人，从人性的角度看，成年人在自己的认知范围内，往往会不自觉的刷存在感。
这个无意识的行为会导致用户反馈voice时带入两个自己毫无察觉的误导：
1、过早抽象
用户会根据自己的经验、价值观、屁股决定脑袋等因素，把原始问题细节忽略掉，进行了一些抽象并给出了倾向性结论，这些结论有的符合客观事实，有的是以偏概全，甚至有的还有推脱和指责的成分。
2、以方案代替问题
成年人一看到问题，会不自觉的给一个判断，并进一步给出解决方案，最后一般还很坚定认为这个方案就是问题。
那如何定义好问题并设定目标呢？一般我们建议采用七步法：
接下来我按七步法逐步展开问题定义！
还原问题
首先对问题进行现场还原，本来gosee的要求就是现场->现物->现实，即到现场看现场中的现物发生的现实。就像还原案发现场一样，让一切蛛丝马迹都显现出来。
问题还原我们一般使用5w（4w+1h）法中的4w(why除外)，即：
who
问题的苦主是谁，谁会在这个问题中受害，让受害者发声往往会获取第一手的资料。
如果让中间人或者声音最大者转述，受害信息往往会被过早抽象，丧失了很多问题的立场，立场不同，问题方向可能会有很大偏差甚至南辕北辙。
问题定义中我们碰到过很多偏差的情况，都是问题材料来自于转述，而不是苦主亲临诉苦，由于立场的原因导致问题被自觉不自觉的带偏了。
另外，确认苦主之后，问题解决也有了验收人，只有苦主觉得问题带来的痛楚减轻或消失了，问题才算是开始得到解决。
when
什么时间发生的问题，有了时间这个要素，更能确认事实。
另外就是问题发生的频率如何？
如果是偶发且危害性不大，那可能还需要观察而不是立即投入重兵解决。
where
问题发生的地点和部位。
这个需要对问题所处的结构进行分析，同下面how里面表述的情况一样，越是具体部位越是清晰易盼。
what
到底发生了什么，这个把问题整个场景进行了还原，即著名的英雄救美模型:
坏蛋，受害人，英雄(可能有可能没有)，坏事，伤情。
这五者是如何相互作用的，重点在坏事和伤情两个纬度，和how比偏重结果。越是细节越是有助于问题的澄清。
how
怎么发生的，问题的来龙去脉，包括问题发生的环节，和what比偏重于过程。
能具体问题发生的具体流程中的某些环节，往往对看清一个问题是否重要。环节越是具体越是清晰。
问题还原是问题定义的第一步，还原问题后，我们就可以考虑问题定义的要素：
确认问题
前面讲过，用户voice很多都是解决方案，比如下面这个问题：
经常有人下班回家说：饭怎么做这么慢。
其实做饭就是一个解决方案，问题应该是饿了，但成年人微妙的心态不会直接说自己饿了，而是要说别人有问题。
其实解决饿了这个问题，解决方案不一定非是做饭，想快点吃饭还可以是点外卖，出去吃饭等等。
从图中可以看出，定义问题前都需要从用户voice回溯真正问题，用户voice基本都是由已有方案/举措执行不当或不到位导致的，需要通过问题回溯到已有方案/举措，再通过已有方案/举措回溯到方案原始目的才是真正问题，需要验证已有方案是否真的是目的有效解，不能解决了半天发现还有更加有效的方案或者该方案无效，那就悲剧了。
一个问题没有回溯目标并遗漏其他方案导致重大偏差的小段子：
袋⿏逃跑的故事
动物园⾥来了⼏只可爱的袋⿏，⼀天动物园管理员发现袋⿏从笼⼦⾥跑出来了，于是开会讨论，⼀致认为是笼⼦的⾼度过低。所以他们决定将笼⼦的⾼度由原来的10⽶加⾼到20⽶。结果第⼆天他们发现袋⿏还是跑到外⾯来，所以他们⼜决定再将⾼度加⾼到30⽶。
没想到隔天居然⼜看到袋⿏全跑到外⾯，于是管理员们⼤为紧张，决定⼀不做⼆不休，将笼⼦⾼度加⾼到100⽶。
⼀天长颈⿅和⼏只袋⿏在闲聊，“你们看，这些⼈会不会再继续加⾼你们的笼⼦？”长颈⿅问。“很难说，”袋⿏说，“如果他们再继续忘记关门的话！”
然后，袋⿏进⼀步说：“就是他们把门关了也没事，地下还有⼀个洞呢，还是可以出来的。”
回溯重要的方法论就是5why法，要点：
直接原因
下一步都是上一步的直接原因，不能跳跃。
比如“需求交付速度慢-》日均合格代码产出少-》员工技能不足-》新员工数量多”，这就是一步步的直接原因展开；
而不是“需求交付速度慢-》新员工数量多”，这属于间接原因跳跃。
归并
拆分的子问题中，如果有重复的部分，要及时进行合并，防止发散。
另外还要考虑方案的约束，约束分为
可变约束
不可变约束
在可变约束下的方案才具有可行性。比如疫情期间，很多店里不能堂食，只能点外卖，那出去吃饭这个方案受疫情不可变约束，就变得不可行。
综上，很多团队成员提出的问题其实都是解决方案，都不是真正问题，需要进行通过方案回溯到问题，才能定义出问题。
上述案例中，把通过加大指导老师的投入作为快速提升员工成长的方案执行中碰到障碍当作一个问题，典型的把方案当作问题了。
找到真正问题后，才可能找到真正的杠杆解，才能最终有效彻底解决问题。
分解问题
一般问题都是多个子问题的聚合的大泥球，大泥球问题本身是很难定义和解决的，必须拆细拆小。
常用的拆分方法有：
搭建问题树
把大泥球问题按照构成分解成一个个子问题，子问题再拆分成孙问题，孙问题拆分成重孙问题。。。
这样一层层拆解下去，拆分时常见类型：
流程
比如“需求交付速度慢”，就可以拆解为
需求分析
方案设计
测试设计
代码开发
测试执行
结构
比如“项目外部协同不畅”，就可以拆解出项目的所有外部协作方
规划团队
运维团队
产品团队
平台团队
中间件
数据库
。。。
这一系列的子流程，各个子流程在整个需求交付流程中的时间占比，很容易定义出问题具体在哪一段占比较高，从而定义出问题
通过一系列的协作方，很容易找到协助不畅的具体点。从而定义出问题。
用公式思维拆解问题
研发团队的业务公式：月有效代码数=人数*人均代码*（月有效工作天数-平均bug修复时长*bug数-消耗时长（任务切换、等待、过度开发等））
有了这个公式，就可以很容易定位出部门工作效率的问题所在。
广告公司：广告收入=展现量*点击率*点击价格
煎饼摊：收入=套数*单价-面粉费-鸡蛋费-食用油-蔬菜-佐料-人工
拆解后，就很容易看出问题的焦点在哪里了。
拆分的目标
问题要拆分到什么地步才算结束呢？拆分的目标：元问题（复杂问题，掺杂了多个维度和变量），两个标准：
MECE（Mutually Exclusive Collectively Exhaustive）
拆清（正交，没有部分重复）
拆净（全部拆完，没有剩余）
原子
拆分成原子问题，所谓原子问题，有两个特征：
我们认知范围认为不能再拆的问题
超出我们的影响范围的问题（比如最近员工隔离在家办公导致无法面对面沟通是因为疫情影响，这个问题超出我们的影响）
合理预期
现状和合理预期的差距才是问题，合理预期从哪里？三看：
看业界
看同行/对手
看自己
纵向（自己的历史水平）
平均（自己历史平均水平，所在组织整体水平等）
危害&苦主
危害首先要找到苦主，只有苦主在，才能确定立场并还原细节，同时验收问题的解决效果。
现状带来了哪些危害，包括对方案执行的危害和对最终目的达成的危害，需要设立观察指标进行确认，有危害才是问题。
危害应该以形容词和副词为主，比如上述案例：以师带徒中师傅工作负荷超预期，这就不一定是个问题。只有构成了显著的痛点形成危害才成为问题。比如超预期造成了对师傅正常需求交付造成了严重冲击并影响项目整体交付，这里的“严重”才是问题的一个关键特征。
声明&量化概念
问题是现状和合理预期的差距，那合理预期、现状和目标都需要声明、量化/细化。
一、声明
需要把问题中的要素进行离散化，抽取其中的核心要素符号化并把符号进行概念定义。
其次使用模板进行定义抽象出的概念：
定义时要考虑以下要素：
中英文描述
实例化表达
生命周期
要素间关系
二、量化/细化
这些概念可以分为：
数值（数值）
枚举量（分类）
阶段量（等级）
不能量化的概念可以按等级进行描述（来自业界通用等级或自定义等级），从而实现细化。
确定目标
对确定后的过程子目标进行确定改进目标，目标要保持SMART原则，目标要考虑以下因素：
考虑时间窗
不可偏离项（资源约束）
利旧(已有方案和资源)
和目标执行方、苦主强相关（绩效、口碑等）
同一个目标，是把问题解决到80%还是解决到50%，投入的资源和方案可能完全不同，需要和干系人达成一致。
小结
文章开始时的问题定义的优化，大家可以参考下。
参考答案
其中苦主的确定非常重要，决定了：
问题的立场
精准的还原现场
解决目标的评价
苦主要一上来就确认好。
综上：
如果你要解决好一个问题，用80%的精力去拆解和定位这个问题，用20%的精力去寻找解决方案就足够了。
只有问题定义明确和深入才能有的放矢，才能定义出目标；只有问题定义的足够硬才能让相关干系人信服，让别人觉得你对比你自己觉得自己对更重要。
