3.团队缺乏的不只是管理
团队的一些基本特性：主从、监督和责任。
做管理起码需要能承担责任，这是最基本的素质。
从管理角度来看，项目失败与否与项目经理的经验直接相关。
项目的成功是两个方面的评估：项目完成质量和项目完成时间。
项目经理是需要时间来成熟的。他需要有机会来承受错误，而不是一开始就享受成功。
皮之不存，毛将焉附。没有确定的组织机构，又如何能指望做出来的管理制度“合用”呢？
经常的情况下，动摇了制度的人不是犯错的员
工，而是管理者自己。如果在制度面前，既做得到“人性化”又做得到“公平性”，那么当管理者的便可以多做一段时间。
中小型规模的公司和团队的参考组织机构模型
如果有一群开发人员象蚂蚁一样辛勒地工作着，那么，先不要打扰他们。你应该跟随他们，看看他们是如何做的。发现规律，分析这个规律的价值，最后再尝试改变它们( 的一些负面价值的规律) 。 所以你要紧紧地跟随他们但是不能去蚂蚁洞。
作为项目经理，你需要先分工。被优先考虑的是弹性分工。确定被“弹性分工”的员工需要可以快速地转换到新的角色，但首要考察的并不是他是否“有能力”胜任这个角色。能力可以通过学习来增强，而角色的转换，则首先是思想的转换。更好的选择是明确分工。做管理≠做伯乐。
4.流于形式的沟通
深入项目的需求阶段的项目经理或者调研人员，被
要求深谙项目所涉的业务。但这往往我们所做不到的，因
为我们是软件公司，而不是做这些( 客户的) 业务的公司。
这时惯常的做法是聘请行业咨询公司( 或者个人) 来介入
需求阶段，协助了解和分析需求。
“最简沟通”客户在公司层面的外在表现、内部机制和运营管理手段。 客户在项目中既已明确的需求和可能发生的需求，以及客户围绕其公司行为( 和方向) 所提出的需求。
为不存在的角色留下沟通的渠道，这个渠道丰富和准确为项目的后继开发、维护提供了可能。
需求阶段：与谁联系，联系方式、过程、结果以及由此引发的需求或变更；
设计阶段：如何进行设计、最初的构架、各个阶段的框架变化、因需求变更导致项目结构上的变化有助于了解构架的可扩充性) ；
开发阶段：每一种技术选型的过程、每一种开发技巧的细节和相关文档、摘引的每一段代码、算法、开发包、组件库的出处和评测；程序单元的测试框架；每一个设计和构架变更所导致的影响；
测试阶段：测试用例和测试报告。
流于形式的沟通，可能是使得你的项目被不断推翻和不断延迟的最直接原因。
5.失败的过程也是过程
做过程不是做工程 。
瀑布模型将软件开发的过程分成需求、分析、设计、开发和测试等5 个主要阶段。
项目走过场是一件危险的事，直接毁灭项目。
实现，才是目的 。工程只是一种实现的途径。工程被当成了借口，掩盖了我们做事的真正目的：“实现”。这样的结果是：我们做完了工程( 的每一个过程) ，却没有完成项目( 的每一个“实现目标”) 。
只看到了事物的表面，而忽略了实质的东西。我们则应该去思考由瀑布模型到V 模型这种变化的真实意图。
越是简单的东西，往往越是接近于本质。过程理论中，如果懂得了所谓的模型原本都演化自那个简单的瀑布，那么文档是按XP 写还是按RUP写，也就可以应时、应需，因地置宜，择善而从了。
不是“做”工程，而是要“组织”工程。项目经理的工作，就是要去组织这个工程中的各个角色，使得分工明确，步调一致，共同地完成这个项目。