浅谈项目管理经验

一、项目目标等同于Leader目标，Leader目标要等同于guys目标 ????????

明明有一个stakeholder作为标准名词...

总结的很好，但是很粗。逐条解读一下：
  一、项目目标等同于Leader目标，Leader目标要等同于guys目标
项目目标究竟是什么没有描述清楚。PMBOK2004对PMBOK2000有一个核心的修正就体现在对项目目标的描述上。
一定要意识到项目干系人的目标有很多是对立的。team leader的目标也绝不等同于guys的目标。如果这样理解是会出大问题的。
  二、项目设计要投入牛级人物，设计完成后留下核心人员即可
项目设计是否需要巨牛的人物，这个视情况而定，其实系统框架的设计要求较高而常常被忽略，而设计实际上比较简单的，只需要明白设计的思想、方法和原则的人一般都可以OK。设计最好和开发有一个比较好的延续。
  三、项目开发阶段要与客户经常沟通、确认每一个功能点
客户的参与对满足客户需求，得到客户认可很重要；但是实际让客户确定每一个功能点是耗费很大的一项工作，一定要充分考虑项目的成本，不是客户满意度最高就表明team leader做的最好的。
  四、客户向来不会提需求，他们的需求只有一句话，管理者不要对此感觉烦恼
哈哈。
  五、团队管理上采用引导方式
团队管理要意识到，管理是基础，指导和领导是发挥。
  六、你的代码不一定能写多少，但是书一定要多看，你应该站在一个广度上，guys应该站在一个深度上
若非足够大的项目，team leader最好不要放弃设计和编码。
  七、对于项目的发展方向以及流程要一定掌握在手里
应该说对于项目的各种发展趋势要掌控和处理，流程不明白楼主具体的意思。
  八、参与数据库设计需留下必要文档，否则后期早已经忘记了自己怎么样设计的了
数据库的设计文档是必须及时更新并且受控的，同时有其他设计，在时间和费用允许的情况最好文档化并受控。
  九、让团队成员有满足感
最好能做到呵呵。

总体来说总结了各个方面的东西，这个精神值得我学习。

客户的需求频繁变更是肯定的，关键是看前期的调研、需求是否充分，不然一旦变更到对已成架构的伤筋动骨，那就惨了
调研、需求挖坑，开发、实施的填坑，所以接手后一定要充分做足功课
和客户沟通是必须的，关键是对客户的需求变更进行引导，最好能把主动权抓在自己手中