帮团队发个招聘信息。

豆包输入法在 11 月底正式对外发布，目前获得了不错的口碑。产品正在快速迭代中，目前有一些岗位需求开放，订阅本公众号的朋友里有没有感兴趣的朋友呢？如果身边有朋友在看机会，也欢迎帮介绍一下。招聘的需求具体见以下一览图。不了解豆包输入法的朋友，可以在应用商店下载体验一下。

感兴趣的朋友，可以给 HR 直接发信息，也可以加我微信了解更多岗位信息（微信：shunpingye)。

阅读原文

跳转微信打开

第一次参与翻译技术书籍，聊聊其中的苦乐与收获

大概三年前，本人参与了一本技术书籍的翻译，书籍是《The Design and Implementation of the FreeBSD Operating System (2nd Edition)》，中文名为《FreeBSD操作系统设计与实现（第二版）》。19年那会我主要精力在做车载语音交互，花了很多时间做离线语音交互系统的性能优化，那段时间集中看了一些计算机体系结构的书籍，比如《计算机体系结构》这本书。

操作系统的书籍从本科开始就买过很多，当时看到《FreeBSD操作系统设计与实现》这本书，第一版有中文版本，但是第二版只有英文版，所以就买了一本英文版看。看完感兴趣的章节后，觉得受益不小，因此在朋友圈中推荐了下这本书。

这本书和大部分源码分析的内核书籍不同，这本书更强调的是“设计与实现”，其中的实现也是high level的，而不是具体代码层面的。说实话，有经验的工程师更需要的是问题分析，解决思路的选择和工程上做的折衷方案，而不是各种代码细节。原因在于，解决思路有了，对有经验的工程师而言，怎么实现都是苦力活罢了。本书搭配Hennessy大佬的《计算机体系结构：量化研究方法》，熟悉一下软硬件接口，以及硬件层面的性能改进技术，基本上内核代码怎么实现就没太大必要知道了。尤其对应用开发工程师而言(用户态程序开发者)，对内核的实现细节做到如数家珍帮助不一定很大，反而熟悉内核的设计思路，背后的软件工程思想，知道What和Why，可能对日常工作更有帮助。

下面摘抄几条网上对这本书的评价，供大家参考：

The content of the book is highly technical and is dense in operating system concepts. It is written with an excellent academic style.

Compared to others classic "Internals" books, it focuses more on the design and algorithmic concepts and less on the specific detailed structures of the FreeBSD kernel.

The design and implementation of the FreeBSD operating system book fits perfectly for an advanced operating system course, due to the academic style of presentation and to the fact that it covers new contemporary topics, as for example the ZFS file system, and an elaborate presentation of the networking architecture.

Outstanding technical writing. Somehow the authors manage to make dense technical topics readable. A worthwhile update of the previous version. For example, chapter 10 has an excellent description of ZFS in about 25 pages -- a monumental change to FreeBSD involving an extra 250,000 lines of code.

Many technical books focus on "how". There are plenty of excellent biographical accounts of teams or individuals -- the "who". This book focuses more on the "what" and, more importantly, the "why". Not everyone needs to have this depth of understanding, but when you've hit a plateau in understanding infrastructure, this book will definitely help you "level up". Even if you're not a big user of FreeBSD there is a ton of useful information about a wide variety of topics relevant to other Unix/Linux systems, networking, storage, and even Windows.

当时发了这条朋友圈后，北大师兄郭立峰刚好看到，就说他也许可以联系下出版社，看看是否有机会一起翻译下。当时郭师兄已经出版过一本操作系统方面的书籍，也参与翻译过一本操作系统内核书籍。之后几天，郭师兄和北大的陈向群教授联系了下，因此促成了这次翻译。

翻译大概花了半年左右的时间，我负责5，6，13，14四个章节，涉及安全、存储管理和网络协议等话题。不过成书在2021年11月才由机械工业出版社出版。下面是翻译版本的链接，有兴趣的朋友可以买来看看。不过英文好的话，还是推荐买本英文书。虽然我们也花了一些时间消化书籍，以尽可能翻译准确，不过毕竟我不像其他两位译者，本身并不是专业从事操作系统研发的，翻译不当之处应该不少。

言归正传，本文来简单聊聊我第一次参与技术书籍翻译的体验，尤其是翻译的困难之处。

平时很多书籍我都会买英文版，或者是中英文两个版本都买回来，优先看中文版，主要是阅读中文的速度更快。遇到中文看不太明白的地方，也会看看英文，增强理解。阅读的时候使用英文书，虽然没有太大的压力，但是往往阅读过程“不求甚解”，尤其是复杂的句子，扫一眼，大概理解理解就过了。实际真正翻译起来的时候，往往就有捉襟见肘的感觉。之前简单翻译了几篇短文，感觉还没那么强烈，比如之前我曾经翻译过jemalloc 的文章《【译】使用jemalloc实现可扩展的内存分配》，整体翻译过程还算顺畅，这次要翻译点操作系统内核的章节，处处抓襟见肘。难点有几个:

1，没有吃透原文很难翻译好。一般读书都是囫囵吞枣，或者挑点自己感兴趣的话题和章节，有选择性地阅读和吸收。翻译工作却不行，哪里没搞明白，翻译得好不好自己心知肚明。也就是说，阅读的时候，往往是选择工作中经常接触的章节进行学习，因为相关性比较高。而那些不太相关的章节，往往选择性略过，或者只是泛泛而读，毕竟不像学生时代，为了应付考试不能错过任何一个知识点，因此也就谈不上深刻理解。而翻译自己不擅长的方向，所能做的只有保持学习心态，不要半桶水就上，见笑方家。但是翻译毕竟不是正经工作，无法投入太多时间去“切磋琢磨”，毕竟翻译在国内基本没什么回报，不过是“重在参与”罢了。

2，一些英文句子语法结构复杂。技术英文本来单词量比较少，单词和术语成为拦路虎的概率倒是不高，奈何经常见到巨复杂的语法结构，翻译起来直让人抓耳挠腮。要翻译为简单通顺的中文，实在是需要反复推敲琢磨，先拆散再重构。FreeBSD这本书里，有相当比例的句子，语法结构复杂，让我初读下来费解。有一些地方我参考了第一版的翻译，但是第一版的翻译质量远非尽善尽美，看着他人的译稿，反而更懵了。不过有时候推敲一两遍，整明白了作者想表达的意思并使用流畅的中文翻译出来后，确实有“哦，原来如此”，“啊，终于这里不会再误导读者了”的兴奋时刻。

3，中英术语的关系不容易处理。偶尔插入一些英文术语，留而不译，这固然很精准，但是读起来毕竟文气差了一些。之前阅读侯捷的很多技术翻译书，虽然觉得他的翻译精准，但是英文单词满篇都是，总觉得阅读下来不够酣畅，至少英文夹杂过多，看起来不太像地道的中文书。搜索网上信息，经常能看到讨论某个术语的翻译，很多讨论者都心有戚戚。不过很多术语，其实业界并没有通行的翻译，而是每个高校的教材或者每本译作都有自己的处理。有时候某个术语翻译成A版本，虽然也能理解，但是如果和业界的通行翻译不同，就会加大分歧。比如在翻译信息安全相关章节的时候，我就参考了FreeBSD中文社区的术语，尽可能和社区的翻译趋同。

一些技术术语的翻译实在是磨人心性。好的时候，可能有翻译先例在前，但是经常有不尽如人意的情况。不幸的时候，Google搜索半天也找不到翻译先例，只能推敲琢磨一翻，硬着头皮自己上。这种创造性的翻译，就更加没底了，有时候会出现这样的情况：翻着成这个词也行，那个词也不赖，但是好像都缺点儿意思。

4，有些章节篇幅虽然不大，信息量却大得吓人。比如信息安全部分，虽然我本科和研究生的专业都是信息安全，不过翻译起内核中信息安全相关章节，也是被逼得抓破脑袋，只好做各种补课工作。下面是本书安全相关的章节目录，基本上囊括了操作系统中所有的安全话题，从安全模型，到Jails、安全审计，到磁盘加密等，不一而足。

Chapter 

5. Security

5.1 Operating-System Security 

5.2Security Model 

5.3 Process Credentials 

5.4 Users and Groups 

5.5 Privilege Model

5.6 Interprocess Access Control 

5.7 Discretionary Access Control

5.8 Capsicum Capability Model

5.9 Jails 

5.10 Mandatory Access-Control Framework

5.11 Security Event Auditing

5.12 Cryptographic Services

5.13 GELI Full-Disk Encryption

5，脱离代码的文字，很难精准理解。因为本书是“设计与实现”，而不是仅仅停留在“操作系统概念”上，所以其实很多篇幅是和实现相关的。但是阅读代码又谈何容易。内核代码大几百万行，甚至千万行规模，要快速检索到书中文字对应的代码文件、数据结构、函数实现，绝非易事。更何况，还需要读懂代码，并和书籍内容相互参考。这块我并不能做到熟读代码，没那个精力，也不一定有那个能力。翻译过程中，我倒是花了一定的时间，翻阅FreeBSD的在线文档，查看一些函数对应的接口说明，甚至了解大概的实现，以搞明白这个函数大致的作用。在线文档的地址：https://docs.freebsd.org/en/

最后说一下参与翻译的几点心得：

1，翻译过程是忐忑不安的。虽然本书有第一版译作可供参考，但是第二版相比第一版做了大量的更新，有好几个章节甚至是全新的。另外，第一版并不算非常出色的译作，参考价值有限。作为翻译方面的新人，担心自己的翻译质量不行，祸害读者。

2，有时候看到上个版本的翻译里出现了一些对原作的误解，我以为自己掌握了“真理”，应该能准确翻译过来，就会有“哈，我真是原作者的解语人”的激动一刻。有时候之前的翻译句子桀骜不驯，难以理解，语法复杂度堪比英文原文，而我的翻译版本则简短而不失晓畅，这时候就放佛给自己之前写过的文章进行“改头换面”，以“重新做人”，有了很大的快感。

3，有时候一时半会无法理解原文，总觉得自己的翻译很膈应，这时候参考第一版翻译，觉得人家的理解挺到位的，就会觉得很汗颜，心中感叹，“哎，差点又要误人子弟了”。“三人行必有我师焉”，孔夫子诚不我欺也。人和人之间的理解本就是困难的，面对面都如此，何况面对冷冰冰的异国文字，存在理解上的偏差在所难免。

4，在中国，写作和翻译技术书籍回报是真的差。一些知名的书籍，其实翻译都是行业外的人士，或者是在校的学生。只有部分极其顶尖的书籍，才有技术作家愿意花时间翻译。还是挺佩服《计算机程序设计艺术》这类书籍的翻译的，没有一定功力翻译不了这样的书籍，并且需要长期坐冷板凳的功力。但是这样的书籍，如果出现一些较为明显的错译，又比较容易被吐槽。总之，在中国搞翻译，很容易出现这样的局面：翻译者觉得自己是“为爱发电”，而读者可能会觉得翻译者“为了恰饭，连脸都不要了”。这和职场是一样的，很多时候员工觉得呆在公司是为公司在牺牲（考虑外部机会的机会成本），而老板们却觉得员工拿着高薪不干事，两相受气。

5，有幸参与翻译，也算是一次奇特的体验。自己写文章，随便怎么写都行，信笔由缰，我的文章我说了算。翻译这个东西则是“带着镣铐跳舞”，要怎么做到“信达雅”，则是对个人的磨练。

第一次参与翻译，错漏在所难免，希望读者能够谅解。当然，这个译本对阅读该作应该是有一些帮助的，毕竟译者们还是花了不少时间趟过不少文字坑的。

希望以后有机会自己独立完成某本书的翻译，不限于技术书籍，也可以是管理书籍或者是科技史等。希望有机会写作并出版自己的书籍。

阅读原文

跳转微信打开

AI是否已经在“说话”方面赶上人类？

上面三条音频的正确答案，会在文章发布后的第二天，于本文留言区公布。欢迎收藏后再回来看，结果相信会打破你的三观。

近日出门问问公司推出了新一代合成引擎MeetHiFiVoice，在发音人音质、韵律节奏等方面均有质的提升。下面我们来欣赏一段视频（大部分为魔音工坊用户制作的视频片段），看看目前的技术，做出来的作品配音效果是否足够以假乱真了？

在大众的固有印象中，AI配音总是给人机械的印象。那么人工智能经过这么多年的发展，TTS是否已经摘掉了“一听就是机器人”的帽子呢？

三年前，出门问问有个公众号投票，针对MeetVoice的合成效果进行了一次”以假乱真“的声音鉴别投票，投票结果如下图。投票数据显示，当时的AI和真人的声音已经接近“傻傻分不清”了。不过当时参与投票的发音人比较少，并且投票的时候预先知道了两条音频里“一条为真一条为假”，不够接近真实世界的现状，说服力还不够强。

以下是某支音频的投票结果：

可以看到，该条音频总共有190人参与投票，投真人106票，投合成84票。

我们先来听听这条音频：

下面再来分析看看最终的评测结果，以下是总体的投票信息：

从上面的表格可以看到，音频的平均准确率只有59.4%，而盲猜的准确率也会有50%，说明真人的辨别能力，和盲猜结果相差无几。

大概有10条音频，真人和合成的得票数在40%-60%之间，也就是说，大部分人都无法分辨出来。

对176个投票用户的投票结果进行的分析

（投票结果比例图表：指不同得分范围对应的人员比例）

从以上图表可以看出，准确率低于盲猜（50%准确率，即50分）的用户，达到了19.9%，说明对这部分用户而言，合成已经真正达到“以假乱真”。而得分为60分以下的用户，占到了55.7%，也就是说，过半的用户，可以在一定程度上辨别真假，但是接近盲猜（高了不到10分）。176个用户里，最高得分为75分。

另外， 我们还重点看了下四位声音领域的专业用户的投票结果（其中C和D是专门邀请来进行测试的，不在统计的176个用户里）。

专业的主播和配音从业者，也很难有效判断出某个音频是AI还是真人，更何况对声音不太敏感的普通大众？看到这里，你还会认为“AI配音很机械”，或“配音还是得使用真人，否则效果不自然”么？

是的，媲美真人的配音时代已经来临！

下面我们来听几支音频，看看哪些音频是比较容易被AI克隆的，哪些是AI难以逾越的。

先来看看“以假乱真”的合成音频1。上面这支采采的音频，有高达55.8%的用户认为它是真人原声，而不是合成的。有一些投票用户认为，该音频“有吐气之感”，确信它是真人，而不是合成的。

再来看看真人音频2。满超老师的这支音频，目前对AI而言，依然是不可逾越的高峰。由于满超老师的演绎水平很高，可能导致大部分用户认为AI目前做不到这个水平，所以有75%的用户投票“真人”。满超老师已经入驻魔音工坊，他和杨婧老师的《斗罗大陆》有声书，堪称有声小说的标高，有兴趣的朋友可以在“云听”收听两位老师的精彩演绎。

再来听听满超老师激情风格的样音，看看真人可以做到多“真”，张力多强：

当然，主播的演绎越好，风格越多变，对AI来说越是无法逾越的高峰。不过技术在持续进步，路漫漫其修远兮，魔音工坊团队也会持续勇攀高峰，争取开发出更好的AI模型以飨用户。

目前出门问问MeetHiFiVoice 的模型已经落地到魔音工坊中了，可以访问以下发音人，实际听听他们的合成效果：

看完这篇文章，你觉得目前的AI技术，已经做到了“以假乱真”了么？如果没有，又有哪些方面和真人存在差距？ 欢迎大家在留言区留下你的看法。也可以在留言区留下你判断一条音频是真人还是合成的“黄金法则”，我们来看看，到底这些人类判断的经验法则，是否经得起AI技术的考验！！！

阅读原文

跳转微信打开

作为工程师工作11年了，这里分享下自己的三段“产品经理”经历。

工程师角色很少转型为产品经理的，我也不例外，目前更多的角色还是工程师。近期收听了不少播客，大部分都是互联网产品经理和创作者主理的，于是有一定的冲动，做一做播客尝试看看。不过做播客并不容易，就和做视频号一样，对习惯写文字的人来说，需要做一些改变。播客还是以后再说吧，这次我们先使用文字梳理下我过去的几次“产品”经历。

先说一下这次时隔两年再次开始写文章的原因：1，公众号10周年了，觉得不应该荒废了。2，看到小宇宙等平台里的很多蛮出色的互联网人，都一直在坚持输出，尤其是在小宇宙“为爱发电”做播客，觉得坚持写作（或者叫内容输出）是一个好的习惯。这次重新开始，希望能坚持一定的写作频率。

我在09年开始实习，第一次实习做的是一个聊天工具，其实就是高仿版本的QQ。当时我的角色是「Windows开发部经理」，算是研发负责人，不过刚开始的半年多时间里，公司里这个项目并没有正经的产品经理，所以我也承担了一定的产品角色。对于还在读研的我来说，开发一款QQ这样复杂度的软件，并不容易，不管是技术难度，还是产品复杂度。那会做了几个事情：

• 深度玩了下QQ的所有功能。包括所有按钮，所有菜单，所有产品文案，甚至包括支持的所有设置信息。

• 反复测试文件传输，音频通话，视频通话，文本聊天，表情包等功能。

• 深度调研的Miranda项目，以及一些第三方的IM框架。

第一次实习，虽然没有太深度参与产品定义（因为产品本身就是copy的），但是却对当时最大的互联网产品做了深入的了解，虽然仅限于功能细节的了解，没有能够从产品创新，商业模式等入口，但是也有了一定的收获，那就是对产品保持好奇心。

