工作多年，也有一些项目管理经验，在此总结一些自己对于项目管理的看法。
　　开始阶段
　　项目启动的时候，个人认为重要的是要弄清楚项目的目标和项目的范围，包括需求范围和时间范围。
　　通常，我怕听到领导说：“把这个工作做一下，需求大概是balabala”，“啥时要？”，“不知道，你先做着，尽快吧。”这种场景经常会出现，由于没有明确的需求和时间约束，有时候会无法分解工作包，导致无法安排人去做。
　　这种情况相信在大多数人身上都有发生，这时候只能根据个人的经验从有限的需求说明中推算出大致的需求，还要估算一个合理的时间，因为虽然领导没指定具体的时间，但不意味着无限期的时间，总是得有个大概的范围。
　　关于项目需求的收集，有时候急于心切想一下子获取全部的需求，但是大多数情况下，这是难以做到的。因此我总是确定一些大的需求方向，通过滚动规划，渐进明细的方针，逐步细化这些需求。使得需求的细节尽量在大方向之内。如果时间允许的话，可以先构造一个原型，通过原型能更好的把握项目的需求以及面临的风险。
　　关于技术框架架构的选择
　　通常情况，总是选择成熟好用的框架作为。事实上，我工作过的公司，都有自己的一套框架，大多项目都遵循这套框架，这些框架都经受了生产环境的考验，因此所面临的风险是小的。有时候，会觉得这个框架真土，或者太烂，而花太多的时间在修改框架上，但是这在我看来不是重要的。框架的目的是把程序员拉到流水线上，提高生产力，越复杂的框架对性能的影响也越大，理论上说，不使用框架的代码性能好，但是可读性差，不易于管理，因此不得不使用一个良好的框架来组织代码。
　　举个例子，本人曾经历过的一个项目，觉得是过度设计了框架，有点为设计而设计的味道，框架设计者为了实现解耦，将系统拆分的极度松散，以至于调用某些类库的时候还得依靠反射等方式，而为了完成一个功能业务，常常要在十几个项目中修改许多不同的文件。且不说对系统性能的影响，单单对开发人员的开发体验很糟糕，疲于在各个工程项中查找要修改的文件。通俗的说，解耦的主要目的之一是实现代码复用，诚然，框架解耦的目的确实达到了，但是又怎样呢？从来没有后期的项目会使用这些解耦的子项目，因为系统业务一旦复杂后，虽然竭尽全力的避免，但是还是会有功能模块相互交织，根本不能独立出来作为一个DLL供给其他项目使用。事实上每到新项目开始的时候，多数情况下还是采用原始的复制代码的方式，而不是直接采用某个dll。解耦的另一个目的是减少系统的关联度，使得修改程序的时候能更简单，这是书上读到的。但是事实上，我觉得跟本不是这么回事，任何更改，如果是简单的代码更改，即使耦合度高的系统，也是很快能改进，而如果出现了较为复杂的业务更改，低耦合度也降低不了改动的规模。当然在此并不是否定解耦不好，只是说明一下，系统设计的时候，要综合考虑，而不是书上说什么是什么，在我看来，保持KISS原则会让我省心不少。
　　团队建设
　　项目经理的主要工作之一是将任务分解成工作包，然后分配给个人。本人喜欢的方法是开个会，大家一起商量，评估工作时间，认领任务。个人比较喜欢自下而上的方式，即项目成员各自确定各自的任务和时间后，汇总给我，然如有必要，稍做一下微调。自下而上的方式比较民主，大家也乐意接受。相对而言，自上而下的分配工作，有点“闭门造车”的感觉，不清楚团队成员的情况。关于开发模式，本人也经历过多种方式，比如瀑布模式，迭代式等等，个人觉得比较死板，尤其是当年做日本项目的时候，瀑布式开发使得我写了一堆没有实际价值的文档。
　　个人喜欢目前流行的方式——敏捷开发。因为其快速响应，随时应对变化，注重实用性而不是文档，选择敏捷开发模式，好是在团队成员个个都水平较高的时候采用，如果团队成员一堆应届生，一问三不知，那么怎么也敏捷不起来的。因此，对于这种情况下，我通常会采用结对编程的方式。实践出真知，个人感觉结对编程的效率是非常的高，而且可以互相学习技术，互相了解业务，个人非常推荐这种做法。选择怎样的开发模式和管理方法，会建设出怎样的团队。
　　风险和变更范围
　　通常情况下，在做准备工作的时候，尽量的预估一下风险，风险包括技术上可实现性，人力资源的可用性和项目变更的预判。这点是经常会忽略，技术不是，面对有些苛刻的场合不一定能实现，这个风险要尽早的发现，考虑生成一份备选方案，好做出原型来证明方案的可用性。而项目的变更对于开发者来说是家常便饭，但是好把变更权控制在自己的手中，领导的旨意常常是不能拒绝的，但是也要以理力争，尽量通过邮件，IM聊天记录等确认变更，因为这可以作为变更证据，而不用通过口头叙述，尽量避免范围蔓延和“项目镀金”，不然到时时间来不及背黑锅的是你了。
　　后，对每一个项目都总结一下经验校训，无论是技术上的和非技术上的，对于以后的项目也是大有裨益的。以上是本人的一些经验分享。