1、需求变更

需求变更这个问题也是很多ERP软件项目经理比较头疼的一个问题，那么出现需求变更的原因无非就是两种情况一是前期项目在沟通的过程中产品人员或者是项目人员对于需求的理解有偏差。第二种情况就是项目开发过程进入到一半的时候甲方觉得这个功能不符合当前的业务了需要进行变更。

针对上述的两种情况首先来看第一种如何进行规避。首先在国际货代物流软件项目规划阶段的时候要多花费上一些时间来把需求梳理沟通明确最重要的就是所有的研讨会议都要有文档的沉淀，在需求评审或者研讨会议的时候让技术和测试都参与进来，因为信息的传递是有消耗的。举个例子来说：信息从A传给B的时候可能就会丢失或者是消耗掉20%所以说最好的办法就是减少信息传递的节点。有不明确的问题当场解决。在需求沟通明确以后内部在对照着相对的文档（包括但不限于：产品逻辑文档、原型、需求说明书等）进行内部评审，这时候的评审测试是整体的项目成员进行参加，保证本次会议能够把和甲方确定好的逻辑内部成员能够统一的理解。做好了这些基本上就能够保证不会出现在开发过程中出现需求不理解导致变更。

对于出现甲方提出的需求变更这时候要做好对于需求变更的控制，需要空运货代软件项目经理在前期的时候就需要做好准备工作，比如制定好项目的变更流程，本着先明后不争的原则，在项目规划阶段就首先要声明那些问题我们是可以变更的那些问题是需要走变更流程的制定好变更的策略和应对方案，项目的变更原则就遵循着一记录二分析三决策四执行。甲方提出的变更并不可怕，可怕的是项目经理不能够管理好项目的变更。做项目的在一开始就要给甲方制定好一些规则，陆运货代软件项目经理要多去引导对方按照你的思维来进行项目活动的开展。

2、人员问题

无论是做项目还是说一个公司的运行最重要的就是人，人才是立足之本，所以考虑问题的时候也要过多的从人的角度去考虑问题。会计出纳软件项目团队每个公司的情况都不一样不过无非也就两种，一是有固定的项目团队，项目来了以后按照项目的行业或者是项目的情况直接交给一个团队去开发。另一种情况就是按单聚散，有了项目先确定好项目经理，然后人员的问题让项目经理去解决。

先来说第一种情况，直接把项目丢给一个团队去开发，这种情况下项目经理的压力相对来说会小一些都是熟悉的人，做起来事大家都配合的很好一般不会出现什么太大的问题只要做好项目执行过程中的安抚就好了。

着重说下第二种情况，前期的光杆司令，这种是比较头痛的，按单聚散这种情况也比较常见，项目经理回去各个职能部门给职能部门的经理去要人，如果是这个项目是领导比较重视的一个项目还好说，人家能痛快的把人借给你，但是领导如果支持能力较弱的情况下就只能靠项目经理的软技能来沟通了。还有的公司是没有闲置的资源给你去用，那么出现这种情况的时候就需要借助外部的力量。外部的人员要多去筛选面试，还有就是和外部资源方要明确的表明这个项目的工期，中间如果出现了人员更替的解决方案是什么，项目结束了以后人员的退厂问题。外部资源到位以后最起码需要3-5天的时间大家才能够相互熟悉。这也是时间的成本。这种情况下建议是先从一些简单的需求入手。等人员慢慢熟悉以后在去细化需求进行分工。特别要强调一点，外部资源的场景下项目经理一定要展示出来过硬的项目素养，不是说让项目经理有多强硬而是要让团队的成员足够信服你，这样项目才好开展。

3、外部协同问题

外部协同问题涉及到了跨部门和跨公司有时候一个大的项目可能会有好几个承包商来做同一件事，涉及到跨部门最常见的就是沟通可能会出现偏差另一种就是出现了问题会出现你不承认是你的问题我觉得是你的问题这种情况。尤其是除了问题是最难办的。对于外部协同通过的时候出现了问题甚者说影响较大，这时候记住千万要冷静的去处理问题，首先内部进行排错确保内部没有问题以后再去找对方聊。这时候不至于很被动。将所有的证据都拿出来。如果遇到不好界定责任的问题尽可能的将责任降低。

在和外部的部门沟通的时候要讲究一些的技巧。举个例子：有一个新的功能要开发，这时候可以先明确一下本次开会的会议内容提前梳理出会议纪要，如果是你来组织这个会议的话，可能会有很多相关的人都想参加，但是这些人参加了以后又会拖延时间。避免这种问题的办法就是开会之前发会议通知，最后注上，有些领导如果不能够与会，会后将会发送本次会议的会议纪要。这样一些不必要的人就可以给排外了。