写到这里，想到了近期面试一个产品候选人的有趣经历。有个大概工作了七八年的产品，当我问他几个比较大的互联网产品的时候，他提到最大的是QQ，然后是淘宝和微信等。我接着问，那微信和QQ的DAU大概是多少，他提到QQ大概是三五亿，微信DAU大概是QQ的一半。我接着为，为什么QQ的日活会是微信的两倍呢？他说微信主要是成年人在用，而QQ很多小孩也在用。当时我挺震惊的，原来作为产品经理这个职业的从业者，可以对微信和QQ的基本数据如此陌生！

第二次产品经历，则是我的第二份正式工作。当时在宜搜科技工作，最后半年的时候，团队做了很多创新产品的尝试，比如安卓市场的App Store（类似豌豆荚），比如新闻阅读产品（类似今日头条，或者内容为主的UC浏览器）。不过可惜的是，当时团队的产品能力不够强，更多的还是趋势的判断，但是产品创新能力并不够强，而技术执行能力也不够强，导致产品做出来只能自己玩玩，基本都停留在从0 到1的阶段，还没有进入大规模推广阶段，团队核心成员就四散纷飞了。

那会我其实也做过一次产品尝试，做一款新型的视频搜索产品。当时是13年，移动互联网方兴未艾，各种移动互联网的产品创新层出不穷。那会有几个视频方面的痛点：

1. 优酷土豆等视频网站四分五裂，很多看一个电影或者电视剧，往往不知道哪个网站才有。搜索的成本很高。有时候搜索到了，那个视频却需要付费，但是大家都还没有同时购买好几个视频网站会员的习惯。

2. 当时电驴等BT搜索网站还很多，但是产品使用体验一般。很多能搜索到资源的网站，都是小团队做的，技术能力有限，产品体验更是糟糕。

3. 迅雷等下载软件，以及百度云盘等产品，都开始推出在线云播产品功能，用户在大规模增长中。

基于上面的几个现状，我觉得有机会开发一个综合的视频搜索产品，可以解决几个痛点：

• 搜索版权视频，一个入口查找主流视频网站的资源，并且标记出来哪些视频是需要会员才能播放的，哪些是可以免费观看的。

• 精准搜索种子文件，或者是magnet 链接，并且做一些去重。搜索到种子后，直接使用云播产品一键播放。

• 版权视频和种子资源的搜索，整合在一起，一个搜索按钮搞定所有视频搜索需求。

当我把原型出来后，当时我的leader还让一位前端，一个产品，一个设计师配合我，当时大概花了小一个月的时间，开发了这个产品的雏形，并且在贴吧等地方简单推了下。没有想到的是，还是有很多用户进我们用户交流的QQ群的。我们几个同事自己也会使用这个产品去找一些视频看，使用下来，对我们自己是有产品价值的。当时之所以快速开发了出来，是因为我们团队之前是做网页搜索的，爬虫，网页解析，索引等都是我们团队负责的。而我自己当时也业余时间读了开源搜索引擎的源代码，所以利用我们几百亿网页资源，快速从一些特定网站中解析magnet链接，然后利用我们团队的索引检索能力，搭建一个原型系统还是非常快速高效的。

遗憾的是，这个产品因为后来的“扫黄打非”停摆了，当时因为色情资源等问题，百度网盘和迅雷的云播功能，都进行了深度整改，于是种子搜索和播放的核心体验无法依赖云播产品搭建起来，加上有一定的触雷风险，大家也就不再重点看这个项目了。过了一段时间，团队大动荡，我也离开了公司，来到了出门问问。

而我的第三次产品经历，则是目前在出门问问做的魔音工坊。魔音工坊是一款AI配音软件，旨在为用户提供全方位的编辑功能，人机结合，快捷生成高品质无错误的音频，配音效果媲美真人。有大量的音频创作者有AI配音的需求，主要几个原因：1，自己的声音不好听。2，普通话不标准。3，找朋友配音很麻烦。找专业的配音机构又太贵。4，家里没有安静的环境，更不可能有专业的录音棚。5，专业麦克风不便宜。6，配音念错了，需要反复重念，时间成本高，甚至枯燥无聊。

第三段经历，我则不再是简单地参与魔音工坊这个产品，而是从产品创意的提出，核心功能的定义，核心技术的推进，交互和设计细节的反复讨论和确定，都下了大量的功夫。这次经历，也算了让我完成了工程师到“产品经理”的角色转型，虽然岗位还是技术岗位，不过花在产品上的功夫已经不比技术少了。所幸的是，魔音工坊这个产品不再是胎死腹中的产品点子，也不是藏之深闺（公司内使用）或者浅尝辄止，而是迭代了两年多，并且得到了蛮多用户的认可。

对这个产品感兴趣的朋友，可以在我的视频号观看产品介绍视频。在过去的推文里，也有两三篇相关的文章。

下面的文章，我会来简单总结下作为工程师和作为产品角色的差异，以及两个角色的欢乐与痛苦，而我又是如何从这两种不同的角色中获得兴奋点的。

阅读原文

跳转微信打开

最近在做的一款配音产品，非常适合自媒体作者，读者朋友们，如果你有配音需求，可以考虑下魔音工坊。

网址：https://voice-maker.mobvoi.com/

购买会员的话，找我有优惠。后台私信我，或者公众号里找一下我的联系方式。

跳转微信打开

魔音工坊是一款AI配音软件，旨在提供全方位的编辑功能，人机结合，快捷生成高品质无错误的音频，配音效果媲美真人。

影视解说中，有大量创作者有AI配音的需求，主要几个原因：

1，自己的声音不好听。

2，普通话不标准。

3，找朋友配音很麻烦。找专业的配音机构又太贵。

4，家里没有安静的环境，更不可能有专业的录音棚。

5，专业麦克风不便宜。

6，配音念错了，需要反复重念，时间成本高，甚至枯燥无聊。

影视解说人群而言，AI配音就是非常好的选择。而魔音工坊是目前市面上非常专业的配音软件，已经有很多抖音达人，靠这款软件，在两三个月内就做到了大几十万粉丝。

我们来看看魔音工坊有什么强大功能，又怎么使用吧

跳转微信打开

聊聊读书的需求，以及微信读书这个产品。

三年之前曾经写过一篇文章《读书之痛》，说了一些读书的痛点（不禁感叹光阴似箭，三年前就恍如昨天）。其中有两三个地方提到了微信读书，比如签名之痛：

比如微信读书，做笔记就很方便，不仅做笔记方便随心，还能让你肆意划线，就彷佛你手里握着你喜欢的那支笔，可以在书上划划重点、指点江山。

再比如做笔记之痛：

比如微信读书，做笔记就很方便，不仅做笔记方便随心，还能让你肆意划线，就彷佛你手里握着你喜欢的那支笔，可以在书上划划重点、指点江山。

那篇文章我提到的痛点，总结下来有这么十二条：

1，痛在太挤。

2，痛在太慢。

3，痛在签名。

4，痛在太贵

5，痛在太厚。

6，痛在太监。

7，痛在太硬。

7，痛在太重。

8，通在好书少。

9，痛在翻译太差。

10，痛在常被借走。

11，痛在无人交流。

12，痛在写不出。

三年已经过去，我这三年使用微信读书也阅读了不少的书籍，我看了下我微信读书的数据：

书架上书籍数：772本

笔记数：174

阅读时长：336小时

被赞数：272个

读完书籍数：50本

创建的书单：3个

总体上，不能说是重度用户，不过应该算是活跃用户了，保持了在微信读书上一个月至少阅读一本书的记录。搜索了下自己的朋友圈，这几年说过的有关微信读书的朋友圈内容就有二三十条。

最近的一次阅读，我发现微信读书的改进速度非常快，不过还是有不少小问题值得继续改进。为了方便阅读，也方便自己更好地梳理读书类的产品需求，我整理个脑图出来。由于不是专业的产品经理，因此脑图不一定很专业，不过基本上把围绕着读书这件事的各种事情都大致梳理出来了。

下面来具体聊聊微信读书的厉害之处。

1，微信读书已经一定程度打通了实体书和电子书了。之前在微信读书上有一个最大的痛点，那就是找不到书，或者书是找到了，但是没有上架，只能订阅，订阅后，上架会通知你。目前如果一本书没有电子版，但是有实体书，你可以直接购买，购买的时候，如果你已经填写了地址，是可以一键完成了（准确地说是两步，点击「购买纸书」，接着点击「微信支付」）。

二十年前，我买书一般在实体书店，或者是路边摊，十五年前，我买书一般在当当网，主要是便宜。再后来，我就在京东的小程序上购买实体书，主要是送书快。要知道，「贵」和「到书慢」可是读书人的两大痛点，太贵了买不起，书再好也只能忍痛割爱，而发现一本好书后，恨不得马上开始阅读，当天熬夜阅读完毕，要是等好几天书才能送到，有时候看书的心情都冷却一大半了，等待心目中的书籍到货的过程，不亚于等待佳人让人难熬。

2，微信读书已经很好地解决了找书的问题了。推荐系统在读书这个场景是最容易做出彩的，一般找书，无法几个渠道：朋友介绍，喜欢的作家的书，喜欢的作家提及或者推荐的书，热门书籍，喜欢的人里提到的书，某个主题或者领域的书（比如有关中美关系的经典书籍，再比如价值投资的书籍等）。书籍这种东西，最容易激发读者的高质量互动，包括短评、长篇书评等，主要是阅读本身是需要花费大量的时间的，所以进行反馈比较自然。基于评分，基于评论内容，基于用户的阅读历史（自己的阅读历史，相似用户的阅读历史，好友的阅读历史等）等进行推荐，都会让用户获得传统读书中没有的良好体验——技术让好书更容易被发现、被找到。

微信读书除了使用推荐系统外，最近有一个不错的产品设计，就是书中提到的书籍，大部分会出现超链接，点击后会出来三个内容：词条释义、书籍、网络搜索。当然这里目前做得还比较粗糙，在确定是书名实体的时候，没必要出来三个来源的信息。并且目前还有比较大的问题，一个是，还有不少书籍没有被定位出来，也就是没有自动添加链接标记，另一个是，搜索出来的书籍，还做不到最优，比如没有根据上下文的作者信息，定位到最佳匹配书籍（同名书籍并不少见）。这个功能豆瓣很早就有了，不过豆瓣至今还做得不好，已被微信读书超越。有关这部分，我之前写过一条朋友圈，发在这里：

#万书互联#

微信读书加上以下功能的话，作为一款互联网读书软件，就更成熟了:

书名添加搜索链接，类似万维网的超链接，书作为实体，加上链接，几乎就可以计算出来类似pagerank的排行榜了。更主要的是，读者找书其实主要是通过书来找书。当然，和网页搜索收录的网页越多(靠spider)体验越好一样，微信读书里收录的书籍越多，书联网的价值越大。

这个想法其实豆瓣已经做了(比如影评里的电影名)，我自己使用下来觉得效果很赞。有认识微信读书产品经理的朋友，不妨去推荐下这个功能，为书友谋下福利。

(图一为豆瓣，图二为微信读书)

这个功能其实有很多可以发挥的地方，随便举几个：

• 自动挖掘一本书里提及的书籍列表。这个还是挺有必要的，我之前就曾经想写个程序，分析下某个作家引用过的作家列表以及书籍列表。

• 找出某个作家的影响谱图。就是说这个作家收到哪些作家的影响。当然，有一些作家是绝口不提自己的师承关系的，这个可能和「影响的焦虑」有关。

• 做一个全局的实体关联图，构建全局的好书榜单，以及特别的书单。大部分书单都是人整理的，我看目前微信读书团队就整理了一大堆的书单。其实搞个这样的书单就非常有价值：鲁迅提及的书籍，托尔斯泰提及的书籍，鲁迅提及的作家，《论红楼梦》一书提及的书籍，《论中国》提及的书籍等。之前知识图谱一般使用在人物关系上，尤其是明星之间的关系，不过用在作家和书籍上，会非常有价值。
  

3，微信读书已经很好地解决了读书贵的问题了。根据微信读书的提示，我使用连续包月功能后，它已经帮我节省了大概3341元了。节省了多少，虽然是一个数字，不过我相信它确实物超所值，如果没有电子书，我大概率会花几千块钱买实体书，甚至会更多，因为电子书本身的定价已经比实体书便宜不少了，尤其是有点年头的文艺方面的书籍，不少定价才几块钱。按照我目前770本左右的电子书，估计实体书买下来得三四万左右。

如果微信读书抬高年卡价格，我愿意出的价钱至少在1000以上。

4，微信读书的读书体验已经很棒，不少超过了实体书的阅读体验。比如说，划线功能，和实体书的划线体验接近。扉页的自动签名，也提供了接近实体书的体验，当然，真好做细致，签名这里还是有改进空间的。书签标志的体验，在UI上也接近实体书的风格，不过可惜的是，没有类似表情包的生态出来，我愿意为模拟实体书签付费。

更值得一提的还是注释的处理，传统书籍的注释，一般在书页底部，或者是该章节的结尾。而电子书籍就比较容易处理成注释和内容绑定的方式了，一个特殊的UI，比如「注」字，点击后再显示注释即可，阅读体验比传统书籍更佳，传统书籍里，注释并不是每条都感兴趣的，但是占据了纸张，从而影响翻页的效率。

更关键的是，「写想法」和「制作书签」的效率比传统书籍高太多。之前写想法一般写在书页的空白地带，毛泽东就特别喜欢在树上写评论。在自然科学领域，最知名的可能莫过于费马大定理了，费马在书上写的问题，让全球数学家整整忙了几百年，而他居然宣称他已经想到了绝妙的证明，只是书上的空白处写不下他的巧妙证明，你说气不气人？

传统的笔记，一般使用笔记本加烂笔头，输入效率比较低。在目前的APP里，你可以打字，也可以使用语音输入法进一步提高效率。

下面聊一下微信读书近期的改进，以及还存在的一些不足。

1，大幅改进的书籍的详情页，增加了目录入口，点评信息，作者作品列表，书籍推荐，相关书单，相关公众号文章等。这方面的改进还是非常关键的，因为在开始阅读一本书之前，读者往往需要做一点外围的了解，以对是否开始阅读进行决策。改版后，目前我认为整体的体验已经不差豆瓣了，并且在内容覆盖上，已经显示出优势来。

另外， 目前「听书」、「购买纸书」、「阅读」三个入口并列，满足读书人的不同阅读喜好。

2，书名实体链接的引入，大大改进收藏书籍的体验，降低书籍发现的成本。找书方便了，自然就更有冲动阅读更多的书籍。其实我觉得在阅读结束时推荐的「继续阅读」里， 不妨就放这些在阅读过程中被放进书架的新书。

3，大幅改进了阅读完毕一本书的体验。这里增加了「查看全部点评」和「退出阅读」，体验明显变好。尤其是「退出阅读」，看起来不起来，但是之前经常习惯性左滑，自动就匆匆帮忙结束了一本书的阅读，但实际上我可能只阅读了几页。显式点击「退出阅读」，更接近真实世界的体验，你读完一本书，总得盖上书，并且摆放回书桌或者书架吧。

不过想吐槽下这里「查看全部点评」的UI设计，一来搞了个暗黑的背景色，让人不舒服，二来上下滚动不舒服，三来退出的方式也不够完美。豆瓣短评的查看全部短评就好得多，不仅交互自然舒服，并且提供了「热门」、「最新」、「好友」三个分类，热门其实还是挺有价值的，因为点评比较多的话，按照点赞数排序就是提高效率的有效方式。

4，微信读书的藏书量已经大大提升。

按照PC网页上的信息，粗略估计有接近十万本的书了。古人说，「读万卷书，行万里路」，十万本相比十万卷，在规模上已经远远超越。我之前曾经因为微信读书上没有某些书，就在实体店或者京东上买了，结果一两周后，好几本书就上架了，很让人出乎意料。想想一年200万的年卡，K12阶段也就是两千块钱左右，就能解决掉阅读资源不足的问题了，其实非常划算。在我读书的时候，书籍非常匮乏，学校里也几乎没什么书籍，村里有藏书的家庭也很少，和别人借书还是挺费劲的事情，一方面不知道和谁借去，一方面能借的书不多。买书就更没钱了，小学的时候一个星期最多几毛钱的零花钱。初中以后我们班主任倒是有一些书，不过放在学校的估计也就是几十本，他读的大部分也不一定适合初中书阅读。

微信读书的持续做大，我认为对整个社会来说，都是一件好事。对年少没有购买力的「我」，提供了低成本读万卷书的可能性。对目前的我而言，哪怕我一年花一万块钱买书吧，其实也就几百本，存储成本和搬家成本也非常高，如果哪天微信读书藏书百万，而我花几百块钱一年就可以免费阅读的话，对我而言也是幸甚至哉。很多时候在书店里闲逛，一些书你是有兴趣买的，但是想到存储成本高，读完扔掉又太可惜，处理的时间成本也高，这时候往往你就决定不买了。但是电子书没有这个问题，你可以随时放进书架，也可以读了一章就不看了，扔在一旁，束之高阁，等你想起来了后可以继续看，不想看了，你直接挪出书架即可。

5，目前还有一些朋友喜欢读实体书，但是实体书又太贵。我觉得在未来探索出一种购买版权后打印出来阅读，或者按年费租赁实体书并支持快速退还，可能会是很好的模式。有一些朋友，至今还是无法接受电子书阅读，希望在未来能够探索出一种低成本的实体书阅读模式。

最后，谢谢微信读书产品，谢谢微信读书团队。祝微信读书做得越来越好，引入越来越多的好书。

阅读原文

跳转微信打开

完结篇：上线与发布，代码重构，绩效考核，OKR，TGIF，20%自由时间，谷歌双雄。

