坦白来讲,我不是一个很擅长人情往来的人。
这次来西安,看到了钟楼旁的大唐文创市集上的那句「我在乎的不是礼,而是往来」,让我意识到我对于人情往来的错误认识,也意识到自己过去的傲慢。
过去,我认为,礼嘛,人不到,但是礼到。没问题的,交给大伯帮我捎上礼就行。但其实,对方需要的是人到,反而不在乎这个礼。是的,谁又在乎这个礼呢?没有人在乎礼钱。
礼钱是个心意,多少随心。关键是,你心中是否有我?
我赠予你礼,你是否会回礼?你赠予我礼,我是否会回礼?有来有往,方成人情。
坦白来讲,我不是一个很擅长人情往来的人。
这次来西安,看到了钟楼旁的大唐文创市集上的那句「我在乎的不是礼,而是往来」,让我意识到我对于人情往来的错误认识,也意识到自己过去的傲慢。
过去,我认为,礼嘛,人不到,但是礼到。没问题的,交给大伯帮我捎上礼就行。但其实,对方需要的是人到,反而不在乎这个礼。是的,谁又在乎这个礼呢?没有人在乎礼钱。
礼钱是个心意,多少随心。关键是,你心中是否有我?
我赠予你礼,你是否会回礼?你赠予我礼,我是否会回礼?有来有往,方成人情。
在软件领域,我们有非常经典的 IaaS、PaaS、SaaS 模型,我们使用这个模型定义着我们的产品。
但另一方面,这个定义也局限了很多人的想法 —— SaaS just Software as a Service。
实际上,如果你是一个独立开发者 / 直面用户的岗位,你需要深刻的明白 —— SaaS 更大的价值不应该是 Software ,而应该是 Solution —— 用户从来不关心你是不是有 Software,用户只关心你的 Solution 能不能解决你的问题。
如果你不知道你的 Software 是在解决谁的问题 —— 不妨想想,是不是你没有找到你的Software 到底应该如何放在 Solution 当中 ,以及那个 Solution 对应的问题到底是什么。
持续关注用户的问题,尝试提供靠谱的 Solution 去解决他的问题 —— 而不是关注你的 Software。除了你,没有人真正在意你的 Software。
过去很长一段时间里,在坐高铁/飞机的时候,我总是习惯坐在靠走廊的位置。理由嘛,倒也简单 —— 我不想麻烦别人,毕竟坐在中间意味着你起身接水和上厕所需要麻烦坐在走廊位置上的人。
不过最近,我开始拥抱坐在高铁/飞机的中间,甚至靠窗位置上了。是什么推动了这样的变化 ?
是仔细分析了自己的行为习惯后得出的结论:
上面的一切分析告诉我了一个答案 —— 我在为一个 1% 发生的事情,而让自己投入了 100% 的成本,从 ROI 的成本来看,划不来。
于是乎,开始拥抱坐在窗边,开始享受坐在窗边,即使依然会觉得起身会麻烦别人,但,坦然接受这种小概率事件的发生。
多说一句,我其实平日里,比较讨厌持续做一件事 —— 我害怕被温水煮青蛙。实际上,如果我没有突然想开始分析自己,我可能继续会被温水煮青蛙,然后继续坐在靠走廊的位置上。
当你开始习惯一切可能成为「惯例」的事情时,你就离僵化不远了。
今天和朋友聊天时,突然意识到,我的很多价值观是隐藏在水下的,因此,单开此文,记录我的价值观,此文将会定期更新。
胜率是指你获得胜利的概率(如果你可以定义出胜利);而赔率则是你取的胜利后的获得收益的倍数。比如,买个股是一个胜率低但赔率高的事情;买大盘指数基金是一个胜率高但赔率低的事情。
在很多的决策中,我追求的都是胜率而非赔率:
因为我认为,人这一生很短暂,也没有重来的机会(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 又有何用呢?
我希望我的反思能够启发大家,在产品开发和解决方案提供之间找到合适的平衡点,共同进步。
在上次写完「为什么是产品决策优先级」之后,我也和身边的几个产品同学聊了聊我的推演逻辑,他们给了我不同的输入,让我觉得,这些内容应该分享出来,既帮我厘清了思路,也帮助我看到了不一样的产品。
首先是产品 A 同学, 他的观点很简单:产品经理之所以决策优先级,是因为产品经理为这个产品的最终结果负责。这个逻辑其实是从证明的视角来看的,虽然所有人都为产品结果负责,但运营同学可以通过篇一些其他指标来证明自己的价值 —— 比如运营指标好;研发同学可以通过技术指标来证明自己的价值。唯独产品经理别无选择 —— 他成功与否的评价唯一标准便是 —— 产品自身的成功与否。产品最终承担一个产品背后的所有结果,从权责利对等的视角来看,则应该由产品 —— 这个最终承担后果的人来作出决策。
其次是产品 B 同学,他的观点比较有意思,也给我带来了不同的视角:产品经理之所以需要决策优先级,是因为价值不明确,需要“有判断力”的人来做出价值判断。他给我觉得例子是早期头条研发,早期的头条研发在整个产研链路上是比较有话语权的, 原因是产品的收益相对明确 —— 调整某个策略,能够非常明确的计算和评估出 ROI,导致最终优先级和价值回收变得非常简单粗暴 : 按照策略的预测上能力即可。相比于简单粗暴的广告 / C 端业务,B 端的业务显得收益不那么明确 —— 产品设计出一个功能,商业化团队未必能卖出去;商业化需要的功能,从产品视角来看,未必是适合产品定位的。从产品到商业化的长周期链路,使得对于产品的决策能力要求会更强 —— 需要产品能够从海量的信息中找到什么是最重要的?找到那个必须要做的事情。
这个是个好问题:
我的答案如下:
总结一下:
压力山大的时候,我就会选择去零食箱拿点零食,来消磨自己内心的压力(这也是为啥体重一直居高不下)。取零食多了,我开始有一些有意思的发现:
让我想到一个问题 — 如果我是餐饮同学,我会怎么做?
如果我希望零食被消耗的更快,那我会每次拍照或简单统计一下剩余的零食,然后大概可以知道不同楼层的零食偏好,并在下一次补仓周期里,重点补上那些大家消耗比较快的零食。这样可以让零食大量的被消耗。
如果我希望零食被消耗的更慢,那我会每次拍照并简单统计一下剩余的零食,这样可以大概知道大家不喜欢什么,在补仓周期里就可以进一步的补充大家不喜欢的零食,从而让零食可以被消耗的更慢。
每年我都会给自己开一些新的坑,用于探索新的技术方向、新的领域。2024 年,我的新项目是 —— Read it!
Read it! 是一个用于分享我自己觉得不错的文章、网站的地方, 你可以在这里看到我日常浏览网页过程中发现的不错的网站、文章。
我会在分享链接的过程中,加上一些我自己的看法、总结。
readit.ixiqin.com
,就可以看到我分享的网站。https://readit.ixiqin.com/rss/bookmarks/
贴在你的 RSS 阅读器里,就可以查看到它。我是湾区日报的读者,也很喜欢湾区日报的形式。包括过去也尝试过用 WordPress 之类的系统来搭建类似的形态。但,繁琐的操作会消磨我分享的耐心。
最近又在整理书签,加上也开始进行一些大模型应用的开发,所以决定借助大模型来帮助我自己完成一些工作,就重新搞起了 Read it! 这个项目。
Read it! 目前的工作模式挺简单的,我找到觉得不错的文章,直接在 IM 里发给他,他会自动解析我的意图,并将解析出来的结果录入到系统当中,给大家看。想来这样的交互可以让这个项目活得更久一些~
Read it! 可以理解为是我自己再看的各种文章,所以并不会局限领域、方向,只要是我自己看的觉得有收获的,我都会分享。后续会考虑提供分标签的订阅方式,这样你可以选择只订阅自己喜欢的文章。
值得所有工程师来读一遍。