做决策需要谨慎，尽可能多的收集上下文，然后基于自己的上下文和分析的范式，进行决策。如果可以，拿着决策去找长者聊聊，让他们用经验给你指导。
做完决策后，快速落地，以免夜长梦多。
比如 -> 2024.9.2 一个重要的决定
本文初次写于 2023 年 10 月 8 日。
谨慎的做决策，然后快速的落地
OnCall 别说「报错消息很明确了」
今晚在写飞书 Bot ，遇到了一个无法解决的问题的时候，不得已，找到了飞书的 OnCall。但在聊天的一开始，OnCall 的同学便回复了「报错消息很明确了」的回复。
让我开始有点生气。
生气的点在于，作为一个专业的开发者，onCall 之前查文档我还是心里有数的，如果问题可以被解决，我就不会选择进入 onCall 的流程。这样的回复有点质疑我的专业的感觉。
但是，换个角度来思考，onCall 同学可能确实是在忙，有点不爽。可以理解。
那有没有一个更好的办法来规避这个问题？
- 回复：「你好，这个报错文档中有对应提醒，是否已经按照文档描述调试过了？」这样的回复虽然含义差距不大，但缺少了「质疑」的感觉。
- 直接回复错误码对应的问题（但这部分其实是需要工具支持的，比如帮助 onCall 同学提供一个快速回复的工具，降低成本）
希望各位 onCall 同学都可以规避这个问题，不要陷入 onCall 导致脾气暴躁的环节。
推广需得法
对于很多运营新人来说，社群运营 = 发广告。但，运营推广实际上是会消耗你的 Credit 的。因此，在实际去落地你的推广动作时，最好想清楚你到底想要什么？以及你的动作会损失什么。
举个例子，假设你有一个社群，你可以选择不停的去发广告，这样可以获得足够的曝光，但另一面是，频繁的发布广告，会让你损失你的用户 —— 因为你伤害了用户的体验。
如果你的运营行为本身会伤害用户体验，那么这个行为是否有必要，要认真思考一下。不仅如此，在触达用户时，也需要考量自己的频次，假设你的内容不是刚需，则需要尽可能的控制自己触达用户的频次（你又不是人民币，别人凭什么对你笑脸相迎？）。多次的触达可能意味着让用户困扰，甚至拉黑。举个例子来说，你有没有接到过各种保险公司打电话过来让你买保险的电话？前几个电话可能你还真的愿意接，但随着电话的频次越来越高，你就不再愿意接电话了，而是选择直接挂掉电话，甚至拉黑。
运营并不简单，也并不是任何一个人都能做的。
密码保护：2024.9.2 一个重要的决定
如何在繁杂的工作之中，找到属于自己的时间
作为一个产品策划 & 产品运营，我难免会有一些会要开。不过，我始终遵循着在腾讯时的习惯 —— 为自己预留 Focus Time，借此为自己留下属于自己的时间。
什么是 Focus Time？
有些时候，我需要一个整段的时间来思考一个问题时，我就会选择在日历上预约一个小房间，然后在这个小房间内静静地完成思考。
- 手机静音
- 飞书 设置暂停通知
通过这样的设定，强行将自己拉到一个新的、空白的环境中，确保自己可以有整块的时间来完成思考和内容的构建。
在实际过程中，一些建议
- 除非必要，尽量预定小房间：小房间可以用大房间替代，但大房间却无法用小房间来替代。你将大房间占用，可能会影响别人的正常工作。
- 不要长时间 Focus Time：人的精力很难长时间集中，如果长时间集中，你大概率会整个人精疲力竭。 1 ～ 2 个小时的 Focus Time 足以让你完成自己的思考。而细节的工作，其实可以在工位上完成。
你需要两个日历
在进入字节之前，我一直在 iPhone 上使用 Calendar 5 来管理自己的日程，简单方便。进入字节后，我将日程的管理转移到了飞书之上，使用飞书来管理的我的日程，方便，毕竟约会议室什么的，确实很舒服。
不过，我也发现了一些问题，出于安全原因，飞书的日历不支持在外部读取，只能在飞书上查看（也正常，毕竟日程里还包含了与会人、时间、地点等信息，真要是泄漏了很麻烦的），那就需要考虑，我的生活日历放在哪里？当然可以放在飞书上，并设置隐私，但总觉得奇奇怪怪的。所以，我还是用回了 Calendar 5。
在具体的使用上，我是这样操作的：
- 工作日历保留在飞书上，工作日历的时间设定在上午的 10 点 ～ 下午 7点（合同里的工作时间），基本上满足了绝大多数场景下的需求。
- 个人日历放置在 Calendar 5 上，只用来记录下午 7 点 ～ 早上 10 点之间的日程（当然，有一部分是睡觉的时间）
这样有意识的区分可以让我将工作和生活的日程区分开。
在实际操作的时候，一定要注意，不可将生活日历放在飞书中读取，因为这样会让你下意识的想在飞书中加入日程，是比较不方便的。因此，有意识的隔离是必要的。
投资投的是认知
为什么说投资投的是认知？
因为每个人的风险偏好、资金情况、收益时间、收益预期不同。
别人讲投资策略还可以看看，聊投资标的看的意义不大。
我自己的“认知”的例子
我自己曾经是 $NVDA 的持有人，我在 100 美元买入，在 150 美元卖出，这是因为在我看来， $NVDA 只值 150 美元。但实际上，$NVDA 一路疯涨，涨到了 1000 美元，并完成了拆股的动作。
如果我认知到 $NVDA 值 1000 美元，那我不会在 150 美元卖出。
你知道一个股票值多少钱，便是你的认知。认知结合当前的市场价格，就很容易做出投资的决策。
成为对抗「制度化」的人
对于大企业的员工而言，我们会有逐渐「制度化」的倾向。因为制度确实帮助我们包办了一切。但作为一个独立的个体。我们既要享受制度化带来的便利，也要警惕制度化带来的问题。
在《肖申克的救赎》当中，制度化使得图书馆管理员老布身上体现带来的淋漓尽致。被关押了 50 年的他，没办法再良好的重新生活在社会当中，最终，以自杀告别。
而对于我们每个人的启示就是，我们要学会主动对抗制度化。主动对抗制度化不意味着你要抗拒企业提供的各种制度。也不意味着你为企业服务一段时间后就离开。
主动对抗制度化意味着你应该学会主动反思企业提供给你的各种价值，以及反思企业提供的价值是否有可以替代的解决方案。在 Netflix 的文化当中，鼓励员工去外部企业面试，也是一种提醒你反思体制化的手段。但所有的这些，都不如我们自己反思「我是否被所在的企业制度化了？」，「除了企业的制度化相关的东西，我们还有一些什么？」
用什么样的视角看待问题决定产品的形态
在计算机领域有一个非常经典的业务模型 —— IaaS、PaaS、SaaS，借助这个业务模型的区分，我们可以快速的给自己的产品找到定位。
但在看产品的时候，其实你不应该去关注这些技术维度 —— 或者说，你真正应该关注客户的问题，以及你如何看待这个问题。
当你关注问题的视角不同，你的产品形态也会完全不同。
举个例子：
- 网站的部署需要服务器
- IaaS 层的产品认为我们只要让服务器易于获得就好，那我们就做 IaaS 层的云主机进行售卖。
- PaaS 层的产品认为服务器只是资源维度，用户并不关心资源，只关心应用的部署，那我们就做平台层面的产品，我们给用户提供基建，用户只关心基建之上的应用即可。
- SaaS 层的产品认为，网站不过是服务于业务的产品，既然如此，我为什么不直接给用户提供能解决问题的手段，技术根本不重要。
当你去找你的产品的竞品的时候，除了去关注同一个层次的产品，也需要关注到哪些和你不是同一个层次，但解决的问题相似或类似的产品，这些东西会有助于你更好的理解自己的产品，并划分产品的界限。
大团队和小团队的工作体验
今天在上班路上听播客听到了关于创业公司和大公司的事情（也可能是我看即刻看到的，记不清了）。提到了大团队和小团队的工作体验。刚好也聊一下自己的体验。
小团队
我进公司以来，其实大部分时间是在小团队工作 — 轻服务团队，20多个人，包含产研。虽然大家都是研发工程师，但细分为架构组、业务组、前端、产品组四个方向，每个组内几个人，坐在两排位置上。
在轻服务的工作体验最大的就是 —— 开心，我们只需要关注我们想要做的事情，把我们要做的事情做到最好就可以。不需要太过思考这个业务对于领导和公司的价值（我乐观的相信这个业务是有价值的，未来是可以成的）。我的日常工作是创造出一个新的东西来，去解决新的问题，价值感满满。
不过现在回过头来想想，我们当时之所以能做的那么开心，可能很大程度上是王潇在替我们负重前行，帮我们扛住了更大的压力，让我们可以更加的开心做想要做的事情。
大团队
来到开放平台后，我的工作模式不可避免的从一个小团队的模式变成了大团队的模式。开放平台单产品就有 20 人左右（产品+运营），加上研发，估计要百来人？
我们每个人工作的事情也会更加的细致和细分，每个人都在做一些更细致的问题。以我为例，我最近专注在如何让飞书开放平台的 OpenAPI 可以更好用。虽然说起 OpenAPI ，大家都觉得这是个小事，但想要做好还是有许多细分的事情要做。我需要在更加细分的领域深耕细作。
在小的领域深耕细作的价值感显然不如创建新的东西。但我觉得不一定是坏事，过去我的似乎都太过于野路子、创业公司化，深耕细作磨练一下自己是一个不错的选择。
在开放平台的另外一个感受就是 —— 责任，不同的 leader 的管理风格不同。有的 Leader 的风格好处是让每一个人都可以更加专心做自己想做的事情。另一方面也会失去承担更大责任的可能（因为责任都是Leader在扛）。另外的 Leader 显然对于我是有明确的预期的，对于我来说，我也感受到了这样的预期。对我自己而言，是一种压力，也是一种激励，希望自己可以达成那样的预期。
总结
大团队也好，小团队也罢，都有所得，挺好。在小团队野路子不是坏事，在大团队深耕细作也不是坏事，只知道这一种选择才是坏事。记得，参差多态乃是幸福本源。
OKR 要长远，但迭代要敏捷
飞书执行季 OKR 已经很久了，相比于过去的双月 OKR，我认为这确实是一个好的事情。季度 OKR 可以让我们在一个更长期的事情上来完成我们要达成的目标而无需担心自己所做的事情要更加的长远和长期，也期待更多的团队和协作方可以享受到季 OKR 的带来的长期。
但从另外一个方向来看，即使我们使用了季度 OKR，也需要关注执行的迭代。
OKR周期是我们达成目标的周期，而做事的手段则应该尽可能的敏捷和快速。快速判断、快速执行、快速复盘、快速修正。
目标大和周期长是我们要着眼于更重要、更长期的事情。而迭代的敏捷，则可以帮助我们更好更快的抵达目标。
作为一个技术出身的产品的自我阉割
作为一个技术出身的产品同学，我比较自豪的是，我不会提出一些非常离谱的需求。因为我大体上可以感知到技术的边界在哪里，但另外一个层面，我同样也会有比较严重的自我阉割的问题。
比如，如果某一个数据的要求严重超出了一般意义上的限制，我可能就会先自我阉割，认可这个事情虽然能做，但可能 ROI 划不过来，前置给了判断。但实际上，真的做不到么？未必，也可能只是我们没有去做。当然可能 ROI 上划不过来，但在产品对标和洽淡合作时，这些可能是会被客户挑战的问题：“为什么你不如 XXX”
下次做决策，要先多调研一下， 再做判断，不能让自己的技术脑完全占领了高地。
先 Solution，再 Product
我们部门名字之前是叫「Integration and AI Solutions」，但坦白来讲，过去我一直没太理解这个部门的含义，加上自己的序列一直是产品，所以始终带着 Product 的帽子，而没太在意 Solution。但最近发生的一件事，让我更理解我们的部门名，以及，想清楚了更应该做什么。
作为 RD 出身的 PM，我不自觉的会将手头在做的事情进行抽象 —— 抽象出面向对象的类，避免面条式代码。这样做很好，我们尽可能的提升我们在做的事情的可复用性（从一个具体的事项中，抽象出可以服务更多的人的需求，这也太产品了）。但，这样也很坏，因为一但没有把握好度，就会陷入到无限抽象的怪圈里。虽然产品抽象出来了，但用户的问题并没有得到解决。很显然，我曾成为后者，忙于抽象和设计产品，而不是真正的解决问题。
而走过这个阶段，我所得到的教训便是：「做事应该先 Solution，后 Product」，你需要先为用户解决问题，产生价值，再思考如何通过抽象去服务于更多的人。如果过早的开启抽象，大概率会陷入到虽然设计的很好，但不落地，不解决问题的困境当中。
用户关心的不是你的 Product ，他只关心他的问题是否得到解决， Product 只是 Solution 的一环。如果连问题都没有解决，那你的 Product 又有何用呢？
我希望我的反思能够启发大家，在产品开发和解决方案提供之间找到合适的平衡点，共同进步。
为什么是产品决策优先级（二）
在上次写完「为什么是产品决策优先级」之后，我也和身边的几个产品同学聊了聊我的推演逻辑，他们给了我不同的输入，让我觉得，这些内容应该分享出来，既帮我厘清了思路，也帮助我看到了不一样的产品。
首先是产品 A 同学， 他的观点很简单：产品经理之所以决策优先级，是因为产品经理为这个产品的最终结果负责。这个逻辑其实是从证明的视角来看的，虽然所有人都为产品结果负责，但运营同学可以通过篇一些其他指标来证明自己的价值 —— 比如运营指标好；研发同学可以通过技术指标来证明自己的价值。唯独产品经理别无选择 —— 他成功与否的评价唯一标准便是 —— 产品自身的成功与否。产品最终承担一个产品背后的所有结果，从权责利对等的视角来看，则应该由产品 —— 这个最终承担后果的人来作出决策。
其次是产品 B 同学，他的观点比较有意思，也给我带来了不同的视角：产品经理之所以需要决策优先级，是因为价值不明确，需要“有判断力”的人来做出价值判断。他给我觉得例子是早期头条研发，早期的头条研发在整个产研链路上是比较有话语权的， 原因是产品的收益相对明确 —— 调整某个策略，能够非常明确的计算和评估出 ROI，导致最终优先级和价值回收变得非常简单粗暴 ： 按照策略的预测上能力即可。相比于简单粗暴的广告 / C 端业务，B 端的业务显得收益不那么明确 —— 产品设计出一个功能，商业化团队未必能卖出去；商业化需要的功能，从产品视角来看，未必是适合产品定位的。从产品到商业化的长周期链路，使得对于产品的决策能力要求会更强 —— 需要产品能够从海量的信息中找到什么是最重要的？找到那个必须要做的事情。
为什么是产品决策优先级？（一）
这个是个好问题：
- 为什么是产品来决策优先级？而不是研发而不是运营而不是项目经理？这个背后的核心到底是什么？
- 产品决策优先级的底层逻辑到底是什么？如果底层逻辑可以迁移，是不是别人也可以决策优先级？
我的答案如下：
- 产品决策的优先级核心逻辑是信息补全，产品让渡了一部分时间去参与各种会议，来换取足够的上下文，并基于这些上下文做出决策和调整。
- Leader 的预期是产品会被拉到各种不同的群 / 上下文里，梳理不同的信息，明确优先级，并帮助业务达成目标。
- 严格来说，一个好的产品需要的能力挺多的，你需要有用户感知、项目经验、沟通能力等各种不同的能力，才能更好的当产品。正是这样的原因，也让产品可以成为团队中的 Connector ，对齐不同人的信息和上下文。
- 产品决定大范围的优先级，但一些细节的优先级可以由具体执行的人来决策，毕竟要让听到炮火的人来做决策，才不会出现问题（也依赖听到炮火的人的能力）。
总结一下：
- 产品的决策底层逻辑是信息，这个人可以是运营/产品/研发，只需要让渡时间来做这些事情，你就可以成为这个做决策的人。
零食经济学
压力山大的时候，我就会选择去零食箱拿点零食，来消磨自己内心的压力（这也是为啥体重一直居高不下）。取零食多了，我开始有一些有意思的发现：
- 我们楼层经常会剩下一些烤面筋、虾片、鸭脖；
- 每次补仓的时候，并不会把之前的零食拿走，而是直接往里加新的零食；
- 周末的时候，即使大家不怎么喜欢的零食，也会被吃完；
让我想到一个问题 — 如果我是餐饮同学，我会怎么做？
如果我希望零食被消耗的更快，那我会每次拍照或简单统计一下剩余的零食，然后大概可以知道不同楼层的零食偏好，并在下一次补仓周期里，重点补上那些大家消耗比较快的零食。这样可以让零食大量的被消耗。
如果我希望零食被消耗的更慢，那我会每次拍照并简单统计一下剩余的零食，这样可以大概知道大家不喜欢什么，在补仓周期里就可以进一步的补充大家不喜欢的零食，从而让零食可以被消耗的更慢。
使用 Renamer 批量重命名，节约重命名时间
我最近在用 Youtube 看《喜人奇妙夜》（毕竟 Youtube 上有纯享版，体验太好了）。同时，为了方便我可以在地铁/高铁上看，我还会使用 Youtube-DLP 下载到本地。但，Youtube DLP 下载到本地的视频文件往往名字都特别特别的长，比如：
【纯享】《看不见的TA》i人闫佩伦和“鬼怪”张佑维变室友？ ｜ 《喜人奇妙夜》Amazing Night EP3 SKETCH #喜人奇妙夜 #闫佩伦 #张祐维 [XUsi1R1Ny80].f614.mp4
这个内容长度中存在了大量的无用信息，虽然对于 Youtube 这样的视频平台来说，有助于流量和搜索，但对于我这样的本地存储用户来说，大大的影响了我的本地观感，因此，我一般都会手动移出其中的无用信息。只保留作品名和基础的介绍信息，比如上面的文件名我会修改成 《看不见的TA》i人闫佩伦和“鬼怪”张佑维变室友？.mp4。
当然，我可以写一个脚本来完成，但重命名这件事实在是太过于常见了，所以我也懒得写脚本（且脚本还需要指定路径，麻烦。），刚好，SetApp 套装中有一个 Renamer 的 App，可以解决这个问题，于是便有了这篇文章，介绍我自己是如何处理的。
分析目标和模块
Renamer 提供了多种重命名的能力，其中包括文本替换、正则表达式替换、数字、移出文本等多种能力，这些能力将会成为我稍后使用的工具。
如果看我们的文件名前后，可以很清晰的分辨出，我操作了两个部分：
- 去除了最前面的【纯享】
- 去除了 ｜ 后面一直到拓展名的中间介绍文字。
因此，我需要用到两个模块，来实现替换 —— 正则表达式（Regular Expression） 和文本替换（Find & Replace）。
配置替换
替换纯享
纯享因为是固定文本，所以替换比较简单，新增一个替换的动作，选择 Find & Replace，并配置只对文件名生效，设置 Find 为【纯享】，Replace 为空，就会在执行替换的时候，将【纯享】替换为空文本，来达到移除特定内容的效果。
当然， 同样的功能你还可以用移除文本来操作 —— 选择 Remove Text, 并把要移出的 【纯享】放在里面即可。
替换其他内容
【纯享】因为是固定文本，相对简单，但后续的内容则就复杂了许多，其中的内容会变化，且包含了大量的 ID、标签等信息，单纯的 Find & Replace 是无法解决的，因此我们这里用到正则表达式替换来完成。
你可以借助于 Regexr 这个网站来调试你的正则表达式，在上方编写你的表达式，并在下方填写你的测试文本，通过高亮，即可判断是否正确匹配。
测试匹配正确后，复制上方的正则规则，在 Rename 中新增一个 Regular Expression 替换动作，配置成文件名 Only，并填入你的正则表达式。
效果
最后，拖入你要修改名称的文件，就可以查看到批量修改文件名的效果了。这时你只需要拖入多个文件，就能一次性给 N 个文件完成更名的动作了。
公司的期权该卖么？
在 X 上看到小橘子的这个信息，我觉得可以给一些我自己的输入。
从我自己的视角来看：如果你还愿意在这家公司工作，那么就应该继续持有。
接下来继续解释原因：
我这几年也在做一些投资，来满足自己在规律性的投资之外的动手的欲望。我卖飞过 NVDA、卖飞过 PDD、卖飞过 Microsoft。不过整体的收益还是正的，倒也还算是有一些心得。
期权可以理解为你所在公司的一部分权益，是兑换未来股票的机会。他代表着你对于一家公司的金钱的投入（虽然你并没有真实投入钱，但它也会占用同样钱的机会成本）。而你为一家公司工作，则是对这家公司的时间投入。
从这个视角来看，如果你觉得一家公司还不错 、还在增长，或还有增长的空间，你应该继续持有这家公司的期权或股票（至少这些不是卖出期权的理由）。那么，什么是我们卖出的理由？是我们发现更好的投资标的（比如你当前公司的增长是年化 10%，但你找到了年化 50% 的渠道）；或者是我们发现当前公司已经不是优质的资产（比如你的公司已经在走下坡路了，它已经无力增长）。
如果你的卖出期权的理由符合上述两者任一，那么不要犹豫，卖吧。此外，如果你发现卖出的理由是当前的公司已经不是优质的资产，我建议你额外加一层评估：我当前是否有必要继续在这家公司工作？避免金钱投入分散了风险，但大量的时间放在了垃圾的资产之上。以及，记得在离职的时候把你的所有期权出清（既然它对于你来说已经是劣质资产了，为什么不卖掉呢？）。
当然，上述的这些条件依然需要你自己判断。不过，如果你持有的是自己所在公司的期权，其实相对来说还是好判断的，因为你真的懂这家公司，你真的能够感受到它的好与坏。相比于不熟悉的投资经理来说，我们还是可能拿到更细节的信息辅助判断的。这些信息，足够让你判断是否要继续持有当前公司的期权了。