项目管理的的文章和书籍到处都是，我也不敢在这班门弄斧。所以以下的文字主要关注从没有管理到开始对项目进行一些管理这个过程，通常没有进行管理或者很少进行管理的项目也不会特别大，所以本文并不一定适合大型项目。本文也不完全符合某一流程或者标准，其中一些只是我个人的一些浅见，如果能抛砖引玉，那就再好不过了;如果哪里说的不对，肯定各位筒子们尽管拍砖。

　　作为项目组的成员之一，不论你是开发工程师，测试工程师还是数据库工程师，你都对项目管理负有责任。在工作中，工程师应该精通自己的部分，优秀的工程师还应该熟悉别人的部分，实际情况中的工程师通常还需要在必要的时候(有人离开)顶上去做任何一个部分，此时，对项目的整体的把握至关重要。在参与到管理的过程中，也会提高自己的项目管理能力。其实，“项目管理”四个字重点不在管理，而在项目，当你的心在项目上，你就是管理者，项目就有可能因为你而成功;反之，即使你是个小角色，项目也可能因你而面临失败的危险。

　　(一) 我们需要什么样的人

　　在前面的文字中，我提到项目中的人员。我个人通常喜欢称项目的参与者为“工程师”，不管是开发，测试还是数据库管理，还是需求分析，项目管理人员。工程师这个词，其实包含了很多内容，不仅仅是垒代码，而是要像做一个建筑工程一样，考虑自己的部分对其他部分的影响，设计自己的部分，构建自己的部分，测试自己的部分，这是一个有机互动的过程，不是一个简单机械运动。我要强调的是工程师是技术工种，不是熟练工种，作为项目组的一员，我们也要从内心去做一个技术工种而不是熟练工种。

　　基于以上的考虑，我认为项目组成员应该至少具备如下三个特征：

　　1， 具有本领域内基本的技术能力和学习能力。我坚信不知道开机按钮在哪的同志确实干不了修理电脑的活儿，也不认为三天学不会hello world的程序员还有在这个领域生存的机会。

　　2， 专注于工作的精神。哪怕你工作一分钟，也请专注的工作，专注的思考。专注成就价值，只有专注的做事情，才能有所斩获。

　　3， 能够与人沟通。众所周知，沟通对于项目的成功有多么重要，所以沟通是项目组成员比不可少的素质之一。

　　工程师，还是代码工人。你的选择?

　　(二) 始终关注交付物--不管是项目经理还是开发人员(项目中的所有人)

　　项目一开始，我们就开始和客户谈需求。“汽车怎么卖跟我程序员有什么关系?如何让你的客户满意又关我什么事?只要告诉我你要什么就行了嘛，废话这么多”，很多程序员都这么想。

　　随着这些我们并不关心的事情越谈越多越谈越深入，我们越不耐烦，越想早点儿结束，进入我们自己的代码的世界。此时，我们忘记了真正重要的真正最核心的东西：我们要交付什么东西!此时你会说，我没有忘记，我就是要做个B2B的电子交易平台。没错儿，就是它，但是它是什么呢?包括什么呢?为什么是这样的呢?将来有可能会变成什么样呢?甚至这个平台能为我们的客户带来什么呢?不知道你能回答上来多少。

　　我们的交付物---它可能是一个独立工作的功能，可能是一个部署的方案，也可能是一个帮助文档， 它才是值得我们一直关注并且必须要关注的东西。对于它，我们应该深入的去了解，它能干什么? 为什么要这么干或者能为客户带来什么?在整个项目中处于什么位置?关键的挑战在哪里?何时交付最给力?最晚何时交付还能有效?如果没能交付会有什么后果，还有替代方案吗?

　　为了了解我们的交付物，我们必须深入的了解客户的需求。当我说到需求，我不想你联想到海量的客户业务信息，虽然那也是我们需要了解的;我只想让你去深入了解当前你在思考的交付物，以及跟它有关联的业务接口，当然，还有它产生的影响。关注交付物的最大好处就是能够保证项目的交付，而最核心的技术就是学习客户的业务—虽然我们是程序员，但其实我们应该是全才。

　　在此过程中，原型法是个不错的主意。原型不一定是一个客户看的东西，我不太看重那些重型的花费太多精力的原型。有时候，一个流程图，简单的几行字，几条描述业务的问题，一段与用户关于功能点的深入短暂的交谈，都是很好的原型。原型其实就是将你理解的东西，让用户理解，并得到用户的反馈，不管用什么方式，只要达到这个目的，那你的原型就成功了。

　　最后，一切关注交付物的努力都将迎来收获的季节：验收。项目组员可能关注交付物，而项目领导者可能更关注验收。其实关注交付物，就是关注验收，因为验收就是由一系列的交付物组成。乍一看，验收貌似就是一堆代码或者一堆文档，其实不然。验收其实是一个过程，是一个从开始就需要得到关注的过程。在项目开始的计划和设计阶段，每一个交付物都应该有一个完成的标准，即做到什么时候为止，一切交付物都应该是可验证的，而这种验证方式应该得到客户的认可。这些验证方式可以是一些测试用例，也可以是一些其它的标准，但是必须得有，我们一切的工作都要围绕这个验证标准进行。要努力让客户相信：验收就是跑完客户已经签字的测试用例，系统出现的错误在可以接受的范围之内。我们并不是欺骗客户，而是要客户进行深度参与，让它们意识到这些测试用例的重要性，从而更好的实现双赢。