写给新人的沟通建议

最近也碰上抄袭的号, 转了我几年前两个文章, 只改了标题, 然后删掉每篇文章中我个人的一两段吐槽, 然后发出来. 抄袭当原创, 然后在评论里以作者的角度回复别人, 看着有点恶心. 这种成本还是太低了, 举报两次, 知乎给删掉了, 但是对于我来说还是很不爽的, 举报的成本太高了, 来一篇举报一篇. 这个号下面的文章(入口), 目测都是直接用别人的文章改个标题了事.


很多年前写过一篇在自己博客里面, 后端不高兴——关于协作和沟通, 做后端的同学可以看看吐槽哈.

工作也好多年了, 前前后后跟不少新人合作过, 实际合作中不免各种问题, 都是从新人过来的, 所以打算写一些点, 算是一些感受吧

关于问题描述

好像之前有人也讲过.

不要发: hi, 在吗, 你可能会发现过了很久对方回复:, 然后你可能也没立即接下一句, 晚一会回复:xxxx问题, 然后对方又隔了很长一段时间才回….如此来来往往, 一次沟通跨度从一两个小时到好几天

一般新人会觉得心累, 有点玻璃心的会觉得委屈, 如果事情紧急, 光自己干着急了.

其实老鸟也很累, 一般事情比较多, 各种事情混在一起, 面对这种类型沟通, 无法获取足够多的信息, 自然无法快速解决. 其实心里也想事情快速处理掉.

这种有点类似打乒乓球的沟通方式是不对的. 每次没有提供足够的信息, 而又期待对方快速反馈, 然而每个人都有自己忙碌的事情, 势必导致这类沟通十分之低效.

正确的沟通方式应该是: 倾倒式的沟通.

hi xxxx:
我是xxxxx
目前遇到一个问题
现象
数据
结果

这个问题是xxxxxx?

而对方在看到你的消息后, 一次性就可以全面了解你的问题, 了然于胸, 很快就能解决问题.

而区别是: 一次传达的有效信息量.

如何问题

建议不管是新手还是老鸟, 都读一读 提问的智慧

实际上, 有些时候某些问题看起来十分的无奈

- 系统挂了       -- 一脸懵逼, 什么系统
- 接口返回错误   -- excuse me? 哪个接口? 给的参数是? 返回结果/状态码是?
- 页面有点问题   -- 哪个页面? 什么问题?

......

很是无奈, 很多问题看起来言简意赅, 但是蛋疼的也是这个, 缺乏信息量, 缺乏对问题的准确描述, 往往站在信息接收人的角度是: 一脸懵逼. 然后, 就开始来来往往的沟通

所以: 如何准确描述问题, 算是提问的基本要求了

基础问题不要问

基础问题, 例如某些库的方法/参数, http状态码, 某个异常堆栈信息.

很多时候, 拿这类问题去问别人, 是十分低效且有害的!

因为: 这个时代, 搜索引擎这么强大, 技术资料如此丰富, 各类社区如此多前人踩坑, 团队的wiki如此完善, 你还拿一个如此基础的问题去问别人, 似乎说不过去吧.

只要是搜索引擎能回答的就别问别人……

也不是说不能问, 但是前提是, 自己搜索无果, 无法解决的情况下.(google, 且会基本搜索技巧)

这类问题, 看起来很简单是吧, 对其他人也许也就一句话的事情, 但是, 这样造成不好的结果是, 对方被你打断了! 无论多短暂, 都是打断, 断点-思考-回答-回到断点.

因为回答你一个本可以自己解决的问题, 而手头正在做的事情被打断.

而这个, 对效率影响是非常大的.

所以, 忠告: 不要把同事当做搜索引擎, 尊重对方.

遇到问题, 先从自己查起

很多人遇到问题后, 第一意识是, 我的代码是ok的, 你的接口有问题.

然后, 直接抛给对方(对方大写懵逼)

而此时, 对方心里肯定第一意识也是: 我的代码是ok的, 一定不是我的问题. 此时心态上会有些变化, 然后去确认接口是不是有问题, 如果有问题也就罢了, 没问题会反向再反馈回来, 自己排查.

而很多时候, 要么没看文档, 没配host, 配错host, 环境不对, 没有遵循协议, 参数传错等等一系列自己代码的低级错误导致的.

也许这都是小事, 但当次数多了, 而大多数问题不是对方问题时, 你的信誉点已经降到了最低, 你的任何问题反馈, 无形中会被降级.

想象一下, 有人说你接口有问题, 然后你确认服务没问题(几分钟), 找对方要参数数据复现没问题(十几分钟), 然后到对方电脑查问题(几分钟), 一折腾半个多小时没了. 最后发现是一个低级问题(例如没配host), 你心里…..

所以, 先确认错误, 排查下是否是自己的问题

不要胡乱猜测, 拿数据说话

接上个问题, 当你认为别人系统有问题时, 请拿数据说话. 当别人认为你系统有问题的时候, 请对方提供数据.

发现自己在跟人沟通时, 问的最多的问题是: 把调用的接口/参数/返回值/状态码/日志等等, 发给我, 谢谢.

发现有问题, 不要猜, 代码是确定的, 查就是了.

当看到报错, 从上往下查, 一层层向下跟踪, 确认输入/输出/异常/状态码等. 学会追踪调用是必备技能.

有足够的数据才能断定是哪的问题

如果是自己的问题, 修正.

如果是别人的问题, 拿着数据, 也方便别人定位问题.

特别忌讳的是: 没有数据的情况下, 猜测, 然后把问题抛出去了, 会造成组织效率低下, 可能你一个小小猜测, 花费别人很多时间. 每个人的时间都需要尊重.

该问就问, 不要害怕打断

基于上面的几点, 假设问题自己没法解决, 需要求助, 那就求助吧.

不要害怕打扰别人, 一般程序员都很nice, 有问题, 把问题准备好, 精确描述, 自己的尝试, 目前遇到的点等等, 将信息汇聚, 一次性问, 然后直接去问.

紧急请当面, 次紧急用电话, 不大紧急, 可以用IM 工具, 对方实在忙, 可以先约个时间.

小结

学会基本的沟通技巧, 善用之, 同时, 尊重他人的时间, 他人也会尊重你的时间.


blabla

2122 Words

2017-04-09 08:00 +0800