今天计划把剩下的主题全部写完，文章可能会比较长。

上线与发布

这部分具体不是很清楚，只是听前谷歌的人说过一些。Google内部会有release engineer，有点类似国内的运维工程师吧。搜索到了三本书，详细剖析Google的运维之道。链接如下：

https://landing.google.com/sre/books/

一本是《Building Secure & Reliable Systems》在线阅读地址为：

https://static.googleusercontent.com/media/landing.google.com/zh-CN//sre/static/pdf/Building_Secure_and_Reliable_Systems.pdf

一本是《The Site Reliability Workbook》，介绍如下：

The Site Reliability Workbook is the hands-on companion to the bestselling Site Reliability Engineering book and uses concrete examples to show how to put SRE principles and practices to work. 

This book contains practical examples from Google’s experiences and case studies from Google’s Cloud Platform customers. Evernote, The Home Depot, The New York Times, and other companies outline hard-won experiences of what worked for them and what didn’t.

在线阅读地址为：

https://landing.google.com/sre/workbook/toc/

另一本书是《Site Reliability Engineering》，书籍介绍如下：

Members of the SRE team explain how their engagement with the entire software lifecycle has enabled Google to build, deploy, monitor, and maintain some of the largest software systems in the world.

在线阅读地址如下：

https://landing.google.com/sre/sre-book/toc/index.html

由于这个话题不是很专业，上面的三本好书也还没来得及系统阅读，只能等后续阅读完毕再分享了。下面补充一些我听到的信息吧。

1，Google内部的部分工程师是需要作为Release Engineer的，也就是参与部署上线。听说是有特殊的奖励的，可能一个月几百块钱吧。

2，Google的基础架构很牛逼，运维部署系统也很专业，业界有不少开源的项目，都是Google放出来的,比如Kubernetes，项目地址为：https://kubernetes.io/

3，C++的一些编译工具，Google也开源了，比如bazel就是非常方便的C++工具，目前已经扩展到支持各种不同的语言了。项目网址为：https://bazel.build/

4，Google为了解决大规模的代码编译，还实现了一套很复杂的系统，包括

Blaze, Forge, SrcFS, ObjFS等。目前对外的信息并不多，下面是一篇：

https://mike-bland.com/2012/10/01/tools.html#blaze-forge-srcfs-objfs

七八年前，百度的基础架构团队，有计划clone一套Google的代码编译系统，不过后来好像没有听到成功落地。当然，百度倒是借鉴Google的C++编码风格，弄了好几套百度内部的C++编码规范。

代码重构

一般工程师都参与过代码重构，但是不见得你的老板们会为你的重构工作买单。代码重构是必要的，就和房间需要经常打扫一样。现在我回想刚毕业那会写的很多代码，解决问题的算法和框架都已经很落后了。差不多10年的时候，我在一家搜索公司当研发，写了不少的代码去做网页的各种解析和质量分类等，之前很多都是依赖人来分析网页，从而编写规则，搞了一套套的专家系统，不过效果并不好。目前很多任务都使用深度学习来做了。

像我们做的语音合成，早期使用HTS，后来做拼接，再后来流行LSTM，目前基本主流的公司都切换到类Tacotron和 类WaveNet的系统了，否则根本没什么竞争力。

代码需要重构，我的理解里，主要是几个原因吧：

1，时代在进步，人也在进步，重构代码，可以让代码与时俱进。有时候旧瓶装新酒很困难，使用旧的代码框架，已经不再适合最新的思路和解决方案了。

2，人都是喜新厌旧的，尤其是聪明人，员工换岗，或者是离职，都会导致有新人来接手旧项目。而最好的接手方式，就是按照自己的理解重构下代码。

听说Google内部很多项目一两年就会整体重写一遍，他们内部也比较认可代码重构的价值，这可能是Google保持活力的原因之一吧。

说到重构，大部分人很少专门学习重构的技巧，可能也没有摸索过IDE工具里的重构能力和插件，建议没有这方面经验的人，找个时间尝试看看。代码重构领域，有一本书比较知名，这里推荐下英文原版：

我挺喜欢代码重构的，我曾经做过很多代码重构的工作。代码重构的乐趣，一定程度上类似的改写自己多年前的作文。随着审美的提高，多年前的文章，总觉得又臭又长。文章如此，代码也是这样。对文章而言，需要讲究谋篇布局，讲究简洁是美德，对代码也是一样，简洁，舒服，设计合理，用词精准等，都是很重要的原则。

OKR

Google内部讲OKR，国内大部分公司讲的还是KPI。目前国内推行OKR之风挺猛的，很多的OKR培训讲师冒出来。记得在之前的系列文章里提过前Google的一位朋友，上次没找到她课程的链接，后来问了下她，课程地址放在这里，有兴趣的朋友也可以听听看：

https://apphisefxvl7233.h5.xiaoeknow.com/v1/course/column/p_5eb7d8e64c7af_EEklDizt?type=3

国内目前字节跳动等公司都在大规模使用OKR，并且开发了很多内部工具，用于实现OKR的对齐，也就是你的目标，和上级等进行对齐，保证大家的重心不会有较大的偏离。我目前所在的公司，目前也在使用OKR，并且也开发了一些简单的工具，实现在企业微信内部编写OKR。同事之间可以使用企业微信，查看彼此的OKR。不过我认为我接触过的OKR实践并不算成功，这里就不详细展开了。

我说一下个人对OKR和KPI的区别理解。KPI有时候容易跑偏，导致围绕这目标，各种变形的动作出来，原因是大家对目标的理解有误解，或者是每个不同团队的目标，其实是不一致的。而为了达成一个不够全面的目标，各种手段都出来了，导致「为达目的不择手段」的事情时有发生，尤其是为了实现某个商业目标，往往会牺牲产品体验。

KPI往往是自上而下的，但是上层往往有更全局的视角和目标感知，但是目标传递到下面，往往就理解上带有偏离了。OKR更鼓励的是自下而上，倾向于发挥底层的创新力，让大家都想想自己的中长期目标是什么，而通过上下对齐，在保持底层活力和能动性的同时，又保证整体的力气是往一个大的共同方向使的，从而使得整体向心力较强。

OKR的落实难点，往往在于人员素质的难点。很少听说类似桥水等机构效率低下，因为人员很少的时候，人员的招聘和管理相对比较容易。人一多，招牌难度，管理难度都加大太多，所谓鱼龙混杂吧。招聘非常关键，招聘关把好了，找到的都是自我驱动力很强的人，想的都是怎么最大化自己的影响力，自然OKR的落实就会很容易。

20%自由时间

很多外企都会有20%时间的做法，在20%时间里，你可以根据自己的兴趣，做一些你感兴趣的项目。本系列第二篇文章里介绍的创新工场CTO，当时他在Google的时候，20%时间就经常参与Google涂鸦（doodle），玩转技术和艺术结合的乐趣。

在2004年Google发布的IPO letter中，创始人Larry Page和Sergey Brin在信中写道：

除了各组的常规项目之外，我们鼓励员工每周花20%的时间开发自己感兴趣、也可以促进谷歌发展的个人项目。
We encourage our employees, in addition to their regular projects, to spend 20% of their time working on what they think will most benefit Google.

那么有哪些知名的项目是20%自由时间里搞出来的呢？

• 2002年，Google News测试版发布

• 2003年，AdSense发布

• 2004年，Gmail测试版发布

• 2005年，Google Maps发布

不过从网上的信息看，目前Google的20%自由时间几乎已经名存实亡。

美团的王兴看起来也对Google的20%自由时间不以为然，看看他怎么说的：

这里我不打算加入口水战，说一下我个人的看法：

怎么激活员工的活力，是公司管理层，以及每一位管理者都需要想办法去做的重要事情。有些公司喜欢让员工时刻保持工作状态，认为有时候刷刷朋友圈，或者是饭点的时候看看视频都是不可接受的。他们恨不得员工时刻处于战斗状态。

我个人比较欣赏张弛有度的工作状态。忙碌的时候要进入打仗状态，但是也应该有休养生息的时刻，应该给予充电和学习的时间，没有学习和思考的时间，怎么才能做到厉兵秣马呢？

根据我的个人经验，花一定比例的时间在阅读和学习上，甚至在思考上，往往整体的效率更高。时刻花在特定问题的思考上，往往不容易有新的思路，因为很多时候「功夫在诗外」，其他方向，甚至其他专业的知识，也能对解决当前问题有所帮助。

绩效考核

gogole 的绩效考核机制，还是比较值得学习的，原因很简单，Google的创新活力依然不错。我没有专门做过人力资源，所以就找了下相关资料，找到了一份比较全面的资料：《Case Study: How Google does Performance Review》，链接地址如下：

https://worklogixblog.files.wordpress.com/2018/08/b3318-google.pdf

这份资料我看起来挺有价值的，值得一读，我自己也计划详细阅读。

基本上分为三个部分，个人自评，360度环评，校准。根据我呆过的两家Google系公司的经验（他们的绩效考核是否学到家我不清楚），对程序员而言，大概是这样的：

1，程序员准备下自己的评价，包括去年的主要工作，今年的规划，相关的代码链接， 个人打分等。

2，直接上级，工作上接触比较多的同事，会对你进行打分和评价。

3，管理层对员工个人打分进行校准。一般是兼顾公平原则吧。不过就我的经验而言，员工个人的打分没什么价值，一般是个人的工作总结比较重要，因为往往做绩效决策的人，并不熟悉所有人的工作情况。

TGIF

TGIF就是 Thanks God, It's Friday的意思。在Google，往往周五的时候，会举办公司活动，公司会准备一些零食水果或者酒水等，让员工在欢快的氛围中，听公司的老板分享一些信息。员工有什么问题，也可以随时提问。

在我呆过的两家公司里，除了老板分享公司的近况外，也会举办生日会，给当月的寿星们祝寿。此外，也会做一些内部产品发布，内部知识分享（比如技术分享，或者是产品分享，营销分享等）。

听说Google内部的CEO提问环节，挺open的，比较犀利的问题也可以去提问。Google对员工秉持的是信任原则，分享的一些信息，他们相信员工不会传播到外部去。我呆过的公司里，CEO提问环节中，员工也问过千奇八怪的问题，很多问题也是让CEO们抓破脑袋，不过再难回答的问题，确实也都直面问题，而不是直接就过滤掉问题，甚至不让提问。这可能就是Google文化对他们潜移默化的影响吧。

除了生日会，一般在TGIF上也会介绍一些重要角色的加入。比如，记得在李开复的自传里提及，李开复加入Google的时候，总部那边在TGIF上对他的欢迎仪式还蛮隆重的。

不过国内不少公司其实实行的是996，所以TGIF这个东西，多少有些变味。

谷歌的大佬们

本系列的文章里，提到了Google出的几本比较知名的书，也推荐了两三个Google工程师的公众号。这里写点儿工程师角色吧，重点是Google工程师双雄。

先来看看Google的技术级别：

• Level 1 - I.T. Support Staff

• Level 2 - Fresh out of college

• Level 3 - Master’s Degrees

• Level 4 - Several years of work or a Ph.D.

• Level 5 - Most progression stops at level 5

• Level 6 - The top 10%

• Level 7 - Level 6s with a long track record

• Level 8 - Associated with a major product or piece of infrastructure

• Level 9 - Spoken of with reverance

• Level 10 - A Google Fellow

• Level 11 - Google Senior Fellows

在业界比较知名的谷歌技术大牛，恐怕是Jeff Dean和Sanjay了，他们也都是Google Senior Fellows，处于工程师金字塔的顶级。江湖上流传着很多他的传说。可以读一下这篇有关他和他的好基友的文章：《Jeff Dean的传奇人生：超级工程师们拯救谷歌》

先来看看Jeff Dean的介绍：

Dean joined Google in mid-1999, and is currently the head of its Artificial Intelligence division. While at Google, he designed and implemented large portions of the company's advertising, crawling, indexing and query serving systems, along with various pieces of the distributed computing infrastructure that underlies most of Google's products.[3] At various times, he has also worked on improving search quality, statistical machine translation, and various internal software development tools and has had significant involvement in the engineering hiring process.

The projects Dean has worked on include:

• Spanner, a scalable, multi-version, globally distributed, and synchronously replicated database

• Some of the production system design and statistical machine translation system for Google Translate

• BigTable, a large-scale semi-structured storage system[3]

• MapReduce, a system for large-scale data processing applications[3]

• LevelDB, an open-source on-disk key-value store

• DistBelief, a proprietary machine-learning system for deep neural networks that was eventually refactored into TensorFlow

• TensorFlow, an open-source machine-learning software library[3]

He was an early member of Google Brain,[3] a team that studies large-scale artificial neural networks, and he has headed Artificial Intelligence efforts since they were split from Google Search.[10]

再来看看Sanjay的介绍：

Sanjay Ghemawat (born 1966 in West Lafayette, Indiana)[1] is an Indian American[2] computer scientist and software engineer. He is currently a Senior Fellow at Google in the Systems Infrastructure Group.[3][4] Ghemawat's work at Google, much of it in close collaboration with Jeff Dean,[5] has included big data processing model MapReduce, the Google File System, and databases Bigtable and Spanner. Wired have described him as one of the "most important software engineers of the internet age"

Jeff的一些论文和公开的PPT，我大概看了一些。而源代码的话，大概看过LevelDB的，Tensorflow大概使用过。Sanjay也参与过LevelDB，levelDB的项目地址为：

https://github.com/google/leveldb

作为比较迷你的知名key-value 数据库实现，这个项目的技术分析文章，甚至是源码解析，都随处可见，有兴趣的朋友可以找来读读。有时间的人，当然是读读代码更好。

而Sanjay还有一个项目是开源的，那就是性能剖析相关的gperftools, 项目地址为：

https://github.com/gperftools/gperftools

这个项目相当值得阅读，对内存分析，CPU分析和性能改进相当有帮助。强烈建议有时间的朋友们读一下代码，至少读一下相关的文档吧。

Sanjay参与的论文很少，除了Google三驾马车相关论文外，看起来就TensorFlow的论文了。被引用比较多的文章如下：

而Jeff Dean在AI时代，相对比较活跃。他目前是GoogleAI的掌舵人，在机器学习领域也多有参与。来看看他参与的被引用数靠前的文章：

当然，Google的牛人来来往往太多了，可能一本书都写不完。

阅读原文

跳转微信打开

这篇继续聊一下调试与剖析这个话题

这篇继续来聊一下调试与剖析这个话题。

一般软件调试使用GDB来进行，不过对GDB熟悉的不一定多。我认识的几个Google出来的工程师，使用GDB并不多。其中一个Google的工程师甚至说，使用glog打印一些日志，基本就可以看出问题了，要什么GDB啊。

如果说代码质量比较高的话，边界的测试比较多，确实不太需要使用到GDB。不过大型项目就不好说的，因为依赖的代码错综复杂，可能你的代码质量很高，但是依赖的third party质量一般，有一些隐藏的Bug，甚至操作系统有一些隐藏的Bug也不无可能，所以还是需要学会一些调试技巧。

接触的Google相关的调试技巧并不多，其中有一个是用于收集崩溃报告的。一般我们发生了crash，会生成core dump文件，但是core dump文件很大，存储和上传都比较困难，这时候是否可以考虑生成一个比较小的文件，包括一些比较关键的信息呢？当然是可以的，Google 就有一个开源的C++项目，叫做breakpad，官方是这么介绍的：

Breakpad项目目前被以下项目使用到：Google Chrome, Firefox, Google Picasa, Camino, Google Earth等。

breakpad主要包含三部分：client， symbol dumper 和 processor。client负责生成minidump文件，symbol dumper 则定义了自己的一个文件格式，读取编译器生成的调试信息，转换为自定义的符号文件。而processor则负责读取上传到服务器段的minidump文件，为相关版本的二进制文件和minidump文件提到的动态库查找对应的符号文件，然后生成人可读的C/C++堆栈信息。

以我的理解，breakpad主要就几个事情：

1，怎么捕获和处理各个平台的异常，然后在处理函数中，收集必要的信息并保持到文件中。需要设计一个自定义的文件格式，格式应该比较紧凑。

2，将信息上传到服务器。

3，服务器存储minidump文件的时候，按照相关版本的binary来索引。

4，要使用minidump来分析问题的时候，需要将相关的binary，动态库都找到，然后生成函数堆栈信息。怎么去遍历堆栈信息，打印出函数名等比较方便定位到相关代码的信息，是比较关键的，可以参考以下文档：

https://chromium.googlesource.com/breakpad/breakpad/+/master/docs/stack_walking.md

总结下软件调试：

1，代码质量过硬的话，确实在日常开发中不太需要使用到比较复杂的GDB调试技巧。

2，复杂项目，难免出现软件崩溃、内存泄露、死锁等问题，掌握一些调试技巧还是有帮助的。

3，复杂环境，比如客户端软件，典型的比如浏览器，聊天软件，下载软件等，一般都会出现崩溃，比如大家在使用电脑的过程中，应该碰到过不少次IE浏览器异常退出，QQ崩溃，或者电驴软件崩溃等现象。这个时候就要求客户端软件能够在崩溃的时候，能够自动收集崩溃信息到后台，从而在后台能够定位问题，让软件在下一个版本变得更加稳定。

聊完了调试部分，我们接着再来说剖析（Profiling）。一般有两个场景，一个是看内存的使用情况（Heap profiling），比如，看看内存都被哪些代码分配的，从而给内存优化找到放心，再比如，另一个是出现了内存泄露的话，怎么去定位并解决。一个是看CPU资源都被哪些代码使用了，以有的放矢地开展性能优化。

做这些性能剖析，Google内部使用比较多的gperftools，开源版本的项目的地址为：

