可能在项目管理中，没有什么比半路接个项目更可怕了。幸好这次还有些底气，是因为自己以前和这个团队合作过，人头还比较熟悉，另外就是在公司也算老员工了，各方面人头比较熟，应该能调动的资源更全面一些。

  如果放在传统项目中，可能进入项目之后的第一件事情就是翻阅文档。可是在敏捷这样的大环境中，这些都是奢侈。唯一留下的就是人。所以第一件事情就是尽快评估分析谁是key person。一般来讲，BA是整个off shore团队的的需求来源，通过与他的沟通可以了解整个release的范围以及目前已经完成的状况。同时也就了解了剩下待完成的内容。结合剩余的时间可以大致评估出来项目目前在进度上的风险等级。因为没有人会希望完不成，到最后是没有人喜欢听借口的，哪怕你真的是半途上来的。领导一句话就可以堵死你，我就是知道情况危急才调你来的，我这是信任你。而一旦发现进度紧张就匆忙的安排加班，那么很快就会失去团队的信任，因为没有人喜欢加班，而且加班根本出不了活。

  广而告之。了解了情况后，我紧接着就是通知全球各个与项目相关的人，第一，从现在开始所有项目有关的信息发到我这，我统一协调；第二，所有off shore的信息，以我发出的为准。这样避免在这样一个阶段，信息丢失，彼此不在一个地区工作，会引起不信任和紧张感。另外就是明确责任，也保证从这个时间点开始的项目上的一切情况尽在掌握，这是以后谈判协调决策的基础。

  士气。意外的人员变动通常会引起大家的猜测和不解。士气会随之降低。所以建立彼此的信任很重要。口说无凭，需要用行动证明，所以即使在如此紧张的进度要求下，我还是连续两个下午开会，让大家尽情的吐槽。我发现大家的很多好想法都是有去无回，久而久之就会失去斗志，把项目中的smelly code视而不见。另外就是彼此之间缺乏沟通，缺乏信任。到处充满了，这个事情是你，那个事情是我的。明确了问题，那解决起来就简单。我跟大家亮明态度。所有问题只要反映出来，必定会有反馈。受决策的流程，资源等因素影响，我不能保证 问题都可以立刻解决，但是我们即使当下解决不了的也一定要安排出时间表加以解决。而我也确实安排人员将大家期望已久但是却没有勇气动的代码改了一圈又一圈。

  嫡系。另外一个团队是我带了三年多的团队，算是嫡系。我这次也将里面的人全部抽出来一起做半路接手的产品，因为他们以前做过拥有足够的经验，而且对我绝对服从，了解我做事的要求，习惯。我把他们带过来之后，另一个产品就是我一个人在撑着了，虽然辛苦，但是我觉得我的做法很正确。第一，毕竟这个团队也运作了两年多，已经形成了一些自己的习惯，这些习惯有的时候很难通过嘴上说说就改掉的。而我带过来的团队，可以起到表率作用，我希望他们可以用高标准的要求来感染其他人。另外就是代码重构这样的活，毕竟是比较苦的体力活为主，让熟悉的人去做毕竟少了很多口舌，大家已经熟到不需要多说什么了，他们也很理解我现在需要得到的支持。还有更重要的就是我接下来会打破团队界限，加强人员流通，形成统一的团队文化。

  很多时候真的是将熊熊一窝，当你看到一个很好的团队没有完全发挥，整天屈辱的在干活的时候，你就会心痛。今天，当你 有机会去改变这一现状的时候，一定要勇敢的站出来作你应该做的事情。

  相信自己，更要相信你所在的团队。