在软件开发中，有无数个永恒的话题 ，其中有一个话题叫做：Bug。传说它是沟通开发与测试之间的桥梁，不过我们要讨论的并不是开发与测试的关系，而是项目管理与Bug之间的关系，因为在这之前，有很多的项目不是输在了开发，而是输给了Bug。

　　据说，在系统交付前，你问项目负责人，项目有Bug吗？99%的项目负责人会说No，1%的人则会说有。那到底项目在交付的时候有没有Bug呢？实际上，没有Bug的系统是不存在的，测试人员没有发现Bug，并不能说明项目没有Bug。不过，从另一个角度说，该项目经过项目测试组的全面测试，没有发现任何Bug，也可以说是项目没有Bug。但也有可能是项目负责人没有说实话，出于善意的目的，说项目没有Bug。

　　因为没有一把严格的标尺来衡量Bug，你说它有它有，说它没有它没有。也正因此，让Bug成了永远也讨论不完的话题。我们还是上面的事说事，从上面项目负责人的回答可以看出，大部分项目负责人都严格要求自己的项目不带着Bug上线。这也反映了当前项目管理的现状，项目经理只盯着Bug，而忽略了开发，将没有Bug的系统做为上线的目标。

　　如果时间充裕的话，我相信所有的负责人都不会让他们的项目带着Bug上线。而事实并非如此，在实际项目开发过程中，开发周期特别短，而系统的业务很复杂，需求又经常变更，每天都会产生很多Bug。有些项目经理只关心系统的Bug和进度，根本不考虑当前的资源和需求变更情况，这导致开发人员盲目的跟着Bug跑，每天拆东墙补西墙，只是在原地踏步，而系统的进度没有增长。

　　尽管开发人员每天都很忙，但实际上却在做无用功。Bug多，也别乱来，别被Bug主导了开发。如果系统的Bug突然变多了，一方面可能是需求变更了，另一方面是代码结构已经紊乱，需要重构了。如果是结构混乱引起的Bug，一定要停下来重构。要知道，80%的项目都经历过代码重构（包括架构重构，框架重构，模块重构等）。

　　作为一名开发工程师，几乎每天都要和Bug打交道，发现很多Bug都是因为开发者没有遵循项目开发规范，把原本稳定的结构变的越来越混乱。作为项目负责人，应该加强对新人代码的Review，防止因开发人员破坏了系统结构，而产生难以数计的Bug，让项目管理陷入混乱。