后端不高兴——关于协作和沟通
==================
再过两月毕业三周年，回顾一下，突然想起了一些问题，顺手记录一下
选择后端的原因之一，代码写得好一些，然后改需求的时候，刷刷刷改几行代码发布，然后泡杯茶站在前端同学后面看他们苦逼地改页面:)
工作那么久，逐渐变得“冷血”，要学会说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), (╯‵□′)╯︵┻━┻