Vol.012：如何给未来的自己，储备今日的知识

## 卷首语

本周杭州一直下雨，主题曲都和雨有关：

• 听风暴 ：Watch the Storm by U137
• 听暴雨 ：暴雨将至 by 彭飞
• 听大雨 ：Rain Watcher by 惘闻

**少楠说：**其实一直对于投资一直有一些误解，认为投资只和钱有关。最近突然明白了，最大的投资是时间，甚至不是全部时间，而是自己可控的那一小段时间而已。把时间放在哪里，就是对什么事情的投资。在狭义投资中犯的错误和经验，在日常中也屡屡出现，比如爱频繁做决策而决策筹码太小的毛病等等 。

想起欧文 · 费雪在《利息理论》中关于投资和消费的小故事：

一个人买了一篮水果在一个钟头内就吃掉了，确是将钱用于吃水果的享受。但是，他若在秋季买一桶苹果而留到冬季吃时，他是将钱用于消费还是用于延迟享受的投资？在理论上，这一桶苹果是投资，相当于房屋或其他耐久财货的投资。在实际上，它是划做消费的，虽然这是属于两可的情形。消费与投资只有程度上的不同，它决定于花费与享受间时间间隔的长短。消费是花钱于很快就要来到的享受。投资是花钱于延迟到日后的享受。

所以当你打开这封信的时候，我希望对你来说是一份投资，而非消费。希望这些内容的半衰期足够长，长到三五年后还值得你再来翻翻，我也会作为园丁，不断地耕耘这块土地。

所以从时间的角度来看，本期的内容就很有趣了。「渐进式总结」是教你如何给未来的自己储备今日学到（但还用不上）的知识；「领域驱动架构」是教你如何从整个生命周期来看业务该如何架构；以及「人总有一刻，开始思考死亡」。

从另一个角度来看时间也很有趣，许多产品的生死，和占用别人的时间也有关系。宁可占据一小部分人的绝大多数时间（比如 Notion，Sketch），也不要让多数人使用一点时间（比如 Xmind，Wunderlist）。因为任何一个新的平台，都是由少数人用得多，然后这个少数人变成了多数人而形成的。

想起熊培云的一首小诗：如果三月播种，九月将有收获，焦虑的人啊，请你不要守着四月的土地哭泣。土地已经平整，种子已经发芽，剩下的事情交给时间来完成。

❧

何谓渐进式总结：Progressive Summarization

**少楠说：**本文作者是Tiago Forte @fortelabs，也是之前 The PARA Method: A Universal System for Organizing Digital Information 这套组织系统的作者。这个系列有六章，这是翻译完的前三章。感谢 @Mengna Z 协助翻译和 @Gofurther Liu 的监督催促。

这篇内容主要解决的是，当我们建立好信息组织系统之后，开始向系统内添加内容的时候，该如何确保几年后的我们，能理解今日我们存下来的只言片语呢？如果你看过三体，可以理解为你该如何「增援未来」的自己呢？

为此我特地打开了用了十年的 evernote，发现除了我记下来的个别关键词搜索能出来一些内容外，整个笔记结构散乱不说，除了少数几次要做分享之外认真整理了几个主题，其他内容基本上就和草稿纸一样无法辨认了。

渐进式总结试图给这种情况一个解决方案。这个系列吸引我的并非是具体的执行方案，而是作者分析问题和提出问题的角度 —— 功不唐捐，但许多时候我们都是在错误的时间学习了正确的知识，并且没有把这些将来可能会用到的知识打包存好发给未来，要么变成了阅后即焚没有归档，要么变成了缺乏上下文无法辨识，要么就是原文存储造成再次检索的成本更高。

其实作者的解题思路也不复杂，即你把耗时但无风险的活动（阅读、高亮、总结）尽可能早地准备，而把快速但有风险的活动（执行、决策、交付）尽可能推到未来。但这么理性的和未来的自己对话，试图理解未来的自己所处的状态，这个思考角度便是极有趣的。

在解题过程中，作者用的其实就是我们日常的「划线标注」法，但是在使用过程中的改造和比喻非常有趣。相对来说我习惯于划根线就结束了，但是作者建立了五层标注的系统，能让我们未来回顾我们笔记的时候，不需要从密林中寻找蛛丝马迹，而是可以从高空看到笔记们的结构和重点。

作者有个观点我想在国内的同学应该都很熟悉：未来的你一定比现在的你更加智慧，而且使用的时候会有更加具体的项目来提供更好地视角和实践场景，能让过去存储的知识发挥更大的价值 —— 当年邓公也是利用这个思路解决了巨大的分歧问题，带来了我们今日所习以为常的改革开放。