https://github.com/gperftools/gperftools

官方是这么介绍的：

The fastest malloc we’ve seen; works particularly well with threads and STL. Also: thread-friendly heap-checker, heap-profiler, and cpu-profiler.

gperftools is a collection of a high-performance multi-threaded malloc() implementation, plus some pretty nifty performance analysis tools.

简单来说就是，它是Google内部使用的性能分析工具。该项目实现了性能非常好的malloc版本tcmalloc, 并且多线程安全，和STL的兼容性也很好。此外，它还实现了一些剖析工具，比如内存剖析、内存泄露检测、CPU剖析。

tcmalloc 我没有系统介绍过，不过类似的实现jemalloc, 本公众号曾经详细介绍过，没读过的推荐看看：《【译】使用jemalloc实现可扩展的内存分配》。本文就不具体介绍tcmalloc的实现了，放一下之前这篇文件的个人文字吧：

在我工作的第一家公司里，所有的binary都是默认链接tcmalloc的，大部分情况下，性能会得到不少提升。

下面通过一张图来大概看看tcmalloc的内部架构：

想要了解tcmalloc原理的，可以详细阅读下这篇文档：

https://github.com/google/tcmalloc/blob/master/docs/design.md

有关内存问题，有时候我们是为了分析内存都去哪里了，有时候是要找出来内存泄露在哪里。如果泄露的内存很大，一般做一下heap profiling，就可以快速定位出来了，因为跑得越久，泄露内存的地方，占据内存的比例越大。而如果内存泄露很小，比如跑一天下来，才泄露几M内存，就不容易通过heap profiling来定位了。这类问题，我们往往是通过在单元测试中进行内存泄露检测来实现的。在测试程序结束的时候，将内存检测的结果输出，如果发现了泄露，就生成一个报告，必要的话，就让整个测试的结果判定为失败。

内存泄露问题相对来说比较复杂，比如上面提及的泄露几M的问题，也可以通过输出多个profiler文件，比较各个函数分配的内存比例，来定位随着运行时间越长，哪些函数分配的内存比例越高。也就是说，无法通过一份profiler文件来定位，因为可能分配的内存很小，泄露了很多次，总体的内存占比也不够高。这时候就只好通过对比比例的变化，来判定是否出现了泄露了。

再说一个内存分析的问题。有时候在嵌入式平台，运行heap profiling是非常慢的，主要是因为stack unwind过程非常慢。有时候一个程序运行十几个小时，我们才确认出现了内存泄露的现象，这个时候如果打开heap profiling，程序的运行速度会成数量级的降低，很可能需要跑好几个月，才能从profiling result中看出问题。而这显然不具有可行性，就和机器学习训练任务一样，如果一个训练任务需要好几个月，做实验的话肯定连自杀的心都有了。当时我们的解决方案是，给gperftools打了个补丁，对stack unwind操作做了一定的采样比例，从而让程序的运行速度保持在同一个数量级上。通过这个改动，解决了一两个顽固的内存泄露问题。

说完了内存剖析，就是性能分析了。那么Google的CPU profiling怎么使用呢？大概分为三步：1，链接gperftools library到二进制，2，运行程序，3，使用pprof工具分析，输出profiling结果。想要了解更多细节的，可以阅读下面的文章：

https://gperftools.github.io/gperftools/cpuprofile.html

通过做cpu profiling，可以拿到某个函数消耗CPU的大概比例。比如下图：

从图中可以比较方便地看出来，如果要进行性能优化的话，优先级应该安排安排（按照图中矩形的面积大小即可）。除了上面的输出方式外，其实输出火焰图方式的性能剖析工具也比较流行，有兴趣的可以自行搜索下。

说到性能分析，我面试过的大部分工程师，都不知道怎么在不看具体代码的情况下，去对程序的性能问题进行大概的摸底调研。换句话说，类似gperftools的工具，大部分工程师都没有使用过。

不过有了工具其实还不够，主要还是要掌握足够多的性能优化技巧。性能优化方面，我之前写过几篇短文，列在这里：

《GCC编译器中的性能优化》

《<C++性能优化指南>推荐与批评》

《性能优化分享 -- static search set 篇》

《性能优化之—通才与专才》

有关性能优化部分，计划近期专门写一篇文章，详细总结下之前的经验，另外也总结下阅读过的比较不错的书籍，以及文章。希望通过那篇文章，给之前几年在性能优化方面做过的学习和探索做一个总结。

阅读原文

跳转微信打开

这一次我们聊聊软件测试，以及gtest

在《聊聊Google的工程实践（一）》，《聊聊Google的工程实践（二）》中，我们分享了代码仓库管理、构建系统、代码审查三个话题，有关Google的几本书，以及谷歌工程师的几个公众号。

这篇我们来继续分享软件测试这个话题。

Google的软件测试在业界是非常出名的，在上篇文章中，我们也介绍了Gtest的作者是华人。Gtest和GMock 在谷歌内部被广泛使用，

先说为什么软件需要测试？我认为有几个原因：

1，代码和bug几乎是伴生关系，再好的代码，也难免出问题。测试可以预防出现bug.

2,写实现代码，和写测试代码，有时候考虑事情的视角不同。这就和有了开发工程师的同时，也存在测试工程师一个道理。当我们编写测试代码时，我们更多地考虑边界条件，极端条件等，因此，在我们编写实现代码的时候，也有助于我们更好地处理边界问题。

3，测试代码一定程度上可以看成是教程，可以让使用者快速熟悉代码的接口，各种主要的接口和使用场景，使用方式。

4，在代码重构的时候，如果有足够多的测试代码，我们进行重构就比较大胆，敢于放手去做。我曾经重构过一个非常大的项目，好几万行的代码，但是几乎没有测试用例，代码的风格不说，代码的质量还比较糟糕，这时候就非常痛苦了，绝大部分人这时候会有心无力，无从下手，有一些还不错的人，会选择重写而不是重构。当时我的选择是，先引入Gtest，编写了一些单元测试用例，然后再进行大刀阔斧的重构。

5，用来保障依赖的代码不会引入新的问题，或者是行为的不同。比如，我们结合Jenkins等工具，定期编译主要的target，并且执行单元测试，就可以检测到一些依赖的库变更了，引入的新bug。这时候如果执行测试泄露检测，还可以预防一些内存泄露问题。因为这个原因，所以基础库的编写者，一般需要去编写更多的测试用例，并且在编译工具中，引入类似bazel这样的编译工具，以在提交基础代码的时候，能够编译所有依赖它的build target会不会被break。

那么，在那么多的单元测试框架中，我们为什么要选择Gtest呢？我们来看看谷歌官方对Gtest功能的介绍。

• An xUnit test framework.（xUnit is the collective name for several unit testing frameworks that derive their structure and functionality from Smalltalk's SUnit）

• Test discovery.

• A rich set of assertions.（断言丰富）

• User-defined assertions.（支持用户自定义断言）

• Death tests.（死亡测试）

• Fatal and non-fatal failures.（区分严重和不严重的测试失败）

• Value-parameterized tests.

• Type-parameterized tests.

• Various options for running the tests.（提供了不同的参数以运行测试）

• XML test report generation.（可生成XML格式的测试报告）

解释下几个概念：

Death tests.（死亡测试）：In many applications, there are assertions that can cause application failure if a condition is not met. These sanity checks, which ensure that the program is in a known good state, are there to fail at the earliest possible time after some program state is corrupted. If the assertion checks the wrong condition, then the program may proceed in an erroneous state, which could lead to memory corruption, security holes, or worse. Hence it is vitally important to test that such assertion statements work as expected.

Value-parameterized tests：Value-parameterized tests allow you to test your code with different parameters without writing multiple copies of the same test. This is useful in a number of situations, for example:

• You have a piece of code whose behavior is affected by one or more command-line flags. You want to make sure your code performs correctly for various values of those flags.

• You want to test different implementations of an OO interface.

• You want to test your code over various inputs (a.k.a. data-driven testing). This feature is easy to abuse, so please exercise your good sense when doing it!

Type-parameterized tests：Sometimes, however, you don't yet know all the types that you want to test when you write the tests.  For example, if you are the author of an interface and expect other people to implement it, you might want to write a set of tests to make sure each implementation conforms to some basic requirements, but you don't know what mplementations will be written in the future.

How can you write the tests without committing to the type parameters?  That's what "type-parameterized tests" can do for you.

以下是最新的Gtest高级用法的介绍，

https://github.com/google/googletest/blob/master/googletest/docs/advanced.md

大概看了下，发现我自己掌握的也只是其中一部分，可见Gtest的功能是多么强大。

那么Gmock又是干什么的呢？还是来看一下官方的解释吧：

Google's framework for writing and using C++ mock classes. It can help you derive better designs of your system and write better tests.

It is inspired by:

• jMock

• EasyMock

• Hamcrest

It is designed with C++'s specifics in mind.

gMock:

• Provides a declarative syntax for defining mocks.

• Can define partial (hybrid) mocks, which are a cross of real and mock objects.

• Handles functions of arbitrary types and overloaded functions.

• Comes with a rich set of matchers for validating function arguments.

• Uses an intuitive syntax for controlling the behavior of a mock.

• Does automatic verification of expectations (no record-and-replay needed).

• Allows arbitrary (partial) ordering constraints on function calls to be expressed.

• Lets a user extend it by defining new matchers and actions.

• Does not use exceptions.

• Is easy to learn and use.

不过Gmock的使用没有Gtest广泛，写起来也比较专业。在我过往的实际开发中，使用的频率也不算高。

几个总结：

1，软件测试是非常有价值的，不仅对测试工程师是必备技能，对开发工程师亦然。

2，测试驱动开发的理论和书籍，值得开发工程师去研究下。推荐下《测试驱动开发》这本书。有测试工程师的思维模式，对编写高质量的代码有帮助。当然，有产品经理的思维模式，对编写高质量可维护的代码也有帮助。

3，Gtest和Gmock值得广大C++工程师学习和使用。

4，很多工程师还没写过测试代码。

5，大部分工程师还不太会写测试代码。我面试过大量的工程师，工作中有过编写单元测试经验的不算多。而在我接触过的工程师里，能把单元测试写得比较好的，更是少见。

6，测试和重构有较大相关性。推荐看一些重构的书籍，这里推荐下《重构》这本书。

7，写测试框架也是很有含金量的。比如编写Gtest的作者，也就是上篇文章里介绍的老万，听说很早就是Google Staff工程师了，薪资不会低。

阅读原文

跳转微信打开

推荐基本和谷歌有关的书籍，以及几个前谷歌技术人的公众号。

在上篇文章《聊聊Google的工程实践（一）》中，我分享了代码仓库管理，构建系统，代码审查三个话题。文章末尾提到，还有一些话题会找个时间分享下。包括以下话题：

• 软件测试

• 调试与剖析

• 上线与发布

• 代码重写

• OKR

• 20%时间

• 绩效考核

• TGIF

• 谷歌的大佬们

没想到8个月过去了，这些话题还没开始写。这转眼今年都快结束了，给自己立了个Flag，打算最近两三个月把之前公众号文章里提到的所有未竟文章全部写完，我估计至少有二三十篇的样子，工作量应该不小，粗粗算下来，平均三天就需要写一篇文章了。不过幸好还有个国庆，国庆期间写个五六篇文章应该问题不大。

今天咱们先不展开技术问题，先来介绍几本和谷歌有关的书籍，几个前谷歌人的公众号吧。

先介绍读过的Google相关的书籍吧。有关谷歌，最知名的一本书可能是前Google CEO施密特的《How Google Works》，施密特都是谷歌的CEO了，内容怎么样就不做评价了。书籍链接如下：

另一本比较知名的可能是李开复的《世界因你不同：李开复自传》这本书了。书籍链接如下：

开复老师不仅在微软工作过，同时也是谷歌中国的开创者，对谷歌的理解，当然是旁人不能及的。这本书里，有关谷歌的部分内容如下：

第十章 谷歌的童话世界

感受谷歌

招聘的“魔鬼试题”

我的50位“关门弟子”

ICP牌照风波

做好搜索是谷歌中国唯一的出路

神奇的自我管理

坚守的意义

再见，谷歌

说到谷歌，一般会想到工程能力，会想到TGIF，会想到OKR等。最近OKR在中国企业圈非常火，包括头条等企业都在大规模实践OKR。正好前Google大中华区培训及发展负责人，在我目前的公司也工作过一段时间，后来创业的一个主要方向就是做OKR相关的培训，她对谷歌的OKR是非常熟悉的，有OKR方面的需求，可以搜索下她的相关文章。如果有需要培训的企业，也可以给我留言联系她。

最后推荐几个Google出来的技术人的公众号，都是低调有才的技术人。

第一个是目前创新工场CTO王咏刚老师的公众号「半轻人」，ID：ban-qing-ren，二维码如下：

咏刚老师非常多才多艺，写诗，也写小说，更写得一手好字。他之前写过几篇很不错的文章，有一篇更是总结了他在谷歌的一些工作经验，像《为什么AI工程师要懂一点架构》和《不装逼地说，在Google到底能学到啥？》这两篇，都是非常不错的文章。

前段时间发现，GTest（就是在谷歌内部甚至整个C++圈被广泛使用的单元测试框架）的作者也开通了公众号，名字叫「老万故事会」，ID：laowangushihui。这哥们更绝，别人是偶尔写点诗，舞文弄墨一番，他则是“偶尔写几个字，作点小曲”，卖的是文字+声音的双才艺，咱是真学不来。

有关代码审核和单元测试，他也写过几篇文章，比如代码审查的《我看代码审查（二）：修炼的要点》。公众号二维码如下：

明天开始，转入技术话题分享。

阅读原文

跳转微信打开

本公众号推出AI有声版

最近公司做了个新产品——「AI魔音」小程序，我使用这个产品，将公众号内容搬到了小程序上，之前推送过的公众号文章，目前都有了音频版本了，总共大概180篇。欢迎读者朋友们扫描下面的二维码，「收听」本公众号的历史文章。

除了提供公众号的音频化功能外，「AI魔音」小程序上还有不少好玩的AI功能，好奇的读者可以上去看看。

阅读原文

跳转微信打开

欢迎各位关注我的视频号，会有一些好玩的AI产品和不一样的分享。

跳转微信打开

员工离职，怎么留人？

配音由出门问问「魔音工坊」提供技术支持

在上篇文章《管理者的几个特殊能力》中，最后一部分谈到了离职留人的难处，不过文章只是提到了难处，并没有提到我怎么解决难题的。这篇文章简单展开讲讲。

上篇文章提到了七个点，这里也按照这七个点顺序展开吧。

1，管理者最痛苦的事情莫过于，自己欣赏的人要离职，自己却无法留住他。不能说我多么优秀，但是现在的我挺能体会我的leader留我的无奈。

管理者对优秀员工的离职，一般心里很难受。员工离职，无非是公司不行，或者团队不行，或者leader不行。而作为公司的管理层，或者作为团队的leader，你责无旁贷。

我第一次离职的时候，我的leader多次找我沟通，并且让CTO找我沟通，都未能让我留下。在我工作半年后，我约他一起吃饭，吃完饭后，他让原公司的HR再次联系我，邀请我回公司。对于他的重视，我一直心存感激。

我的第二家公司发展一般，在我离职的时候，不少优秀人才已经选择离开了。这个时候我反而会劝说一些还不错的员工，尽早离开，找一个更好的平台。

在我目前这个公司，也有不少还不错的团队成员离开。记得我刚来公司的时候，招聘了一个蛮不错的员工，工作半年左右，就选择了离开，有一次团队一起吃饭，他竟然哽咽了。有时候优秀员工选择离开，只能祝福了。

随着团队管理职责的扩大，后来我也负责一部分UI，测试，产品，项目等。在不同角色间沟通，其实挺有意思的，给工作带来不少新鲜感。不过这时候有团队成员要离职，就不如技术人员离职那般容易应对了。毕竟，他们的职业路径是怎么样的，上升通道在哪里，工作诉求是什么，虽不能说完全茫然，却也说不上了然于胸，毕竟一个管理者不可能深入了解所有的工种。

2，当你的同事一口咬定要离职，绝口不提真实的离职理由的时候，你怎么继续有效沟通，找到突破口？

大部分人离职的时候，都会显得非常的决绝。很多时候，理由很简单，世界很大，我想出去看看，我在这边已经呆了两年了，需要改变。

这类理由说起来很容易反驳，比如我会结合自己的经验，告诉他，其实目前的团队还不错，技术在业界也还比较受认可，你自己的能力呢，在公司内，也有很多可继续学习的地方。公司内也有不少优秀的人可以帮你进一步成长。

我曾经有一次给我前CTO打电话，当时我还没有大公司的工作经验，想要有晋升技术总监的机会，觉得很难，想问问他有什么职场经验。当时他告诉我两点：第一，我第一次跳槽其实对职业生涯帮助不大，除了团队管理经验，技术上并没有太大的成长。第二，不管有没有大公司的机会，优秀的人，努力工作，时间到了自然有升职的机会。果不其然，我在半年后左右，升职为技术总监。其实对公司而言，贡献才是最重要的绩效衡量指标。背景和出身虽然有帮助，但是并不能带来必然的帮助。比如我认识的某个人，百度出来，在小公司里就一直没有能够晋升为总监，一直是资深工程师或者架构师的角色。

