正确地表述问题

(Asking Right Questions)


《商略》这本小说里有一段:

负责研发万门程控的总头目武锐锋策划的一个“百夫长行动”,把几百名研发人员分为26个队伍,A 队负责预研、B~Y 队负责研发、Z 队是个“救火队”,哪个队有了疑难问题就找 Z 队请求支援。

开发的战役一拉响,各个队伍就“被问题的猛烈炮火,压迫在出发阵地,根本无法实施有效的进攻”,武锐锋把26个队的头目召集起来,开始了下面的一段别开生面的训话:

武锐锋进来后,照例没有开场白,就直截了当地训起话来:“今天开始编程,很多团队提出不知从何下手,”武锐锋这么一说,下面不少领队都频频点头,他一看这情况更加生气,“温亚杰是老实人,你们一提这样的问题,他就派人去协助分析。不过,这算什么狗屁问题!这样又怎么能解决问题?!”

除了戴明伦,武锐锋的这帮心腹大将,都被他的这顿怒骂震得目瞪口呆。“我问你们,”武锐锋却毫不顾忌他们的情绪,继续吼叫,“如果我烧了一桌饭菜,请你们来吃,你们会提什么问题?”吼到这里,武锐锋知道下面无人敢于回答,就放缓了口气:“你们一定会嚷嚷,‘肉太老了’、‘菜太咸了’、‘饭夹生了’、‘没有碗筷’了,等等等等,是不是?你们吵的这些问题,都有什么特点?啊,你们自己说说,有什么特点?!”武锐锋边说,两只眼睛边亮闪闪地扫视着会场,他那帮大将都被他的气势所震慑,居然没人敢接口。“这些问题的特点,就是具体而客观。有人说:正确地提出问题,就等于解决了问题的一半。这句话我觉得不一定完全对,但倒过来说,一定是对的:没有正确地提出问题,根本无法解决问题!你们说不知道从何下手,到底是没有设计思路?还是不知道设置参数?甚至是不知道编写语句?

“没有设计思路?我们可以坐下来确定。不知道设置参数?把技术规范多研究几遍。不知道编写语句?如果你们提这样弱智的问题,那我倒要看看,你们还会不会吃饭!”

一顿吼完,武锐锋又语重心长地说道:“你们这些家伙啊,把问题报上来前,先仔细动动脑筋,尽量把问题提得具体些,深入些,老这么不过脑子,笼统地提问题,不得把大家都累死。”

趁着武锐锋停顿的间隙,戴明伦发言,他说话的口气温和而有力:“任务很紧,压力非常大,武总讲得很正确,我看我们散会以后,是不是制定一个‘问题规范’,确定一下,究竟什么是问题,遇到问题应该如何思考,哪些问题需要提请支援团队协助,这样可以更有效率些。”

“呵呵,到底姜还是老的辣,戴总高明。不过不用等到散会,我们现在马上制定这个规范。”

散会后不到几分钟,各团队都通过内部网络收到了《问题规范》。自此,各研发团队的思考能力,被强制纳入了研发管理流程,万门程控的编程工作,终于被艰难地一步步推进起来。

 

学会正确的表述问题、学会问正确的问题,是测试人员的基本技能之一。我在STB(Software Testing Basics)公益测试课程第一讲中提到,测试的本质是“沟通”的问题,而正确的描述问题,是解决问题的第一步。

 

举几个例子。

 

昨日收到一个tester的邮件,简短的自我介绍后,只有一句话“特向您咨询有关自动化培训方面的信息”,我很希望能够帮助她,但完全不知道她的问题所在,是她想从事自动化培训的工作、还是她希望了解自动化培训的行情,还是她希望学习自动化培训的知识等等。

 

MiniStarClub的QQ群昨日也有一网友发问“各位,谁有好的测试WEB的方法啊,告诉我下”,这样的提问又暗示着无数种可能了,是测试PC互联网、还是移动互联网?是功能测试还是性能/安全/易用性等非功能测试?是手工测试还是自动化测试?是测试设计方面的问题还是测试执行方面的问题?

 

记得以前引导某team开敏捷的站会,每个成员要陈述三个问题:昨天做了什么、今天打算做什么、遇到什么困难。其中,这第三个“困难”总是感觉大家说不好,“进度可能有点紧”、“估计今天完成有点困难”,这样的表述问题的方法,你的队友包括你的主管都感觉无法给予你有效的帮助。一次站会结束后,我问负责记录“待跟踪问题或风险”的人员,都记录了哪些风险?他说只记录了两个,实际上大部分人都说了些自己遇到的风险,可惜由于表述的模糊,都没有被记录在案。

 

我在使用T-RCA方法,引导团队分析缺陷的根因时,首先第一步要知道问题是什么,这时需要正确的描述缺陷、完整的认识缺陷本身,然后才能正确的分析导致缺陷产生的根因。当我问“问题是什么?”就会有人开始描述问题:“XX模块有一个事件丢失了。当开发第一次定位这个问题的时候。。。”我赶紧打住他:“先别急探究问题的原因,让我们先了解清楚问题本身。”也许有些人会认为,因为我是局外人,自然不是很了解他们的问题,这个team的每个人都了解问题是什么了。多次实践证明,其实不是这样的,经常的情况是,包括问题提交人、问题定位人等相关人,都不是十分准确地了解问题的全貌。证实这一点,你只要从你们的缺陷库中挑选一个缺陷,然后,去询问相关人员如下的问题:“请帮我描述一下这个问题?”“在什么情况下这个问题会被触发?”“触发这个问题,还有没有其他的条件?真的没有了吗?再想一想。”“在这些条件下,用户需要做哪些操作,会直接导致问题的产生?”“问题发生后,具体的现象有哪些?”“这个问题会导致的后果是什么?对最终用户的影响是什么?”你就会发现被提问者经常不知道答案是什么,这时现场往往陷入一片争论之中,因为大家此时才发现原来每个人对这个问题的理解是那么的不同。

 

对于那些经常过早地结束对问题本身的描述或探究、而急于去寻找解决问题的办法或寻求改进的措施的人,下面这几句话也许可以帮助您在认识问题上放慢些脚步:

找到问题才有改进的可能;

不,找到真正的问题才能改进;

不,找到真正问题背后的问题才能改进。


Comment Box is loading comments...