对了，千万不要试图组建一个「完美」的系统，因为多数情况下我们都不会是随时处于精力十足的状态，而是懒散的，疲惫的，焦虑的普通人。那么过于精妙的系统，会在这些状态时，功亏一篑。

批注版：https://www.notion.so/plidezus/Progressive-Summarization-faf06977850b46a6a7de1623ebf699f2

原文：https://fortelabs.co/blog/progressive-summarization-a-practical-technique-for-designing-discoverable-notes/

❧

领域驱动架构（DDD）建模中的模型到底是什么？

**少楠说：**本文是 @Gofurther Liu 压箱底的珍藏。但别担心，我也不懂技术，这一篇里面也没有太多的技术术语 —— 其实我对技术的态度，就像看英文小说一样，能听懂别人讲这个小说多么精妙，剧情结构多么好，甚至可以应用在自己的中文小说中，只是我很难用英语去写出句法优雅的英文小说。

之前 @Light 在 向 AI 学习解决问题 中也提到，毕竟许多发明技术的人都是这个星球上顶尖的聪明人，我们即使不去学习具体的实践，其设计思路也是值得借鉴的。

曾经我的导师告诉我，优秀的产品经理都需要自己设计数据库结构，当时我还是懵懂。后来懂了一些数据库原理之后，才意识到他的意思是，你应该懂得如何设计业务模型，而不是每次都从前端的界面开始设计。所以今日为何经常说程序员要干掉产品经理呢？是因为多数时候产品经理只承担了沟通和部分交互、用研工作，而在业务模型的设计上，却希望依赖于技术同学搞定 —— 尴尬的是，技术的同学往往由于这种琐碎的 Case 太多工期太紧，导致根本没空去仔细揣摩和理解业务，这就形成了一个恶性循环，直到有一天系统过于复杂而突然崩溃。

其实如果跳脱 DDD 在技术领域的应用来看，在日常工作中我们也是用得到的：首先需要定义一套「通用名词」，确保业务上下游都用这个名词。曾经我们就出现过「快速开药」「快速图文」「开药问诊」「续方开药」「去开药」来描述一类产品功能，可想而知我们自己内部每次都要讨论半天「我们究竟在做什么」，更遑论医生用户看到这些名词更会头大 —— 好的命名是成功的一半，所言非虚。

其次就是 DDD 将系统分为了四个层次，这个比「用户体验要素」中的分层更加的「动态化」，因为在后者中，虽然融入了战略高度，但是过于关注了体验，忽略了「领域逻辑」和「应用层」，而只是简单地用「交互」和「信息架构」来替代，显然是不适合今天的复杂环境的。

• UI 层，负责界面展示。
• 应用层（Application Layer），负责业务流程。
• 领域层（Domain Layer），负责领域逻辑。
• 基建层（Infrastructure Layer），负责提供基建。

其实换个角度来看，真正的产品经理应该干的活儿大概在领域层和部分应用层，而运营的同学干的活应该在应用层，UI 层多半是产品设计好，交给运营来使用而已的某种手段而已，你觉得呢？

批注版：https://www.notion.so/plidezus/DDD-1a542d013856453d9a2d6410dc020408

原文：https://www.zhihu.com/question/25089273/answer/233316164

❧

软件吃软件，编程工作会越来越多吗？

**少楠说：**上周和一个投资人朋友聊天，国内做 Notion Like 和 Airtable Like 的创业公司越来越多，大家都笃定下一波 2B 工具的机会即将迸发，而这一波工具的核心其实都是围绕着 NoCode 和 LowCode 作为卖点，提高小微企业和个人的效率。

从积极地角度来看，以后创业「只差一个程序员」的情况会有所缓解，更多创造力的事情将会出现；而从悲观的角度来看，更多人将会失去职业 —— 因为越来越完善的基础架构，会导致许多人从创造者变成了组装者 —— 因为太多完善的组件和素材可以使用，并且这些东西足够优秀，已经鲜有机会从零来经历这些东西创造出来的过程了。当有一天系统足够强大的时候，这些维护系统的人就不需要了。

从这个角度来看，产品经理会越来越多还是会越来越少？这取决于软件自动化的程度。而我认为没有一个叫「医生」的岗位，他只是相关岗位的集合，我们经常开玩笑说 —— 一个皮肤科医生和美妆博主的距离，或许比神经内科的距离还近一些。许多产品人（尤其是新人）都认为有一个叫「产品经理」的岗位，其实最终来看，他应该是电商产品经理、IM 产品经理、交易平台产品经理等。试图学习一套通用性的思路来解决问题，就像用一套开源框架解决已经被人解决的问题一样，这个过程中自己增加的附加值很少，那么对于公司来说这种人就不重要。

