本年度比较折腾，整体而言可以分为两个大的阶段，简单而言，转岗前和转岗后。
个人收获
据说程序员有几大浪漫，比如操作系统、编译器、浏览器、游戏引擎等。
之前参与过游戏引擎，现在有机会参与存储业务交付，职业生涯的经历，距离完美又近了一步。
个人总结
本年度主打关键字，折腾、憋屈。
有时在园区遇到前部门的同事，还以为我现在过的很悠闲，其实转岗前、转岗后没有太多的变化。
平心而论，转岗到新产品之后，领导还是给了不少机会和辅导，奈何自己的心态、经历、工作方法、周边配合等因素，没有掌握好，所以没有获得认可。
领导转发的周边调查意见，说我躺平，当时把我气够呛。
唉，上有老、下有小，哪里敢躺平。
给自己打气，要争取逆风翻盘，虽然机会渺茫，但既然还在岗，就要打好这份工，唱好这台戏。
经常想起如下的段子。
给你机会，你不中用啊。
原来的老同事A和B，发展路径不同，最终结果不同。
A是金牌个人，领导安排升19级。
B和我一样，被领导安排扛指标，已沟通在24年中的时候离开。
转岗前
2月23日晚上沟通绩效，看项目经理一脸难受的样子，进会议室前就预知结果肯定好不了，毕竟春节放假前也暗示了几次，我有心理准备。但没想到绩效结果为C，这就突破我的底线了。
项目经理解释了原因：
- 业务上的原因，比如项目不成功，业务发展始终看不到效果，不是领导重点关注的业务，无法达成上层领导的预期效果。
- 近期外部环境不好，导致离职人数不足，没有人来扛指标。细想下来，当前的项目组在一年之内，少了5个人。
- 近期领导在努力下，安排了续约，因此部门领导认为我来扛指标相对会好一些。
- 合作团队的人员变动也很大，离职加换岗，很多同事选择了离开。
业务不成功，其实很伤团队和个人的积极性。
项目经理担心的场面没有出现，我还是很平和的完成了沟通，没有发脾气。
每临大事有静气。遇到问题要冷静，切忌不可冲动。这个时间发脾气并没有意义，毕竟都混到高职级了，时间和精力要留着做有价值的事情，比如想对策。
和项目经理沟通完毕之后，我直接给之前的PL打了一个电话，简单聊了一下境遇，然后直接启动了调动。
部门领导第一时间得知，然后电话中批了项目经理一顿。项目经理得知我发起了调动，他也发起了调动。后来我才得知，项目组同事中有一个是他的小弟，和他一同发起了调动。
部门领导当然不期望项目组有这么大的变动，安排了几批人来劝，酒喝了两顿，中间有段时间，一度动摇。
但是开弓没有回头箭，现在的情况是已经扛了指标，意味着在公司的职业生涯已经进入倒计时，不管在哪边都会是扛指标的命，不如放手一搏，到新的产品尝试一下得了，给自己的职业生涯增加一些体验。
于是静下心来站好最后一班岗。
- 准备交接材料。
- 补丁回合开源社区。
- 申请社区的Reviewer角色。
整理交接材料和工作笔记时才发现一个问题，事不成，人不爽，还没有积累。
可怜我加了那么多的班。
转岗后
4月10日点击了交接申请，由于从发起至今已超出30天，所以直接切换SAP。
奋战了几年的部门变成了前部门，见证了前部门同事之间的塑料友情。
人际关系六度理论，听起来不靠谱，但亲身经历验证了理论的正确性。
转岗后，在新部门遇到的版本SE、产品SE，细数起来或多或少都有点渊源。
本来我以为转岗到的新部门没有熟人，后来发现产品的QA、DE，居然有几个之前曾经合作过，其中一个还是入职时部门的老同事，其余人是网友。
4月
学习业务知识。
5月
领导安排，作为FO，即Feature Owner，参与版本交付工作。
- 组织方案评审工作。
- 评估工作量和交付计划。
6月
丈母娘离世，回去参加葬礼。项目交付工作继续。
- 交付范围最终定稿。
- 刷新项目交付计划。
- 方案初步定稿。
- 刷新工作量和人力诉求。
- 输出质量策划。
7月
各团队人力到位，开发工作终于启动。领导临时安排，要求在转测试前，对一线团队做一次showcase。另外由于前期对需求和方案的理解出现偏差，导致我所在团队的人力出现缺口，不得已已，只好由我自己顶上。
- 基本功能第一轮转测试。
- 组织特性的showcase，面向一线团队。
- 组织基本功能联调和自验证。
8月
按照计划，月初第1周要转测试但并不顺利。
- 各团队的代码上主干。
- 各个代码仓库反复出现冲突，挤占了联调的时间。
- 代码上库过程中出现了遗漏，由于上库周期和节奏不匹配，同样浪费了不少时间。
- 联调。
- 环境不足，没有协调到足够的机器。各子特性出现了环境争用的现象。
- 等环境准备好了，出现了安装失败的现象。只好采用换包的方式来准备联调环境。
- 待上述阻塞问题修复之后，原本规划的联调时间已不足，但转测试时间已到，只好先转测试。
- 功能验证。真正的噩梦此时才开始。
- 基本功能不可用。
- 基本业务流程未打通。
- 团队成员都是新手，不熟悉测试用例，不熟悉测试工具，不熟悉操作方法。
9月
由于进度延迟，作为FO，天天被领导批评。这个月同样很憋屈，终于忍不住和领导吵了一架。于是工作内容做了大幅调整，只处理技术类的问题，不再跟踪交付进度，这就省事多了。
- 支撑问题定位。
- 修改问题单。
- 梳理业务特性。
- 组织代码评审。
- 一线支撑，澄清业务、技术类的问题。
10月
日常交付状态，有问题单就定位、修改问题，有一线求助就响应一线求助。
11月
本来以为当前的版本就这样结束了，手上也没有什么事情，于是和领导申请参与新版本的设计工作。
结果刚认领任务，在研版本的问题和一线的问题铺天盖地的堆过来，打了我一个措手不及。
刚认领的设计工作，也是一个坑。评方案的架构师和版本SE忙的要死，完全没有时间澄清需求和方案的问题，导致输出文档的进展非常不顺利。
这个月也很惨，被版本层面投诉，部门领导也不满意。
本月整理交付文档：
- 方案讨论的纪要。
- 接口清单。
- 错误码清单。
- 业务分析材料。
12月
在研版本终于进入尾声，投入很小了。
终于可以专心参与新版本的设计工作。
- 完成需求拆解工作。
- 组织各团队分析各项任务的交付方案，评估工作量。
- 输出设计文档。
- 申请在线评审，处理评审意见。
- 整理需求方案的材料。
- 整理竞品分析的材料。