反馈问题的技巧

反馈问题的技巧

有人写过“提问的技巧”,主要是讲述提问者该如何清晰地表述提问,以达到交流上的最低成本。在软件开发过程中,我发现,不单只提问,反馈问题也存在类似的问题,不清晰的反馈问题,会导致很多时间上的内耗,不值得。

软件开发中,难免出现软件的问题(BUG),就必然存在同事之间问题反馈方式的交流了。反馈问题的人可能是测试部的,或者是用户反馈给市场部再反馈回的;接收问题的人是开发部的。

问题出现到处理完成问题,过程一般是:
1)发现问题,
2)反馈问题,
3)确认问题,
4)解决问题。

在上面的2)、3)环节上,如果没有一个很好的反馈,会做成很大的时间成本损耗。看看下面的失败的例子:

(问题反馈者为 T,问题接受者为 D,假设内部正通过 IM 群聊通信)
T:测试环境服务出问题了 。
(D 打开APP看一下,访问正常)
D:我这边没有出现,能正常访问,你那边报了什么错误?
(若干分钟后)
T:打开APP时候,出现请求 500 错误。(注:http 500,可能服务器某代码存在语法或者环境错误)
(D 继续看下 APP,也没有发现有500 错误)
D:你那边访问哪个API 请求出现500,做了什么操作?
(若干分钟后)
T:在登录的时候出现的。
(D 在去登录页面确认了问题)

上述例子,T 向 D 反馈问题时候,若干次交流确认,D 才确认了问题。作为问题反馈者,T 每次反馈都是只说现象,没有提供更多环境现象和更详细的错误信息,使得D 不断通过向T拿多次信息,审问方式多次交流才确认问题,时间成本就白白的浪费了不少。

那么怎么样方式的反馈问题,才是好的,省时的?

——一次能把问题说清。

理想的应该示这样:

T:测试环境访问时候出现了问题,登录过程出现了500 错误。我用的是华为手机,早上登录是正常的,现在登录进度转圈很久,之后失败,提示500 错误。每次必现。

(D 去确认问题)

D:收到,确认问题了。

这次,T 先描述了问题,再简述自己的环境和问题的现象。D 一次就Get 到了问题点,交流成本大大降低,处理问题也快捷了。

可以看到,反馈问题的技巧,尽力一次把问题描述清楚,而不模棱两可那种反馈,之后就是给人一种“你猜”的感觉。这样,问题接收者,就不得不多次去跟踪摸索,再咨询反馈者更多的信息了。实际中,很多反馈问题者没有很好的反馈方法,这样 T 和 D 一来一回多次确认,而且中间还可能存在时间差,这个时间消耗,是很不可观的。特别在 T 的问题如果是在用户 U 那边反馈回来带时候,这个一条链的反馈时间成本就会成倍的增加了。

作为问题反馈者,若要提高反馈问题的效率,应该尽量多地提供问题错误信息、出现问题的环境、前后操作代上下文(如果有),和重现问题的步骤等。如果T 的问题是用户U 那边的,U 可能没有一个很好的反馈问题意识,那么T 就应该尽可能地向U收集多一点的信息,再反馈给D 了。

那么,T 如何判断需要什么信息?这里有个简单的技巧,就是:

如果你是D,你希望需要拿到什么信息?

别把 D 当成你,是站在已知的位置看问题的,否则就会出现上面的审问方式的索取更多信息了。但是,T 很可能不知道D 需要什么,毕竟不是自己去解决问题。这个,只能在和D 交流工作时候,尽量多的了解D可能需要什么信息了,或者,D 尽早沟通T,如果反馈问题,自己需要什么信息。毕竟一块工作,这块得双方慢慢磨合。

(全文完)

原文链接:http://blog.yuccn.net/archives/659.html

(欢迎转载本站文章,但请注明作者和出处 云域 – Yuccn

发表评论

电子邮件地址不会被公开。 必填项已用*标注