01 多参与，多沟通

在去一个新项目之前，我们应该尽可能地预先去了解这个项目的相关事情。但即使我们从侧面已经知道了一些相关内容，这个项目对我们而言还是新的，所以要靠我们主动地去参与，去沟通。

多参与是指除了需要的会议讨论(比如需求讨论，技术确定等)，平时如果组员内部在开一个小会，也可以主动去参与进去;可以不发言，但务需要仔细去听他们怎么讨论的。

可以试着去记录他们的讨论流程，讨论结果和每个人发言方式等等。

有两个益处，从组员的角度来说，新来的项目经理对他们的讨论是关心的，是想参与的，而不是冷冰冰，高高在上的。这样对后续的工作开展是有帮助的，合作会相对比较自然和容易接受。

另外对项目经理来说，组员的工作状态也可以通过这种观察有个初步的了解，那么对分配任务方面也可以有的放矢。

说完了参与，再说说沟通。

其实到了一个新环境，和组员沟通是需要的一项。看到过太多的项目经理，两眼一抹黑，对组员不熟悉的情况下，只是根据每个人的简历去分配任务，结果不多久就要重新调整。有时候简历并不能体现每个人的真实情况和技术能力。

如果是技术出身的项目经理就和组员聊聊技术能力，大致判断一下技术领域和能力水平。

当然更重要的是要问一下组员对哪块业务熟悉，看一下对整体系统的业务熟练度如何，这对以后分配工作很重要。

还有从沟通的过程也可以对组员的性格有个大致的判断，为以后如何相处做个准备也是有必要的。

02 体现专业性

相信很多人比较反感的一种领导方式就是 -- 瞎指挥。

项目经理不是万宝全书，什么都懂，在一个新的地方，在不了解的情况下不要轻易下结论。盲目作出一个指示，很有可能在组员心中产生不信任感，怀疑专业性。所以有时候藏拙也是必要的，专业的事情给专业的人来做，这本身就是一种专业性的体现。

那么接下来有人会问，我对项目管理很清楚，软件生命周期如数家珍，是不是就可以开始把自己原有的知识加入到新项目中了?

不是。搞清楚这个项目原来的管理方式是什么样子的，是瀑布式的，还是敏捷的?当中几个节点是怎么分布和判定的?一般有几个会议是需要的?等等这些问题先搞清楚，既然存在就有合理性。

项目经理一定要结合现有项目的实际出发，根据自身的经验去做完善处理，千万不要一上来就大刀阔斧改革，最终结果往往是双方都无法适应，导致项目失败。

所以项目经理在熟悉和专业的领域，体现专业性会更容易赢得整个团队的信任。

03 有担当

项目经理要敢于承担责任，尤其是和其他项目组打交道的时候。

比如自己项目组出现问题，原因是开发人员一个单纯bug导致的。如果直接把这个开发人员丢出去担责，那么也会让全组士气跌落。

哪怕是自己刚来，这个问题肯定不是自己的原因;但既然已经发生在组内了，作为项目负责人不管怎么样都应该要担起责任。

要让全组人知道，项目经理是他们的依靠，而不会在关键时刻抛弃他们。

除了责任，该争取的权益，项目经理也应该去据理力争。比如明显项目工期安排是不合理，管理层给出的时间完成不了。那么项目经理应该和公司去陈述原因，而不是默默地接下来，然后把压力全部给到组内。导致怨声载道，得不偿失。

项目经理应该扮演好自己的角色，做到内部和外部协调。尤其是新加入的情况下，更能给大家留下一个好印象，方便今后的工作开展。