极客时间已完结课程限时免费阅读

33 | 技术人的犯错成本

33 | 技术人的犯错成本-极客时间

33 | 技术人的犯错成本

2018-01-26 朱赟 来自北京
《朱赟的技术管理课》
课程介绍

讲述：丁婵

时长07:36大小3.48M

今天和你分享一下我和周围一些朋友在职场曾经犯过的错误，供你参考和反思。基于表述的方便，我会采用第一人称或我的同事或朋友的方式讲述，读者们无需对号入座。

错误一：所有关于公司公关层面的事都不是小事

尤其是公司规模大到一定程度，这种事情更应该小心处理。
很多技术人都喜欢分享，但是分享的过程中要避开公司公关层面内容，更多去分享自己的技术和成长体验。比如我的公众号“嘀嗒嘀嗒”里，很多读者会留言：“安姐，可以说说 Airbnb 的某某方面怎么做的。”
这其中有很多内容可以写，但更多的内容是相对敏感的，不合适在个人作者的公众号里披露出来。所以我很少在公众号写公司的事情，毕竟“嘀嗒嘀嗒”并不是 Airbnb 的官方宣传工具，而是个人创作平台。以前我曾经出过类似的问题，一不小心，就会惹出不小的麻烦。
我曾在一篇文章中提及了 Airbnb 使用的一个第三方服务，表述方式其实都算不上负面评价，只是言辞中指出了这个公司的一些产品的瑕疵，结果该公司的公关直接联系了我们公司的公关及我们组的负责人，说这样的文章对他们公司的产品有负面影响。
最终这件事的结果是我把那篇文章删除了事，但是若细究起来，我也有被辞退的可能性。一个人具备了一定的影响力，所有公开的言论都可能会被认为，你代表了公司的观点。从那以后，我就很少去写公司相关的具体事件了，就算有涉及的也会泛泛带过。
后来我开始负责 Airbnb 的官方博客，每一篇博文的发布都是要经过公关审核的，当用户量形成规模之后，每一篇正式的稿件，如果措辞模棱两可，都可能引起误读。
作为技术人，如果你在任何场合有公开演讲或者文字输出，都要谨记自己可能被默认是公司的代表。

错误二：人事变动的宣布一定要谨慎

有一次，某公司空降了一位技术经理，不过按照公司惯例，一线的技术管理岗位都是需要做大概半年的工程才能正式转岗成为管理者。
所以，虽然大家都知道：只要半年内没有大的问题，他就会成为技术经理；但是，这个任命并不是立即宣布的。结果一位不明就里的同事给全组发邮件，欢迎这位新的技术经理，事情就弄得比较尴尬，管理层也觉得流程上出了问题。
类似的事还见过几次，比如，老板还没宣布谁离组离职，某同事就在公开的邮件中就提及此事等。或者在一些群组里，把未公开的、很多人其实并不知道的人事变动透露出来，显得自己消息灵通。在职场上来说，这些都是很不专业的举动。
这么做的代价有可能会让事情变得很糟糕，你也会失去领导和伙伴的信任。

错误三：关于技术或业务问题，如果你不确定，就不要随便给答案

我有一位朋友，他的能力不算差，本人很喜欢交流和分享，就是有时候爱出点风头。因为这样的个性，他比较喜欢在自己公司的各种群里回答别人的提问。
虽然说大部分时间里他的答案都是准确的，但确实也有几次，他给出的答案是错误的，或者不完全对，不过他并没有使用不确定的语气来表示他给出的信息可能不准确。
喜爱分享和帮助别人自然没什么错，但是对自己不那么确定的答案，最好用“我觉得”“可能是”，或者“我也可能是错的，你最好验证一下”这样的措辞，否则同样会失去信任。
即使你帮助了很多人，但还是会有人觉得你不那么靠谱。长此以往，即使你的答案是确信无疑的正确，大家对你的信任也会打个折扣。
一旦涉及技术和业务，都是可丁可卯的事情，很多时候对就是对，错就是错，没有中间态。技术人处理这些问题一定要严谨，千万不要丢失自己技术上的信用分。

错误四：技术失误导致错误的产品决定