说回来怎么找到离职原因的突破口。紧紧咬住不说的时候，不妨先充分肯定该同事的绩效和努力，然后找一些常见的原因，结合他的实际情况，尝试分析分析。比如，是否是因为这次的绩效考核不及预期？如果是的话，应该解释一番，奖励不够好，不是你本身绩效的问题，或者是你虽然很优秀，不过有一些地方做得更好的话，未来会有更优秀的绩效表现等。再比如，是否是因为工作方向不喜欢，或者觉得工作挑战比较小？如果是的话，帮他分析一下他目前的工作，看看是否可以做一些调整？一般工作调整最好是在组内，如果组内的工作都无法满意，可以尝试在公司内帮他找找其他方向，毕竟，优秀人才的离职，对公司都是很大的损失。

再比如，是否是因为工作压力太大了，天天解bug, 压力大的同时，还心情烦躁？还有一个比较常见的原因是，外面有别的机会了，并且薪酬更高。这时候可以以闲聊的方式，问问他如果外面找工作的话，会找什么样的机会，大概的薪酬会是怎么样的？

总之，绩效不满意，工作压力大，家庭原因，外部机会，工作方向等，都是很常见的离职原因，大概以这些方向去试探下，很多时候还是可以问出一些眉目的。

3，提了离职后，真的可以留住他么？怎么打消他留下来后心里的膈应感？大部分人提了离职，感觉都当了一次叛逃者，觉得对不起leader，没能一起同甘共苦。那么从挽留者的角度，如何打消他的这种顾虑，让他放心留下来呢？

一般业界的看法是，提了离职，一定不要留下来，所谓好马不吃回头草。其实我觉得大可不必。还是以我自己为例，我第一次离职就有点后悔，毕竟第一家公司虽然发展一般，但是团队里还是不乏让自己技术上持续成长的牛人的，只要自己足够好学，快速成长是不缺环境的。我觉得当初我要是直接说了我在外面的薪酬，公司也满足我的薪资预期，我就应该继续留下来。当时没什么经验，觉得答应了下家公司了，就不应该反悔，咬紧嘴巴绝口不提离职是因为薪酬等元素，现在想想都觉得当时太嫩了。

我在目前的这家公司呆了五六年时间了，其实中间也提过离职，但是被公司留下来了。留下来后，我并不会觉得不自然，反而工作更用心。我的逻辑很简单，既然选择留下来了，就收收心，好好干。

那么，作为leader，我也留过一些人。我会不会对曾经提过离职的人打了特殊的标签呢？其实不会。愿意留下来是信任leader，既然人家放着外面的机会不走，愿意继续跟着团队，我们就更应该让他在团队得到成长，让他工作更舒服一些，更能得到施展，否则就浪费了当时的一番口舌了。

能一起工作本身已经是缘分，提了离职，被留下来了，能继续共事，更是难得的缘分，作为Leader，万万不可辜负这份信任。留下来后，作为Leader，应该偶尔找个时间和他一对一聊聊，看看是否能在工作上提供一些帮助。

4，有些人还没找到机会，裸辞也要走，人很优秀，你怎么想办法让他多留一段时间？优秀的人往往性价比很高，能多留一段时间，对公司都有好处。

一般，优秀的人都是得到团队成员认可的人。得到认可的人，往往和团队都有一定的感情。如果说确实留不住了，而公司又需要他，比如项目很紧迫，他又是关键角色，这时候和他有话直说，他一般都会从公司角度出发，作出一定的配合。毕竟，只要答应了他的离职申请，过段时间他离职也会比较顺利，多留一段时间本身问题并不大。

一般，优秀的候选人，下一家都可以多留一定的时间等他入职。有时候，员工离职其实只是想先休息一段时间，并不一定是找好了下一家。

5，被挽留者已经找到了很多工作，有一些offer虽然现金增幅不大，但是公司是巨头，同事们有大厂镀金的情怀在，怎么告诉他，优秀如他，在小公司也能有足够大的成长，小公司也不会有程序员的中年危机？

要打消大厂镀金的想法，其实挺难的。不过我一般会举几个身边的例子。说起来，大部分小公司里，都会有不少BAT等大厂过来的人，毕竟BAT等公司一年离职的人没有几千也有几百。对一家独角兽级别的公司而言，来自谷歌、微软、雅虎、BAT等公司的员工更不在少数。举出公司内外的一些例子，其实都能给准备出去镀金的人一些实在的例子。

其实我也认识一些在BAT工作了几年的人，目前并不太好找工作的。对创业公司的招聘者而言，我们反而更喜欢那些在创业公司历练的人，他们往往身经百战，能够有更好的灵活性，能够有更宽广的技术视野等。

说起这个话题，我记得我之前写过一篇文章，文章名为《30了，程序员中的老司机们，30后的路该开向哪里？》，虽然文章有贩卖焦虑的嫌疑，不过还是写得很认真的，没读过的朋友可以读一下。

6，被挽留者的offer虽然不是大公司的，公司不怎么样，甚至风险很高，但是给的待遇非常高，怎么挽留他？

这个时候，根据公司的情况，以及团队成员薪酬的情况，量力而行吧。如果他的薪酬确实在团队内比较低，看看是否能给他争取下，适度平衡。

如果他经济压力非常大，哪里钱多就去哪，那怎么挽留也没有用。不过就我的经验而言，一般人不至于靠跳槽去赚钱，毕竟钱都不是天上掉下来的，大部分招聘单位都不太可能花两三倍的价钱挖人。一般调整下工作内容，做一些后续工作规划梳理，加上一定的加薪平衡，还是有机会挽留的。当然，前提是公司的情况还不算糟糕，他本人对团队也还算认可。

对团队不认可的人，没必要做挽留。留下来只能是对团队的伤害。不过虽然没必要挽留，问一问他对团队管理的意见，有什么对公司的建议等，还是有必要的。毕竟，没有无缘无故的恨。

7，当前薪资和他拿到的offer落差大，但是团队当前的整体薪资并不高，不加不能留下他，加了团队容易失衡，怎么办才能两全其美？

如果出现这种情况的例子很多，说明团队的薪酬在市场上缺乏竞争力了。这时候应该向公司的HR反馈，甚至向公司高层反馈。

团队内部的薪酬平衡是非常重要的，如果这个候选人对公司足够重要，或者目前的重要项目因为他的离开，会有较大的风险，这时候不妨试试使用长期激励（比如期权）来平衡，或者是申请给以一次性的奖励。一次性的奖励意味着，base还是大概平衡的。如果因为他要离职，为了匹配他拿到的最高薪酬，而把他的薪酬调整到不合理的水平，引起团队内部失衡，反而得不偿失。这时候往往应该放手让他走，降低对现有团队人员的影响。

当然，他离职了，估计团队内的人员也会大概知道他在外面拿到的薪酬，所以根本的解决方案只能是，让公司的薪酬能够基本匹配市场价格。而公司能给出匹配市场水平的薪酬，其实离不开大家的共同努力。作为Leader，做好平时的工作，加强团队管理，让团队成员更好地成长，并且让团队的成长促成公司的成长，是主要职责所在。

阅读原文

跳转微信打开

给「技艺丛谈」公众号创建了几个专辑，方便大家阅读

系列一：职场分享系列

系列二：技术文章系列

系列三：面试攻略系列

系列四：文艺闲笔系列

系列五：卜雨文丛系列

欢迎大家阅读

阅读原文

跳转微信打开

继续聊聊管理工作中踩过的坑。本文体验下付费阅读功能，90%可免费阅读。

配音由出门问问「魔音工坊」提供技术支持，音频版本包含全文

在上一篇文章《聊聊技术管理》中，我分享了一些技术管理的经验。这篇继续聊聊以下话题：管理者需要刻意练习的能力，我踩过的一些坑，管理角色的思维模式和普通开发者的差异，管理者需要有意回避哪些普通开发者的思维模式等。

这篇文章不再强调技术管理，而是聊聊管理岗位都有的问题。

管理者需要哪些能力？自律的能力，招聘的能力，留人的能力，解决问题的能力，遇到问题迎头而上的勇气，打鸡血的能力，确定优先级的能力等。下面一个个展开聊聊。

1，确定优先级的能力。

大部分人都很清楚哪些事情比较难，哪些事情对自己的成长比较有帮助，但是其实很少有人清楚地知道哪些事情更有价值。这个一方面是公司层面需要做好上下信息流通，战略的同步和信息的透明度，另一方面，个人也需要做到要事优先。有时候老板们觉得重要的事情，因为没有不对称，员工们并不知道其重要性，一旦事情的发展出现差异，就会导致出现信任危机。

对公司而言，优先级的确定，就是战略部署问题。对员工而言，优先级的确定，就是将个人精力投入在最有价值的事情上。最有价值的判断，是企业需求和员工诉求结合起来看的。比如我熟悉搜索技术，但是公司并不需要太强的搜索能力，这时候我死磕搜索，就无法最大发挥个人价值，一方面公司觉得花了高薪，产出却不符合预期，对员工有抱怨，另一方面，员工觉得自己的才华没有施展的舞台，浪费了青春，对比外面的机会和高薪，也会对企业有抱怨情绪。那么，怎么去避免类似事情的出现，就是管理者需要去思路和解决的。

那怎么办呢？管理者应该定期和员工一对一沟通，了解个人在公司的发展规划。假如个人能力很强，觉得现有岗位施展不开，这时候可以看看是否有其他事情可以去做，同时兼顾现有项目的开发。大部分工程师都觉得热门的方向好，天花板高的职位好，其实不一定。一方面，其他方向不一定适合你，另一方面，你个人的技能积累也无法有效发挥。管理者要做的是，这个人如果调整岗位，那么对现有岗位的人员会不会有不好的影响，如果不调整工作方向，该员工离职，对企业损失大不大，相比其他岗位新招聘一个，该员工转岗是否性价比更高？

确定优先级当然可以使用一些工具，比如OKR工具。每个月的工作重点是什么，定期写出来，防止自己忘了。另外， 管理者应该经常去梳理目前的工作，看看哪些工作是比较有中长期价值的，哪些事情是目前火烧眉毛的，哪些事情是有技术壁垒的，哪些事情值得重兵投入，抢占时间？

不过如何确定优先级，对个人很难，对管理者也不容易。很简单的道理，我们从小到大都有年初做计划的习惯，日记里、朋友圈里立个flag, 今年要做什么，达成什么什么目标，但是能够定期去review目标的完成度，甚至做到提前完成，这事儿说起来容易，做起来却非常难。人都有惰性，那怎么办呢？看下面的一条。

2，自律的能力。

说到自律，我做得也不好。比如，每天准时上班这一条我就没能做到。有不少人能做到。比如业界都比较熟悉的陆奇。我之前曾经接触过美国微软的一位朋友，级别不低，他说他每天早上7点左右准时到公司，看一些文章，了解业界的发展现状，确保不会落伍。等大家都陆陆续续到公司后，他已经上班两三个小时了。当时我很佩服。我问他，那你几点休息呢，他说9点左右。虽然休息比较早，很多人觉得，你看我每天2点才睡觉，10点上班，其实差不多。不过能坚持每天早早到公司，比很晚离开更考验自律能力。何况，你每天10点上班可以做到，但是你每天都2点睡觉可以一直坚持么？可以晚睡，但是你能做到每天2点前都花两三个小时学习么？

反正我是还没能做到。也许有一天也可以做到？目前我连每周坚持写一篇公众号文章都无法长期坚持下来。

团队做到没有人盯着都可以高效运转并不容易。大部分公司都是老板出事了公司就黄了或者开始走下坡路了。一方面当然我们需要建立高效的组织文化，让组织能力自我发展，搞接班人计划等。另一方面，还没到这一步之前，作为管理者，应该做到以身作则，严于律己。做项目的时候，尽最大的努力推进，不管是谁成为了项目的阻力。碰到问题，想尽一切办法解决，包括自己撸起袖子干，找外面的朋友帮忙，协调团队里的其他人帮忙等。

另一点比较重要，做到坚持学习，保持头脑开放，永远不要被自己的以往经验束缚住。你要是习惯早起，就每天早期学习一会。习惯晚睡，那就睡前学习一会。看不进去前沿的论文吧，那就看看综述文章，哪怕看看行业内比较优秀的公众号文章也行。总之，让自己和这个时代保持同步。

假如一个管理者有一天突然发现自己连公司推行的代码风格，公司主要技术使用的术语，日常线上服务使用的技术和服务都开始陌生，那基本就和时代脱钩了。这时候管理经验再丰富，其实也无法高效推进实际的项目了。

3，打鸡血的能力。

打鸡血挺难的，很多工程师不喜欢夸夸其谈的领导。但是怎么让大家的工作情绪调动起来，建立起足够的技术自信，能够在繁琐的工作中，保持对技术的热情，保持对勇争行业第一的渴望。不要让员工因为公司的发展瓶颈，因为业务的调整，因为研发资源的缺乏，因为有巨头在竞争，就不断被消磨斗志，是非常考验每个管理者打鸡血的能力的。

人们总是更容易看到别人的光鲜。但是级别越高的人，越知道大家彼此的难处和不易。那么，怎么让员工看到问题的时候，做到更加理性，就需要管理者能客观进行分析，同时适度打打鸡血了。比如，强调下公司的积累，公司在行业中的角色和位置，团队的优势，部门内外的一些新进展等。很多东西，埋头做事的工程师看不到，所以管理者应该及时输出正面信息，激励团队。

有时候公司出于一些特殊的考虑，减少福利等，本来是芝麻蒜皮的小事，但是往往员工角度看，会觉得公司克扣员工福利，甚至推论出公司每况愈下，公司快黄了的结论。正如小事容易引起员工情绪上的波澜一样，适度的沟通和打打鸡血，甚至说一两句鼓励的话，都能对员工情绪起来正面作用。

这方面我也有一些教训。前几年做过一些比较复杂的项目，项目难度大，周期长，很多同学的工作很大一部分是解bug, 导致长久下来情绪比较烦躁。大概没有任何工程师愿意天天解bug吧，大家都喜欢重新造轮子，原因之一可能就在于，造轮子毕竟对工程师是新鲜的，造出来甚至挺有成就感的。但是你给一个现有的轮子打个补丁，做点补轮胎的工作，估计没几个月能做出来成就感。有部分同事平时非常尽职尽责，项目需要的时候经常加班到很晚，看起来鸡血满满，但是到了离职的时候，我们经常发现，他们的消极情绪已经累积很久了。消极情绪需要找到合适的出口，并且定期得到发泄。另一方面，适度的传递正面的信息，打打鸡血，往往容易对公司和团队更有信心。

4，招聘留人的能力。

先说每个管理者在成长的路上都需要迈出去的一步：裁员。公司在顺利的时候，大部分管理者都不需要去主动裁员。但是在整体经济不景气的时候，在碰到疫情类似特殊情况的时候，在部门业绩糟糕需要做业务调整的时候，需要裁员怎么办？裁谁？裁贵的还是裁便宜的？是一起裁员，还是一次几个？如果需要优化掉的人，是你非常熟悉的员工，怎么办，你怎么去做沟通？

有些人素质很好，但是因为在公司的主要技术方向或者业务上，并没有发挥很大的作用，但是入职时候的薪资却不低，这时候是优化掉呢，还是让他转岗换个方向呢？有些人素质一般，潜力不算非常突出，但是薪资低，性价比很高，是否要优化掉？有一些角色其实没那么重要，但是如果优化掉了，一些聪明人可能就得天天做一些琐碎的工作了，在聪明员工看来，可能就是脏活累活了，在这些聪明员工看来，工作的体验就差了不少了。

上面的这些问题，都是管理者面临的头疼的问题。也并没有非常好的解决方案。总体而言，抱着公司利益最大化，团队利益最大化，个人诉求和团队诉求匹配的角度来衡量吧。另外，抱着对个人负责的角度去沟通，如果说个人确实在公司找不到很好的价值定位，让他另谋其他岗位，未尝不是对个人好，对公司也不差的选择。

接下来说说招聘。招聘的难点在于：

1，公司融资很多的时候，着急招聘很多人，但是招聘速度跟不上怎么办？公司发展一般的时候，说好的HC突然又冻结了怎么办？

2，招聘太聪明的人，自己不一定能很好地管理怎么办？

3，候选人和岗位很匹配，但是潜力一般怎么办？

4，好不容易找到了个不错的候选人，但是候选人每次都拿到一堆大公司的offer，我们怎么说服他们加入团队？

5，某个团队现在素质都不错，大家协作也挺好的，但是缺一个leader， 而你自己又没有足够的精力去做好日常管理，是否应该招聘一个leader过来？leader进来了团队成员是否可以接受？不接受的话，是否反而把事情搞砸了，反而给团队管理带来更大的挑战？

6，校园招聘到底是去北大清华碰碰运气，和巨头硬碰硬抢人呢，还是可以去二线城市试试看？鸡头还是牛后比较好？

7，看到一些候选人，聊下来感觉能力还不如自己，但是在之前的岗位上，薪资比自己却高得多，心理失衡怎么办？

8，一些岗位自己并没有经验，怎么有效甄别候选人？比如你是技术出身的，但是要你去面试产品，设计，或者是商务，你怎么快速找到切入点去考察？再比如，你是做后端的，怎么去面试前端工程师呢？看到简历上一堆不认识的技术术语或者框架，你怎么找到合适的考察点？

9，候选人的薪资预期，谈一次高一次，人才难得，弃之可惜，怎么去争取？

招聘进来，怎么让他快速熟悉团队，怎么快速发挥他之前的技术积累？如果不合适的话，是快速调整他的方向呢，还是在未转正之前就优化掉？

最后聊聊留人。也许没有比留人更难做的管理工作了。对离职的人来说，很难做出离职的决定。如果团队leader你还比较欣赏，找个离职理由都会想破脑筋。我曾经用过以下理由：1，想去学学技术，精进一下。2，公司挺好的，leader也挺好，但是我想去试试新的机会，尝试下不同的业务方向。3，想换行了。

