今天和朋友聊天时，突然意识到，我的很多价值观是隐藏在水下的，因此，单开此文，记录我的价值观，此文将会定期更新。
胜率是指你获得胜利的概率（如果你可以定义出胜利）；而赔率则是你取的胜利后的获得收益的倍数。比如，买个股是一个胜率低但赔率高的事情；买大盘指数基金是一个胜率高但赔率低的事情。
在很多的决策中，我追求的都是胜率而非赔率：
因为我认为，人这一生很短暂，也没有重来的机会（maybe 有），所以要追求胜率，因为可能一旦失败，就万劫不复。
我认为，生活本无意义，我们的行为为我们的生命增添色彩，且更多的色彩的生活更值得过，所以我追求生命层次的丰富性，我会去体验和追求不同的生活。
我和很多人合作过，基本上我会尽可能的追求与合作方线下协作。因为我奉行「见面三分情」，见面会让我们可以具像化的认知网线的另一端的那个人，我们会知道 TA 是一个什么样的人，TA 会怎么和你交互。这一切信息，都会帮助你更有效的降低沟通的摩擦力。
上个月完成了工伤的认定，于是把治疗期间的费用拿去进行了一些报销。把一些信息也分享给大家。
工伤报销需要你提供的是你从入院到出院所用到的各种发票、明细、收据等信息，进行报销。在治疗期间，你大概率是会使用医保 + 自行支付的方式来进行报销的。所以到时候报销的是你自行支付的部分。
如果你在出事故的时候，刚好处在一个尴尬期（比如我当时就是刚从深圳 relocate 到北京，社保虽然已经交上了，但还没有社保卡和社保电子凭证），你就需要先自行垫付所有费用。并在完成治疗后进行报销。
当你完成了治疗后，可以联系你的报销同学，需要进行一个手工报销的申报表，大概是下面这样的。会需要你填写一些基本的信息。包括工伤证号、就诊医院等等。
此外，你的门诊和住院需要分别填写单据。
理论上，你的所有医疗费用都可以通过工伤报销来进行报销。工伤保险达成的条件相对比较苛刻（需要完成工伤认证），相应的进行的补贴也会比较多。特别是你使用的是正常的医疗救助的情况下，工伤理论上可以报销所有的开支。
如果工伤保险的报销未能覆盖完你的所有医疗支出，那么工伤保险可以开具一个分割单，你可以拿着分割单，进行商业保险的报销。
我之前在字节圈发布过工伤的一些基本信息，有同学提到了“会给一笔巨额赔偿”。这部分是这样的。
并不是所有的工伤都会有巨额赔偿的！
正常情况下，工伤保险的主要用途是用来支付你的医疗费用。凡在工伤保险诊疗项目目录、工伤保险药品目录、工伤报销住院服务标准的，都会进行报销。
理论上，你在进行治疗时，可以咨询一下医生，如果你使用的都是在医保范围内的，大概率都可以在工伤当中报销。
《工伤保险条例》
第五章工伤保险待遇
第三十条,职工因工作遭受事故伤害或者患职业病进行治疗，享受工伤医疗待遇。
职工治疗工伤应当在签订服务协议的医疗机构就医，情况紧急时可以先到就近的医疗机构急救。
治疗工伤所需费用符合工伤保险诊疗项目目录、工伤保险药品目录、工伤保险住院服务标准的，从工伤保险基金支付。工伤保险诊疗项目目录、工伤保险药品目录、工伤保险住院服务标准，由国务院社会保险行政部门会同国务院卫生行政部门、食品药品监督管理部门等部门规定。
职工住院治疗工伤的伙食补助费，以及经医疗机构出具证明，报经办机构同意，工伤职工到统筹地区以外就医所需的交通、食宿费用从工伤保险基金支付，基金支付的具体标准由统筹地区人民政府规定。
工伤职工治疗非工伤引发的疾病，不享受工伤医疗待遇，按照基本医疗保险办法处理。
工伤职工到签订服务协议的医疗机构进行工伤康复的费用，符合规定的，从工伤保险基金支付。
至于大家提到的“巨额赔偿”，这部分其实是指工伤的“劳动能力鉴定”部分，根据工伤保险条例，如果你的劳动能力鉴定获得了等级评定，则会获得相应的赔偿。但你认定工伤不意味着你一定有劳动能力鉴定等级，二者并不对等， 只是绝大多数的时候，我们看到的工伤往往都是较为重大的伤情，所以我们会下意识认为“工伤 = 巨额赔偿”。能否评级需要经过工伤部门的劳动能力鉴定委员会进行评审，评审通过后，获得等级，即可申请赔偿。
在你正常治疗的时候，你大概率是无法判断自己是否是工伤 & 能否认定。所以你会进行最方便的救治，因此这部分就只能通过手工报销申报来完成报销。
而工伤定点医院，则是可以使用你的工伤证进行就诊，通过工伤证直接进行工伤基金的费用报销（此部分待确认，主要是我的下一次手术在明年了。暂时只能根据公开信息确定，明年做手术了再同步这部分信息。）
你在获得认证后，工伤部门会给你发放工伤证。你需要将其交给你的工伤办理同学，方便他进行办事。
做决策需要谨慎，尽可能多的收集上下文，然后基于自己的上下文和分析的范式，进行决策。如果可以，拿着决策去找长者聊聊，让他们用经验给你指导。
做完决策后，快速落地，以免夜长梦多。
比如 -> 2024.9.2 一个重要的决定
本文初次写于 2023 年 10 月 8 日。
作为一个产品策划 & 产品运营，我难免会有一些会要开。不过，我始终遵循着在腾讯时的习惯 —— 为自己预留 Focus Time，借此为自己留下属于自己的时间。
有些时候，我需要一个整段的时间来思考一个问题时，我就会选择在日历上预约一个小房间，然后在这个小房间内静静地完成思考。
通过这样的设定，强行将自己拉到一个新的、空白的环境中，确保自己可以有整块的时间来完成思考和内容的构建。
在实际过程中，一些建议
在进入字节之前，我一直在 iPhone 上使用 Calendar 5 来管理自己的日程，简单方便。进入字节后，我将日程的管理转移到了飞书之上，使用飞书来管理的我的日程，方便，毕竟约会议室什么的，确实很舒服。
不过，我也发现了一些问题，出于安全原因，飞书的日历不支持在外部读取，只能在飞书上查看（也正常，毕竟日程里还包含了与会人、时间、地点等信息，真要是泄漏了很麻烦的），那就需要考虑，我的生活日历放在哪里？当然可以放在飞书上，并设置隐私，但总觉得奇奇怪怪的。所以，我还是用回了 Calendar 5。
在具体的使用上，我是这样操作的：
这样有意识的区分可以让我将工作和生活的日程区分开。
在实际操作的时候，一定要注意，不可将生活日历放在飞书中读取，因为这样会让你下意识的想在飞书中加入日程，是比较不方便的。因此，有意识的隔离是必要的。
对于大企业的员工而言，我们会有逐渐「制度化」的倾向。因为制度确实帮助我们包办了一切。但作为一个独立的个体。我们既要享受制度化带来的便利，也要警惕制度化带来的问题。
在《肖申克的救赎》当中，制度化使得图书馆管理员老布身上体现带来的淋漓尽致。被关押了 50 年的他，没办法再良好的重新生活在社会当中，最终，以自杀告别。
而对于我们每个人的启示就是，我们要学会主动对抗制度化。主动对抗制度化不意味着你要抗拒企业提供的各种制度。也不意味着你为企业服务一段时间后就离开。
主动对抗制度化意味着你应该学会主动反思企业提供给你的各种价值，以及反思企业提供的价值是否有可以替代的解决方案。在 Netflix 的文化当中，鼓励员工去外部企业面试，也是一种提醒你反思体制化的手段。但所有的这些，都不如我们自己反思「我是否被所在的企业制度化了？」，「除了企业的制度化相关的东西，我们还有一些什么？」
今天在上班路上听播客听到了关于创业公司和大公司的事情（也可能是我看即刻看到的，记不清了）。提到了大团队和小团队的工作体验。刚好也聊一下自己的体验。
小团队
我进公司以来，其实大部分时间是在小团队工作 — 轻服务团队，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 又有何用呢？
我希望我的反思能够启发大家，在产品开发和解决方案提供之间找到合适的平衡点，共同进步。