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

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

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

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

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

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

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

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

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