让步还是继续前进

当然这个取决于你的组织到底有多大的决心来改进。
比如说我咨询的一个客户，他们在很多年的痛苦和反思之后终于明白，代码质量是重要的──所谓重要，那就不是可有可无的，而是不可讨价还价的。最简单的一个例子：如果真到了必须二选一的时候，要坚守质量标准就做不完需求，要做完需求就得降低质量标准，那么这个客户的选择就一定是坚守质量标准，在需求上讨价还价。因为很多年的经验教训已经让他们明白，质量低下的代码就算写出来完成功能，它也一定会让你付出更大的代价。不符合质量标准的代码不是生产率──实际上它是负生产率，因为你将来要花更多的工夫来维护它。
如果你有了这样的觉悟，那么接下来的事情就很简单了，比如说checkstyle必须通过，不通过就break build，然后所有人都停下来直到build被修复。但是如果这个组织对质量的重要性还没有这么深的认识，他还没有痛到这样的程度，那么他就不会有这么大的决心来贯彻，那么你也就只能随波逐流。这种事情，强扭的瓜不甜。

楼主没啥信心了现在，有信心的话会把问题一二三四列出来，让大家帮忙解决。。。目前有点快崩溃的感觉。。。项目失控中。。。。

你是不是认为，老总写了确认书之后，就不会有变化了？！

突然看到这句话，解除了心中的一个困惑。

突然又有了另一个困惑：面对“无知无畏”的团队，该如何下手进行过程改进？

我已经说过了，如果一个组织还没有认识到质量低下会带来怎样的损失，你就没办法有效地引入质量改进的手段。
所以你应该做的第一件事是让他们意识到这种损失。
这分成两部分：
1. 让一些严重的损失具现出来，让所有人都意识到这种损失
2. 让大家意识到这些损失是因为质量的缺失而造成的
先想办法搜集证据，至于证据能不能说服人，就再说吧。

你们说楼主这头像是男人还是女人？ 

非常认同这种看法,不失去一些东西总是无法提高自我认知
从人的水平发展来说,也是分阶段的,想提高一个台阶,总是要付出很多才行吧

你现在应该感觉很头大吧！

任何人不是天生就能做项目管理，这需要一个过程。你现在只是拥有成为合格项目经理的机会。

给你提点建议。
1   不管项目有多大压力，作为项目经理，你要保持自信；
2   找你认为能帮助你的人，与他仔细沟通项目的现状，协助你认清项目的问题所在，并做好相应的对策；
3   从现在开始，做好项目中的文档；
4   不要所有问题自己扛，调配周围的资源；

这个帖子看完，我才发现gigix是个牛人。
说的一些建议太有棒了

大概是静态页的机制，如果实时刷计数，系统压力太大，不可能单为一个读数去更新静态页。

关于主题，和我们的情况差不多，所以，感觉沟通方面的比其它的要重要，只要能达成一致就好，用什么方法和手段在其次。一些工具化的东西还是要的，一方面有利于规范操作，另一方面回溯性好。当然，第一次用感觉好累，也没什么效果，但这些东西好多是为了过程管理的，认为有好的过程就有好的结果。但关键在人，实际上是要人来熟悉以至主动按规程工作，效益从长期角度讲的，第一次往往是痛苦的。所以在还不太熟悉这个套路时，人们出于惰性可能反对他，或不认真执行，那其实也是项目管理的一部分，不过最好是有高层的支持。