为什么要写这篇文章呢，因为我意识到这次面对的恐怕是至今从来没遇到过的巨大挑战。

哪怕是放在整个行业的职场上，我认为这样的事也算罕见。

所以，这样的压力其实除了我自己，着实不容易有人能理解了。

也许未来某一天，当我回过头来看自己此时正经受的考验，一定会为我当初敢于接受它的勇气而感到自豪。

1.几乎不可能发生的工作交接

任何一个项目在发生交接行为的时候，它一定是伴随着多个老员工对应一个或多个新员工，并且前者会远大于后者，除非这个项目真的不需要维护了。

而真的不需要维护的定义是现有项目几乎没有线上问题且几乎没有新的需求。

显然我目前接手的这个项目，两者都有，并且每天都有线上问题需要支持，还有十分紧急的新需求要做。因为其产品的现有客户群十分庞大，几百这个数量级，且还有新的客户待签单。

然后，我是那个唯一的接手人，原团队7个成员差不多都离职了，也就是说交接人与被交接人比值是7:1。

最后，要知道这个项目已经由7个人做了至少两年了。

无论如何这种情况的交接都很难发生在一个还算被市场很认可的产品（项目）上——原团队直接解散，交接给一个人，而这个人之前并未有过相关负责整个项目的经验。

我的技术水平和资历都跟原团队leader差的不是一点半点。

难道是公司草率吗？

2.绝对小众的技术栈

在如今java技术栈几乎一统天下的时代，该产品所采用的技术栈可以说是绝对小众了。先不考虑前架构师所描绘的其架构设计和技术选型的合理性，这个产品用的技术确实不是现在主流的技术栈风格，这意味着采用小众技术做的项目很不好从市场上招到对口的人才，反过来说，只掌握这个项目的技术栈其实也不是特别能迎合市场。

学习小众的技术是有一定风险的。

再者，小众，对于我而言，我现有的技术栈更是与这个项目用到的技术没啥交集。一个技术小众就算了，它竟然还用了七八个，自然也都是我之前没接触过的，这一下就能看出来我的学习量了。

然后，小众的技术自然也意味着网上的资料也会相对少，这也给我的学习增加了难度。

最后，很重要的一点，由于我一个人接手，所以这意味着我要迅速补足一个团队技术leader的技能，至少是部分技能，而这个在我之前的工作中，是非常欠缺的，这个角色转变所带来的技术要求是我要重点关注的。

3.几乎空白的业务了解

技术上，已经如此大的挑战了，但在业务上，我所面临的恐怕与前者相当。

这是因为我个人而言，之前并没有接触过这个产品，也没有过类似项目的经历。而一个由七个成员做了两年的项目，可想而知它的业务量又多大。

我要从零开始，去了解它的业务，这个时间花费是无法预估的。

很有可能，将来有一天当出现一些客户现场问题时，我只能一行一行地去读代码！

4.极度考验能力的运维工作

如果说前面几个情况已经足够让我力不从心了，那么由于这个产品的特殊性（本身就是用来作运维的）所带来的运维工作将会是另外一种绝对让人压力陡升的事——这里的运维不只是一般意义上的运维，是泛指一切客户现场问题的处理。

要知道，哪怕是之前的leader在遇到很多运维问题时，也不见得很快能定位出原因。

很不巧，运维需要的知识和经验都是我极度欠缺的。

所以，我好几天前就开始了每天看书学习相关运维知识。我知道，跟普通开发工作不一样，处理现场问题要求我响应得非常快，运维知识储备都只是基本的，还需要丰富的实际处理经验！

刚刚说了，运维工作其实泛指现场问题的处理，除了纯粹运维类问题之外的那些现场问题，需要的则是我对这整个产品的技术和业务都要有整体且细致的了解！

——而这又不得不回到了前面那三个大的挑战。

矛盾就在于我不可能短时间内完成那三个挑战，但客户现场问题可是天天都有可能发生的。

我正面临怎样的压力呢？

大概就是，

我几乎每天上班都不知道怎样给自己安排工作才最恰当，是了解业务还是学习技术？了解业务应该有怎样的优先级？了解到什么程度？怎样的方式更有效率？学技术的话，重点要放在哪里？怎样能快速上手？暂时要忽略哪些细节？

我还没法制定出一个完整而合理的学习路线，因为要学的知识太多，很多都不简单，需要一定时间，有的可能更紧迫，要先学更好，也不能一个个技术挨着学，我也没那个时间，那要怎样制定细致具体的学习计划呢？

完全不知道下一秒钟会遇到怎样的客户现场问题，遇到问题，我该怎样快速定位？怎样快速找到相关日志或代码？如果遇到阻碍，我应该怎样应急处理？或是怎样寻求帮助？

。。。

而很可能，这样的阶段会持续很长时间，至少

硬着头皮罢，谁要我当初做了选择呢！