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

软件开发中，难免出现软件的问题（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，如果反馈问题，自己需要什么信息。毕竟一块工作，这块得双方慢慢磨合。

（全文完）

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