做了四年项目了，单枪匹马的干过，团队合作的也干过；政府项目做过，商业项目也做过；Web的项目过，Windows的项目也做过；给钱的项目做过，没钱的项目也没少做。那么，项目管理究竟是什么？或者说包括哪些？
先从目标来看，项目管理的目标可是说是将项目需求种的所有要求都完成。这是最基本的目标，不过如果仅仅是着眼于这个目标，那么项目经理和工头又有什么差别？而且实践证明，如果这样来管理项目，那么十有八九项目最终是要失败的。原因？软件项目从来不像想象的简单，一板一眼的按流程完成合同中规定的要求就可以交付项目的情况，通常是可遇而不可求的。所以不能把项目管理的目标仅仅放在实现合同规定的项目需求上。
敏捷方法论提出的观点是，要为客户创造价值，以提高客户的竞争力为出发点，这比仅仅完成合同更进了一步。客户是整个软件项目的发起者，从这一个角度来讲，甚至可以认为客户所说得一切都是对的！时刻牢记这一点，通常能够是项目的进行保持在一个更接近正确路线的状态。客户需要什么？客户遇到这个问题会怎么办？客户觉得这个功能重不重要？客户在这个功能点上会不会提出变化？常常问问自己这些问题，通常能够保证项目不会做成想当然的样子。如果自己回答不了这个问题，那么赶快拿起身边的电话吧（当然不是让你订购什么）。理想的情况当然是客户就坐在你的身边，这也是敏捷地观点：把客户作为团队的成员。
说到这儿肯定会有人跳出来说：什么都是客户说了算，那项目永远不要想交付了，因为客户总会有新的想法，那公司还搞个P呀？
我觉得很多人在作项目的时候喜欢和客户对立起来，原因也很容易理解，辛辛苦苦写出来的东西被客户一句：我需要的东西不是这样的，就推翻了。然后需求全变了，以前做得都没有用了，工期又进在眼前，老板在催，开始加班，带着一股怨念，拖着疲惫的身心，之能写出垃圾代码。于是，项目失败也就不远了。回过头来看，似乎噩梦似乎是从客户变更需求开始的。需求变更变成了程序员挥之不去的梦魇。如果客户能够一开始就给出一个明确的需求，世界该是多么美好。
其实，这仅仅、仅仅是个态度问题，我是认真地，这真得仅仅、仅仅是一个态度问题。假如你早已经知道知道需求会变化，知道你做得东西会被用户否掉，甚至在用户说“我需要的东西不是这样的”的时候，你会想：早知道你丫的会这么说！那么这个项目你会怎么样去做呢？
从另一个角度来说，项目的需求从来就没有变过，客户的想法也非常的明确，只是或许你从来没有考虑过。商业用户的需求基本上都一样：通过引入先进的软件，提高效率，降低成本，赚取更多利润。只要你能为他实现这一点，那么你怎么做，他不关心，Ajax或者Flex对他来说毫无意义，甚至只要最终的收益比投入成本高，比原计划花更多的钱和等更长的时间，他也乐意──当然，让他相信你。
当然，不同的客户的需求不一样，但有一定可以肯定，客户做这个项目的目的不是为了否定你的努力，更不是折腾你玩。所以，我们需要从新，认真地考虑项目的目标，考虑客户在项目中的地位，像揣摩领导心思一样虔诚的去做需求分析。
