==================

再过两月毕业三周年,回顾一下,突然想起了一些问题,顺手记录一下

选择后端的原因之一,代码写得好一些,然后改需求的时候,刷刷刷改几行代码发布,然后泡杯茶站在前端同学后面看他们苦逼地改页面:)

unhappy

工作那么久,逐渐变得“冷血”,要学会说no,学会排期,学会去“降低”一些人的期望甚至是“无情”扼杀,所以或许初次合作会给人一种不“友好”的印象。

但是在“友好”和“效率”,我选择了后者,记得当初很菜很菜的时候,我还是很“友好”的。(妈蛋,一天要处理N多问题,跟运营运维产品前端测试等等沟通,还得挤时间码代码测试发布上线,只能高效至上了)

不扯了,归正题,聊一些平时沟通合作遇到的问题

PS:这里后端偏指服务端开发,当然,问题普适于各个角色


1. 问问题的方式

之前在微博看见人说过的一个现象,再次提一下

假如有人找你咨询一个问题

A: 在? (在么?/在不在?)
B: 额
A: xxx功能你知道么?
B: 知道
A: xxx有个功能有问题了,能帮看下么
B: 什么地方
A: xxxxxxxx
B: 算了你切个图过来吧
A: [图]

这个,首先,可能我在写代码,闪动弹窗对有轻微强迫症的人来说,必须要点开的啊(妈蛋),然后,我即时响应了,可能由于你有事什么的,过一会回答,但是这个等待过程中我又很那去投入一件事,很容易投入没几分钟被打断...这几句对话可能跨度是几分钟,甚至几个钟头(跑去吃了个饭回来看到消息给才给回复,哥都快忘了),其次,我真的很吝啬打那么多字>_<#

效率杀手之一

最有效率的其实是:

A: 在吗?xxx功能你知道么?现在有问题了,xxx异常,访问链接 http://xxxxxxx,截图如下
   (给力一点的还会圈起来标注说明)
B: ok,稍等我看下
.....
B: 已修复,验证下
A: 好的

感受下吧

推荐一篇文章 如何提问 | 一本书 学会提问

2. 搞明白“这事谁的问题”

当一个人发现一个问题的时候,总是很兴奋地,迫不及待想要证实

然后就会有如下

A: xxx系统是不是挂了,我登陆不上去【有时候是页面差异,系统操作失败等】

B: 稍等,我看下
三分钟后
B: 后台正常,刚才重新走了一遍流程,没问题,[切图]
   你再试下,可能xxx问题
A: 我忘改xxx/登陆超时了/xxx了/我忘记做xxx操作了

吐血的问题,很多时候,都是自己机器的问题,可能是host/网络/浏览器/系统登陆等等因素导致的,但是大多数人已发现问题,总是认为是别人的问题(系统的问题),然后迫不及待,然后,我们要花费时间来排查各个可能的问题,跳转N多机器,检查N多服务,而且,相信我,这个过程不会很有趣,而且问题本身的种类很难导致很难将其自动化....《论排查问题的复杂性》

当然,如果是可以自动化而你偏偏要每次人肉查而且乐在其中,那我没办法了。

后来就变成

A: xxx系统是不是挂了,我点发布了但是前台没更新

B: 重做一遍,10分钟后没更新通知我 【够冷血吧】

这类问题次数少也就忍了,担心的是对应人员新人进来的时候,没有老员工带或者培训,那么系统开发者往往一次又一次成为“义务培训导师”.....

另外遇到问题也要忍住证实的欲望,先自己确认下

有一本书推荐《你的灯亮着么》

3. Suprise

后端最讨厌的是suprise,安排和做事情的节奏都会被打乱。

我的原则是,不接受&unhappy,紧急的会去配合做,当然心情不会happy

方案设计,评审,开发,测试那么多环节都没发现,要上线前,需求变更或者xxx有问题,suprise

然后,上线时间有时候又是固定的,所以必须要配合处理

当然,作为一枚“有责任感”的后端,肯定都会全力配合处理,不高兴是一回事,把事情完美地搞完是一回事。

