● 预先行其事，必先利其器。用软件武装团队提高生产效率，例如：版本控制，错误跟踪，信息发布，自动发布，CASE工具，调试工具，测试工具，文档管理，代码生成工具等等。

　　● 分析项目类型，在管理和构建之间找寻平衡。商业系统、使命攸关的系统、性命攸关的系统在整个项目阶段具备不同的控制粒度。需要根据项目的具体类型来确定管理的严谨程度，避免“过度控制”或“控制不足”。

　　● 需求必须被冻结。需求必须被冻结，如果需求不能冻结，那么谁来了都没有用。再强的团队也无法完成一个无尽的任务。

　　● 变更必须走流程。正确应对变更，变更并不可怕，可怕的是失控的变更。以下建议希望对读者有所帮助：

　　在构建期间处理需求变更

　　1、核对需求，评估质量：如果需求不够好，停下来，把它做好再开始。

　　2、确保每一个人都知道需求变更的代价：让客户知道需求办更并不像在Excel上进行几个修改那样容易，“进度”和“成本”是你有力的武器。

　　3、建立一套变更控制程序：固定的变更控制程序让你知道在什么时候处理变更，让客户知道你会处理他们的提议。

　　4、使用能适应变更的开发方法：迭代与增量。

　　5、放弃这个项目：如果以上提议没有一条奏效，需求变更极其频繁，那么，评估你的项目，考虑放弃它吧，继续下去你只会越陷越深。

　　6、注意项目的商业案例：性价比，没必要满足超出项目成本的需求。

　　● 关于加班。做IT的加班是很正常的，但加班要加的有意义，而且不应该长期加班。必须针对关键路径上的工作进行赶工，而不是做些无法加快整体进度的工作。而且，应当安排调休，而不是支付加班费。其主要原因也是我不赞成加班的原因??疲劳更容易引人缺陷。加班无疑会使人疲劳，每个人都想尽快结束手上的工作后回家休息。在长期疲惫的情况下，人员的工作效率会下降，士气会低落，非正常离职率增加，重要的是疲惫的团队很难保证软件的质量，缺陷在不知不觉中引人，在后期无疑会为此付出代价。项目的总成本和周期，都会随着引人缺陷的数量的增加而倍增，而且发现的越晚越严重。

　　● 做好版本控制和配置管理。版本控制和配置管理是必须有的，即便是再小的项目也不能忽视，必须加以重视，一旦版本混乱，多多少少会对构活动造成影响。所以，平时不要偷懒，管理好每个基线。

　　● 授权的好处。授权好处多多，包括：一，减少管理者工作量；二，对人员有意识地进行锻炼，培养储备人才；三，提高人员对项目的参与度，从而提高士气。

　　● 乐观管理与悲观管理。乐观与悲观完全取决于人的性格，一般来讲多数倾向于乐观，应该清楚这两种性格在项目中的优势与劣势。我本人倾向于悲观，可能是性格使然，但悲观的管理至少不会误事。乐观管理的优势在于，很容易营造气氛，擅长给客户或领导描绘一个美好的未来。这种作风，前期很舒服，但后期可能要吃苦了。乐观管理容易出现的问题是对风险的预计不足，不能预留充足的缓冲时间，没有准备足够的预防措施。其表现是，在进行进度计划时，总是认为的问题可以解决，已经修复的BUG将不会再次出现，用户需求是后一次变更，等等诸如此类的乐观想法会使管理者蒙蔽双眼，而没有做足风险应对，其结果是不管怎么加班是赶不上进度，因为进度计划被设计为顺利的情形，而不是现实场景。悲观管理的好处是，为潜在风险做足了准备。但悲观管理有一个非常大的缺陷，是“过度控制”，可以比喻为“疑心病”（小心的都有些病态了）。其表现是为：按照之前的措施，发现遗漏了一个问题，那么悲观管理者会在之前措施基础上增加新的保障措施，然后又发现遗漏了一个问题，之后会继续追加保障措施。乍看之下没啥问题，因为是在不断地进行过程改进，但问题出在保障措施的增长速度过于惊人，称其为“疑心病”一点也不为过，悲观管理者容易在很小的地方施加过多的控制，造成人日的浪费，而忽略掉本应该关注的更为重要的问题。不管那种性格的管理，清楚自己的弱点总是好的。

　　● 有效的沟通，不要踢皮球。软件项目因为其本身的复杂度和涉众众多，所以更加需要沟通。沟通问题是所有大型项目都共用的问题，在大多数团队中往往也不认为沟通是个问题。但我还是想请读者认真对待沟通，比如邮件。邮件可以回复的慢，但请回复邮件。当我在一个连发出的邮件都没人回复的团队中工作时，除了无法解决问题，让我感受到的只有无奈以及冷漠。

　　● 客户是我们的朋友。把你的客户当成朋友，客户是我们做重要的资源之一。在每个客户背后往往隐藏着更多潜在的客户。我们必须清楚，客户作为非专业人士，其可能并不理解我们的工作，在项目执行阶段产生摩擦是难免的。但是，这些都不能成为我们迁怒客户或故意在工作中放水的借口。即便是为了项目能成功收尾，我们也必须维护好与客户的关系。

　　● 不要超前设计，不要项目镀金。超前设计和项目镀金都是不可取的，因为他是在浪费资源。满足需求以外的东西，不会对你的项目有任何好处，但是却可能引人缺陷。

　　● 总结经验教训。必须对阶段进行经验教训总结，没有什么比这些收获更有价值。这样文档是组织的资产，是以后类似项目的参考和依据，并在持续优化方面发挥更为重要的作用。

　　● 不要让会议和文档拖了团队的后腿。“当船快要沉的时候，我们需要的是一个发号施令的，而不是开会。”软件项目的核心问题是降低复杂度，越是复杂的项目越需要沟通，但别让开会拖了我们的后腿。没有必要的会尽量少开或不开，要常开会，开小会，每次会议几个相关干系人碰头沟通下可以了，没有必要扩大为全员参与。冗长的讨论应该适时的终止，毕竟会议室上只能做出决策，而解决问题还得在会下。所以我认为应该精简那些冗长的会议，别然开会成为我们的工作。此外，要时刻谨记客户终需要的是可以良好运行的软件产品而不是华丽的文档。所以，文档要恰到好处，写的再漂亮的文档没有完备的系统也不过是废纸一堆，别丢了西瓜捡芝麻，可以正常工作的软件才是我们的工作重心。

　　● 核对表的你的好助手。像飞机工程师在检查飞机时使用核对表一样，软件项目也可以大量使用核对表。核对表可以帮助检验文档的质量，降低缺陷数量，以及改进项目管理。好的核对表，是你工作中的好助手。

　　● 小范围的受控好过大范围的失控。要注意控制的粒度，事无巨细。根据项目规模，人员构成，要采用不同的控制粒度。评估可控范围，并不是控制越广越好，控制不了是失控。 对无暇顾及的地方授权别人管理是个可行的做法。 即便是小范围是受控，也好过大范围的失控。一个失控的项目，谁也不知道其会走向何方。