在这个技术越来越重要的时代，我们常说工程师手握几千万甚至上亿的数据资产，如果对应到支付或交易，那就是真金白银。
有人和工程师炫耀说：“我炒股每天上下几十万浮动”，工程师们就会笑笑回复：我一行代码就是千万资金，这倒也所言非虚；所以涉及交易、产品决策的技术和数据问题，都要慎之又慎，反复考量犯错的概率和成本。
举个例子，某公司在做一个大的产品决策前，用 A/B 测试来测试不同功能对用户、公司利润、数据增长的影响，最后，所有的验证结果都一边倒地偏向新特性 B。
那么，公司就投入资源和人力全力研发 B 特性，可是等到 B 特性上线后半年，工程师才发现数据实验设计中有一个参数错误， B 并不是最优选择，甚至都不是一个好的选择。
这个失误导致公司白白损失了一大笔研发费用，还有上千万的产品收入，最后，公司还需要花费很大的力气把 B 特性下线。
事实上，有时候技术人犯的错误会有很严重的后果，损失可能是一辈子的工资都赔不起的。
比如我曾经看到的一个案例，一个游戏公司的工程师手抖把公司的用户数据库删掉了，而恰恰这个数据库的自动备份由于某种原因在一个月前停掉了，最后这个公司真的就倒闭了。从删库到跑路，并不是传说中的故事。
这一期，我和你聊了聊技术人可能会犯的各式各样的错误，那么说，把错误拎出来单独谈，目的是什么呢？
我想，错误告诉我们两个重要的事情就是：第一要去试错；第二要从错误中成长。
在工作中，很多公司都会鼓励试错，鼓励多尝试，但某些时候，工程师们的错误成本是很大的。这些错误可能会引起比较大的麻烦或损失，也可能会让我们失去信用和机会。
这并不是说我们要裹足不前，什么都不做，而是去认清我们犯错的成本，知道我们可能会犯什么错误，避免去犯致命的错误。
在下一篇文章，我会介绍一种关于错误的分类法，以及技术人如何从错误中成长，如何避免犯没有价值的错误。
你在工作中有什么样的错误或教训呢，可以在留言里告诉我，我们一起从错误中成长。感谢你的收听，我们下期再见。
分享给需要的人，Ta购买本课程，你将得18元
生成海报并分享

赞 8

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
32 | 硅谷人如何做 Code Review
下一篇
34 | 如何从错误中成长？
 写留言

精选留言(14)

  • 缪文
    2018-08-04
    在淘宝工作时，曾因一行代码错误，导致百万商品下架，数十万商家被处罚，甚至关店。
    27
  • 程序猿爸爸
    2018-01-26
    刚入IT行业没多久，在公司因为业务部门需要，我第一次手动执行一个存储过程，使用toad工具的时候，准备点击Execute Procedure的时候手一抖点成上面的Drop Procedure。紧接着惯性思维都是点击确定....然后，一个6000多行的procedure被我完美的删除了..然而数据库备份查找那时我根本不懂，只能去向领导请罪，寻求解决办法，至今难忘。
    10
  • Grapef
    2018-01-27
    这篇总结得太好 所有的这些我都有亲身经历 作者能总结出来告诉新人和次新人太好了 等发生问题再总结往往太晚了

    池建强回复: 专栏的目的就在于此

    5
  • GeekAmI
    2018-01-26
    曾经犯过把测试代码推到了线上
    5
  • songyy
    2018-01-26
    刚入职一家支付公司时 负责了写meeting minutes (会议记录)。当时顺手写: “xx这个模块的设计，是由yy说了算的。我们要在会议之后询问一下yy的意见”，并在会后发送给了与会人员。 刚发完，一个很有经验的员工就紧张的跑来找我，说zz和yy是平级的，这里不能够说什么东西是由yy说了算的。 当时感觉的确是自己不小心了，但是这家公司的politics好严重啊。。不知道大家怎么看 😂
    展开
    4
  • Alexis何春光
    2018-12-26
    看到songyy的留言，个人不觉得这是politics中的表现，反而是professional的表现，尊重每一个人的职位和角色。
    3
  • Danny.zhu
    2018-01-26
    最近犯了两个错误： 一个是在向公司内部sales分享信息时把一个internal服务说成public facing。对public facing理解错了。经理用upper case纠正了这个信息，心里那个汗啊。 第二件学到的是回邮件要看收件人角色。我在中途被拉入一封邮件做support，花了几分钟浏览上下文后回了封技术邮件给提问的人，经理补了一封说这个邮件suppose to给另一个人。在当时还纳闷为什么，后来仔细一看，发邮件的人是个经理，另一个人应该是真正做代码过的人。事后悄悄给经理发了个感谢：）
    展开

    池建强回复: 处理的很好，这篇文章该早读到

    3
  • self-discipline
    2018-07-25
    有一次都说我把测试库给删了,但是我查看我的本地历史记录就没有删库的,最后不了了之的,我把我本地客户端的sql记录，若干天的都找出来了,是我的责任我不推脱,不是我的锅，我也不背
    1
  • 怀揣梦想的学渣
    2022-03-20
    自从见到各种删数据的案例，无论是操作Linux下配置文件，还是动数据库，我第一个事情就先确认备份，没备份的完全不敢操作。如果数据持有人同意我无备份操作，我也得拿到邮件回复才操作。现在这种备份优先的原则已经是公司内的规范流程，严格写入所有的变更方案。
  • dao
    2020-12-22
    实用，反复读。
  • 何慧成
    2020-09-05
    多想想蝴蝶效应，多想想牛家庄的假设，就会对设计、代码和测试肃然起敬了
  • mikejiang
    2019-12-03
    犯错成本大小并不会防止出错，能做的就是小心谨慎，发布多检查，灰度发布，sql语句执行必须提前准备好，禁止临时写sql. 大部分时间是要用只读账户登录
  • AlphaGao
    2019-07-18
    我两次格式化了公司的公共资源盘，都是自己买数据恢复软件恢复的...
  • yiluo
    2018-07-17
    第一次认识到DBA的作用就是错删了一个数据库（还好不是线上的，但是开发在用，重建很麻烦），DBA根据其他的文件和log把数据库恢复了。