其次，这个项目我不是那么熟悉，如何在短时间获得最多的项目资料？需要借助工作平台，第一时间阅读项目相关资料，对项目有个大概的了解。然后召开一个正式的项目组内部会议介绍项目组人员、项目背景、进度等，还需要包括一期项目中遇到的问题以及获得了哪些成就。正式的会议可以保证信息的正确性，同时会议可以了解到文档所没有包含的信息。跟一期的项目经理和技术经理多做交流，在交流的过程中挖掘项目中存在的问题根源，分析项目中做得好的点以及可以改进的地方。
再者，这个产品我不是那么熟悉，如何在短时间内掌握这个产品？也许有人会说项目经理不需要对产品很了解，只要有好的项目管理技能就可以了。我不大认同这个观点，一个好的项目经理需要对所处的行业以及产品有一定自己的商业看法，这在需求分析以及项目范围控制上可以起到很大的辅助功效。也有助于在发生需求变更时，能有自己独立的分析看法帮助做出决策。快速学习的方法有很多，我喜欢自己亲自去体验一番，然后自己画出这个产品的模型图，再拿着这个模型图跟项目成员画的模型图去对比。这过程中会有很多不理解的概念，或者是不清楚某个功能的价值点，这就需要以空杯的心态，多请教PD。对商业的看法无对错之分，只有赞同和不赞同。
最后，这个产品的设计我不是那么熟悉，怎么更快速的了解设计思路？这就要求项目经理有一定的技术背景，先通过项目的设计文档获得一个大致的了解，再请教项目中的技术经理或者主要开发成员。在这过过程中，姿态很重要，不要因为怕暴露自己的无知而影响在项目成员中的威信，态度决定一切，只要是真心实意，并且是认真学习，我相信会获得大家的尊重和好感的，因为大家感觉到了你在努力，你跟他们站在同一战线上。了解了设计思路，再结合对产品的了解，可以更清晰的知道需求功能点之间的依赖性，便于功能点的拆分以及任务的分配。同时还可以帮助项目经理对每个功能点的工作量评估有个大致的把握，当然在工作量评估上应该信任项目组成员，但这可以帮助项目经理理清项目风险，在有突发情况下，能最大弹性的以不变应万变。
-----------------------------------------------------------------------------------------------------------------
半路接手项目的情况其实在实际工作中是很常见的，个人感觉要做以下几点，项目成功的概率会大大增加：
1、尽快了解项目目标、项目进展情况、相关干系人对项目的影响等详细信息；2、跟项目团队做好沟通的前提下，尽快融入项目团队。无论从私交还是上级借力，都要让项目团队成员更有效的听你指挥；
3、在项目执行的过程中把控项目变更和识别变更带来的风险，并有效告知相关干系人变更带来的问题和影响，由客户和上级签字或邮件确认影响是可接受的情况下，再执行变更；
4、跟上级领导要保持紧密的沟通，让上级领导时刻了解性的真实情况。不要有问题憋着，怕领导批评，一切以项目成功为目标。这样，上级领导会对项目有参与感，就会主动或者愿意帮阻你解决项目中遇到的问题，在关键时刻给与你足够的支持。
5、跟客户也要保持紧密的沟通，不断了解客户的真实意图或需求。让客户在姓名进展的过程中了解项目情况，产品是否是客户所需，大的功能改动可以跟客户沟通等下一个版本再添加。很多情况都是客户在使用产品的过程中会有真实的改进需求，在项目的进行中只有天马行空，合理控制客户的需求特别重要。
6、如何把客户的不满意变成满意也是一种艺术。
-----------------------------------------------------------------------------------------------------------------
接手前的准备
接手前，先要了解一下这个项目目前的状况，可以咨询主管这个项目的领导，当然如果这个领导忽悠你，跟你说这个项目是标杆，或者说这个项目怎么怎么的好，那么你就要多思考一下是不是一个坑了。
这个时候你就需要领导提供项目的 bug 修改单或者是需求变更单，这样大致能客观的展现出项目存在的问题。
如果 bug 单里修改的东西很多，或者需求变更频繁，那么就不建议再接手这个项目了，不然最后难受的是自己，你把烂尾项目处理好了，是应该的，处理不好就是你能力差，其他同事也是站着说话不腰疼的去挤兑你。
如果项目的 bug 单和需求变更单不是很频繁，这个项目还是可以接手的。
接手后的第一件事情
立即着手使用项目，把项目的流程先跑通，然后了解项目的设计目的，因为这些内容就好比是一个灯塔，能在大方向上给你指明道路，并帮你将代码片段串联起来，把一个功能点的代码从数据层，service 层，到 controller 层理出来。
做到能快速定位相关位置，还有每一层之间与项目相关的配置文件的熟悉，例如有定时任务配置文件，加解密配置文件等，从而形成一个整体。
我们要记住越是复杂的项目，其目的和设计占的比重越是重要。
把项目拆解，编写自己的项目文档
项目难，往往是因为不了解，看着一大堆东西，心理上首先就有压力。一定要顶着压力往前走，把项目分模块的去了解，通过代码去理解业务。
一个系统一定有使用频繁的模块和非使用非频繁模块，这个可以通过给客户的使用手册来了解。
如果项目缺失具体的设计说明书，那么就需要看相关功能代码是怎么写的，通过了解代码和使用项目来了解业务流程。
同时要学会编写文档，主要是让自己好理解这个项目。因为你接手了这个项目，就意味着项目再出什么情况都由你自己承担。
哪怕出现的问题是由于项目设计，或者开发期产生的，也得由你承担。因为编写文字不像说话，耗费的时间会多一些，在打字的过程中，我们会花费心思去组织语言和思考，这会让我们发现更多项目上的问题。
进入维护状态
当我们了解了项目的业务和相关的代码，就算正式接手了项目，可以开始处理项目中的实际问题。
同时我们要养成每天下班把生产日志拿来看一下，看看项目中是否存在潜在的问题，比如内存开销过大，死锁等问题。
看日志主要看 error 日志，确定所呈现的 bug 是紧急还是非紧急的。紧急的，立即就要着手去修复。同时要写邮件抄送给相关领导。(不然你把问题处理好了，领导也认为你没有工作量)
查看服务器的 CPU，内存等开销。这个不必天天进行。
写一些 SQL 脚本，来检测数据库表里是否出现了数据重复，垃圾数据。主要防范出现 SQL 注入等问题。
写在最后
唯有经历过以上所有步骤，我们才能成为一个专业的项目接盘侠，然后开心快乐的成长，对于之前负责项目里给你留的坑也好，bug 也罢，我们当然选择原谅他!