所以从这个角度来看，我个人对「培训」出来的产品经理有一种特殊的偏见，记得当时和腾讯的 Teddy 兄聊天，他给我们讲过最初他们那批人（做 Qzone 的）刚开始成长很慢，但是能一直成长。而后续他们精心设计了成长体系后，新人成长比他们迅速很多，但是最终都停在了某个瓶颈上，很难突破 —— 建造系统的思维方式，和使用系统的思维方式，截然不同

批注版：https://www.notion.so/plidezus/9a37a6753a9c4627a57472919d8099d2

原文：http://www.ruanyifeng.com/blog/2020/05/will-programmers-increase.html

❧

Persona 的起源

**少楠说：**虽然现在 Persona （用户画像）似乎被说烂了，但是真正会用的人也不多，能不断地更新画像的团队就更为稀少了。这个技能之所以知易行难是因为，你交谈的对象是一个活生生的人，有丰富的背景，**你需要从海量的信息中捕捉到，哪些背景是影响他决策的因素，**以及他在使用你的产品时，处于一种什么样的情境 —— 这也是我一直说解决问题要到现场去的原因，在办公室里面是无法 YY 出来用户所在的环境的。

而之所以 产品沉思录 ProductThinking 开篇就是关于认知和思维，一方面是让我们更好地理解我们自己，另一方面是为了更好的理解他人。

这是 2017 年初翻译的一篇关于 Persona 的起源，最近整理笔记的时候又发现了，似乎没在这里发过，所以重新整理了下。知道过去，才能更好地设计未来。

当时正在帮许多公司做产品咨询，发现许多公司并不知道自己的用户是谁，沟通起来效率也很低，就额外增加了 Persona 这堂课和这个调研部分。不过当时也激起了自己的好奇心，想知道用户画像到底是怎么来的，便有了此文。Persona 不是什么玄学，文中 Alan Cooper 当时想法也很朴素，为了让团队都知道典型用户的样子。当时虽然没有成熟的理论，但也已经够用了。所以如果你现在对你的用户画像模糊，不如开始做起来访谈吧。

2017 年中加入丁香医生之后，也要求团队做了大量的用户调研，最终沉淀了一些用户画像，文章末尾有一些早期案例（不代表今日用户构成），仅供参考。

批注版：https://www.notion.so/plidezus/Persona-4f2a3e362c7f44d39993288d3c56ba75

原文：https://www.cooper.com/journal/2008/05/the_origin_of_personas/

❧

温故知新：人生总有一刻，我们会开始思考死亡

收录时间：january 2017

**少楠说：**当时摘录这篇文章的时候，还没有「少楠说」这个部分。我记得我开始思考死亡，是有一次从老家回上海，在火车上看《最好的告别》，那时候才理解什么是死亡，以及我们该以什么样的方式面对。前年一周内，先后送走了姥姥和爷爷，在火葬场看着青烟升起的时候，我也在思考我们活着的意义是什么呢？

我一度很沮丧，沮丧于始终没有找到自己所热爱的东西，或者说曾经有过热爱的东西，被我自己搞丢了。又会非常焦虑，焦虑于已经过了而立之年，依旧一事无成。或者当年年轻气盛的时候很容易找到意义 —— 只需要和你们不一样就好了，大不了重新来过。而站在今天的时间和空间，能选择的范围其实更多，但是 load 的次数却变少了。

我大概明白了，茨威格在《人类的群星闪耀时》所说的那种幸运是什么 —— 「最大的幸运，莫过于在年富力强的时候，发现了自己的使命」

我依旧没有答案，只是相比些许年前创业失败时候的迷茫，现在的迷雾中大致能看到些许微光，不知是黎明，还是鬼火。不过文中的两个解决方案我倒是认同。一种是将自己与一些更宏大的东西联系起来：一个数学定理、一本文学著作、一件艺术作品或一种恒久的信仰。马尔克斯与康德靠《百年孤独》与《纯粹理性批判》遗世独立，米开朗基罗把《创世纪》和《最后的审判》印刻在西斯廷大教堂里，供千万后朝拜——他们肉身虽灭，但精神不朽——反正建筑是永远戳在那儿。还有一种就是，生活在当下的每个瞬间里，不烦扰过去、不担忧将来。

热爱可抵岁月漫长

批注版：https://www.notion.so/dd0826476d064e3d9968b16860666df6

原文：https://zhuanlan.zhihu.com/p/24640592