① 根据项目范围和预算确定团队的人数

　　项目初始阶段，项目经理也许只了解到一些有关项目范围、交货期限方面的信息以及客户对一些功能需求的简单描述。为了对项目人力进行估计，有必要进一步细化项目范围。

　　◆ 首先在企业内部争取到一个比较得力的助手，他可能是项目未来的开发经理、系统分析员或高级程序员。这一点很重要，既然你的项目组一定会有其他人的参与，与其到外面去招，不如在内部找你熟悉和信赖的同事加盟。因为你不仅了解他们的能力，而且作为老员工，他们的稳定性也相对有保障，更重要的是，项目一开始你就不再是孤军奋战，至少有一个得力的助手和你一起讨论，分担你的工作压力。经验表明，在有人一起讨论的情况下，工作的积极性、决策的准确度等通常都会提高。

　　◆ 下一步就是和他一起花一些时间与客户沟通，把手头上的项目范围和功能需求描述尽可能再细化一些，包括每个功能需求都有哪些子需求，这些需求是如何配合形成一个业务链的。有哪些系统数据需要维护，有多少张报表要出，哪些需求是要优先完成的，系统需要实现的业务有多复杂，哪些外围系统和当前系统有关系，是否有数据接口和数据转换方面的需求等等。

　　◆ 把细化后的项目范围录入项目管理系统(推荐使用MS Project)，根据客户要求的优先级把项目划分成若干阶段，每个阶段提交一部分功能并预留一些风险准备时间，根据需要加上需求分析、系统设计、编码、测试以及项目管理等方面的活动。

　　◆ 对其中的任务，找实现技术相近的已完成的项目进行对照，估算出每个任务大致需要的man-day数，然后参考以下方法粗略估计出项目需要的人数。

　　人数=man-day总数/(距交货期限的工作日数×工作效率)

　　其中工作效率指的是日有效工作时间与日总工作时间的比值。

　　例如：企业采取8小时工作制，组员可能只有6～7小时真正投入到工作中，有1～2个小时可能会心不在焉，四处走动或处理一些私事，那么工作效率就介于6/8=0.75和7/8=0.875之间，根据经验一般取0.8比较合理。

　　Y提示

　　★ 估算某一任务的man-day数时，最好两个人独立估算，然后再进行比对，差距较大时，听一听对方的考虑，再得出结论。

　　★ 估算某一任务的man-day数时，估算人应该依据目标角色的平均水准而不是他自己的能力标准来进行估算(除非该项任务就是由他本人负责的)。

　　★ 成熟的IT企业一般建有项目资源库，也会提供一些标准的经验统计值，这些都是很好的参考，但还是建议和对照项目的负责人好好聊一聊，取取经，可以获得更加准确的信息。

　　★ 这个估算值是比较粗略的，因为有好些因素还没有考虑进去。

　　例如：组员的休假计划，特别是一些可预期的长假计划，任务之间的制约关系，人员未必是一次性全部到位的。

　　◆ 如果任务超过5个man-day，需要把它进一步拆分成相关的多个子任务，这样每个子任务就可以只分配给一个人完成，并且在一周内就可以得到明确的进度反馈。考虑到任务之间会有一定的制约关系，有些任务必须等到其他任务完成后才可以开始，有些任务必须与其他任务同时开始或同步完成，尽量把这些最基本的约束关系明确下来。很多项目管理软件提供了甘特图功能，可以方便地完成这些事情。

　　◆ 以之前粗略估计的人员数目为基准，根据人员的目标角色和预计的到位情况，尝试逐个增加人数，对甘特图进行调整，直到能较好地匹配交货期限为止。

　　◆ 估计出大致需要的团队人数后，还要统筹考虑项目的预算。国内很少项目经理有用人方面的预算支配权，更多的是老板告诉你，项目组最多不能超过多少人，甚至干脆为你指定了一些人手，在这种情况下，争吵和认命都是不足取的。事实上，对较大的项目，很少有项目经理感到他们得到了足够的人手，项目经理仍然应该做好人员的估算工作，并尽力发掘比较可行的方案。这样当发现人手确实严重不足时，你手头上就已经拥有了一些有说服力的数据，不然你拿什么和老板聊，老板又凭什么要相信你。

　　② 系统分析员岗位以上的人选，优先考虑内部选拔

　　对项目起关键作用的人选，应该优选考虑内部选拔。

　　这样做有几个好处：

　　首先，这些人你都比较熟悉，你了解他们的缺点和长处，长时间的同事关系，使得大家也容易相处和合作。

　　项目初始阶段，这些人的职责和能力都比较重要，有了他们的协助，项目就会有一个良好的开端。

　　这些人都是比较资深的员

[1] [2]  下一页