当公司雇佣了一名顾问之后，无论这名顾问是为了短期项目临时增加的还是因为他是某一技术方面的专家，公司都会期望能够看到该顾问能够带来明显的效益。然而，增加一名顾问并不等于项目的成功就有了保障。当你希望把“临时工”顾问快速的融合到团队中去的时候该怎么去做呢?下面就是有关这个问题的五点建议：

　　明确定义他的角色

　　如果你领导着开发设计人员，并且习惯于自己对项目计划进行说明，那么，你应该学会和你的顾问共同的完成这一工作。即使你的领导角色并没有改变，你也应该向你的团队说明这个顾问对哪些事务负有责任。你要考虑下面的这些内容：

　　谁将会对整个系统的设计负责?

　　你希望你的顾问为此负责，还是只是希望这个顾问为你们的设计编码?

　　由谁来编制测试脚本?

　　由谁来管理控制变革?这其中包括的不仅仅是指定编码编程任务;这应该是实现明确的职权范围，要求所有的人都清楚自己的角色所在。

　　不要忽略上面的这些细节，即使你在以前的工作中曾经使用过这些顾问，也要重新对上面的这些问题进行评估。如果你不理会上面的那些问题，那么在将来的工作中就会产生各种各样的问题来困扰你。

　　在顾问正式开始工作之前要要进行尽可能充分的分析工作

　　你所雇佣的顾问可能拥有编程方面的专门技术，但是他们可能并不十分清楚你的应用软件以及商业操作的具体情况。由于这个原因，有效的把商业逻辑灌输给这些短期顾问就变成了一件相当重要的任务，除非你的公司愿意为这些顾问付出额外的报酬来让他们对此进行研究。甚至还有更糟糕的情况，就是他们有可能会等着你去完成这些工作，可能在这时候这些顾问还没有开始工作呢。我以前曾当过计算机“千年问题”顾问，当我们的客户完成项目计划的决定和指派任务的时候，我对于在这段时间之内只能无所事事感到非常的惊奇。对于顾问们来说，在这段时间之内是可以领到报酬的，但是对于公司的财政来说却不是一件好事。

　　一定要尽早完成这一步骤，这不仅对于整个的开发工作有用，而且还将会提高项目评估的准确性。当你提出一个商业逻辑文件的时候，你就使公司以及顾问都能够远离把问题过分简单化所造成的困扰。举个例子来说，如果你最初的需求只是要“做出销售佣金报告”，那么，顾问可能会给你交出一份只描绘了大致情况的报告。从另外一方面来说，如果你要求含有更多的细节性内容，比如说“依靠销售人员的经验和动态区域微分得出的佣金价格来做出销售佣金报告”，那么，顾问给你提供的报告中就会含有更多的细节性内容，同时也更加的精确。

　　要相信你自己的评估结果

　　即使顾问向你提出了包含有开发时间估算的建议，你的团队仍旧应该自己完成一份估计报告，并且在这两者之间找出不同点。一些因素能够导致不切实际的过低估计出现：这个顾问可能会使用最为乐观的评估方法定出最短的完成时间以取悦你的公司，或者该顾问还会过低估计该商业过程的复杂性。

　　就像在上面的那个步骤中一样，你能够通过完整的文件需求以及商业逻辑来控制第二个因素。你抓住最乐观估计的唯一机会就是完成你自己的评估并且把这个结果和团队一起进行讨论以区别开两种估计的不同点。即使在项目开发的过程中评估需要做出调整，人们还是倾向于记住最先的评估结果，并且使用它来指定最终日期。

　　帮助顾问把建议变为现实

　　在较大型的项目中，顾问们经常会提出经过他们汇总的正式建议。这些文件包括高级项目的计划书、实现方法以及各种相关标准。一旦管理层决定采用它，一定要在项目周期中保留这个文件随时可用并且可以对它进行修正工作。在你团队中的每一个人都应该把它当作一种实际的项目计划文件，并且能够帮助你们完成公司的业务。

　　当所有的人都明白了最终的目的和计划之后，你所面临的就将是避免各种错误对你的项目产生不利影响。如果在建议中包括了项目管理的实践经验、编程标准、或者测试方法，那么最重要的事情就是让该计划真正发挥效力，并且让你公司的付出能有所回报。

　　贯穿整个项目的文件

　　使用顾问的那些项目或者计划总是趋向于往更高方向发展，并且这些项目的具体过程和预算通常都会被仔细的检查。在项目开发的过程中保留一个账目是一种非常明智的做法。这种做法只会占用你短短的几分钟，你在一天的工作都结束的时候就可以利用几分钟的时间来完成它。要记录下来完成的工作、障碍、解决方案、变化、以及团队中的其它一些问题。

　　如果在你的团队中每个人的角色都已经有了定位、并且已经明确了具体的需求，也完成了准确评估的工作。那么接下来的一个文件步骤就能够作为

[1] [2] 下一页