如何开始对项目进行管理
引言 谁应该对项目进行管理
项目管理的的文章和书籍到处都是，我也不敢在这班门弄斧。所以以下的文字主要关注从没有管理到开始对项目进行一些管理这个过程，通常没有进行管理或者很少进行管理的项目也不会特别大，所以本文并不一定适合大型项目。本文也不完全符合某一流程或者标准，其中一些只是我个人的一些浅见，如果能抛砖引玉，那就再好不过了；如果哪里说的不对，肯定各位筒子们尽管拍砖。
作为项目组的成员之一，不论你是开发工程师，测试工程师还是数据库工程师，你都对项目管理负有责任。在工作中，工程师应该精通自己的部分，优秀的工程师还应该熟悉别人的部分，实际情况中的工程师通常还需要在必要的时候（有人离开）顶上去做任何一个部分，此时，对项目的整体的把握至关重要。在参与到管理的过程中，也会提高自己的项目管理能力。其实，“项目管理”四个字重点不在管理，而在项目，当你的心在项目上，你就是管理者，项目就有可能因为你而成功；反之，即使你是个小角色，项目也可能因你而面临失败的危险。
（一） 我们需要什么样的人
在前面的文字中，我提到项目中的人员。我个人通常喜欢称项目的参与者为“工程师”，不管是开发，测试还是数据库管理，还是需求分析，项目管理人员。工程师这个词，其实包含了很多内容，不仅仅是垒代码，而是要像做一个建筑工程一样，考虑自己的部分对其他部分的影响，设计自己的部分，构建自己的部分，测试自己的部分，这是一个有机互动的过程，不是一个简单机械运动。我要强调的是工程师是技术工种，不是熟练工种，作为项目组的一员，我们也要从内心去做一个技术工种而不是熟练工种。
基于以上的考虑，我认为项目组成员应该至少具备如下三个特征：
1， 具有本领域内基本的技术能力和学习能力。我坚信不知道开机按钮在哪的同志确实干不了修理电脑的活儿，也不认为三天学不会hello world的程序员还有在这个领域生存的机会。
2， 专注于工作的精神。哪怕你工作一分钟，也请专注的工作，专注的思考。专注成就价值，只有专注的做事情，才能有所斩获。
3， 能够与人沟通。众所周知，沟通对于项目的成功有多么重要，所以沟通是项目组成员比不可少的素质之一。
工程师，还是代码工人。你的选择？
（二） 始终关注交付物--不管是项目经理还是开发人员（项目中的所有人）
项目一开始，我们就开始和客户谈需求。“汽车怎么卖跟我程序员有什么关系？如何让你的客户满意又关我什么事？只要告诉我你要什么就行了嘛，废话这么多”，很多程序员都这么想。
随着这些我们并不关心的事情越谈越多越谈越深入，我们越不耐烦，越想早点儿结束，进入我们自己的代码的世界。此时，我们忘记了真正重要的真正最核心的东西：我们要交付什么东西！此时你会说，我没有忘记，我就是要做个B2B的电子交易平台。没错儿，就是它，但是它是什么呢？包括什么呢？为什么是这样的呢？将来有可能会变成什么样呢？甚至这个平台能为我们的客户带来什么呢？不知道你能回答上来多少。
我们的交付物---它可能是一个独立工作的功能，可能是一个部署的方案，也可能是一个帮助文档， 它才是值得我们一直关注并且必须要关注的东西。对于它，我们应该深入的去了解，它能干什么？ 为什么要这么干或者能为客户带来什么？在整个项目中处于什么位置？关键的挑战在哪里？何时交付最给力？最晚何时交付还能有效？如果没能交付会有什么后果，还有替代方案吗？
为了了解我们的交付物，我们必须深入的了解客户的需求。当我说到需求，我不想你联想到海量的客户业务信息，虽然那也是我们需要了解的；我只想让你去深入了解当前你在思考的交付物，以及跟它有关联的业务接口，当然，还有它产生的影响。关注交付物的最大好处就是能够保证项目的交付，而最核心的技术就是学习客户的业务—虽然我们是程序员，但其实我们应该是全才。
在此过程中，原型法是个不错的主意。原型不一定是一个客户看的东西，我不太看重那些重型的花费太多精力的原型。有时候，一个流程图，简单的几行字，几条描述业务的问题，一段与用户关于功能点的深入短暂的交谈，都是很好的原型。原型其实就是将你理解的东西，让用户理解，并得到用户的反馈，不管用什么方式，只要达到这个目的，那你的原型就成功了。
最后，一切关注交付物的努力都将迎来收获的季节：验收。项目组员可能关注交付物，而项目领导者可能更关注验收。其实关注交付物，就是关注验收，因为验收就是由一系列的交付物组成。乍一看，验收貌似就是一堆代码或者一堆文档，其实不然。验收其实是一个过程，是一个从开始就需要得到关注的过程。在项目开始的计划和设计阶段，每一个交付物都应该有一个完成的标准，即做到什么时候为止，一切交付物都应该是可验证的，而这种验证方式应该得到客户的认可。这些验证方式可以是一些测试用例，也可以是一些其它的标准，但是必须得有，我们一切的工作都要围绕这个验证标准进行。要努力让客户相信：验收就是跑完客户已经签字的测试用例，系统出现的错误在可以接受的范围之内。我们并不是欺骗客户，而是要客户进行深度参与，让它们意识到这些测试用例的重要性，从而更好的实现双赢。
（三） 我们需要哪些文档，工具和努力
软件项目肯定离不了文档和管理工具，如果您的项目还没有它们，那么请从现在开始。那么文档是不是越多越好呢？老话说的好，合适的才是最好的。小而精的文档和工具会让我们事半功倍，大而全的文档会让我们疲于奔命，最后迷失在文档的海洋中。
我们写代码的都知道，错误的注释比没有注释更可怕；同样的，没有及时得到更新的文档比没有文档更可怕，因为文档就是项目的注释。那么我们是否有必要去更新那些我们根本没有用到的文档呢？很显然，那是非常没有必要的，是对资源的浪费。文档说起来其实就是一个工具，是一个让我们开发时有依据，可以追溯开发过程以及记录开发结果的工具。我们只有用到它，它才有存在的必要。
那么文档过于少或者干脆没有文档，不是更简洁？我想说：不写代码不是更简洁？玩笑归玩笑，没有文档或者文档太少会导致的问题大家可能也都遇到过：那就是过程不可追溯，有些非常重要的逻辑没有记录，需要用到时团队成员各执一词，甚至需要重新找客户确认而是客户认为我们不够专业；有些非常重要的设计没有记录，导致代码维护困难，以至于维护人员破口大骂开发人员写的什么垃圾代码做的什么垃圾设计。有些设计非常的巧妙，非常的值得学习，然而就是因为没有留下记录而被初学者如我一样的人骂了N次。在反省自己不够聪明时，是否也该让写代码的人反省一下为什么没能留下点儿记录？
有一种观点是最好的设计就是代码，意思是代码就是设计，代码应该非常的优秀，可读性特别好，让人一看就明白，我完全同意。如果代码写到这种程度，那文档就真的没用了。那么请自问，您是这样吗？如果是，没文档，没问题；如果不是，请把重要的东西写下来。那么，哪些是重要的呢？
哪些是必须的， 哪些是Optional的。对于哪些文档更重要些，应该由项目的具体情况而定，特别是项目的大小，逻辑的复杂程度，人员的情况等等很多因素。在我做过的项目中，我个人认为最重要的一些文档和工具如下所述：
1， 功能说明书（Functional Specification）------按独立功能划分优先级，每一条记录都是一个可交付物，都是一个功能。整个文档就描述了整个项目的交付功能和优先级。项目中的所有人，都应该关注这个文档：测试用它来写测试用例；开发人员用它来决定先开发哪个功能；PM用它来查看功能的完成和验证状态。它通常不应该内容过多（由项目规模决定），我觉得最多两行字就可以描述一个独立工作的功能，至于对这个功能的理解，应该由负责它的程序员来完成。
2， 核心流程图。这个流程图可能描述了用户使用该系统的过程；也可能描述系统中数据的流转；也可能描述表单的流转。总之，它描述一个过程，这个过程对用户来说非常重要。这个图有时候也会被其它的图，如顺序图代替。
3， 部署文档。该文档描述了该系统应该如何部署，它不一定非要是一个word文档，也可能仅是一个bat文件而已。这个文档应该描述该项目如何部署，步骤是怎么样的，需要哪些文件，需要哪些硬件支持，以及需要注意什么。部署历来都不太被重视，大家觉得只要东西做出来了，部署不就是放上去吗？其实不然。在经历了一定周期的开发后，开发过程中积累的配置，对环境的要求，在真正部署的时候很多就忘了，所以部署可能会花费很多没必要的时间，我觉得这也是微软要做daily build的原因之一，每天都build一个可用的版本，当然部署就没有问题了。我们刚开始可能不需要每天都build一个版本，但最少要一周或者两周部署一个版本吧。每次部署都整理一个自动化的脚本或者文档，会让你最后上线的时候非常的从容。
4， 测试用例。我不是一个测试人员，测试也是我觉得一直没有做到位的地方。客观的说，我觉得用例应该花很大心思去编写，就像用户真正的在使用软件一样。项目应该在设计和开发的时候就以满足用例为目标，而不是开发完了才想起来用例，去测试，发现问题再修改，回头想想，这可能就是测试驱动开发产生的原因吧。我们知道用户发现错误修改的成本高于我们自己发现的错误；同样的，设计和开发阶段就解决的问题成本也远远小于测试阶段发现的。正是，问题发现的越早，解决起来就越容易，成本就越低。
5， Bug管理工具。这个管理工具可以是一个excel，当然，我并不推荐这么做，毕竟excel却是不那么自动化。但是，只要比excel自动化一点点儿的信息系统就可以了，它需要可以记录问题，可以传截图，这就够了。我推荐使用bug tracker，这是个dotnet开发的开源的bug管理工具，其实也可以管理需求，是非常实用的。
以上五个是我认为最重要的，我觉得是项目开始进行管理的阶段必不可少的；而下面几个，则是大家视情况可选的。
6， 核心类图。这个可能是可选的，因为有时候，类的关于没那么复杂，也就没有必要有这个图；相反，则需要进行记录。
7， 数据库设计。数据库设计文档可能在review的时候用到。
8， 系统间接口图。如果产品有若干个子系统，如web service等等，那么我认为需要一个描述系统间接口和交互关系的图，这个图应该在设计的早期就开发出来供大家使用并且随时保持更新和关注。
有了文档和工具，是不是就一切OK了呢？不对，就像大而全的文档并不能帮助我们成功一样，有了文档并不代表项目就能成功，如何维护和使用这些文档和工具是相当重要的。每个文档都应该有人去维护，那么谁去做这个事呢？我认为项目经理应该经常拿着功能说明书开会，它也可以被看做是WBS的初级版本，可以被标注状态和优先级；所有人都应该熟悉流程图，并随时提出对流程图进行检验和review；应该指定一个人负责构建，这并不需要花费很多时间，但是需要细心和一些完美主义精神；测试人员自然要维护好测试用例；每个人特别是开发人员，都应该有一种觉悟，那就是一旦想起了哪些重要的逻辑，不管是业务的逻辑还是系统的算法，都应该记录到bug管理工具上。Bug管理工具完全可以记录这些零散但却重要的东西，以便将来方便查询。
在这里我也是根据自己的经历简单的谈了一些我的看法，这并不是金科玉律，我还得说，合适你的才是最好的。
（四） 代码规范的选择
做开发不可避免的遇到代码规范，从上学时就会学习到一些规范，但是每个公司都不同，那么我们到底要遵守哪些规范呢？我个人认为，一个合格的程序员应该可以随时调整自己适应任何一种规范，这是一种职业素养和能力。而何时该遵循何种规范，这也有一定的原则。
1， 在现有系统（代码）基础上进行开发。这种情况下，我们应该尽量的去遵循原有系统的规范，不论是命名还是注释。因为如果这时你非要按照自己的习惯写，那么系统就会出现两种完全不同风格的代码，这对将来的维护是一种噩梦。但是，遵循原有规范不是迁就原有错误。如果发现原有的规范会造成一定的问题，就要立刻改正，不能装傻充愣假装看不见。
2， 新建团队开发新的系统。新建的团队中团队成员可能来自不同的环境，对规范的选择倾向一定是不完全一样的，此时要怎么做呢？这时，项目的领导者应该组织大家一起做一个决定，讨论如何定义变量，如何给控件取名等等。在出现意见不统一又谁都说服不了谁的情况时，项目经理应该做出明确的决定。此时选择一种规范远比同时迁就两个人要来的好，不然造成新系统中存在两种规范，同样是维护的噩梦。
3， 稳定团队开发新的系统。这种情况就容易得多，团队稳定后团队成员渐渐的了解了互相的习惯，互相学习后就更容易达成妥协。只要注意让新加入的成员适应就可以了。
有人可能觉得代码规范没什么大不了，功能正确没有bug不就行了？当然，如果没有bug那肯定没问题，然而一个系统运行到退休还没有bug，哪位见过呢？我做了一些运维工作之后才渐渐了解到，不同风格的代码读起来就像是一会儿在赤道，一会儿在南极，非常的痛苦，有时甚至会造成系统很多的不一致，大大增加了维护的工作量。我们的目标之一不就是增加系统的可维护性吗？
（五） review和重构
说到review，有些筒子可能立刻就想到了：吵架。确实，有的时候review真的可能演变成吵架，但是我们为了项目的成功，这个风险一定要冒，慢慢成熟以后，被人批评的次数多了，脸皮厚点儿就好了。；）玩笑归玩笑，review确实是需要技巧的：在review别人的代码时，要注意你的话语有时会伤害别人的自尊心，让别人觉得你是在鸡蛋里头挑骨头；在别人review你的代码时，同样的你也会觉得别人是在鸡蛋里头挑骨头，伤害你的自尊心。这里我也没有太多的技巧可言，一句话，换位思考，脸皮厚点儿吧。哈。
Review可能分成以下几种：
1， 设计的review。说起review大家更多想到的是大家坐在一起边侃大山边看别人的代码，其实设计的review是更加重要的和更加高级的，也是更有价值的，问题发现的早解决的代价就小嘛。在review别人或者自己的设计时，我们都能学到别人的设计理念，方法和技巧，这能大大提高团队成员的能力。项目中的技术牛人，项目经理和技术骨干应该作为设计review的主力人员，多多谈谈自己的看法；同时也要注意尊重设计者的感情，让大家都有收获的同时，把项目做好。
2， 代码的review。代码review的形式可以多种多样，两个人坐在一起看看代码也是一种review，也没有必要非得所有人都凑齐。Review代码的可以让自己迅速成长，也能让项目组成员熟悉别人的业务和代码，以最大程度减少人员变动造成的损失；同时也能让代码规范更加一致。
不管是设计review还是代码review，都不一定要全部人员到场，这可能会浪费一些时间；但是设计的review最少要有一个技术骨干或者项目经理在场，否则review就会变成讨论会进而升级成战争。
Review有时候也会被认为浪费时间，特别是很多程序员对review别人的代码没有任何兴趣，也不愿意让别人对自己的代码说三道四。我想说，作为一个二十一世纪的软件工程师，我们不但要善于对技术进行钻研，更要善于把自己的技术传播出去，也要善于通过别人的指点更快的提高自己的工作能力。这是一个开放的时代，是一个需要交流的时代，是一个迅速发展的时代，你慢，就就完蛋。
在review发现了很多问题之后，我们要怎么办呢？对，重构。这几年重构这个词已经非常的火了，大家都说重构很重要，但是又有几个人真正的去重构呢？有几个人真正的不允许自己写重复代码呢？大家是不是还在说：“项目schedule太紧了，等有空了再优化吧”？我认为，这句话是有问题的，项目的总时间短，任务重，我们没办法；但是优化（重构）却不会增加这种时间的压力，相反的，重构会大大减少后续的开发和debug时间。因为重构后，出现的bug更容易被定为，更容易被fix；相反垃圾代码引起的debug和fix bug的时间将远远大于重构的时间。