但这时候,往往会发现,时间不等人,所有人都盯着你,瞬间亚历山大,如果没搞好还很容易成为“责任人”,延期什么的很容易落到你头上,属于吃力不讨好的角色,前期按时完成,suprise却要背负所有,心里瞬间失衡(╯‵□′)╯︵┻━┻

问题是,这个suprise的来源. 才是问题所在,更多的应该反思这里,否则很容易造成后续合作困难。

另外,suprise很容易导致黑逻辑、补丁、牛皮糖、硬编码等等,将一块干净的自留地变成垃圾桶,而且破窗理论,所以,要控制。

4. 要明白一个道理

1个人1个月能干好一件事情,不代表30个人在1天能把这件事做了

很简单的一个道理,但是很容易被人忽视

5. 关于估时间

后端需要信任,虽然我们有时候估时间不大准,但是基本都能在少于估算的时间内完成,超过的情况并不多。

而且随着工作经验积累,估算时间会越来越准。(三小时就是三小时,额,上下误差几分钟)

一般问题过来,很简单顺手做了,复杂的会给个完成时间。

不要站在自己的角度去给后端的估时间,常见的理由是:“就简单加一个xxx”,“修改一下而已”等,你要知道有些系统并没有那么简单,你要的可能是一个现在能用的东西,但我们需要一个以后无论怎么改都好改而且能用的东西。(相信我,差异很大),同理,不要估工作量啊(2天的量估0.5天,要做完,那另外1.5天怎么破,哥做不到>_<)

记住,除非火烧眉毛,否则,能在承诺完成时间内搞定的,不要催。

我们需要的是冷静和清晰的思路。催促和打断于事无补。

6. 上帝,同一时间内有且仅只有一个

所有人,都认为自己的需求优先级最高。

对后端来说,合作和沟通的每个人都是上帝。

但是要记住,上帝,同一时刻内只有一个。

所以,有了优先级这一说,会排期,一次只做一件事。

再给力的后端也不是超人,一次处理N件事情效率很低容易出错,非常不明智的

所以,要学会接受排期,除非排的时间不合理要去沟通。

你会发现,在截止日期到来的前一刻,后端小伙伴的东西已经搞完提供了。

7. 合理使用项目管理工具/邮件/IM/电话

综合使用工具进行沟通

涉及项目跟踪通知等,请用项目管理工具(目前tower)

极重要事情,请邮件

极紧急事情,请当面,或者电话

其他,IM

小事,确认,疑问,突发奇想?灵机一动?等等,注意除非这个沟通有可能导致你必须要去等,否则不到万不得已不要杀过去打断一个程序员的思路。

打断是效率杀手,如果不用电话,那恕我只能定期去查,异步回复,所以就不要傻等。

8. 被开会

不重要的会议不要勾选抄送我,谢谢

冗长无聊相关性不大的会议允许早退,或者过了跟自己相关的部分允许早退

超紧急临时会议,没问题

其他临时会议,没提前发邀约提前通知的会议都是耍流氓,要知道本来用来码代码的两小时被突如其来的会议占用,打乱了计划安排,那么晚上就得花一个小时加班补回来【别问我为啥是一个小时】

9. 拿到承诺

如果有一件事,你提给后端,不说明问题,优先级,截止时间,或者,压根你就扔给后端就不管了。(被动等待会等到海枯石烂的)

然后你期望他把事情给做了,把结果给你,或者将事情跟完。很多时候,这都是你的幻想。

如果我们没做出承诺,可能这件事情就被排后了,至于完成的时间,完全与取决于工作安排和工作量。

所以,一般提给后端的时候,可以多问一句,“什么时候能搞定”,拿到承诺,一般没问题了。

10. 当面沟通时提供上下文

遇到次数不多,但是还是会遇到,干活中都是有“状态”的

有时候在做一件事情,一半

然后例如这样

A: 把xxx字段改成xxxx.... blablablabla.......

B: 啊?(脑补痴呆状)

或者这样

A: 把xxx字段改成xxxx.... blablablabla.......

B: 不合适吧,xxxxxxx.......

A: 我在说xx问题

B: 我以为你说XXX问题

其实可以这样:

A: 关于xx的问题,我们..........

你要相信,大部分后端都是善良的孩子......

而且大部分后端,一个人干N个人的活(N>=2), (╯‵□′)╯︵┻━┻