77 lines
6.8 KiB
Markdown
77 lines
6.8 KiB
Markdown
|
||
|
||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||
|
||
|
||
33 技术人的犯错成本
|
||
今天和你分享一下我和周围一些朋友在职场曾经犯过的错误，供你参考和反思。基于表述的方便，我会采用第一人称或我的同事或朋友的方式讲述，读者们无需对号入座。
|
||
|
||
错误一：所有关于公司公关层面的事都不是小事
|
||
|
||
尤其是公司规模大到一定程度，这种事情更应该小心处理。
|
||
|
||
很多技术人都喜欢分享，但是分享的过程中要避开公司公关层面内容，更多去分享自己的技术和成长体验。比如我的公众号“嘀嗒嘀嗒”里，很多读者会留言：“安姐，可以说说 Airbnb 的某某方面怎么做的。”
|
||
|
||
这其中有很多内容可以写，但更多的内容是相对敏感的，不合适在个人作者的公众号里披露出来。所以我很少在公众号写公司的事情，毕竟“嘀嗒嘀嗒”并不是 Airbnb 的官方宣传工具，而是个人创作平台。以前我曾经出过类似的问题，一不小心，就会惹出不小的麻烦。
|
||
|
||
我曾在一篇文章中提及了 Airbnb 使用的一个第三方服务，表述方式其实都算不上负面评价，只是言辞中指出了这个公司的一些产品的瑕疵，结果该公司的公关直接联系了我们公司的公关及我们组的负责人，说这样的文章对他们公司的产品有负面影响。
|
||
|
||
最终这件事的结果是我把那篇文章删除了事，但是若细究起来，我也有被辞退的可能性。一个人具备了一定的影响力，所有公开的言论都可能会被认为，你代表了公司的观点。从那以后，我就很少去写公司相关的具体事件了，就算有涉及的也会泛泛带过。
|
||
|
||
后来我开始负责 Airbnb 的官方博客，每一篇博文的发布都是要经过公关审核的，当用户量形成规模之后，每一篇正式的稿件，如果措辞模棱两可，都可能引起误读。
|
||
|
||
作为技术人，如果你在任何场合有公开演讲或者文字输出，都要谨记自己可能被默认是公司的代表。
|
||
|
||
错误二：人事变动的宣布一定要谨慎
|
||
|
||
有一次，某公司空降了一位技术经理，不过按照公司惯例，一线的技术管理岗位都是需要做大概半年的工程才能正式转岗成为管理者。
|
||
|
||
所以，虽然大家都知道：只要半年内没有大的问题，他就会成为技术经理；但是，这个任命并不是立即宣布的。结果一位不明就里的同事给全组发邮件，欢迎这位新的技术经理，事情就弄得比较尴尬，管理层也觉得流程上出了问题。
|
||
|
||
类似的事还见过几次，比如，老板还没宣布谁离组离职，某同事就在公开的邮件中就提及此事等。或者在一些群组里，把未公开的、很多人其实并不知道的人事变动透露出来，显得自己消息灵通。在职场上来说，这些都是很不专业的举动。
|
||
|
||
这么做的代价有可能会让事情变得很糟糕，你也会失去领导和伙伴的信任。
|
||
|
||
错误三：关于技术或业务问题，如果你不确定，就不要随便给答案
|
||
|
||
我有一位朋友，他的能力不算差，本人很喜欢交流和分享，就是有时候爱出点风头。因为这样的个性，他比较喜欢在自己公司的各种群里回答别人的提问。
|
||
|
||
虽然说大部分时间里他的答案都是准确的，但确实也有几次，他给出的答案是错误的，或者不完全对，不过他并没有使用不确定的语气来表示他给出的信息可能不准确。
|
||
|
||
喜爱分享和帮助别人自然没什么错，但是对自己不那么确定的答案，最好用“我觉得”“可能是”，或者“我也可能是错的，你最好验证一下”这样的措辞，否则同样会失去信任。
|
||
|
||
即使你帮助了很多人，但还是会有人觉得你不那么靠谱。长此以往，即使你的答案是确信无疑的正确，大家对你的信任也会打个折扣。
|
||
|
||
一旦涉及技术和业务，都是可丁可卯的事情，很多时候对就是对，错就是错，没有中间态。技术人处理这些问题一定要严谨，千万不要丢失自己技术上的信用分。
|
||
|
||
错误四：技术失误导致错误的产品决定
|
||
|
||
在这个技术越来越重要的时代，我们常说工程师手握几千万甚至上亿的数据资产，如果对应到支付或交易，那就是真金白银。
|
||
|
||
有人和工程师炫耀说：“我炒股每天上下几十万浮动”，工程师们就会笑笑回复：我一行代码就是千万资金，这倒也所言非虚；所以涉及交易、产品决策的技术和数据问题，都要慎之又慎，反复考量犯错的概率和成本。
|
||
|
||
举个例子，某公司在做一个大的产品决策前，用 A/B 测试来测试不同功能对用户、公司利润、数据增长的影响，最后，所有的验证结果都一边倒地偏向新特性 B。
|
||
|
||
那么，公司就投入资源和人力全力研发 B 特性，可是等到 B 特性上线后半年，工程师才发现数据实验设计中有一个参数错误， B 并不是最优选择，甚至都不是一个好的选择。
|
||
|
||
这个失误导致公司白白损失了一大笔研发费用，还有上千万的产品收入，最后，公司还需要花费很大的力气把 B 特性下线。
|
||
|
||
事实上，有时候技术人犯的错误会有很严重的后果，损失可能是一辈子的工资都赔不起的。
|
||
|
||
比如我曾经看到的一个案例，一个游戏公司的工程师手抖把公司的用户数据库删掉了，而恰恰这个数据库的自动备份由于某种原因在一个月前停掉了，最后这个公司真的就倒闭了。从删库到跑路，并不是传说中的故事。
|
||
|
||
这一期，我和你聊了聊技术人可能会犯的各式各样的错误，那么说，把错误拎出来单独谈，目的是什么呢？
|
||
|
||
我想，错误告诉我们两个重要的事情就是：第一要去试错；第二要从错误中成长。
|
||
|
||
在工作中，很多公司都会鼓励试错，鼓励多尝试，但某些时候，工程师们的错误成本是很大的。这些错误可能会引起比较大的麻烦或损失，也可能会让我们失去信用和机会。
|
||
|
||
这并不是说我们要裹足不前，什么都不做，而是去认清我们犯错的成本，知道我们可能会犯什么错误，避免去犯致命的错误。
|
||
|
||
在下一篇文章，我会介绍一种关于错误的分类法，以及技术人如何从错误中成长，如何避免犯没有价值的错误。
|
||
|
||
你在工作中有什么样的错误或教训呢，可以在留言里告诉我，我们一起从错误中成长。感谢你的收听，我们下期再见。
|
||
|
||
|
||
|
||
|