这里展开下换行这个故事。我在12年的时候，刚硕士毕业一年。那会的leader是谷歌出来的，对我个人的成长有很大的帮助，技术能力让让人心服口服。但是当时公司发展不算好，加薪幅度不及预期。而这时候有个leader的机会，我就决定了要离职。那会因为公司还给我办理了户口，还是通过特殊渠道办理的，我其实对公司心存感激，但是带团队的诱惑让我已经跃跃欲试了，加上薪资的变化，让我离职想法很坚决。我那会和leader沟通的时候，想了个理由说，我表哥来北京发展了，我打算和他混去。当时我表哥确实来北京发展了，在北京开了家茶叶公司，并且把总部从福建迁移到北京来。不过其实行业差异太大，隔行如隔山，我真去帮他的可能性基本不存在，估计我的leader们也绝不会相信。不过我死咬住离职理由，我的leader也找不到合适的理由让我留下。为了在离职前证明我没有欺骗他，我还在临近离职的时候，送了我的leader一袋我哥公司的茶叶。现在想想，我那会真是戏多。当时很少跳槽，所以对加薪50-70%幅度还是缺乏抵抗力。其实薪资不高的时候，跳槽加薪幅度比较高的机会挺多的，大可不必那么着急。

再说说离职留人的难处：

阅读原文

跳转微信打开

创新工场CTO王咏刚老师有关团队管理的精彩分享

速度和质量不可兼得？

超喜欢看2019年的电影《极速车王》（其实更贴切的译名应该是《福特大战法拉利》）。很早就知道勒芒24小时耐力赛是个苦差事，但缺少直观体验。看到电影里的主角驾驶赛车在雨夜赛道上一圈一圈狂奔的镜头，才觉得无论是人还是车，根本就是在挑战地球人的极限——这比赛的设计真心变态，敢于挑战的人和车真心厉害！

很自然想到创业，想到打造一个过硬的产品研发团队的种种艰难。和勒芒24小时赛道上飞驰的赛车相仿，运营一家高科技企业，或打造一个过硬的产品研发团队，也需要不断挑战速度和质量的极限。

（1）速度：单就打造产品研发团队这件事儿来说，速度通常反映在很多指标上。最核心的速度指标至少包括企业的销售收入、销售利润、用户量、增长率等等。有些指标虽然表面看也是“速度”，例如团队增长速度、资金消耗率、产品发布迭代速度甚至每周代码的累积数量，但它们并非任何时候都和企业的终极目标紧密相关。

（2）质量：相当于勒芒赛车所追求的“耐力”或“稳定性”。研发团队的质量差不多等同于研发团队的价值。这方面的指标通常包括团队拥有的人才价值、知识产权价值、团队的技术领先程度、产品的竞争优势、产品的平均毛利率、产品的平均实施与维护成本、用户满意度等等。

创业公司和发展期的产品研发团队经常出现偏重速度而忽视质量，或者偏重质量而忽视速度的情况。两者都不可取。过于重视速度的团队就好比开着一辆冲刺速度世界第一，但跑起来经常会发动机爆缸的赛车参加勒芒耐力赛，过于重视质量的团队则相当于小心翼翼驾驶着数万公里无故障的家用轿车去勒芒丢人现眼。

比如，有的团队用简单的绩效指标统管所有团队行为，KPI指挥棒总领一切。人都不傻，如果个人所得仅仅和几个简单的KPI数字正相关，那我做事的时候，自然就只会选能直接刺激数字增长的事儿来做。既然“卖得快”指挥一切，那中长期的技术积累肯定会让位于短期的功能“拼凑”，用户的使用体验肯定会让位于简单粗暴的流量拉升，公司的长期成长肯定会让位于今年底是不是能拿到150%的奖金回家过年。

这种用KPI一刀切的团队最常见的结果就是留不住关键人才，产品研发后继乏力，飘红的销售业绩下面暗藏产品同质化竞争严重、售后成本居高不下、毛利率越做越低、团队越做越疲的危机。

再比如，有的团队笃信技术的价值，围绕着某种产品理想闭门造车。研发上烧钱的速度比谁都快，在顶级学术会议发论文、在国际竞赛拿大奖的次数比谁都多，但就是很少有人抬头看一看自己研发的产品好卖不好卖。

另有一些团队则非常坚定地强调内部管理流程和内部文化建设，花费大量资源建立复杂的项目管理流程、质量管控流程、风险防控流程，才几十上百人的团队就参照几千人、几万人的大企业做法，用标准化、数字化、流程化的管理统领一切，产品研发团队的工程师每天花在写文档、填表格、发申请、求审批的时间甚至多于钻研算法、写代码或设计产品的时间。

这两种高度重视质量却忽视速度的团队，大概都会走到对市场变化反应迟钝、高科技拼不过接地气儿、下个月再不融资就前功尽弃的尴尬境地。

速度和质量不可兼得？当然不是。就像跑勒芒耐力赛一样，速度第一，业绩第一，但团队质量也要跟得上。不能极速跑了几圈就开始掉零件。掉车漆、掉翼子板都还好，要是震断了车轴，震坏了离合器，那这比赛就麻烦了。所以，在保证速度第一的情况下兼顾质量，保证赛车不散架，保证企业不会一上市就跌停，这是打造成功的产品研发团队的最低标准。

简单说，就是要打造速度与质量均衡的产品研发团队，既要飞驰，又要稳健。

小工具：弹力矩阵

如何均衡速度与质量？精通企业管理的人有各式各样高明的方法论。我不是管理学家，只是身为工程师和研发管理者，二十多年里，先后在企业级解决方案提供商、世界顶级的互联网科技公司、科技型的初创公司等不同环境里实践、摸索、总结过一些研发管理的小经验、小技巧和小工具。

很愿意跟大家分享一种我自己常用的思维模型——弹力矩阵。

弹力矩阵是从矩阵式管理的方法论中借鉴来的模型。一个产品研发企业，从工作职能维度，大致包含市场职能、销售职能、咨询和售前职能、定制开发和实施售后职能、产品研发职能、探索预研职能等。从产品是否成熟的维度，大致可以分为成熟产品、新产品和预研产品三大类。这两个思考维度相互交叉，共同构成了一个产品研发企业的基本矩阵：

如果只考虑汇报和管理关系，上述示意图就大致回归到了“矩阵式管理”的范畴内。例如，一个企业可以根据不同类型的产品，将所有团队成员分配到不同的产品事业部（或产品线、业务线、业务单元、产品或聚焦领域等其他称谓，内涵上大同小异），而每个事业部又可能同时配备市场团队、商务和咨询团队、实施服务团队、产品研发团队等。每个具体的员工既属于某个特定的职能团队，又属于某个产品事业部，存在逻辑上的双向汇报关系，如下图：

那么，我所说的弹力矩阵又是怎么回事儿呢？

简单说，当管理者开始考虑如何在上述矩阵型组织架构中配置各类资源（包括人力资源、财务预算、渠道和市场资源、战略资源等）时，上面的矩阵就会摇身一变，成为我推荐大家使用的弹力矩阵模型。

在弹力矩阵里，每个格子都像一颗有弹力的啫喱糖，在各自的弹力范围内，可以或上下、或左右地延展、收缩。一个企业内部的产品研发管理，往往是在统一的企业目标指引下，在动态变化中不断调整每颗“啫喱”的长、宽乃至“重量”，以达到速度和质量的最佳均衡。所以，弹力矩阵也可以被叫做“啫喱矩阵”。

肯定不能将公司的资源平均分配到矩阵的每个格子里——这不成了又懒又傻的“自杀式管理”了吗？除了管理者的个人经验，还有哪些简单易行的思考方法，可以帮助我们决定资源在整个矩阵里的分配方式呢？

根据我个人的心得，要达到速度与质量的均衡，关键是三件事：

双向均衡，压力缓冲，动态响应。

双向均衡用于优化全局资源规划，压力缓冲用于优化管理细节，动态响应用于优化企业对外部挑战的实时应对能力。

双向均衡

企业资源在弹力矩阵上的分配是二维的。无论是工作职能的维度，还是产品成熟度的维度，分配时都需要考虑均衡的大原则。

先考察产品成熟度这个维度：通常，有经验的管理者仅凭直觉就会为已经成熟并可以带来大笔销售收入的产品分配最多资源，为新上市但前景不明的产品分配较少但更具战略意义的资源，为面向未来但存在较高风险的预研产品分配最少的资源。

但这种根据产品成熟度分配资源的方式有没有可量化的指标呢？我个人喜欢用 “称重天平法”来完成定量计算。称重天平法所“称”的是我们在每一类成熟度不同的产品上所分配资源的“重量”。这个“重量”的计算方式很简单：

重量 = 面积 x 密度

上式中的“面积”，就是弹力矩阵中相应小方格的面积，也就是我们分配在此类产品中的资源数量（例如，这个产品事业部或产品线某一年的人力成本）。

上式中的“密度”，我把它定义为以年为单位的，该产品达到可大规模推广状态所需的时间。

比如在上图中，假设我们为成熟产品、新产品、预研产品分配的企业资源的大致比例是5 : 2 : 1。成熟产品目前已经处于大规模推广状态，我们将它的密度记为1；新产品在第2年才可以达到大规模推广状态，它的密度记为2，预研产品有可能（但风险较高）在第4年达到大规模推广状态，它的密度记为4。那么，三种产品线所分配资源的“重量”就分别是5x1，2x2，1x4。

如果在三种产品线的“重量”下面加一个天平，很容易知道，整个天平的均衡点位于新产品所在的矩形块下方稍偏成熟产品的位置。这个“均衡点”的含义也很简明，就是管理者在覆盖不同产品线时，精力的分配重心在哪里。

上图是一个相对均衡的资源分配方式：公司超过一半的资源分配在成熟产品的市场、销售、服务与研发迭代上，但管理者的精力重心则会从新产品出发，同时向成熟产品和预研产品辐射。

新产品、预研产品的所谓“密度”，其实反映了他们对于一个企业的战略价值。成熟产品是可以装在口袋里的“现钞”，但因为已趋成熟，可以较少分配管理者的精力。新产品是接下来一年内就可能成为公司业务支柱的战略重心，需要管理者集中精力打造。预研产品的战略意义在四年后才可能出现，虽然战略价值重大，但风险也高，无论是直接投入的资源，还是管理者的精力分配，都必须保持谨慎。

至于已过气、走下坡路的产品，它们在上述均衡图中的“密度”可以是“0”。这样，管理者即便在过气产品上分配了少量资源以维持已有客户，管理均衡点也不会被过气产品牵扯过去。

管理均衡点过于偏向于成熟产品或过于偏向新产品和预研产品，都是极度危险的。我们不妨试着回到1984年1月的苹果公司，看一看当时苹果的三条产品线：

• 曾经辉煌，但仍保持了稳健销量的Apple II（以及失败的Apple III）

• 高举高打的开拓型产品Lisa——其实更像是乔布斯个人风格的实验型产品

• 代表图形用户界面未来的Macintosh——苹果支撑未来销售的主力机型

如果你处在CEO斯卡利或创始人乔布斯的位置，你会将公司资源按照什么方式分配到三条产品线呢？作为苹果最重要的创始人和新产品线负责人，当时的乔布斯把主要精力花在了实验型产品Lisa与新产品Macintosh的研发与营销上，甚至利用自己创始人的身份在资源分配上极力挤压成熟产品Apple II的团队。一旦 Macintosh及Lisa因为产品和销售原因在市场上表现不佳，苹果内部管理的问题就被激发出来，Apple II团队的不少核心员工相继离职。后来斯卡利与乔布斯的矛盾闹到不可收拾的地步，虽然原因很多，但显然也和乔布斯在资源分配上的执拗、失衡有关。

同样，从弹力矩阵的另一个维度——工作职能——来看，管理者也需要小心调整资源分配方案，保证资源和管理精力的平衡点处在最符合业务发展方向的位置上。

例如，上图是一种面向最终消费者的产品研发团队按工作职能划分的资源分配方案——想象一个研发手机版日程管理工具的创业公司。在这种类型的研发团队里，因为要激活的是个人用户的使用和购买欲，市场和渠道需要资源相对较多，咨询和定制服务几乎不存在，产品研发需要的资源也远多于探索预研。

我们同样可以将不同工作职能所对应的战略价值作为“密度”数值带入重量公式。由此，在上图中，管理者的精力平衡点大致会落到市场、销售和产品研发之间的位置。这符合许多成功的消费者产品的常见资源分配模式。

上图则是典型的以企业解决方案为主要产品的团队资源分配方案——想象一家为企业客户提供私有部署的人力资源管理软件的创业公司。大多数此类企业都具有对销售依赖程度高，项目周期长，实施和维护成本高，相关的咨询、售前和定制开发团队规模较大的特点。

在上图中，资源相对平均地投入到各个职能部门，但因为企业的核心业务模式是销售导向（图中销售方块具有最高的战略价值或“密度”），管理者的精力平衡点必然会向销售或咨询、售前端倾斜。

同样是企业级服务，如果占据了技术制高点，并多以产品而非定制解决方案的方式获得销售收入，这样的团队在资源分配方式上就会有很大不同——想象一家技术领先并主要通过SaaS或云服务方式销售的企业级数据智能产品公司（美国此类型成功企业的数量要远多于中国）。尽管在这种团队内，市场和销售的战略地位仍相当重要，但产品的高毛利空间主要来自于领先竞争对手的技术。这样一来，管理者自然就会为产品研发和探索预研赋予较高的战略权重，整个模型的均衡点会大幅向研发职能倾斜。

在产品成熟度和工作职能两个维度上做双向资源均衡，就得到一个完整的弹力矩阵了。不同企业有各不相同的弹力矩阵，不同企业的不同阶段也有必要选择最适合当前情况的弹力矩阵。

例如，下面这个企业的弹力矩阵是否做到了速度与质量的均衡呢？

上图存在好几个明显不均衡的地方：首先，整个企业没有为战略探索和预研分配任何资源，这基本说明了该企业对未来可持续发展的冷漠态度；其次，成熟产品和新产品之间的资源分配比例过于悬殊，大部分资源用于获取看得见的“现钞”收入，对成熟市场被过度“收割”后走下坡路的风险缺乏警惕；再次，即便只考虑成熟产品线内部的资源分配情况，该企业为销售、定制开发、实施和售后配备的资源也过于庞大，势必影响到产品本身的研发迭代，使得产品在市场上逐渐沦为平庸。

有没有更均衡的弹力矩阵的例子呢？

上图这个按照事业部来管理不同产品线的企业在成熟产品事业部、新产品事业部和探索型产品事业部之间，由多至少，分配了相对均衡的资源：较大比例的资源保障被放置在成熟产品、成熟市场中，以获得足够的销售收入；较小但仍然充足的资源被放置在新产品事业部，以保证中短期内可以创建另一个业务增长点；少而精的资源被配置在探索型产品事业部，算是对未来所下的一个“赌注”——也许胜算只有五成，但却有可能为企业带来巨大回报。

这个企业不仅在产品成熟度维度做到了资源均衡，在每个产品事业部内部，又根据各自产品的特点，对各职能的资源分配进行了灵活调整：成熟产品需要尽力推广、完成实施并收回货款，因此商务、实施、售后团队规模相对较大；新产品需要调研和开发，因此市场、咨询、研发团队的规模较大；探索型产品需要集中精力搞科研，研发团队占比最高，甚至还成立了相对独立的科研实验室或企业研究院，用于建立差异化的技术优势。

总体来说，这个企业的资源分配重点突出、兼顾均衡。既有保速度、保业绩的决心，也有保质量、保未来的魄力。

压力缓冲

企业的弹力矩阵如何布局，这是企业管理层的规划问题。但在执行层面，弹力矩阵还必须具备缓冲压力的结构或能力。这就像一辆赛车在高速行驶时，必须有适应赛道的减震器，要不然，赛道上的任何颠簸都直接传导到关键零部件上，那比赛时不乱掉零件才怪。

如果外部业绩和市场的短期压力毫无阻碍地直接传导到企业内的每一个职能部门，甚至每一个员工身上，那不同员工一定会有不同的理解：抗压能力强的员工会将这样的事情当成一次“打怪升级”的机会，但一些业务能力强而抗压能力弱的员工就很容易因压力过大而丧失了工作动力，甚至辞职逃避。

员工的抗压能力和员工的角色、员工个人的工作经历以及员工的个性特点都有关系。销售团队通常对市场变动和业绩指标造成的压力有较强的适应性，而研发团队的员工则普遍有一点“清高”倾向，不愿直接承担来自市场和业绩方面的压力。这是很多人在管理产品研发团队时最头疼的地方。

越是水平高的科学家、研究员、工程师，就越是希望自己能专注于某种特别有成就感的技术工作。至于自己承担的技术工作是否在本月创造了足够的销售收入，短期市场波动是否影响自己可支配的资源，他们是不太愿意考虑或过问的。你可以说这些科研技术人员并不成熟，但单方面要求他们提高承压能力并不现实，因为资深技术人员在人力资源市场上通常处于稀缺、紧俏的位置。如果薪资相同，他们是更愿意在一个必须背负巨大业绩压力、每周例会上都被质疑是否完成销售数字的公司里工作，还是更愿意在一个大部分时间只需要关注产品和代码质量，每天都有足够时间思考技术问题的环境里工作呢？

企业既要向业绩目标全力冲刺，又需要让科研技术人员保持战斗力，这就要求我们在企业管理的执行层面，必须下大力气建立和维护一个压力缓冲机制。也就是说，利用弹力矩阵的两个维度，在不同的产品线之间，或在不同的职能团队之间，设置有效的“减震带”：

