前面讲到的都是团队建设的东西，似乎也不是短期可以把握的（有些理念是根深蒂固的，非经历不能认知，庆幸的是我很早以前认识到了）。尤其是人性方面，不过我觉得己所不欲勿施于人，首先还是得从项目经理做起，谁叫你是带头的呢！能把手下这一帮人搞定，是需要些本事的。 虽然一时还未必能达到，至少能朝着方向努力。

不论如何，项目还是要继续。我们没那么多已经准备好的素质，往往是一个不成熟的项目经理，带着一群尚在成长中的手下，共同为一个目标而努力。怎办呢?绝大多数都是这样的情况，一群还不清楚情况的人，因为一个目的走到了一块，也算是缘分吧！

严格的讲，项目源自需求，不管是外来的还是内生的。需求一旦确定，项目开始筹备了。本来选择成员是很关键的环节，但量化的东西有限 ，比如人员的成本（这是公司比较关注的，或者关注的）、备选人员的技能是否能达到要求（弄个笔试面试什的，一般都喜欢工作经验丰富的，似乎已经成为一个魔咒）。我的建议是，表太在意经验这个问题。你可以事先给备选人员一个模拟假设，看看他能做出怎样的决策和行为。尤其是笔试和面试的时候，不要浪费在一些枯燥的技术问题上（他能找到类似的题库，况且即使不知道查查书或者google一下能解决的问题都不算问题），何必浪费大家宝贵的时间？多考察一些基本素质，例如自我驱动、是否重视沟通、责任感...，远比那些无聊的问题要重要的多。

等人员都齐了，要大家聚一起，先了解一下这个项目了。需求是怎么产生的?产品的规划是什么样的?总之，必须要项目的每个人都知道自己到底做的是个神马玩意儿。有些人总是喜欢藏着掖着，或者不愿意给别人介绍情况，觉得没必要知道那么多（或者更自私的想法都存在）。当然，如果出于公司机密，确实要谨慎也无可厚非，但你觉得如果有意想泄密，还能找不到途径（窃取不到的是文化、理念，和融入这个产品的思想，别人只能模仿无法超越）

虽然我很看重集体的力量，这种力量是伟大的，但任务还得分个先后。需求和设计而言，必须是有这方面的经验者完成。在这个过程中，大家都可参与，比如提出自己的想法、指出可能更合适的逻辑，但主导思想和大的框架要由专门的人负责。这个人可以是项目经理、部门经理、需求分析师、架构师，实际项目中这个人往往都不是专职的。有了这样的一个人把握方向、结构，然后大家可以参与进来，发挥各自的优势和主动性，来充实这个框架细节，这个人替大家把把关、做做指导，即使有问题也能及时修正，至少不会影响整体。这样，既保证了项目的安全性，同时也提高了团队参与性（以后不会有人找借口说：“这又不是我定的需求、我做的设计，我只负责开发或测试”这样的话了:）

需求和设计历来是项目初的、终要的环节，古语有云：差之毫厘，谬以千里。开始出现一点极小的偏差，越往后越难得挽回。因此不管其他任何因素，这两块是决不能马虎，尤其是纵容能力不足的人。怕一些个自我感觉良好的，在IT界摸爬滚打了好几上十年，于是以为无所不能了，更悲哀的是听不进别人的建议或意见。一个人不行并不可怕，可怕的是他还不知道自己不行。因为一个人不行，还有团队在，三个臭屁将定个诸葛亮；自我感觉良好的人，除了葬送这个项目外，更耽误了一群人。（这样的你一定会碰到，尤其在中国，混日子的人太多）。