2017可以说是付费阅读元年，这一年我花了不少钱订阅大v们的专栏、小密圈(现知识星球)等，所幸是有收获的。

最近又订阅了一个专栏，是一个特别厉害的程序媛(微信公众号「嘀嗒嘀嗒」作者)写的。

本次订阅的是「极客邦」出品的极客时间，接触这个是因为看了 池建强 老师的介绍。同时推荐一下池建强老师的公众号「MacTalk」和「极客邦」，前者我是学习 Mac 笔记本使用开始关注的，后者前身是 InfoQ 的升级版，感兴趣的可以去看下历史文章，再决定要不要关注。

再说回特别厉害的程序媛的专栏，下面是专栏目录。

这篇文章主要是对第一周专栏的简要记录。

朱赟的技术管理课第一周

1.开篇词 | 从工程师到管理者，我的思考与实践

姓名：朱赟(Angela)

现职：任职硅谷的 Airbnb，担任支付组技术经理。

教育经历：中科大少年班（体系结构和嵌入式系统研究），美国莱斯大学计算机硕士和博士（期间发表程序语言设计和生物信息学的大数据分析方面论文十余篇）。

工作经历：1.Square：第一位华人女工程师，两年时间，创业公司的锻炼机会和牛人（Google Staff级别）的指导，在支付和搜索领域成长迅速。

发自内心的热爱编程，专注于学习、科研，喜欢用代码与计算机沟通。

多年的技术积累，在「贵人」的帮助下，走向管理之路。

自己的成长过程分享出来，鼓舞同性之人。获得帮助与帮助别人。

专栏分四部分：

• 1.技术领导方面的学习领悟
• 2.技术领域内容
• 3.硅谷见闻
• 4.技术人成长中的困难和克服困难的心路历程

遇到伯乐，遇到了贵人，公司前辈也说过自己的遇贵人经历。

本篇收获：神童，轻描淡写，智商之外的专注、做事方法才是我们应该学习的。

2. 职场分身术：从给答案到做引导

作者带新人的经历，起初是快速给答案。

这样做导致两个问题：第一，在你这儿容易得到答案，愿意问你问题和各种琐事的人越来越多；第二，你给的是答案，下次有类似的问题，别人还可能来找你。

离开给答案的人，他们就不会思考了。

老板说：“你不能每次都给答案，你应该试着用引导的方式，让对方学会自己找答案。”

后来，作者会“拖一拖”再处理，或者给出一些想法。

比如“如果是我，我会尝试去看某某文档” 这样的建议，或者是“你觉得这个线上错误可能是哪些地方引起的呢？”“你有没有试着用排除法，先把那些不可能的因素排除掉？”很多时候用不了太久，对方就会很高兴地说问题找到了，或是知道该怎么做了。

作者心得：

1.首先是：什么时候适合直接给答案，什么时候适合给线索，让对方自己找答案。初代新人，可以直接给答案，因为他们还没学会自我思考；有一定经验后，可以给建议，让其自主思考寻找答案。

2.其次是：如何引导。最关键。问对方正确的问题，通过问题去引导对方进行深入思考，找到解决方案。

3.最后是：引导的好处。解决类似问题的能力提升，调动其工作积极性，解决问题的成就感，启发更好的解决方案。

本篇收获：看问题的对象，给予不同的解答方式；引导胜过直接给答案。也看人。

3.Bug引发事故，该不该追究责任？

“人非圣贤，孰能无过？”无论多么谨慎小心的技术人员，都可能生产 bug。

追究责任，会不会扣工资，会不会被开除？作者的回答是：no。

分两种极端情况说。
如果每个错误都会受到惩罚，会怎样？
如果所有的错误都没有任何追究和跟进，又会怎样？

假如每个错误都会受到惩罚，不难想象，以下情况一定难以避免。

1.大家都怕闯祸，所以风险高的事没人做，或者总是那几个靠谱的“老司机”做。没有机会处理这种复杂情况的人，永远得不到锻炼，也无法积累这样的经验。
2.如果有人搞砸了什么事情，会因为担心承担后果而推卸责任，从而尽可能掩盖错误的坏影响，不让人知道。
3.如果别人犯了错，会觉得不关自己的事。
4.指出别人的错误就会导致别人被追究责任，因此看到有问题也会犹豫要不要指出。

反之，如果无论发生什么错误，都不需要承担后果或进行反省，没有任何担当，那可能又会出现以下情况。

1.同样的错误可能会一再发生。
2.小错没有被及时制止，或者没有引起足够重视，最终导致酿成大错。
3.做事仔细的人会觉得不公平。自己为了安全起见，每次代码改动都写很多单元测试，每个项目都反复测试和预防问题；但是别人的草草而就导致错误百出，却因为显得进度更快，反而被认为更有效率。

正确的态度和措施是：

• 第一，追究责任，但不是惩罚。做好善后工作，避免重蹈覆辙。
• 第二，对事儿不对人。着重改善流程、制度，指责员工也于事无补。
• 第三，反复问“为什么”，从根本上发现问题。bug 为什么发生。找出症结所在，根除之。
• 第四，员工关系的建立也很关键。互信互助。

本篇收获：bug 事故，该追责。不可避免，但规范代码，小心谨慎，可减少 bug 出现率。

4. 每个工程师都应该了解的：A/B测试

定义：简单来说，A/B 测试是一种数据分析手段，它可以对产品特性、设计、市场、营销等方面进行受控实验。在实验中，数据样本被分到两个“桶”中，分别加以不同的控制和处理，然后对采集回来的信息进行对比分析。

原理：通过 A/B 测试，让一部分用户体验新的 程序功能，另一部分用户继续使用旧的 程序功能，再对采集回来的数据进行分析，对不同组用户在这个功能上的转化率进行比较，观察在哪一种功能下，用户更愿意往下走。有了数据分析，我们就可以判断新的设计是否改进了用户体验。

注意问题：

• 1、永远不要过分相信你的直觉。个人直觉有时候或许是错觉，多想一想，多和同事交流。
• 2、实验样本的数量和分配很重要。小样本偏差大，误导性强。样本要足够多，且两组分配的数据要公平、随机。
• 3、分析的维度尽可能全面。功能改动影响的所有指标都要测量和分析。不能只为了转化率。
• 4、其它组的改动对 A/B 测试产生的影响。避免相互影响。
• 5、比较值的趋势必须是收敛的，而不是发散的。每天采集的数据趋向收敛，最终稳定，太大波动的样本参考价值不大。
• 6、数据埋点。数据的埋点和采集是A/B测试成功的关键。如何埋，与公司代码框架有关。前端埋点采集实时数据，后段埋点采集实时事件。
• 7、形成一个流程，或者设计一个工具。流程化、工具化，让工作事半功倍。
• 8、试图给每个结果一个合理的解释。事必有因，解释不了，可能就是 bug。
• 9：必要的时候重新设计实验。设计漏洞、代码问题，需调整或重新设计。实验也需要版本控制。
• 10、不同客户端分开进行实验。Web、Android、iOS分开考察。

本篇收获：对 A/B 测试有了一个初步的认识，对产品在用户体验上的衡量又一个标准，对此进行分析，改变设计，提升用户忠诚度和转化率。而中小公司能做的少之又少，将来或可用到，先有个概念。

声明：如有侵权，请联系本人删除。