上图中，成熟产品到新产品之间、新产品到预研产品之间，都可以建立减震带。成熟产品面对短期的业绩和市场压力，应该承担较多的义务，因为成熟产品可以通过快速扩大销售规模或营销手段，来应对短期压力。而新产品及预研产品因为尚未步入成熟期，如果强行要求它们上产能，背上不符合实际的业绩指标，那只会是揠苗助长，断送了企业的中长期价值。

对应到执行层面，这样的减震带往往意味着在不同产品线或产品事业部之间，施行有一定灵活度的考评和激励办法。成熟产品团队的业绩指标比重更多些，新产品较少些，预研产品基本不背业绩指标。需要强调的是，业绩指标的灵活处理并不意味着团队绩效无法考评。对于研发类型的团队，我们完全可以用产品技术指标，如产品完成度、迭代进度、相比竞品的技术优势等来对团队进行考评，直到产品真正打开市场，再附加相应的业绩指标。

上图给出了在不同工作职能之间设置减震带的建议方式。例如，短期业绩和市场压力可以直接被市场、销售以及咨询售前团队消化一大部分。但对于相对靠后端的定制开发、实施售后、产品研发、探索预研人员，业绩波动带来的影响需要控制在一定范围内。

如果片面将业绩波动全部归因到产品技术人员，那么，他们的心思就会主要花在如何用“短、平、快”的方式推出最容易在当下产生销售业绩的产品，而不会花太多时间去考虑代码质量、代码重构、系统安全、系统可维护性、产品可扩展性等因素。

对于最后端的探索预研人员来说，就更是如此。如果将短期业绩指标与他们的工作挂钩，那几乎就没人会去冒险尝试新技术、新想法，更不会有人去探索新的产品方向了。

简单说，无论是在不同阶段的产品线之间，还是在一个产品线的不同职能团队之间，都需要在合适位置设置减震带，缓解短期业绩和市场压力对那些有战略价值团队的冲击。减震带的设置，要求我们在管理上不能简单化、一刀切、一竿子捅到底。僵化、死板的管理方式也许适合低水平或人力密集型劳动的场合，但肯定不适合以高科技产品研发为核心的企业。

对一个企业来说，减震带主要是由中层管理团队来贯彻和执行的。部门经理、商务总监、技术总监、产品总监等中层领导者，决不能成为僵化、死板的规则执行者，而必须成为一个动态矩阵中的弹簧、润滑油、平衡器，发挥自己承上启下的管理作用，既透明、准确地执行公司战略部署，又帮助自己的团队成员屏蔽外部压力。

必须说明的是，缓冲压力并不意味着允许企业内存在混吃混喝、躺在其他团队功劳簿上享清福的员工。我们在这里强调的缓冲压力，更多是指缓冲业绩和市场的短期压力。企业内的所有部门、所有员工，从中长期的角度说，都必须服务于业绩目标。如果一个产品研发或探索预研团队游离于企业的中长期目标之外，总是研发一些看上去高大上却完全不接地气的技术或产品，那我们讨论的所有减震带都毫无意义，他们要么改变，要么走人。

动态响应

设置好资源分配方案的企业弹力矩阵，在执行层面并非是固化的、无法变通的。弹力矩阵的特点之一，就是矩阵内每个有弹性的资源分配小方块拥有动态响应能力，可以根据企业面临的现实挑战，实时调整自己的大小，甚至临时覆盖其他小方块，演变出不同的应对策略。或者说，动态响应就是弹力矩阵在特定情况下由均衡状态调整为非均衡状态，解决问题后再恢复均衡状态的能力。

上图展示了弹力矩阵中几种可能的动态响应机制。

例如，某条产品线新增销售订单较多，需要在短时间内大幅提升实施和支付能力的时候，拥有动态响应能力的企业可以将售前工程师、实施工程师和部分研发工程师的力量整合起来，在特定时期，集中力量打“歼灭战”。等到实施和交付任务的数量恢复平稳后，再重回弹力矩阵原先的均衡状态。

或者，在企业面临市场或业绩压力，需要阶段性冲刺销售业绩时，成熟的企业拥有在不同产品线之间重新调配市场、销售资源的能力，以保证某一冲刺方向上的资源充足。这种临时性的资源整合涉及的管理难题很多，诸如如何考评个人业绩、如何调动人员积极性等，但拥有这种资源调配能力的企业在需要时可以发挥出市场商务人员的最大效力。

再者，新产品研发的攻关阶段，产品线或产品事业部负责人完全可以跨职能团队，将相关工程、技术、科研力量集中为一个攻关小组，在一定时间范围内，大幅提高研发迭代速度，完成产品研发路径上的关键里程碑。

此外，当企业缺少明确的产品战略，对于中长期的产品预研拿不定主意的时候，完全可以从相关的市场、销售、咨询、售前、实施、研发团队中，抽调精英骨干，集中打一场“战略调研”战役。例如，基于市场调研的结果，在可能的方向上通过一个产品原型的快速迭代，快速将原型推送到用户或客户手中，获得试用反馈，并利用反馈信息评估产品方向的有效性，制定产品的中长期规划。

如果企业面临的短期挑战常态化，那么，基于动态响应机制获得的非均衡状态也完全可以演变为一个全新组织架构的基础，即将一个非均衡状态的弹力矩阵微调后，得到一个全新的均衡状态，以满足中长期战略转型的需要。

记得Google当年在面临Facebook咄咄逼人的社交网络攻势时，也充分发挥企业的动态响应能力，由拉里·佩奇亲自督战，抽调市场、商务、产品、技术、科研各条线上的大批骨干，新创建了一个Google+产品线，试图在社交网络之战中挽回败局。那时我还在搜索和知识图谱相关的技术团队工作，亲眼看到许多特别厉害的同事转到Google+团队，搬进山景城一幢独立的办公楼，相关办公区域甚至不允许其他团队的工程师进入（这在Google是极少见的），还拥有独立的、口味上佳的员工餐厅。

当然，Google+最终以失败告终，并不是一个特别好的企业内资源再分配的例子。当时的拉里·佩奇身上，依稀有一点年轻的乔布斯倾全力打造Lisa和Macintosh的影子。Google+的失败，有人说是Google的企业基因注定了它没有社交网络的“命”，也有人说Google+的产品设计存在重大问题。但仅从资源分配角度来说，我觉得， Google+的尝试一方面体现了Google具备动态响应的强大能力，另一方面也说明，为了一个“赌注”式的新产品，过度集中资源和管理精力，未必是一种均衡的选择。

从管理的成本收益角度做个总结

弹力矩阵工具很有趣。但它只是个帮助我们思考资源分配和管理模式的工具而已。从根本上说，要想在企业内建立速度与质量的均衡，企业管理者必须认识到，这需要投入更多的管理智慧和管理精力，并不是一件轻松的事情。

一方面，本文讨论的所有建议方法，只适用于已经有明确战略方向，处在发展和上升期的企业。如果一个企业面临内忧外患，战略上迷失了方向，无法突出重围，那这种情况下，逾是加强内部管理，就逾是快速地消耗企业现金流以及企业员工的耐心。大多数管理者肯定会认同：有发展有业绩的企业，一切问题都不是问题；没发展没业绩的企业，芝麻大的问题都会成为问题。

另一方面，不同类型的企业适用不同的管理模型，弹力矩阵工具并不是万能药、特效药。比方说，对于简单重复劳动为主的企业，静态、僵化的管理未必是坏事，寥寥数条管理制度，令行禁止，赏罚分明，往往就可以保障企业稳定运行许多年。但对于科技含量高，科研与工程人才多的企业，就绝对不能用静态、僵化的思维想问题。对于后一种情况，管理者需要有足够的决心和耐心，在管理过程中动态思考体系内的资源平衡问题，根据情况随时调整，努力设计管理模型，尽可能包容企业内不同类型职能团队的诉求和特点。这种付出虽然增加了管理成本，但从结果上看是绝对值得的。

如果一定要拿静态、一刀切的管理思路与动态、均衡的管理思路两相对比的话，下表是我个人的看法：

弹力矩阵工具只是我自己的一点小心得，绝对不是什么严谨、高明的管理学理论。大家从中能得到些许启发或共鸣，我就特别开心了。

将一辆赛车调校得既有飞一般的速度，又有足以应对勒芒24小时耐力赛的稳定性，这非常不容易。但从投入产出的角度来说，这种管理智慧和管理精力的付出，可以为企业开辟更广阔的也更持久的发展之路。

速度和质量可以兼得；稳健飞驰才是制胜之道。

阅读原文

跳转微信打开

工作中总结的工程师和产品经理的角色异同

点此收听本文音频版

AI配音由出门问问「魔音工坊」提供技术支持。

本文音频没有经过任何编辑处理，为全自动生成，可能存在部分播报错误。

之前技艺丛谈公众号发过一篇文章《产品经理眼中凶猛的程序猿长什么样？》，谈及产品经理经理眼中比较优秀的程序员是怎么样的。那篇文章是一个朋友写的，今天我也就两个角色聊聊自己近年来的一些感悟。

先说说我自己。我实习到毕业，基本上角色都是工程师，不过有几段时间，其实一定程度承担了产品经理的角色。

第一次经历是，在我实习的时候，我带了一个小团队，开发类似QQ的一款聊天工具。为了开发大部分QQ的功能，我深入研究了QQ的各个主要功能，包括文本聊天，视频聊天，语音聊天，换皮肤，表情发送，文件传输等，基本上把QQ各个功能都摸了个遍，然后琢磨它的优点在哪里，我们怎么学习。这次基本停留在学习阶段（说难听点，就是抄袭），没什么创新。

第二次经历是，在上一家公司，我设计开发了一个视频搜索，当时迅雷和各种网盘的云播正方兴未艾，不过种子的搜索并不方便。从视频消费的角度，一来我们需要能够打破app时代的资源隔离，希望有一款视频搜索工具，能够快速找到版权视频，不管是腾讯视频，还是爱奇艺，还是优酷或者土豆，或者搜狐视频等有这个资源。另一方面，如果这几家都没有资源（比如一些美剧），那是否能够搜索到种子文件或者magnet链接，能够快速在云播平台直接播放，就有很强的需求了。这个产品做了一个来月，国家对视频网站和网盘的审核严格了，也就中途放弃了。不过视频搜索这个产品，基本上从产品创意，到实现的大部分工作，都是我在推进的。算是我第一次比较主动地琢磨用户需求、产品形态以及技术手段等。

来目前这家公司后，相对比较专注技术，很少主动去想产品创意。不过日常工作中，还是保持偶尔体验下喜欢的产品的习惯，比如微信、微信读书、豆瓣等。此外，语音助手的一些竞品，AI相关的产品，也有较高的关注度。最近一年到半年的时间，花了一些精力阅读产品相关的文章和书籍，算是对产品有了更深的理解。阅读了不少书籍，包括俞军的《产品方法论》，不过我对俞军的书评价一般。读过的书籍和文章里，《设计心理学》四卷，以及张小龙的几次演讲，让我比较受益。

最近半年来，花了一定的精力刻意练习产品思维，包括去思考AI讨论能做什么，能给哪些场景带来效率的提升，能解决哪些之前的工具无法解决的问题。也花了不少时间，和产品经理讨论需求，讨论产品设计细节，和设计师沟通某个细节的好坏。此外，也使用工程师的思维，去量化每个交互的时间代理，和心理惯性代价等。最近也比较深度地参与了一个AI配音平台的设计，虽然没有直接输出PRD，不过也实实在在输出了很多产品的想法，细节的改进建议等。在个人角色上，我自己已经打上了半个产品经理的标签了。

下面我想来聊一下，作为工程师，我喜欢什么样的产品经理。而站在产品经理视角，我又欣赏什么样的工程师。

作为工程师，我讨厌抄袭成性的产品经理。直接抄袭，工程师觉得没劲。作为工程师，也很烦自己从事的是复制粘贴的工作。往往工程师做一个方向久了，就会腻味，想转岗。可想而知，去抄袭一款产品，而没有任何创新，工程师会觉得很low。

作为工程师，我喜欢有创意的产品细节，很讨厌不讲究细节的产品经理。没有经理的产品经理，一问起来，这样也许，那样也可以，仿佛几个不同的实现都无关紧要，或者对用户而言都没什么差异一般。

作为工程师，我讨厌没有极致追求的产品经理。有一些产品经理，提了某个需求，本身挺亮眼的，但是工程师反馈说，这个做不了，平台有限制，开发难度大，时间赶不及，产品经理马上认怂了，改需求，做出各种让步。这样的产品经理挺糟糕的。我喜欢执拗的产品经理。当然，偏执的产品经理会让团队抓狂，但是好的产品，突破当前竞品产品体验的新产品，往往是逼出来的。产品审美上的提升，产品细节上的精益求精，是不断逼迫自己逼迫团队的结果，这个和作家写作类似，作家写作也经常逼迫自己，没有「两句三年得 一吟双泪流 」，「批阅十载，增删五次」，哪里来的「增之一分则太长，减之一分则太短」。

作为工程师，我讨厌对技术不懂装懂的产品经理。如果一个产品经理对技术不懂，往往会对产品需求的实现难度不易判断。这时候，如果团队里的技术能力一般，往往会收到负反馈，久而久之，他就会被训练成对技术越来越没追求的产品经理，也就是说，很多产品功能其实是可以做到的，但是在技术的「负反馈」下，产品经理收获了很多错误的知识，从而判断越来越失误。作为产品经理，一方面可以阅读一些技术文章，了解下技术的边界，另一方面，也应该找找竞品，看看竞品在细节上是否做到了很多自己的产品做不到的功能，如果是，琢磨下为什么自己的产品做不到？而不懂装懂的产品呢，看到一个产品做到了某个功能，就自然而然觉得，我们也可以很轻松做到类似的其他功能，但是技术深究下来，两个功能其实是似是而非。

作为技术，我经常被产品经理拉去讨论某个技术方案。有时候我在听到技术的解释后，会觉得确实技术说得有道理，实现有难度。在技术复杂度面前，产品需求又比较着急，我有时候会建议产品经理设计个折衷方案，从而在规定的时间内先上线某个改进版本。有时候一些产品经理会非常偏执，觉得实现应该不难，为什么一定要在产品细节上让步。有好几次，在产品经理的坚持下，我突然灵光一现，想到了其他的解决方案，能够得到产品经理的需求。这时候我会很感谢产品经理没有提前让步。很多时候，我作为技术总监，普通产品经理是非常容易接受「现实」的，早早让步，要不放弃该功能，要不按照技术的反馈，设计一个妥协的交互方案。

作为技术，比较喜欢懂技术的产品。对技术越懂，越容易和技术进行需求沟通。懂技术意味着知道技术的边界，更容易评估复杂度。对复杂度有足够的认知，往往也更知道产品需求的优先级，因为资源往往是非常有限的。不过好的产品经理应该保持和技术的沟通，否则往往很容易因为之前获得的「技术边界」而局限住自己的思维，尤其是限制了产品想象力。「贫穷限制了想象力」其实挺有道理的。如果你呆的团队，技术能力比较弱，产品往往多次受挫以后，会畏首畏尾，设计的方案不够先锋大胆，创新力缺乏。好的产品应该学乔布斯，追求每一个像素的完美，追求内外兼修。当然，创业和做产品都是有限资源下的博弈游戏，所以产品经理更应该不断提高对优先级的判断。

作为技术，讨厌没有自己见解的产品经理。老板让做什么需求，Leader让做什么需求，这些都是非常糟糕的需求理由。身边不少产品经理，其实做的是项目经理的活儿，或者是PRD工人的活儿。想法都是别人的，他只是负责转换为PRD，然后和工程师沟通，让别人的想法变成现实。

作为技术，厌烦只知道做加法的产品经理。好的技术，最怕的就是代码冗余。工程师习惯性地会去做代码重构，让自己负责的项目比较容易掌控，容易维护。而只做加法的产品，随着需求的增加，代码会越来越多，但是没人用的需求，对应的代码工程师却没有机会删除掉。没有价值的产品越来越多，需要维护的「垃圾」代码也会越来越多，产品可以不维护了，代码却不能删除掉，出了点事情，工程师就成了首席「铲屎官」了。

那么作为产品，希望和哪种技术共事呢？随便列举一些，大概有：

1，对技术精益求精的人。不断优化代码，性能越来越快，体验越来越顺畅。

2，保持对技术的产品价值思考的人。如果技术碰到一些新的技术突破，可以及时和产品经理沟通，一起讨论下新技术是否能够带来一些新的产品价值。

3，能够对产品需求提出质疑的人。产品经理往往单打独斗，相比工程师一般人数比较少，并且产品经理往往独立负责一个产品线，因此产品经理之间review对方的产品就很少见。这就会导致产品经理个人的盲点必然会存在，考虑不周的地方，如果技术在评审产品需求的时候，能够勇于发问，往往产品经理就会及时完善产品细节。否则，在测试环节，在未来的使用中才发现一些细节处理不够完善，一些需求考虑不周，往往会造成不必要的反攻，或者方案设计不够到位，反而迭代。工程师之间，往往会有code review的环节，但是产品经理之间，很少看到PRD review的环节。一方面产品经理可以借鉴工程师的code review文化，另一方面，产品经理和工程师之间，也可以加强产品技术沟通，让review发生在产品经理和工程师这两个角色之间。

4，能够提出对极端条件下的产品细节定义的人。产品经理往往关注的是高频需求，而产品功能设计的时候，往往也关注的是正常交互的产品体验流畅度，对极端情况的处理，往往工程师比较有经验。工程师们在刷题训练中（比如刷LeetCode），已经练就了多极端情况的处理，软件工程里，也有测试驱动开发的文化。因此这方面工程师往往比产品经理更为严谨，这时候和产品经理相互补足，对产品经理就有好处了。

