最近半年扑在一个项目上难以自拔，简直就是一个泥潭，无数同行来到这里、陷在这里，谁也不知道到底完成项目还需要多少人来填坑。项目管理混乱，高层领导离职，已无进度管理可言(自打来了项目组，就没见“里程碑”为何物)。干到现在，我所感觉到的仅仅剩下失望、苦闷与挫败感。写到这里有点发牢骚的味道，其实我想说的是项目的成败与管理有莫大的关系，作为一个管理学出身(我现在是开发)，我也想通过我的经历说说我对项目管理的认识。

　　首先，说说我们项目组自身的不足。

　　1 没有“规范”。进入项目我没有拿到任何“规范”性文档，所以开发中数据表、变量、工作流等命名极其混乱。

　　2 没有数据字典。开发对数据库的认识仅能通过查询来了解，对于一个企业级项目来说，表实在是太多了，我们不了解某些数据，现有的表是否保存。

　　3 没有核心人物。对于一个使用独立框架开发的系统，没有一个对其十分了解的技术总监，所有人都是在按照之前的版本改造，尝试性地引入新功能，经常是一错错一片，需要不断地进行整体的返工，非常耗时。

　　4 没有责任到人。项目一贯的拆东墙补西墙的做法，导致某个功能点被分配了N手，所有人都要看前人的代码并熟悉业务，但项目组有不给你足够的时间交接，这样的结果就是大量代码重复，BUG数量飙升，以及出问题没人认领，互相推诿，最后接手的人要为前人买单。

　　5 缺乏沟通。在如此一个需求不明确的情况下，开发就应该坐在需求部门边上不断掌握需求，但是多数人没有，导致了我们都变更单都快追上《C#高级编程》了，而且内部人员沟通不足，缺乏协作。

　　6 不做代码审查。项目组没有质管，破坏现有代码分层，插入不写验证的情况很多，谁来为他们的BUG买单?

　　7 资源分配不合理，奖惩不均。甲方人员闲的打游戏，乙方人员加班到半夜。这其实也没啥，但是我要说的是为啥表扬的总是甲方，乙方加班就是应该的对吗。开发兼职运维，每天都要浪费大量时间来解答用户的各种问题，这也没啥，但为啥不让用户去找培训人员而来找我们，为啥解决问题消耗的人日不列入计划。

　　其次，说说我们的合作厂商的问题。

　　1 顾问能力不足。多数顾问不懂技术，其设计的系统完全违背大型分布式系统的开发原则。一个接口对应N个功能点，为了复用代码他们绞尽脑汁呀，可你可知道你提高了系统的耦合度，你对维护提高的多少成本。自己接口从不写验证，你为啥那么相信你的外围系统，你自己的库你都不看好门吗。完全不知道需求文档该怎么写，你是顾问，你要将用户的需求转换为需求文档，而不是指导用户如果写个EXCEL来应付差事，你的用户不知道开发人员需要什么，也不知道该如何表示自己的需求，再说哪有让用户写需求文档的。完全不能估算工作量，单方地认为改改字段就像改EXCEL文档那样简单，压外围进度压的好死。此外，顾问的业务水平也不高(经常遭投诉)，定个需求要开几天会，等真正做的时候发现业务又走不通了，明显在设计时，没有根据实际业务对设计进行反复迭代。

　　2 糟糕的文档。先不说文档的质量，首先数量就不全，经常是先开发后补文档。再说质量，完全是外行人写的东西，不过也可以理解，毕竟大部分文档是用户写的，我就想问，让用户出设计那还要你顾问干啥，难到就是发发邮件当监工。我觉得这已经不是能力问题了而是职业道德和责任心的问题。

　　3 推卸责任。业务上本该自己系统实现的功能，因为不好做就下发给外围系统，你个几千万的系统做不了，你要个几百万的实现，这理由充分吗。每个系统都应该承担起自己的责任，占有自己的位置，不要因为客户不懂技术，就偷懒。虽然作为顾问，维护己方开发人员的利益是合理的，但也你不能够以牺牲系统的可用性为代价。

　　4 换人不做交接。很难相信会发生这样的事情。不过我确实遇到了，换了人了，之前的设计全报废，然后做新的。

　　5 环境混乱。完全不理解为啥开发需要搭建如此多个环境。用户不停地从1个环境上测完去另外一个。你同类环境1个就够了，为啥整一堆没有针对性的测试环境，最要命的是还不能保证发布的版本同步。而且环境数据脏了就整新的，那得啥时是个头。

　　6 不接受意见。外部厂商顾问不爱接受外围系统给出的意见，比如接口复用问题。完全是把接口做成一个并集，来最大限度进行复用。

　　7 频繁变更。变更过于频繁，这也是项目组遇到最大的问题。不管是否收到甲方的确认函，变更都会到来，我报废掉的代码比现在可用的高出数倍。你完全不知道你的任务啥时候完了，到开发完成，测试结束，用户确认并试点上线之后，本该认为是没事了，但是到来的不是BUG而是变更。看过《C#高级编程》都知道那书有多厚，如果把我们的办更文档都打印出来，页数也差不多了。

　　说了这么多，很多都是自己的牢骚与不满，不过我真正想说的是软件工程的重要性。是什么造就了软件泥潭?原因的多方面的，但是好的项目管理能够帮助我们规避风险降低开发成本，并提高代码质量。比如，与用和其他参与者(包括合作厂商)密切沟通，对需求反复迭代，规范技术文档，好的版本控制，统一编码风格，进行代码走查，问题责任到人，采用合适的开发模型，正确评估工作量，制定合理的进度管理和激励机制，这些都有助于对一个项目的跟进。

　　感谢读者能够耐心地读完我的这篇”牢骚“，作为一名普通的开发人员，我不想指责谁的过失，因为毕竟我没有坐到那个岗位上，没有资格指责别人的工作。我觉得，一个项目的成败，虽然不是某个人能左右的，但是只有各个岗位的人各司其职，全力配合才能够保证系统的顺利上线。我想对刚入行的程序员们说的是，请对你们的代码负责，用户不提的不代表你就不用做了，没测出BUG不代表就没BUG，请在提交前做好代码走查，并不要推卸你的责任，是人就会犯错，你要做的就是承认错误并及时解决;对顾问说的是请对你们的客户和你的设计负责，你要知道你出具的文档是我们开发系统的重要依据，我们是如此的信任着你，请不要让我们失望。

　　最后送上我比较喜欢的一句话：软件开发如同在水面行走一样简单，只需需求已确认，水面已结冰。