机器跟人是两个不同的物种，目前，我的工作 60% 跟前者打交道，剩下的 40% 会跟「五光十色」的程序员、产品、运营、市场等打交道(总算不要跟销售打交道了)。
总的来说，机器比人好管理好沟通的多，因为机器没有欲望，你让他怎么做他就怎么做。当然如果你对他不熟悉不了解就想强上，一般情况下受伤是你自己，所以如果不想出现一些悲剧性的后果甚至是灾难性的，因此最好需要花时间去熟悉，然后再驾驭。
不管是机器还是人，最终都是服务以及被服务的关系，比如 A 机器提供 API 给 B 机器调用，这个可以看成是一个 client/server 的模型，如果 A 机器出问题了，对于 B 机器这个独立的个体来说，最坏的情况是 crash 了，更普遍的情况可能会是 stderr 或者打 log，你可以通过调查这些蛛丝马迹发现 A 「不爽」的原因。
人就不一样了，第一人有欲望(除非你信佛教)，第二众口难调，举三个亲自经历很有代表的例子:
1. 公司每天中午的饭菜，我从 11 年吃到现在，吃了三年吃腻了，有时闻到油的味道就不想入口，当然有不少跟我同等感受的同事；但是观察下来你会发现，还有一部分同事看上去吃的蛮香的，并且跟他们讨论下来，他们也觉得饭菜还不错。这个是一个典型的众口难调的例子，期望不一样，结论也不一样，这不是期望越高失望越大么。至于什么出去玩，你想去 A 地我想去 B 地的问题那就更多了。
2. 上面说的是日常生活方面的，下面说两个技术层面的，虽然跟我们的 production operations 关系不大，但是原理是相似的。
2.1. 11 年我刚去友盟的那会儿，兼职接手了当时新办公室内部网络部署的摊子，没钱没人，只能让着我们的行政小姑娘帮忙打打杂，花了半个多月的时间搞定，信心满满的给第二天要搬到新地盘办公的员工发邮件告知。后来总结起来发现这事面向的是普通观众，大部分人都是不懂 tcp/ip 的，包括众多的分不清 gateway 为何物的程序员，而我当时写的又比较的专业，设想的情况太美好不切实际，比如竟然想到通过静态 IP 而非 DHCP 的方式让每个人去访问网络，所以当时的反馈并不是很好，收到了各种各样有理的无理的回复以及善良的建议，接下来又忙活了接近了 1m，才终于解决了这个问题。后期又总结了下出现这个问题的原因:
* 技术层面也就是网络的实现部署太过理想化，所以面对的大众即使是工程师的环境，也应该使用 DHCP 而非 staic IP
* 其次，对我们的客户的信息的传递上，普通客户就应该使用普通朴素的语言，最好能 step by step 的截图告知怎么操作
* 另外一点就是在出现问题之前没有综合的考虑可能出现问题的各种情况，不然等真出现问题再考虑就有点晚了
* 非主观因素就是，你面对的是一大波的客户，那就更面临着被骂的风险，这个做运营的因该很有体会，尤其是专门维护公司 twitter、weibo 账户的同学，应该是经常能搜到客户的不满以及发泄的，所以，这事最终的结论就是自己先把份内的工作做好，先满足大部分人的要求，在时间精力允许的情况下，再去满足那一小部分人的欲望以及口味
2.2. 第二个是关于我们内部的代码托管平台 github enterprise 维护的事，这事也是我前几个月接手。然后做了两件事，第一个是把我们的 instance 升级到了最新的版本，这个完全没有影响，第二件事是出于安全的考虑，将原来的公网可访问变成了只有通过 proxy 才可以访问内网的方式。这事从技术实现上来说同样不大，换下端口改下 IP 就好了。我索性快刀斩乱麻，加上前期准备花了不到 3h 的时间搞定了所有技术层面的事情。比较麻烦的是在告知我们的客户，也就是所有的友盟员工发生了这件事的大致经过以及结果以及最重要的，对他们的影响。吸取了之前的教训，再加上处理多了这类事情之后自然就轻车熟了。所以在使用了很通俗的语言描述了访问方式变化之后，排除一些垃圾回复(完全 OT 的，自己机器原因无法访问的)得到的反馈还是很正面的。
总之，跟人打交道是门学问，尤其是服务一些吃力不讨好的对象更是如此，要解决这个问题，无外乎这几条路径:
* 尽量少动，专业术语叫少变更，不到万不得已，不要手贱去惹事，实在要做，做之前问下自己，真的要做吗？
* 准备好事后处理的艺术，正如我 2.2. 例举的那个案例一样
* 做完之后正确的区分合理不合理的反馈以及建议，对于不合理的甚至是扯蛋的反馈，有时间有心情就回复周知一下，没时间直接 mute 就好，你很难满足所有人的胃口
* 交给别人做，把自己从火坑里面解放出来，迎接下一个火坑的到来
总的来说，跟机器打交道很简单，跟人打交道相比要复杂的多，有的时候后者或许比前者重要的多。
Related Posts:
由 udpwork.com 聚合
|
评论: 0
|
要! 要! 即刻! Now!
