Everything you care about in one place
Follow feeds: blogs, news, RSS and more. An effortless way to read and digest content of your choice.
Get Feederwechat2rss.xlab.app
技艺丛谈
Get the latest updates from 技艺丛谈 directly as they happen.
Follow now 26 followers
Latest posts
Last updated 9 months ago
聊聊技术管理
over 6 years ago
技艺丛谈 2020-04-19 01:43 工程师转管理，到底是好是坏？ 点这里「收听」本文音频版AI配音由出门问问「魔音工坊」提供技术支持今年除了1月份写了一篇文章外，一直偷懒至今。这几天和团队成员做沟通的时候，有位同事提到我好久没有更新文章了，希望我可以辛勤劳作下，写写某个话题。突然觉得写文章这个事情，值得长期坚持下来。之前的文章里，我刻意使用普通公众号文章的风格，以期能够对拉新用户有帮助，比如使用一些小标题啊，使用更多的排版技巧啊，使用一些观点总结之类的。不过这些东西比较花费时间，以后我希望写作风格上更轻松自由一些，可能会更接近曹政的「caoz的梦呓」一些，想到什么就写什么，不会刻意去编辑和编排。这样一方面我个人的时间比较节省，一方面写作本身也会更为轻松无压力，想必会更容易坚持一些。下面进入正题。今天就来聊聊技术管理这个问题。1，几乎所有人都想当管理者。先说为什么大部分人都想当管理者。正所谓「不想当元帅的士兵不是好士兵」，中国人在骨子里已经养成了「向上爬」的心理，大部分人觉得管理者比较有地位，说话有份量。比如，大家可能都认为：当管理者可以掌握其他人的职位升迁，绩效结果。当管理者时间更自由，想不来公司就不来公司。管理者能接触更多的资源，比如外部讲座、培训等。管理者钱多事少，不再是最底层的码农了。当管理者就不再有程序员的中年危机了，算是爬到了顶层，有了「免死金牌」。想当管理者其实没错，不过中国的程序员有一个误区，以为所有人都适合当管理者。还有另一个误区，以为当管理者的性价比更高，回报比一直写代码更高。中国的IT环境和海外不太一样，至今在大厂还流传着上了三四十岁就可能「被」下岗的风险。大部分人的思维定势都是刑不上大夫，所以有机会当管理者，那意味着裁员之类的事情，轮到自己头上的概率就会大大降低。其实这个未必。在经济不好的情况下，一般企业的思维都是扁平化管理，降低管理成本。如果管理的价值不能被直接看到，优化管理岗的可能性还是很高的。那么，是不是管理岗一定就好呢？2，管理岗是否回报更高？一般而言，管理岗的回报和公司的运营情况会比较深度的绑定在一起。比如，管理者的绩效怎么样，会看公司整体的绩效，和部门的绩效，如果公司或者部门绩效不好，一般管理者的绩效不会好。今年经济受到疫情的很大影响，大家就经???可以看到一些公司高管降薪的消息。管理者带兵打仗，冲在前面，公司运营不好，个人利益最直接受到影响。而普通员工一般而言受到的影响会小一些。技术管理有时候劳心劳力，回报倒不一定高。像CTO之类的高管，固然有两三百万的现金，但是股票的价值更高，公司没做成，回报其实不高。我认识的一些朋友，走技术专家路线，这一两年看起来，在大公司拿到两三百万package的并不在少数。像阿里的P8，P9级别的专家，百度的T8，T9专家，华为的19，20，21级专家，或者外企微软、谷歌、苹果、亚马逊等技术级别高一些的非管理岗，薪酬还是很高的。那么管理岗报酬就低么？那倒不是。如果早期加入小米、头条等，你还能当管理者，相信期权不会少。公司估值数以百倍的增长，收益还是很大的。并且管理者最容易随着公司的成长而快速成长，平台给予的锻炼机会也是普通开发所没有的。3，大部分人转纯管理后都挺心虚的。我自己最近半年的时间，基本上转为纯管理了，很少做具体的编程工作，也很少做Code Review工作了。我个人在实习期的时候就带过团队，在工作一年后，带的团队大概十几个。来目前的公司后，也一直有带团队，升职为技术总监这个管理岗，也有四年整的时间了。不过老实说，之前我一直觉得我更应该当架构师，而不是技术总监。也就是说，我带人的八九年时间里，其实内心是拒绝当纯管理角色的，大部分精力也是花在技术学习和具体的编程任务上。大概梳理了下，有以下理由，让大部分工程师都不太想转纯管理岗：纯管理岗看起来比较虚。工程师总觉得管理者也不写代码，一天到晚不知道干啥，给团队带来了什么贡献。一般而言，职位高的容易看到职位低的同事的工作价值，但是低的不太容易看到高职位的价值，因为你往往只能看到他工作的一小部分。技术领域日新月异，很多管理者的技术比较陈旧。工作上出现下面的人觉得管理者什么都不懂，瞎指挥的挺多的。因此，大部分工程师认为，应该花精力在学习技术上，不要让自己落伍。否则去做管理这种「虚职」，到时候丢了技术的饭碗，就得不偿失了。转管理后，把精力都放在团队上了，反而给自己充电的时间没有了。是成就了别人，但是自己的价值如何提高，没太大思路。毕竟管理的角色，和一直担任的程序员角色不同，因此没思路啊，不知道咋整。那么我最近几个月连代码都不写了，code review也不做了，是不是心里慌得一逼呢？当然不是。在其位，谋其政。既然在技术管理上，就应该想办法做好岗位职责。在之前岗位上成就自己的能力，往往会成为新岗位上的拦路虎。这个是德鲁克经常提到的一个观点。最近两年，我刻意阅读了很多管理类需要的书籍，包括软件工程书籍，德鲁克的书籍，产品设计书籍，创新创业相关书籍等。通过阅读书籍和参考一些同行实践，在工作中越来越认识到管理者的价值和优秀管理者的重要性。老实说，我之前一直以为，让自己的技术更牛逼，对公司更有价值。不过目前我同样认为，对创业公司而言，优秀的管理者对公司更为重要。当然，成为优秀的技术专家并不容易，而成为优秀的管理者同样困难重重，甚至更难。为什么更难？因为管理者面对的问题更为复杂，比如技术管理者，可能需要强化自???的技术深度，扩宽自己的技术视野，强化沟通能力，提高产品素养，培养提高整体团队绩效的技能，甚至应该具有更高的视野和更好的认知，以期在当前严峻的竞争环境下，为团队找到更为靠谱的出路。而这些都非常难。曾经有一次和老板聊天，提到我在管理上的一些新的心得。他提到，其实每个角色的转变是一种取舍。比如当CEO，可能就无法和读博士时期一样，成为世界级的技术前沿探索者了，甚至连读论文的时间都没有。技术带来的快乐，比较难有机会去继续享受。但是当CEO也能带来别的好处，比如，想给自己放几天假，琢磨点自己感兴趣的领域，之前完全没自由，现在可以了。从心虚到不心虚，我花了蛮长时间的。之所以不心虚，是因为我看到了管理者的独特价值。比如：缺某个工程师，我们可以去市场上招聘。行军打仗，有以少胜多的故事。而管理者就是将军，如何鼓舞大家的士气，在行业竞争中，以有限的研发资源，去尽快构建竞争优势，比任何一个人使蛮力都重要。优先级的判断是绩效管理的关键。而管理者站得高，想得远的话，才可能让团队成员做到要事优先。协调资源，做到全局最优。其实资源的有效协调是非常关键的。有价值的项目，有长期壁垒的技术难题，值得投入更多的人力。一个组织的有效运作，离不开资源的有效协调。管理者因为不再执着于局部工作，因此更能抽出身来，考虑全局的人力安排。做管理让你更能思考方法论，让做事更有条理，更具可重复性。而这些方法论，对做开发是很有帮助的。哪天转头你转去做技术专家了，其实产出也会更加突出。因为你更能判断事情的优先级了，你更明白如何与他人共识了，你更清楚如何与产品团队沟通了，你也更明白如何做向上管理了。好了，今天先聊到这，下次有机会再继续聊聊以下话题：管理者需要刻意练习的能力，以及我踩过的一些坑，管理角色的思维模式和普通开发者的差异，管理者需要有意回避哪些普通开发者的思维模式等。 阅读原文 跳转微信打开
「技艺丛谈随身听」AI配音的技术原理
over 6 years ago
原创 叶顺平 2020-04-20 02:03 聊聊小程序「技艺丛谈随身听」的技术原理，主要是语音交互技术中的语音合成。 最近的几篇文章，都提到了本公众号最近推出的「技艺丛谈随身听」，昨天后台有读者留言，说他对该小程序的原理比较感兴趣。作为语音技术研发的从业者，这里给大家简单介绍下背后的原理。相信读者里应该很多都不是语音合成的从业者，所以大概介绍下背后的技术，让读者大概了解下语音合成这一重要的AI方向，也算是以另类的角度切入，给大家科普下语音AI技术中的语音合成。语音技术涉及的面比较广，包括语音信号处理，语音唤醒，语音识别，语音合成等。语音信号处理处理的问题包括降噪、回声消除、声源定???等。典型的场景比如，听歌的时候，播放器里让声音听起来更舒服的一些技术。再比如，亚马逊推出的Echo音箱，需要解决远场交互的问题（比如在3-5米外去唤醒音箱，并与音箱进行交互）。再比如，车载上的语音交互，提供的主驾、副驾模式，就是典型的声源定位和波束成形应用。在主驾模式下，副驾在闲聊，是不太会影响主驾的语音交互的。信号处理使用到的技术术语包括DSP，DOA，beamforming, Echo Cancellation等，感兴趣的读者可以顺藤摸瓜，找一些资料读读。语音唤醒主要解决的问题类似聊天的时候，「叫」某人一声，引起他的注意力，开始听你说话，也就是开始语音识别过程。典型的如手机上的语音助手，比如苹果的「hey siri」,谷歌的「ok google」,国内华为的「小艺小艺」，小米的「小爱同学」等。唤醒要达到唤醒率高，误唤醒率低的几个目标。就和人聊天的场景一样，唤醒率高意味着你一叫他，他就理你，转过头来和你对话。唤醒率低的话，你就会要么觉得对方「耳背」，老需要叫他好几次才能听见，要么觉得他故意不理你，装作没听见。而误唤醒就是说，你没有唤醒他，结果他转过来和你说：「你刚才是不是叫我了」，你就会觉得他莫名其妙，神经过敏。如何在高唤醒率的情况下，又保持低误唤醒率，是语音唤醒的难点。另一个难点在于，如何在不同环境下保持高唤醒率，比如开车的时候，开着车窗是否能唤醒自如。在有风噪、胎噪等不同噪声的情况下，保持较好的唤醒率。在高速路上高速行驶的时候，在后座有人闲聊的时候，在车里开着语音导航或者播着音乐的情况下，是否能提供较好的唤醒率。语音唤醒对应的术语包括wake-up word,hotword, false...
发个字节跳动豆包输入法的招聘需求
9 months ago
叶顺平 2025-12-22 19:49 北京 帮团队发个招聘信息。 豆包输入法在 11 月底正式对外发布，目前获得了不错的口碑。产品正在快速迭代中，目前有一些岗位需求开放，订阅本公众号的朋友里有没有感兴趣的朋友呢？如果身边有朋友在看机会，也欢迎帮介绍一下。招聘的需求具体见以下一览图。不了解豆包输入法的朋友，可以在应用商店下载体验一下。感兴趣的朋友，可以给 HR 直接发信息，也可以加我微信了解更多岗位信息（微信：shunpingye)。 阅读原文 跳转微信打开
一种全新的代码审计技术：SyntaxFlow
over 2 years ago
v1ll4n 2024-06-14 17:38 北京 我们希望把编译技术带入安全代码分析去分析代码行为，为代码行为分析带来新的机会和可能性 代码审计技术在过去的一段时间的发展中，似乎受到了一个魔咒，安全从业人员的很难摆脱 *QL的影响，毕竟编译成数据库，然后通过 QL 来查询。或者通过把 AST 解析进 neo4j，通过...
聊聊工程师和产品经理的角色异同
over 6 years ago
原创 叶顺平 2020-04-24 02:11 工作中总结的工程师和产品经理的角色异同 点此收听本文音频版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，遇到做不到的时候，能够问问其他人，或者是搜索下互联网，搞清楚到底能不能做到。产品经理不喜欢没做足够的调研，就轻易下结论「做不到」的工程师。总体而言，工程师喜欢产品经理异想天开，灵感迸发，给自己的技术带来一个个好玩的用户体验。而产品经理喜欢工程师精益求精，不断突破技术限制，从而不断突破产品体验的天花板。最后聊点自己最近几个月以技术视角怎么去练习产品能力。之前曾经发过一条朋友圈，总结了工程师做产品的一些切入视角，敝帚自珍，发在这里：最近刻意练习产品能力，并和计算机性能优化做类比，比如1，基础的硬件能力（体系结构，指令集）对应基础的交互能力（安卓，浏览器等系统和控件集）2，必要的benchmark工具。类似性能优化的perf,google perftools，做必要的指标埋点和监控。3，量化评估各个环节的心理代价和用户学习代价等（类似各函数的计算量），逐步优化。4，注重架构，应对复杂。架构不好，不容易增删改查，牵一发动全身，也不方便diff（abtest）5，学习事后看反馈信息从而迭代的能力，类似跑benchmark和profiling，重新评估改进方向。6，学习事前模拟，预期各种方案的好坏，（类似Jeff...
稳健飞驰：打造速度和质量均衡的产品研发团队
over 6 years ago
王咏刚 2020-04-27 21:05 创新工场CTO王咏刚老师有关团队管理的精彩分享 速度和质量不可兼得？超喜欢看2019年的电影《极速车王》（其实更贴切的译名应该是《福特大战法拉利》）。很早就知道勒芒24小时耐力赛是个苦差事，但缺少直观体验。看到电影里的主角驾驶赛车在雨夜赛道上一圈一圈狂奔的镜头，才觉得无论是人还是车，根本就是在挑战地球人的极限——这比赛的设计真心变态，敢于挑战的人和车真心厉害！很自然想到创业，想到打造一个过硬的产品研发团队的种种艰难。和勒芒24小时赛道上飞驰的赛车相仿，运营一家高科技企业，或打造一个过硬的产品研发团队，也需要不断挑战速度和质量的极限。（1）速度：单就打造产品研发团队这件事儿来说，速度通常反映在很多指标上。最核心的速度指标至少包括企业的销售收入、销售利润、用户量、增长率等等。有些指标虽然表面看也是“速度”，例如团队增长速度、资金消耗率、产品发布迭代速度甚至每周代码的累积数量，但它们并非任何时候都和企业的终极目标紧密相关。（2）质量：相当于勒芒赛车所追求的“耐力”或“稳定性”。研发团队的质量差不多等同于研发团队的价值。这方面的指标通常包括团队拥有的人才价值、知识产权价值、团队的技术领先程度、产品的竞争优势、产品的平均毛利率、产品的平均实施与维护成本、用户满意度等等。创业公司和发展期的产品研发团队经常出现偏重速度而忽视质量，或者偏重质量而忽视速度的情况。两者都不可取。过于重视速度的团队就好比开着一辆冲刺速度世界第一，但跑起来经常会发动机爆缸的赛车参加勒芒耐力赛，过于重视质量的团队则相当于小心翼翼驾驶着数万公里无故障的家用轿车去勒芒丢人现眼。比如，有的团队用简单的绩效指标统管所有团队行为，KPI指挥棒总领一切。人都不傻，如果个人所得仅仅和几个简单的KPI数字正相关，那我做事的时候，自然就只会选能直接刺激数字增长的事儿来做。既然“卖得快”指挥一切，那中长期的技术积累肯定会让位于短期的功能“拼凑”，用户的使用体验肯定会让位于简单粗暴的流量拉升，公司的长期成长肯定会让位于今年底是不是能拿到150%的奖金回家过年。这种用KPI一刀切的团队最常见的结果就是留不住关键人才，产品研发后继乏力，飘红的销售业绩下面暗藏产品同质化竞争严重、售后成本居高不下、毛利率越做越低、团队越做越疲的危机。再比如，有的团队笃信技术的价值，围绕着某种产品理想闭门造车。研发上烧钱的速度比谁都快，在顶级学术会议发论文、在国际竞赛拿大奖的次数比谁都多，但就是很少有人抬头看一看自己研发的产品好卖不好卖。另有一些团队则非常坚定地强调内部管理流程和内部文化建设，花费大量资源建立复杂的项目管理流程、质量管控流程、风险防控流程，才几十上百人的团队就参照几千人、几万人的大企业做法，用标准化、数字化、流程化的管理统领一切，产品研发团队的工程师每天花在写文档、填表格、发申请、求审批的时间甚至多于钻研算法、写代码或设计产品的时间。这两种高度重视质量却忽视速度的团队，大概都会走到对市场变化反应迟钝、高科技拼不过接地气儿、下个月再不融资就前功尽弃的尴尬境地。速度和质量不可兼得？当然不是。就像跑勒芒耐力赛一样，速度第一，业绩第一，但团队质量也要跟得上。不能极速跑了几圈就开始掉零件。掉车漆、掉翼子板都还好，要是震断了车轴，震坏了离合器，那这比赛就麻烦了。所以，在保证速度第一的情况下兼顾质量，保证赛车不散架，保证企业不会一上市就跌停，这是打造成功的产品研发团队的最低标准。简单说，就是要打造速度与质量均衡的产品研发团队，既要飞驰，又要稳健。小工具：弹力矩阵如何均衡速度与质量？精通企业管理的人有各式各样高明的方法???。我不是管理学家，只是身为工程师和研发管理者，二十多年里，先后在企业级解决方案提供商、世界顶级的互联网科技公司、科技型的初创公司等不同环境里实践、摸索、总结过一些研发管理的小经验、小技巧和小工具。很愿意跟大家分享一种我自己常用的思维模型——弹力矩阵。弹力矩阵是从矩阵式管理的方法论中借鉴来的模型。一个产品研发企业，从工作职能维度，大致包含市场职能、销售职能、咨询和售前职能、定制开发和实施售后职能、产品研发职能、探索预研职能等。从产品是否成熟的维度，大致可以分为成熟产品、新产品和预研产品三大类。这两个思考维度相互交叉，共同构成了一个产品研发企业的基本矩阵：如果只考虑汇报和管理关系，上述示意图就大致回归到了“矩阵式管理”的范畴内。例如，一个企业可以根据不同类型的产品，将所有团队成员分配到不同的产品事业部（或产品线、业务线、业务单元、产品或聚焦领域等其他称谓，内涵上大同小异），而每个事业部又可能同时配备市场团队、商务和咨询团队、实施服务团队、产品研发团队等。每个具体的员工既属于某个特定的职能团队，又属于某个产品事业部，存在逻辑上的双向汇报关系，如下图：那么，我所说的弹力矩阵又是怎么回事儿呢？简单说，当管理者开始考虑如何在上述矩阵型组织架构中配置各类资源（包括人力资源、财务预算、渠道和市场资源、战略资源等）时，上面的矩阵就会摇身一变，成为我推荐大家使用的弹力矩阵模型。在弹力矩阵里，每个格子都像一颗有弹力的啫喱糖，在各自的弹力范围内，可以或上下、或左右地延展、收缩。一个企业内部的产品研发管理，往往是在统一的企业目标指引下，在动态变化中不断调整每颗“啫喱”的长、宽乃至“重量”，以达到速度和质量的最佳均衡。所以，弹力矩阵也可以被叫做“啫喱矩阵”。肯定不能将公司的资源平均分配到矩阵的每个格子里——这不成了又懒又傻的“自杀式管理”了吗？除了管理者的个人经验，还有哪些简单易行的思考方法，可以帮助我们决定资源在整个矩阵里的分配方式呢？根据我个人的心得，要达到速度与质量的均衡，关键是三件事：双向均衡，压力缓冲，动态响应。双向均衡用于优化全局资源规划，压力缓冲用于优化管理细节，动态响应用于优化企业对外部挑战???实时应对能力。双向均衡企业资源在弹力矩阵上的分配是二维的。无论是工作职能的维度，还是产品成熟度的维度，分配时都需要考虑均衡的大原则。先考察产品成熟度这个维度：通常，有经验的管理者仅凭直觉就会为已经成熟并可以带来大笔销售收入的产品分配最多资源，为新上市但前景不明的产品分配较少但更具战略意义的资源，为面向未来但存在较高风险的预研产品分配最少的资源。但这种根据产品成熟度分配资源的方式有没有可量化的指标呢？我个人喜欢用 “称重天平法”来完成定量计算。称重天平法所“称”的是我们在每一类成熟度不同的产品上所分配资源的“重量”。这个“重量”的计算方式很简单：重量 = 面积 x 密度上式中的“面积”，就是弹力矩阵中相应小方格的面积，也就是我们分配在此类产品中的资源数量（例如，这个产品事业部或产品线某一年的人力成本）。上式中的“密度”，我把它定义为以年为单位的，该产品达到可大规模推广状态所需的时间。比如在上图中，假设我们为成熟产品、新产品、预研产品分配的企业资源的大致比例是5 : 2...
管理者的几个特殊能力
over 6 years ago
原创 技艺丛谈 2020-04-29 00:45 继续聊聊管理工作中踩过的坑。本文体验下付费阅读功能，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%幅度还是缺乏抵抗力。其实薪资不高的时候，跳槽加薪幅度比较高的机会挺多的，大可不必那么着急。再说说离职留人的难处： 阅读原文 跳转微信打开
整理了几个文章专辑，方便大家阅读
over 6 years ago
2020-06-12 23:55 给「技艺丛谈」公众号创建了几个专辑，方便大家阅读 系列一：职场分享系列系列二：技术文章系列系列三：面试攻略系列系列四：文艺闲笔系列系列五：卜雨文丛系列欢迎大家阅读 阅读原文 跳转微信打开
技艺丛谈推出有声版
about 6 years ago
2020-07-11 17:04 本公众号推出AI有声版 最近公司做了个新产品——「AI魔音」小程序，我使用这个产品，将公众号内容搬到了小程序上，之前推送过的公众号文章，目前都有了音频版本了，总共大概180篇。欢迎读者朋友们扫描下面的二维码，「收听」本公众号的历史文章。除了提供公众号的音频化功能外，「AI魔音」小程序上还有不少好玩的AI功能，好奇的读者可以上去看看。 阅读原文 跳转微信打开
聊聊Google的工程实践（四）：调试与剖析
about 6 years ago
原创 叶顺平 2020-09-13 00:00 这篇继续聊一下调试与剖析这个话题 这篇继续来聊一下调试与剖析这个话题。一般软件调试使用GDB来进行，不过对GDB熟悉的不一定多。我认识的几个Google出来的工程师，使用GDB并不多。其中一个Google的工程师甚至说，使用glog打印一些日志，基本就可以看出问题了，要什么GDB啊。如果说代码质量比较高的话，边界的测试比较多，确实不太需要使用到GDB。不过大型项目就不好说的，因为依赖的代码错综复杂，可能你的代码质量很高，但是依赖的third party质量一般，有一些隐藏的Bug，甚至操作系统有一些隐藏的Bug也不无可能，所以还是需要学会一些调试技巧。接触的Google相关的调试技巧并不多，其中有一个是用于收集崩溃报告的。一般我们发生了crash，会生成core dump文件，但是core dump文件很大，存储和上传都比较困难，这时候是否可以考虑生成一个比较小的文件，包括一些比较关键的信息呢？当然是可以的，Google 就有一个开源的C++项目，叫做breakpad，官方是这么介绍的：Breakpad is a...
聊聊Google的工程实践：完结篇
almost 6 years ago
原创 叶顺平 2020-10-01 11:56 完结篇：上线与发布，代码重构，绩效考核，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...
聊聊微信读书
almost 6 years ago
原创 叶顺平 2020-10-08 01:52 聊聊读书的需求，以及微信读书这个产品。 三年之前曾经写过一篇文章《读书之痛》，说了一些读书的痛点（不禁感叹光阴似箭，三年前就恍如昨天）。其中有两三个地方提到了微信读书，比如签名之痛：比如微信读书，做笔记就很方便，不仅做笔记方便随心，还能让你肆意划线，就彷佛你手里握着你喜欢的那支笔，可以在书上划划重点、指点江山。再比如做笔记之痛：比如微信读书，做笔记就很方便，不仅做笔记方便随心，还能让你肆意划线，就彷佛你手里握着你喜欢的那支笔，可以在书上划划重点、指点江山。那篇文章我提到的痛点，总结下来有这么十二条：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，目前还有一些朋友喜欢读实体书，但是实体书又太贵。我觉得在未来探索出一种购买版权后打印出来阅读，或者按年费租赁实体书并支持快速退还，可能会是很好的模式。有一些朋友，至今还是无法接受电子书阅读，希望在未来能够探索出一种低成本的实体书阅读模式。最后，谢谢微信读书产品，谢谢微信读书团队。祝微信读书做得越来越好，引入越来越多的好书。 阅读原文 跳转微信打开