我们是不是经常觉得做项目时，老是不断重复之前项目的错误或问题？跳槽几次后，发现项目管理上总是有些似曾相识的感觉。不要奇怪，这很正常，大象也有过这种经历，我将这些经验总结出来，与各位分享一下。
    1、拍脑袋决定完成时间
    这个可以说是绝大多数项目的特点。老板一拍脑袋：XX项目一定要在X月X日上线，不管有多大困难都要达到，我只看结果，其它的你们去考虑……问题的关键不是这句话，而是这时根本就不知道要做什么，这不禁会让人感到很恐惧，继而产生猜疑，有多少任务？做得完吗？没问题吗？有问题吧？……然后当真正知道要做的工作量之后，悲观的情绪开始蔓延，团队士气持续下降，各种不满，各种抱怨都汇集在一起进入到项目开发中……
    这种貌似不着调的决定，其实就是为了遏制成本，深度挖掘出员工的潜力（说的不好听就是压榨），让每一位员工充分的为公司创造价值，领导则将此解释为执行力。如果你经历过很多次这样的情况，你的神经早已坚韧，对此会很淡定，似乎达到了他强任他强，清风抚山岗；他横由他横，明月照大江的境界。

    2、无法在时间点完成项目
    几乎所有项目的开发时间都会被强烈压缩，而工作量又非常大，直接结果就是拼命赶进度，质量已经没时间考虑了。即使如此拼命的做，项目还是无法在确定的时间之前完成，归根到底想在这个时间点交付项目本身就是一件不可能的事情。
    项目经理无法说动老板，不过他似乎得到了老板的授权，必要时可以加人，这让他又信心十足。然而他却没在初期加入新的开发人员，却是在离交付前几周或一个月才发现事情并不是他想象中那样，这时再招人已经晚了。项目经理这时会跟老板反应情况，要求增加一点时间，老板会先狠批一顿，balabala一大堆，然后再十分不情愿的答应，最后道出重点：这次项目奖取消！
    造成这样的结果，一种原因是遏制成本，还有一种情况是在大公司里面，层级很多，所以老板就有很多个，项目经理将无法完成项目的实情汇报给他的直接上司，而上司觉得如果他也这样向上汇报会显得自己能力不行，因此他会隐瞒实情，而作出有点问题但不是很大的汇报。而这个结果在他的上司看来应该是没什么问题，继续向上汇报时就变成了肯定没问题的答复。因此悲剧就这样发生了。

    3、加班文化
    做IT行业没有不加班的，哪怕是其它行业也会有加班。加班对于软件开发人员来说就像吃饭喝水一样平常。很多公司把加班作为自己的企业文化，要员工自觉加班。有了上面说到的两点项目状态，加班就成了必然的事情。
    现在很多公司特别是一些小公司，会想尽办法规避加班的说法。比如大象以前就遇到过这样的，该公司对开发人员不提供工作用的电脑，要你自己去买笔记本，然后公司根据你买的电脑价格提供一定数额的补贴(补贴不是一次性给你，是分月付的)，项目时间很紧，工作量很大，基本每天都需要加班多做一点，但是公司会对你很关怀的说，带回家做吧，你也不想一个人呆在公司里面，然后吃完饭后继续做项目……
    做开发的虽然避免不了加班，但大象认为不能将加班作为一种常态，只要有项目上马，就要每天加班，有的甚至五一、十一这样的假期都要在公司加班。这不光对员工的心理和身体都造成了伤害，也对公司形象造成了损害。试想行业内的同僚聊天时，一说到某某公司就是众口一词，这是个魔鬼加班公司、大家千万不要去、你想过劳死吗？等等诸如此类不好的评价。身体是革命的本钱，就算赚再多的钱，也要有命才能享受得到，你说是不是？

    4、无能的领导
    遇到这种人，你要么把他弄下来，自己上去，要么赶紧走人换一家。不然你就等着被他们弄得欲仙欲死吧！这种人的特点就是真本事没有，只会成天勾心斗角的算计，打压同僚，批评讽刺挖苦属下，以体现他的存在感和显示他的能力。每当分完工作任务后，他就成了最轻松最无聊的人，彻底变成一个甩手掌柜。
    这种人不懂什么技术，也不会管理，他手下人员的流失率非常高。你肯定想问这种人怎么可能一直坐在那个位置上？恩，这是个好问题，虽然他们的工作能力不行，但是他们深谙为官之道，将他们的上司，或直接是老板打点周到，然后工作结果不出什么纰漏，这样他就可以继续耍他的威风。
    大象之前说的那个要自己买笔记本的公司里就有这样一位极品，2009年的时候，当时是三个项目同时进行开发，极品觉得其中有一个项目的资金没有按要求到账，便私自做决定将它暂停一下，集中做另两个项目。我当时知道了后还小小的激动了3秒钟，但世上就是有这么多的神转折，那个停下来的项目甲方竟然在离交付前两个月的时候一次性支付了80%项目款，这下子极品不淡定了，要求马上集中资源全力完成这个项目。用一个月的时间，完成本来要3个月的全部功能开发。大象那一个月每天都是凌晨两三点钟才睡，星期六星期天全天在公司加班，回来后继续做。最后工作完成了，功劳全是他的，那家伙在开会时无比自恋的说：幸亏我英明的决定云云…………那样子要多恶心就有多恶心。

    5、继续错误的方式
    很多人可能都有这样的体会，项目做完之后，开会总结，发现了项目中存在的不足，然后，就没有然后了。因为下一个项目已经准备就绪，需要马上开始做。在这个项目中，上个项目犯的错误继续会犯，错误依然得不到解决。
    这种不想改变的原因，是因为没时间还是习惯了这种工作方式？我认为很大程度上来源于公司的文化和管理。公司只看成绩，注重结果导致了只要把项目搞完就OK了，其它的见鬼去吧！多部门需要沟通配合的工作，由于管理不善，互相之间很难形成良好的合作，使得彼此之间不再有交流，导致问题在最后时刻爆发。

    6、无处不在的变更
    总是在项目进行到一半或者一大半的时候，变更来了。此时你的心情，真是恨不得把电脑砸了。但当你开始着手处理变更还没两天的时间，新的变更又来了，呵呵，请不要愤怒，现实就是这么滴残酷。
    像企业项目开发的变更，还有一点成本因素在里面。但是在互联网公司，情况就完全不一样了。无论在开发之前怎么强调需求变更的成本很高，实际上都没什么效果，对于提出变更的人来说，他们不关心时间，他们只关心他们的需求是否得到落实，他们给出的理由也很充分：这是需要的，这个改动不大，只是换个方式而已，又不用多少时间……大象已经经历过很多次这种状况，可以说已经渐渐习惯了，但是真到了快上线的时候又来一变更需求，心里立即就像有一千万头草泥马奔腾而过……

    7、拖沓的工作
    如果没有好好的分解工作，只有一个大的完成时间点，项目在开始的时候是不会有紧迫感的，心里想着还有这么多时间，我可以做完的，日子慢慢过着，那么无形中进度会慢慢的降下来，直到某一时刻发现，原来还有这么多工作没做。
    还有种情况是在某个问题上遇到了麻烦，自己一个人在那里折腾，抱着不解决它，其它事情都不做的心态，时间就这样一天天过去，如果解决了还好，要是卡在这里了，整个项目的进度都会被拖下来。对于这种工作的方式，大象是非常鄙视的。毫无团队精神，你把问题抛出来会死啊？

    8、追求新技术
    做出好的产品或项目，并不只是用一些新技术堆砌起来的产物。但是对于有些表现欲很强的公司领导，就是喜欢上马新技术，甭管这技术门槛如何，是否成熟稳定，学习曲线等等因素，反正就是要用，目的就是增加噱头，增加政绩。
    08年的时候，Flex非常火，之前提过的那个极品项目经理就决定一定要在当时项目中使用这种技术。他自己是不会的，就要我来学习下，研究怎么在项目中使用，限我一个星期做个DEMO出来给他看，大象心里这个郁闷哦，就那几天为这事搞得我口腔溃疡了都，虽然已经过去6年了，我到现在都还记得很清楚。我的博客很早之前写的使用Flex画时空线形图那篇文章，就是记录当时项目中用Flex做的那个功能。
    Flex其实是Flash的封装，Flex开源，但是Flash并不开源。Flex入门还是很容易的，但想把这门技术掌握好却并不容易。后来HTML5的发力，以及众多浏览器的支持(IE9才支持)，Flex的热度才开始消退。如今，浏览器内的绘图和动画完全可以用HTML5来实现。但由于国内Windows XP系统的市场份额还非常高，因此IE6、7、8用的人相当多，所以很多网站即使采用了HTML5，也还是要兼容IE6、7、8，因此使得HTML5的推广受到了阻碍。
    我以Flex举例，就是想说新技术并不是像看上去那么的美好，做技术选型时一定要慎重，架构应该结合自身的业务特点来进行设计，预先计划着一两年后就可以，不要盲目的一开始就远景规划到五年以后，十年以后怎么样怎么样，这是不切实际的想法。
    再拿大家熟知的淘宝架构来举例，最早03年淘宝刚出来那会儿，它是典型的LAMP，很快它的流量和交易量上涨，MySQL撑不住了，换成了Oracle，但还没过多长时间网站还是抗不住，继而转用Java重做整个网站，然后随着网站的发展逐渐的改变架构并加入新的技术。所以说好的架构是进化来的，而不是设计得到的，业务推动技术的发展，技术发展再反过来帮助业务的提升，这是一种良性的循环。

    9、没有多余的人
    这种情况一般小公司比较常见，秉着节约成本，充分利用资源的原则，开发人员很少，每个人每天都是在超负荷工作着，没有多预留一两个人。直到有一天某个人决定不干了，那么他的工作谁来接手？这种只考虑金钱不考虑时间的做法是非常短视的，当项目进行到某个时间点时，很可能就会发现时间不够用了，这时又想花点钱招人来“购买”时间，到了这个时候一切都已经太晚了。
    这样的公司，人员流动很大，发展也不稳定，刚进公司的人发现没过多长时间就有人离职了，自己的工作又加重了一些，公司马上安抚大家，会再招人补充这个位置，然而当新员工进来后，又有人离开，公司继续招人……这个过程持续下去，很可能一年也很可能半年所有的人都会换一遍，你还会再呆下去吗？

    10、不说出来，沉默以对
    项目按照需求开始进入正式的编码工作，然后做需求的人绕过项目经理单独找上你说，这个地方要改改，你点头答应了，然后没有通知项目经理，也没有知会和这功能有关的其它模块的开发人员。过了几天，需求人员又来找你，说要新加一个功能，你又答应了，然后还是和之前一样沉默的接受，不说出来。最后会出现什么情况？
    有些时候是上级领导提出新的系统任务请求，但是目前的工作压力已经很大了，作为下属如果直接答应，而不会尝试着说“不”的话，团队的士气将受到严重打击，组员对你的尊重度也会下降。

    11、不做出头鸟
    在某个项目阶段性会议上，领导让大家畅所欲言，谈谈现在项目还有哪些问题要解决。如果你提出了一个没被发现的问题，那么，恭喜你，你就是解决此问题的人选了，实际上和这个问题有关的功能根本就不是你负责的。久而久之，以后在会议上再也没人敢说什么了，哪怕自己知道还有哪些隐藏的问题。
    如果是多小组协同开发的项目，如果A小组的负责人说进度达不到，需要增加时间，这时老板肯定一脸不爽，转而问其它小组的进度情况，得到的回答肯定是一切尽在掌握中，而实际情况其实和A组半斤八两，主要区别就是他们没说，老板不知道，而将火力集中到了A组身上。

    12、不确定的项目目标
    很多项目在立项的时候目标不明确，多次开会讨论都不能确定下来，使得混乱加重。其实参与讨论的人可以有很多人，但最终做决定的只能是一两个人，不能有过多的人参与到项目目标的确定。
    今天全世界用的非常多的Linux系统，最早的时候是由Linus一个人独立做出来的。还有在JavaScript里大红大紫的jQuery，最早也是由John Resig一个人开发出来的，以及Hibernate早初也是由Gavin King写出来的，像这样的例子还有很多。他们确实才华横溢，但至少说明项目的目标确实应该由极少数人来决定。
    在确定好项目目标后，声明项目范围，严格把控新需求的增加，坚决拒绝与项目目标不一致或对目标效果不必要但明显增加项目风险的需求。

    13、办公室安静得像太平间
    有一些公司，至少我呆过或知道的一些公司有这种情况，一整天都可能没有一个人说话。就算是有，也是很小声的交谈，走路都轻手轻脚的像阿飘在飞。在这样的环境下，实在是很没有激情，开发本来就是一件很费脑力很枯燥的事情，如果在这样诡异的氛围中工作，会让人更压抑，有可能公司文化就是这样。这样的情况就是人人都呆在自己的位置上做自己的事，造成了沟通严重不足，但你忍心破坏这么和谐的环境么？亲！

    14、进度时间控制
    项目的开发时间永远是紧张的，总是感觉不够。如果团队成员的个人能力差距较大，进度将会受到影响。因此想确保进度可以被掌握，事先一定要好好的计算下各自的工作量，而计算工作量有一个比较通用的公式：
    工作量=(最可能+最乐观+最悲观)/3
    或者
    工作量=(最可能x4+最乐观+最悲观)/6
    这里算出来的工作量就是“1天/人”，比如你算出自己的工作量是15人/天，那代表你需要15天才能完成自己的工作任务。工作量的计算越细化越好，比如以功能为单位就肯定比以模块为单位要精确很多，对工作量越了解自己的心里面就越踏实。特别是计算前要好好的分析一下自己要完成的功能或模块，确定他们是否还需要其它的资源(需求是否明确、调用别人的接口、需要前端协助)，这些因素都要考虑在内。
    在交付时间确定的情况下，根据自己的工作量来安排时间，每天都查看一下计划表，看看进度是否落后，如果确定无法在时间点完成任务，那就需要加班来做了。如果团队中每个成员都能这样保证工作进度，那么在时间点交付项目就不是什么太难的问题。
    这是大象的一些经验总结，有什么不对的或不足的，还请各位批评指正，谢谢！
    本文为菠萝大象原创，如要转载请注明出处。http://www.blogjava.net/bolo

一些常见的项目行为状态[转]