大家好，我是上海的一枚前端，是躲过2021年部门大裁员（裁员比例70%）的幸存者。裁员就像突入其来的疫情一样，时间久了，你总要习惯与“被裁”共生。2022年我的工作思维方式就发生了很大的变化，我称之为：面向“被裁”式工作。这一年，我开启了“自卷”以及“外翻”模式，以确保自己在目前团队中保持强有力的竞争力。目前来看，颇有成效。如果你目前也深陷“被裁”的惶恐中，不防看看我是如何“自我救赎”的，希望对你有所启发。
引言：
思来想去，第一篇就讲讲《如何手握核心业务》，我花了6个月的时间握紧了团队的一个核心业务，最近两个月，每月都能稳定参与这个业务迭代2-3次，说实话，手里有项目——不慌。周报、月报、甚至关乎年终奖的年度总结报告都需要黑纸白字的列出来你所参与的项目，做出了什么业务价值，解决了什么问题。
本文结构：
（1）为什么一定要“手握核心业务”？
（2）如何评估什么是“核心业务”？
（3）你能怎么做？
以下是正文：
（1）为什么一定要“手握核心业务”？
这个就要从去年年底的绩效开始说起了。当时的年度总结中，我分别从按时发布/送测率、千行bug率、研发测试工时比等指标出发，来证明我的开发有多保质保量，对业务贡献有多大。最后打绩效的评语里，写的却是我需要“多扩大自己的影响力”。囧...
回想下，有些同学喜欢用研发“大头兵”、研发“小透明”来描述自己的一种工作状态，那么，当时的状态应该属于这种吧。
那么为什么一定要“手握核心业务”，我认为核心原因就是需要要做一个有影响的人。在结构化表达一下，就是：
- 想对业务有话语权，对内耗的需求say no
- 想了解产品设计的底层逻辑
- 想远离CRUD，面向复杂业务开发
- 想晋升，工作中有所创新
- 等等
了解了核心业务之后，你才可以基于现有的产品或者设计逻辑做质疑。你要抓住需求、设计等等评审的机会，最好能提出有深度的“好问题”，或者给别人一些建设性的意见。在核心业务迭代过程中，你将积累丰富的软件设计经验，对各种常见的场景问题提出专门的解决方案。
（2）如何评估什么是“核心业务”
把握公司的战略规划，了解部门的核心业务，多观察，对于那些领导紧盯的业务，那一定是“核心业务”了。
（3）你能怎么做？
如果你目前没有参与到其中的工作中，最直接的方法是，找你的直接领导，要资源，表达你想参与的意愿。
如果没有角色给到你，那么最好就是能积极主动的多参与讨论，多看相关技术资料进行了解。了解的越多，你就有资格参与。