5，遇到做不到的时候，能够问问其他人，或者是搜索下互联网，搞清楚到底能不能做到。产品经理不喜欢没做足够的调研，就轻易下结论「做不到」的工程师。

总体而言，工程师喜欢产品经理异想天开，灵感迸发，给自己的技术带来一个个好玩的用户体验。而产品经理喜欢工程师精益求精，不断突破技术限制，从而不断突破产品体验的天花板。

最后聊点自己最近几个月以技术视角怎么去练习产品能力。之前曾经发过一条朋友圈，总结了工程师做产品的一些切入视角，敝帚自珍，发在这里：

阅读原文

跳转微信打开

聊聊小程序「技艺丛谈随身听」的技术原理，主要是语音交互技术中的语音合成。

最近的几篇文章，都提到了本公众号最近推出的「技艺丛谈随身听」，昨天后台有读者留言，说他对该小程序的原理比较感兴趣。作为语音技术研发的从业者，这里给大家简单介绍下背后的原理。相信读者里应该很多都不是语音合成的从业者，所以大概介绍下背后的技术，让读者大概了解下语音合成这一重要的AI方向，也算是以另类的角度切入，给大家科普下语音AI技术中的语音合成。

语音技术涉及的面比较广，包括语音信号处理，语音唤醒，语音识别，语音合成等。

语音信号处理处理的问题包括降噪、回声消除、声源定位等。典型的场景比如，听歌的时候，播放器里让声音听起来更舒服的一些技术。再比如，亚马逊推出的Echo音箱，需要解决远场交互的问题（比如在3-5米外去唤醒音箱，并与音箱进行交互）。再比如，车载上的语音交互，提供的主驾、副驾模式，就是典型的声源定位和波束成形应用。在主驾模式下，副驾在闲聊，是不太会影响主驾的语音交互的。信号处理使用到的技术术语包括DSP，DOA，beamforming, Echo Cancellation等，感兴趣的读者可以顺藤摸瓜，找一些资料读读。

语音唤醒主要解决的问题类似聊天的时候，「叫」某人一声，引起他的注意力，开始听你说话，也就是开始语音识别过程。典型的如手机上的语音助手，比如苹果的「hey siri」,谷歌的「ok google」,国内华为的「小艺小艺」，小米的「小爱同学」等。

唤醒要达到唤醒率高，误唤醒率低的几个目标。就和人聊天的场景一样，唤醒率高意味着你一叫他，他就理你，转过头来和你对话。唤醒率低的话，你就会要么觉得对方「耳背」，老需要叫他好几次才能听见，要么觉得他故意不理你，装作没听见。

而误唤醒就是说，你没有唤醒他，结果他转过来和你说：「你刚才是不是叫我了」，你就会觉得他莫名其妙，神经过敏。如何在高唤醒率的情况下，又保持低误唤醒率，是语音唤醒的难点。另一个难点在于，如何在不同环境下保持高唤醒率，比如开车的时候，开着车窗是否能唤醒自如。在有风噪、胎噪等不同噪声的情况下，保持较好的唤醒率。在高速路上高速行驶的时候，在后座有人闲聊的时候，在车里开着语音导航或者播着音乐的情况下，是否能提供较好的唤醒率。语音唤醒对应的术语包括wake-up word,hotword, false trigger 等，感兴趣的同学可以自行找资料阅读。

语音识别的任务，就是将语音转换为对应的文本，相当于人的耳朵提供的听觉功能，把人嘴巴说的声音，转换为正确的文本内容。语音识别系统的发展也有大几十年了，早期的系统是孤立词系统，只能识别有限的几个词汇，比如识别你说的是电话号码里的哪个数字，也就是提供的是0-9总共十个数字的识别任务。自动语音识别，英文叫ASR，全称为Automatic Speech Recognition。后来的大词汇量连续语音识别，英文为LVCSR，全称是Large Vocabulary Continuous Speech Recognition。ASR这里就不展开了，有兴趣的可以找一些相关的文章了解下。或者下载个讯飞的语音输入法，或者百度和搜狗的输入法，使用几天，直观感受下。目前微信发送语音的时候，也可以自动转换为文本了。整体的识别率目前已经挺高的了，假如环境不太复杂，而你的普通话也还算标准的话。没有试过的同学不妨试试看。

接下来进入正题，聊聊语音合成，语音合成英文名为Speech Synthesis。一般使用TTS更多一些，也就是Text To Speech, 文语转换，也就是文本到语音的转换。一般TTS分为三部分，前端分析，声学模型，声码器。最近两三年，TTS方面有很大的技术突破，自从谷歌推出WaveNet论文后，整个行业就开始一路高歌猛进。

TTS相当于是人类的「嘴巴」，让人类的想法，从文字变成声音。一个最简单的普通话语音合成系统可以这样做：

汉语大概1400个左右的带音调的音节（可以参考如下文档：

https://wenku.baidu.com/view/4da45667336c1eb91a375df9.html，这里统计的个数为1316个），如果你想做一个自己声音的合成系统，你把每个音节都录音一下，存储一份音节和音频的对应关系。要合成时，将输入文本切分为一个个字，每个字找对应的发音音节（这里存在多音字的发音分类问题，我们先假设先找该字的高频发音），然后使用音节去查找对应的音频。每个字都找到后，将各个音频拼接在一起，基本上就是最简单的语音合成系统了。

比如「北京今天天气不错」这句话，合成出来的感觉是这样的：

当然，为了让拼接的方法读得更好，有很多工作要做：

我们来看个词汇级别的拼接效果，还是以「北京今天天气不错」这句话，我们切割为「北京/今天/天气/不错」，拼接起来效果大概这样：

在相当长的时间里，业界主流的TTS在线系统，都是使用拼接法来做的。后来也出现了参数预测法。早期使用的更多的是HMM和决策树等。后来深度学习的方法开始流行。目前比较主流的方法，声码器大部分源自Google 提出的WaveNet，声学模型大部分源自Tacotron。

生活中在很多场景都可以看到语音合成的应用了，典型的比如高德地图的林志玲语音导航，比如SIRI的语音助手，智能音箱的语音播报等。

那么，公众号之类的长文章，要使用TTS来播报的话，相比导航或者语音助手的播报，有哪些难点呢？随便列举几个如下：

1，大部分语音助手的播报内容，都是产品经理配置的话术。在语音交互里，有一个模块叫做语言生成，Language Generation，缩写就是LG。LG大部分都是根据产品定义来编写的，变化有限。所以相对而言，语音助手类的播报内容，句法比较固定，相对容易测试和优化。另外， LG一般比较简单，话痨型的语音助手，不太会受到用户欢迎。早期没有办法支持打断功能的时候，话痨更可怕，很浪费用户时间。打断是说在播报TTS内容的时候，用户可以直接开始说话，而不用等到播报结束，它要解决的是回声消除问题，也就是TTS的播报内容，被麦克风录音进去后，应该能够以某种方法被消除掉，用户说话的语音，不应该受到自回声的影响。

2，语音交互的响应文本一般比较短，难度较小。文章较长的时候，就考验音频的质量问题了。这个和说一句话与写一篇作文的难度类似。大部分人都能够流畅地说一两句话，但是要流畅地朗读一篇文章就不那么容易了。要播报的文本越长，可能出问题的地方越多。比如多音字问题，像下面的句子，

「人要是行，干一行行一行，一行行行行行。

    要是不行，干一行不行一行，一行不行行行不行」

这么复杂的句子是否能够读对？比如断句会影响到韵律，抑扬顿挫的感觉不对，往往听起来不知所云。举个例子：「早上点早点早点早上早点吃」，可以根据不同的说话人意图，可以有几个不同的断句。比如

第一种读法，早上/点/早点，早点/早上/早点吃。

第二种读法，早，上点/早点，早点/早上/早点吃。

第三种读法，早上/点早点/早点，早上/早点吃。

一般的程序，还没有聪明到能够根据上下文信息，预测出不同的读法。况且，很多时候上下文其实是缺失的。那么怎么根据作者的意图，读出不同的风格来，就不是AI能自动搞定的了。

3，AI语音一般比较单调枯燥，容易让听众昏昏欲睡。和写文章一样，文章比较长的时候，往往会在必要的地方加个小标题，高亮一下几个关键词，或者是插入一两张图片，让文章更有呼吸感。如果大家听过喜马拉雅之类的播客内容，会发现其实音频生产也类似，需要通过一些音频制作的技巧，比如插入必要的音效，配上优美的背景音乐，或者是根据不同的上下文，变换不同的语速，或者是用上不同的声音情感，从而让听众更加「声临其境」。否则，长文章听起来，可能就有点昏昏欲睡，被听众当成催眠曲了。

出门问问团队打造的AI配音方案，为了解决上面提到的问题，让音频生产者能够快速生产出高质量的音频，开发了一系列的产品。其中一个产品就是「魔音工坊」。魔音工坊的名字是我取的，英文名字是Voice Maker，很明显，我们意在打造一个音频创造的工具，让内容创作者可以快速将文本转换为高品质的音频文件，在AIoT和5G时代到来之际，实现内容形态的升级。

魔音工坊的地址是：

https://voice-maker.mobvoi.com/

可以点击「阅读原文」访问网站。网站暂时还不支持移动版，目前只是首页做了适配，要体验的话，请使用电脑进行体验。欢迎有写文章习惯的朋友体验看看，试着也给你的公众号配上音频吧。

目前魔音工坊和小程序是深度整合的，在魔音工坊编辑完音频后，可以一键发布到小程序，这样在公众号中就可以插入对应的小程序卡片了。读者在公众号中，点击打开小程序，即可收听公众号的音频版本了。

有问题欢迎随时反馈给我。

阅读原文

跳转微信打开

工程师转管理，到底是好是坏？

点这里「收听」本文音频版

AI配音由出门问问「魔音工坊」提供技术支持

今年除了1月份写了一篇文章外，一直偷懒至今。这几天和团队成员做沟通的时候，有位同事提到我好久没有更新文章了，希望我可以辛勤劳作下，写写某个话题。突然觉得写文章这个事情，值得长期坚持下来。

之前的文章里，我刻意使用普通公众号文章的风格，以期能够对拉新用户有帮助，比如使用一些小标题啊，使用更多的排版技巧啊，使用一些观点总结之类的。不过这些东西比较花费时间，以后我希望写作风格上更轻松自由一些，可能会更接近曹政的「caoz的梦呓」一些，想到什么就写什么，不会刻意去编辑和编排。这样一方面我个人的时间比较节省，一方面写作本身也会更为轻松无压力，想必会更容易坚持一些。

下面进入正题。今天就来聊聊技术管理这个问题。

1，几乎所有人都想当管理者。

先说为什么大部分人都想当管理者。正所谓「不想当元帅的士兵不是好士兵」，中国人在骨子里已经养成了「向上爬」的心理，大部分人觉得管理者比较有地位，说话有份量。比如，大家可能都认为：

• 当管理者可以掌握其他人的职位升迁，绩效结果。

• 当管理者时间更自由，想不来公司就不来公司。

• 管理者能接触更多的资源，比如外部讲座、培训等。

• 管理者钱多事少，不再是最底层的码农了。

• 当管理者就不再有程序员的中年危机了，算是爬到了顶层，有了「免死金牌」。
  

想当管理者其实没错，不过中国的程序员有一个误区，以为所有人都适合当管理者。还有另一个误区，以为当管理者的性价比更高，回报比一直写代码更高。

中国的IT环境和海外不太一样，至今在大厂还流传着上了三四十岁就可能「被」下岗的风险。大部分人的思维定势都是刑不上大夫，所以有机会当管理者，那意味着裁员之类的事情，轮到自己头上的概率就会大大降低。其实这个未必。在经济不好的情况下，一般企业的思维都是扁平化管理，降低管理成本。如果管理的价值不能被直接看到，优化管理岗的可能性还是很高的。

那么，是不是管理岗一定就好呢？

2，管理岗是否回报更高？

一般而言，管理岗的回报和公司的运营情况会比较深度的绑定在一起。比如，管理者的绩效怎么样，会看公司整体的绩效，和部门的绩效，如果公司或者部门绩效不好，一般管理者的绩效不会好。今年经济受到疫情的很大影响，大家就经常可以看到一些公司高管降薪的消息。

管理者带兵打仗，冲在前面，公司运营不好，个人利益最直接受到影响。而普通员工一般而言受到的影响会小一些。

技术管理有时候劳心劳力，回报倒不一定高。像CTO之类的高管，固然有两三百万的现金，但是股票的价值更高，公司没做成，回报其实不高。我认识的一些朋友，走技术专家路线，这一两年看起来，在大公司拿到两三百万package的并不在少数。像阿里的P8，P9级别的专家，百度的T8，T9专家，华为的19，20，21级专家，或者外企微软、谷歌、苹果、亚马逊等技术级别高一些的非管理岗，薪酬还是很高的。

那么管理岗报酬就低么？那倒不是。如果早期加入小米、头条等，你还能当管理者，相信期权不会少。公司估值数以百倍的增长，收益还是很大的。并且管理者最容易随着公司的成长而快速成长，平台给予的锻炼机会也是普通开发所没有的。

3，大部分人转纯管理后都挺心虚的。

我自己最近半年的时间，基本上转为纯管理了，很少做具体的编程工作，也很少做Code Review工作了。我个人在实习期的时候就带过团队，在工作一年后，带的团队大概十几个。来目前的公司后，也一直有带团队，升职为技术总监这个管理岗，也有四年整的时间了。不过老实说，之前我一直觉得我更应该当架构师，而不是技术总监。

也就是说，我带人的八九年时间里，其实内心是拒绝当纯管理角色的，大部分精力也是花在技术学习和具体的编程任务上。大概梳理了下，有以下理由，让大部分工程师都不太想转纯管理岗：

• 纯管理岗看起来比较虚。工程师总觉得管理者也不写代码，一天到晚不知道干啥，给团队带来了什么贡献。一般而言，职位高的容易看到职位低的同事的工作价值，但是低的不太容易看到高职位的价值，因为你往往只能看到他工作的一小部分。

• 技术领域日新月异，很多管理者的技术比较陈旧。工作上出现下面的人觉得管理者什么都不懂，瞎指挥的挺多的。因此，大部分工程师认为，应该花精力在学习技术上，不要让自己落伍。否则去做管理这种「虚职」，到时候丢了技术的饭碗，就得不偿失了。

• 转管理后，把精力都放在团队上了，反而给自己充电的时间没有了。是成就了别人，但是自己的价值如何提高，没太大思路。毕竟管理的角色，和一直担任的程序员角色不同，因此没思路啊，不知道咋整。

那么我最近几个月连代码都不写了，code review也不做了，是不是心里慌得一逼呢？

当然不是。在其位，谋其政。既然在技术管理上，就应该想办法做好岗位职责。在之前岗位上成就自己的能力，往往会成为新岗位上的拦路虎。这个是德鲁克经常提到的一个观点。最近两年，我刻意阅读了很多管理类需要的书籍，包括软件工程书籍，德鲁克的书籍，产品设计书籍，创新创业相关书籍等。通过阅读书籍和参考一些同行实践，在工作中越来越认识到管理者的价值和优秀管理者的重要性。

老实说，我之前一直以为，让自己的技术更牛逼，对公司更有价值。不过目前我同样认为，对创业公司而言，优秀的管理者对公司更为重要。当然，成为优秀的技术专家并不容易，而成为优秀的管理者同样困难重重，甚至更难。为什么更难？因为管理者面对的问题更为复杂，比如技术管理者，可能需要强化自己的技术深度，扩宽自己的技术视野，强化沟通能力，提高产品素养，培养提高整体团队绩效的技能，甚至应该具有更高的视野和更好的认知，以期在当前严峻的竞争环境下，为团队找到更为靠谱的出路。

而这些都非常难。

曾经有一次和老板聊天，提到我在管理上的一些新的心得。他提到，其实每个角色的转变是一种取舍。比如当CEO，可能就无法和读博士时期一样，成为世界级的技术前沿探索者了，甚至连读论文的时间都没有。技术带来的快乐，比较难有机会去继续享受。但是当CEO也能带来别的好处，比如，想给自己放几天假，琢磨点自己感兴趣的领域，之前完全没自由，现在可以了。

从心虚到不心虚，我花了蛮长时间的。之所以不心虚，是因为我看到了管理者的独特价值。比如：

• 缺某个工程师，我们可以去市场上招聘。

• 行军打仗，有以少胜多的故事。而管理者就是将军，如何鼓舞大家的士气，在行业竞争中，以有限的研发资源，去尽快构建竞争优势，比任何一个人使蛮力都重要。

• 优先级的判断是绩效管理的关键。而管理者站得高，想得远的话，才可能让团队成员做到要事优先。

• 协调资源，做到全局最优。其实资源的有效协调是非常关键的。有价值的项目，有长期壁垒的技术难题，值得投入更多的人力。一个组织的有效运作，离不开资源的有效协调。管理者因为不再执着于局部工作，因此更能抽出身来，考虑全局的人力安排。

• 做管理让你更能思考方法论，让做事更有条理，更具可重复性。而这些方法论，对做开发是很有帮助的。哪天转头你转去做技术专家了，其实产出也会更加突出。因为你更能判断事情的优先级了，你更明白如何与他人共识了，你更清楚如何与产品团队沟通了，你也更明白如何做向上管理了。

好了，今天先聊到这，下次有机会再继续聊聊以下话题：管理者需要刻意练习的能力，以及我踩过的一些坑，管理角色的思维模式和普通开发者的差异，管理者需要有意回避哪些普通开发者的思维模式等。

阅读原文

跳转微信打开