工作多年，也有一些项目管理经验，在此总结一些自己对于项目管理的看法。
开始阶段
项目启动的时候，个人认为最重要的是要弄清楚项目的目标和项目的范围，包括需求范围和时间范围。
通常，我最怕听到领导说：“把这个工作做一下，需求大概是balabala”，“啥时要？”，“不知道，你先做着，尽快吧。”这种场景经常会出现，由于没有明确的需求和时间约束，有时候就会无法分解工作包，导致无法安排人去做。
这种情况相信在大多数人身上都有发生，这时候只能根据个人的经验从有限的需求说明中推算出大致的需求，还要估算一个合理的时间，因为虽然领导没指定具体的时间，但不意味着无限期的时间，总是得有个大概的范围。
关于项目需求的收集，有时候急于心切想一下子获取全部的需求，但是大多数情况下，这是难以做到的。因此我总是确定一些大的需求方向，通过滚动规划，渐进明细的方针，逐步细化这些需求。使得需求的细节尽量在大方向之内。如果时间允许的话，可以先构造一个原型，通过原型能更好的把握项目的需求以及面临的风险。
关于技术框架架构的选择
通常情况，总是选择成熟好用的框架作为首选。事实上，我工作过的公司，都有自己的一套框架，大多项目都遵循这套框架，这些框架都经受了生产环境的考验，因此所面临的风险是最小的。有时候，会觉得这个框架真土，或者太烂，而花太多的时间在修改框架上，但是这在我看来不是最重要的。框架的目的是把程序员拉到流水线上，提高生产力，越复杂的框架对性能的影响也越大，理论上说，不使用框架的代码性能最好，但是可读性差，不易于管理，因此不得不使用一个良好的框架来组织代码。
举个例子，本人曾经历过的一个项目，觉得是过度设计了框架，有点为设计而设计的味道，框架设计者为了实现解耦，将系统拆分的极度松散，以至于调用某些类库的时候还得依靠反射等方式，而为了完成一个功能业务，常常要在十几个项目中修改许多不同的文件。且不说对系统性能的影响，单单对开发人员的开发体验就很糟糕，疲于在各个工程项中查找要修改的文件。通俗的说，解耦的主要目的之一是实现代码复用，诚然，框架解耦的目的确实达到了，但是又怎样呢？从来没有后期的项目会使用这些解耦的子项目，因为系统业务一旦复杂后，虽然竭尽全力的避免，但是还是会有功能模块相互交织，根本不能独立出来作为一个DLL供给其他项目使用。事实上每到新项目开始的时候，多数情况下还是采用原始的复制代码的方式，而不是直接采用某个dll。解耦的另一个目的是减少系统的关联度，使得修改程序的时候能更简单，这是书上读到的。但是事实上，我觉得跟本不是这么回事，任何更改，如果是简单的代码更改，即使耦合度高的系统，也是很快能改进，而如果出现了较为复杂的业务更改，低耦合度也降低不了改动的规模。当然在此并不是否定解耦不好，只是说明一下，系统设计的时候，要综合考虑，而不是书上说什么就是什么，在我看来，保持KISS原则会让我省心不少。
团队建设
