在软件领域，我们有非常经典的 IaaS、PaaS、SaaS 模型，我们使用这个模型定义着我们的产品。
但另一方面，这个定义也局限了很多人的想法 —— SaaS just Software as a Service。
实际上，如果你是一个独立开发者 / 直面用户的岗位，你需要深刻的明白 —— SaaS 更大的价值不应该是 Software ，而应该是 Solution —— 用户从来不关心你是不是有 Software，用户只关心你的 Solution 能不能解决你的问题。
如果你不知道你的 Software 是在解决谁的问题 —— 不妨想想，是不是你没有找到你的Software 到底应该如何放在 Solution 当中 ，以及那个 Solution 对应的问题到底是什么。
持续关注用户的问题，尝试提供靠谱的 Solution 去解决他的问题 —— 而不是关注你的 Software。除了你，没有人真正在意你的 Software。
工伤后续的恢复期相关的看病，是可以使用工伤证进行看病的。而使用了工伤证在对应的定点医院看病时，是不需要支付任何费用的，全部由工伤保险机构来承担。
上个月完成了工伤的认定，于是把治疗期间的费用拿去进行了一些报销。把一些信息也分享给大家。
工伤报销需要你提供的是你从入院到出院所用到的各种发票、明细、收据等信息，进行报销。在治疗期间，你大概率是会使用医保 + 自行支付的方式来进行报销的。所以到时候报销的是你自行支付的部分。
如果你在出事故的时候，刚好处在一个尴尬期（比如我当时就是刚从深圳 relocate 到北京，社保虽然已经交上了，但还没有社保卡和社保电子凭证），你就需要先自行垫付所有费用。并在完成治疗后进行报销。
当你完成了治疗后，可以联系你的报销同学，需要进行一个手工报销的申报表，大概是下面这样的。会需要你填写一些基本的信息。包括工伤证号、就诊医院等等。
此外，你的门诊和住院需要分别填写单据。
理论上，你的所有医疗费用都可以通过工伤报销来进行报销。工伤保险达成的条件相对比较苛刻（需要完成工伤认证），相应的进行的补贴也会比较多。特别是你使用的是正常的医疗救助的情况下，工伤理论上可以报销所有的开支。
如果工伤保险的报销未能覆盖完你的所有医疗支出，那么工伤保险可以开具一个分割单，你可以拿着分割单，进行商业保险的报销。
我之前在字节圈发布过工伤的一些基本信息，有同学提到了“会给一笔巨额赔偿”。这部分是这样的。
并不是所有的工伤都会有巨额赔偿的！
正常情况下，工伤保险的主要用途是用来支付你的医疗费用。凡在工伤保险诊疗项目目录、工伤保险药品目录、工伤报销住院服务标准的，都会进行报销。
理论上，你在进行治疗时，可以咨询一下医生，如果你使用的都是在医保范围内的，大概率都可以在工伤当中报销。
《工伤保险条例》
第五章工伤保险待遇
第三十条,职工因工作遭受事故伤害或者患职业病进行治疗，享受工伤医疗待遇。
职工治疗工伤应当在签订服务协议的医疗机构就医，情况紧急时可以先到就近的医疗机构急救。
治疗工伤所需费用符合工伤保险诊疗项目目录、工伤保险药品目录、工伤保险住院服务标准的，从工伤保险基金支付。工伤保险诊疗项目目录、工伤保险药品目录、工伤保险住院服务标准，由国务院社会保险行政部门会同国务院卫生行政部门、食品药品监督管理部门等部门规定。
职工住院治疗工伤的伙食补助费，以及经医疗机构出具证明，报经办机构同意，工伤职工到统筹地区以外就医所需的交通、食宿费用从工伤保险基金支付，基金支付的具体标准由统筹地区人民政府规定。
工伤职工治疗非工伤引发的疾病，不享受工伤医疗待遇，按照基本医疗保险办法处理。
工伤职工到签订服务协议的医疗机构进行工伤康复的费用，符合规定的，从工伤保险基金支付。
至于大家提到的“巨额赔偿”，这部分其实是指工伤的“劳动能力鉴定”部分，根据工伤保险条例，如果你的劳动能力鉴定获得了等级评定，则会获得相应的赔偿。但你认定工伤不意味着你一定有劳动能力鉴定等级，二者并不对等， 只是绝大多数的时候，我们看到的工伤往往都是较为重大的伤情，所以我们会下意识认为“工伤 = 巨额赔偿”。能否评级需要经过工伤部门的劳动能力鉴定委员会进行评审，评审通过后，获得等级，即可申请赔偿。
在你正常治疗的时候，你大概率是无法判断自己是否是工伤 & 能否认定。所以你会进行最方便的救治，因此这部分就只能通过手工报销申报来完成报销。
而工伤定点医院，则是可以使用你的工伤证进行就诊，通过工伤证直接进行工伤基金的费用报销（此部分待确认，主要是我的下一次手术在明年了。暂时只能根据公开信息确定，明年做手术了再同步这部分信息。）
你在获得认证后，工伤部门会给你发放工伤证。你需要将其交给你的工伤办理同学，方便他进行办事。
做决策需要谨慎，尽可能多的收集上下文，然后基于自己的上下文和分析的范式，进行决策。如果可以，拿着决策去找长者聊聊，让他们用经验给你指导。
做完决策后，快速落地，以免夜长梦多。
比如 -> 2024.9.2 一个重要的决定
本文初次写于 2023 年 10 月 8 日。
今晚在写飞书 Bot ，遇到了一个无法解决的问题的时候，不得已，找到了飞书的 OnCall。但在聊天的一开始，OnCall 的同学便回复了「报错消息很明确了」的回复。
让我开始有点生气。
生气的点在于，作为一个专业的开发者，onCall 之前查文档我还是心里有数的，如果问题可以被解决，我就不会选择进入 onCall 的流程。这样的回复有点质疑我的专业的感觉。
但是，换个角度来思考，onCall 同学可能确实是在忙，有点不爽。可以理解。
那有没有一个更好的办法来规避这个问题？
希望各位 onCall 同学都可以规避这个问题，不要陷入 onCall 导致脾气暴躁的环节。
对于很多运营新人来说，社群运营 = 发广告。但，运营推广实际上是会消耗你的 Credit 的。因此，在实际去落地你的推广动作时，最好想清楚你到底想要什么？以及你的动作会损失什么。
举个例子，假设你有一个社群，你可以选择不停的去发广告，这样可以获得足够的曝光，但另一面是，频繁的发布广告，会让你损失你的用户 —— 因为你伤害了用户的体验。
如果你的运营行为本身会伤害用户体验，那么这个行为是否有必要，要认真思考一下。不仅如此，在触达用户时，也需要考量自己的频次，假设你的内容不是刚需，则需要尽可能的控制自己触达用户的频次（你又不是人民币，别人凭什么对你笑脸相迎？）。多次的触达可能意味着让用户困扰，甚至拉黑。举个例子来说，你有没有接到过各种保险公司打电话过来让你买保险的电话？前几个电话可能你还真的愿意接，但随着电话的频次越来越高，你就不再愿意接电话了，而是选择直接挂掉电话，甚至拉黑。
运营并不简单，也并不是任何一个人都能做的。
作为一个产品策划 & 产品运营，我难免会有一些会要开。不过，我始终遵循着在腾讯时的习惯 —— 为自己预留 Focus Time，借此为自己留下属于自己的时间。
有些时候，我需要一个整段的时间来思考一个问题时，我就会选择在日历上预约一个小房间，然后在这个小房间内静静地完成思考。
通过这样的设定，强行将自己拉到一个新的、空白的环境中，确保自己可以有整块的时间来完成思考和内容的构建。
在实际过程中，一些建议
在进入字节之前，我一直在 iPhone 上使用 Calendar 5 来管理自己的日程，简单方便。进入字节后，我将日程的管理转移到了飞书之上，使用飞书来管理的我的日程，方便，毕竟约会议室什么的，确实很舒服。
不过，我也发现了一些问题，出于安全原因，飞书的日历不支持在外部读取，只能在飞书上查看（也正常，毕竟日程里还包含了与会人、时间、地点等信息，真要是泄漏了很麻烦的），那就需要考虑，我的生活日历放在哪里？当然可以放在飞书上，并设置隐私，但总觉得奇奇怪怪的。所以，我还是用回了 Calendar 5。
在具体的使用上，我是这样操作的：
这样有意识的区分可以让我将工作和生活的日程区分开。
在实际操作的时候，一定要注意，不可将生活日历放在飞书中读取，因为这样会让你下意识的想在飞书中加入日程，是比较不方便的。因此，有意识的隔离是必要的。
今天在上班路上听播客听到了关于创业公司和大公司的事情（也可能是我看即刻看到的，记不清了）。提到了大团队和小团队的工作体验。刚好也聊一下自己的体验。
小团队
我进公司以来，其实大部分时间是在小团队工作 — 轻服务团队，20多个人，包含产研。虽然大家都是研发工程师，但细分为架构组、业务组、前端、产品组四个方向，每个组内几个人，坐在两排位置上。
在轻服务的工作体验最大的就是 —— 开心，我们只需要关注我们想要做的事情，把我们要做的事情做到最好就可以。不需要太过思考这个业务对于领导和公司的价值（我乐观的相信这个业务是有价值的，未来是可以成的）。我的日常工作是创造出一个新的东西来，去解决新的问题，价值感满满。
不过现在回过头来想想，我们当时之所以能做的那么开心，可能很大程度上是王潇在替我们负重前行，帮我们扛住了更大的压力，让我们可以更加的开心做想要做的事情。
大团队
来到开放平台后，我的工作模式不可避免的从一个小团队的模式变成了大团队的模式。开放平台单产品就有 20 人左右（产品+运营），加上研发，估计要百来人？
我们每个人工作的事情也会更加的细致和细分，每个人都在做一些更细致的问题。以我为例，我最近专注在如何让飞书开放平台的 OpenAPI 可以更好用。虽然说起 OpenAPI ，大家都觉得这是个小事，但想要做好还是有许多细分的事情要做。我需要在更加细分的领域深耕细作。
在小的领域深耕细作的价值感显然不如创建新的东西。但我觉得不一定是坏事，过去我的似乎都太过于野路子、创业公司化，深耕细作磨练一下自己是一个不错的选择。
在开放平台的另外一个感受就是 —— 责任，不同的 leader 的管理风格不同。有的 Leader 的风格好处是让每一个人都可以更加专心做自己想做的事情。另一方面也会失去承担更大责任的可能（因为责任都是Leader在扛）。另外的 Leader 显然对于我是有明确的预期的，对于我来说，我也感受到了这样的预期。对我自己而言，是一种压力，也是一种激励，希望自己可以达成那样的预期。
总结
大团队也好，小团队也罢，都有所得，挺好。在小团队野路子不是坏事，在大团队深耕细作也不是坏事，只知道这一种选择才是坏事。记得，参差多态乃是幸福本源。
飞书执行季 OKR 已经很久了，相比于过去的双月 OKR，我认为这确实是一个好的事情。季度 OKR 可以让我们在一个更长期的事情上来完成我们要达成的目标而无需担心自己所做的事情要更加的长远和长期，也期待更多的团队和协作方可以享受到季 OKR 的带来的长期。
但从另外一个方向来看，即使我们使用了季度 OKR，也需要关注执行的迭代。
OKR周期是我们达成目标的周期，而做事的手段则应该尽可能的敏捷和快速。快速判断、快速执行、快速复盘、快速修正。
目标大和周期长是我们要着眼于更重要、更长期的事情。而迭代的敏捷，则可以帮助我们更好更快的抵达目标。
作为一个技术出身的产品同学，我比较自豪的是，我不会提出一些非常离谱的需求。因为我大体上可以感知到技术的边界在哪里，但另外一个层面，我同样也会有比较严重的自我阉割的问题。
比如，如果某一个数据的要求严重超出了一般意义上的限制，我可能就会先自我阉割，认可这个事情虽然能做，但可能 ROI 划不过来，前置给了判断。但实际上，真的做不到么？未必，也可能只是我们没有去做。当然可能 ROI 上划不过来，但在产品对标和洽淡合作时，这些可能是会被客户挑战的问题：“为什么你不如 XXX”
下次做决策，要先多调研一下， 再做判断，不能让自己的技术脑完全占领了高地。
我们部门名字之前是叫「Integration and AI Solutions」，但坦白来讲，过去我一直没太理解这个部门的含义，加上自己的序列一直是产品，所以始终带着 Product 的帽子，而没太在意 Solution。但最近发生的一件事，让我更理解我们的部门名，以及，想清楚了更应该做什么。
作为 RD 出身的 PM，我不自觉的会将手头在做的事情进行抽象 —— 抽象出面向对象的类，避免面条式代码。这样做很好，我们尽可能的提升我们在做的事情的可复用性（从一个具体的事项中，抽象出可以服务更多的人的需求，这也太产品了）。但，这样也很坏，因为一但没有把握好度，就会陷入到无限抽象的怪圈里。虽然产品抽象出来了，但用户的问题并没有得到解决。很显然，我曾成为后者，忙于抽象和设计产品，而不是真正的解决问题。
而走过这个阶段，我所得到的教训便是：「做事应该先 Solution，后 Product」，你需要先为用户解决问题，产生价值，再思考如何通过抽象去服务于更多的人。如果过早的开启抽象，大概率会陷入到虽然设计的很好，但不落地，不解决问题的困境当中。
用户关心的不是你的 Product ，他只关心他的问题是否得到解决， Product 只是 Solution 的一环。如果连问题都没有解决，那你的 Product 又有何用呢？
我希望我的反思能够启发大家，在产品开发和解决方案提供之间找到合适的平衡点，共同进步。
在上次写完「为什么是产品决策优先级」之后，我也和身边的几个产品同学聊了聊我的推演逻辑，他们给了我不同的输入，让我觉得，这些内容应该分享出来，既帮我厘清了思路，也帮助我看到了不一样的产品。
首先是产品 A 同学， 他的观点很简单：产品经理之所以决策优先级，是因为产品经理为这个产品的最终结果负责。这个逻辑其实是从证明的视角来看的，虽然所有人都为产品结果负责，但运营同学可以通过篇一些其他指标来证明自己的价值 —— 比如运营指标好；研发同学可以通过技术指标来证明自己的价值。唯独产品经理别无选择 —— 他成功与否的评价唯一标准便是 —— 产品自身的成功与否。产品最终承担一个产品背后的所有结果，从权责利对等的视角来看，则应该由产品 —— 这个最终承担后果的人来作出决策。
其次是产品 B 同学，他的观点比较有意思，也给我带来了不同的视角：产品经理之所以需要决策优先级，是因为价值不明确，需要“有判断力”的人来做出价值判断。他给我觉得例子是早期头条研发，早期的头条研发在整个产研链路上是比较有话语权的， 原因是产品的收益相对明确 —— 调整某个策略，能够非常明确的计算和评估出 ROI，导致最终优先级和价值回收变得非常简单粗暴 ： 按照策略的预测上能力即可。相比于简单粗暴的广告 / C 端业务，B 端的业务显得收益不那么明确 —— 产品设计出一个功能，商业化团队未必能卖出去；商业化需要的功能，从产品视角来看，未必是适合产品定位的。从产品到商业化的长周期链路，使得对于产品的决策能力要求会更强 —— 需要产品能够从海量的信息中找到什么是最重要的？找到那个必须要做的事情。
这个是个好问题：
我的答案如下：
总结一下：