IT项目管理的一些心得(2)

项目经理的主要工作之一就是将任务分解成工作包，然后分配给个人。本人喜欢的方法是开个会，大家一起商量，评估工作时间，认领任务。个人比较喜欢自下而上的方式，即项目成员各自确定各自的任务和时间后，汇总给我，然如有必要，稍做一下微调。自下而上的方式比较民主，大家也乐意接受。相对而言，自上而下的分配工作，有点“闭门造车”的感觉，不清楚团队成员的情况。关于开发模式，本人也经历过多种方式，比如瀑布模式，迭代式等等，个人觉得比较死板，尤其是当年做日本项目的时候，瀑布式开发使得我写了一堆没有实际价值的文档。 
个人喜欢目前流行的方式——敏捷开发。因为其快速响应，随时应对变化，注重实用性而不是文档，选择敏捷开发模式，最好是在团队成员个个都水平较高的时候采用，如果团队成员一堆应届生，一问三不知，那么怎么也敏捷不起来的。因此，对于这种情况下，我通常会采用结对编程的方式。实践出真知，个人感觉结对编程的效率是非常的高，而且可以互相学习技术，互相了解业务，个人非常推荐这种做法。选择怎样的开发模式和管理方法，就会建设出怎样的团队。

风险和变更范围
通常情况下，在做准备工作的时候，尽量的预估一下风险，风险包括技术上可实现性，人力资源的可用性和项目变更的预判。这点是经常会忽略，技术不是万能，面对有些苛刻的场合不一定能实现，这个风险要尽早的发现，考虑生成一份备选方案，最好做出原型来证明方案的可用性。而项目的变更对于开发者来说是家常便饭，但是最好把变更权控制在自己的手中，领导的旨意常常是不能拒绝的，但是也要以理力争，尽量通过邮件，IM聊天记录等确认变更，因为这可以作为变更证据，而不用通过口头叙述，尽量避免范围蔓延和“项目镀金”，不然到时时间来不及背黑锅的就是你了。

最后，对每一个项目都总结一下经验校训，无论是技术上的和非技术上的，对于以后的项目也是大有裨益的。以上是本人的一些经验分享。