如何才能调动员工，让他们自己查找网站中该做但未作的部分呢

我同意这位仁兄说的。
如LZ的情况，可以在项目整合期，再投入或者转型一个整合工程师，专门负责发现需要整合的内容，然后提出QA。
既然事情要做，就规范化的做，调动积极性这样的行为，是不足以形成规模化管理的。

一流企业靠制度，二流企业靠老板，三流企业靠人才，四流企业靠忽悠。完全适合于团队。

能否把缺陷进行分类，划分出低级BUG。象上面的这一类错误，可以归入到低级BUG中去。

软件开发中的各类缺陷，总是难免的，但低级BUG不允许出现。

对低级BUG要有一定的评判标准，并辅助一定的惩罚措施。

不知道是否会有效。

责任明确点，该是谁的谁负责

管理上的问题，偷懒和图利是人之本性，如果没有利益驱动每个人都能很勤快的干活，还要管理做什么，理想的共产主义还早着呢

坚持两条大原则：
第一条：金钱物质条件合理。
第二条：有理想主义色彩，而且走在路上。

什么制度、流程都靠边，看激励。
考虑到作为个体的人的经济理性，才有可能有的放矢。

楼主在这个项目中是什么角色？

他们都是有一些安逸  只做自己该做的 别的不做 哎 对他们也无语  我们老师安排项目也是  组长让做什么就坐什么  也不知道创新一下 最后项目都烂尾了 谁也没做完 哎 悲哀啊

事前：作为PM应该在事前在必要的节点、规范方面做好规定和标准，经验不足可以例会讨论，由成员共同商议制定。

事后补救：不要以“常识”等概念模糊规范和标准。
打个比方：单选框、复选框对应的说明文字需要用label for="xxx",以保证点击文字后能改动对应选框的选中状态。
如果在验收时作为“常识”来批判工程师没有做到的话，势必造成项目人员与管理者的分歧。

如楼上几位所说，可以利用评审的过程将这类问题发现和抽取，作为共通标准普及。对于在评审时提出这类意见、或者没有出现此类“常识性”问题的工程师加以鼓励和褒奖。

管理项目应该规范流程，细化每个流程节点需要做的事情，将问题体现在流程中的节点上，有利于及时发现问题解决问题。
这样可以避免在项目收尾时，甚至是交付时问题才大规模的爆发出来。

评审过程其实是很重要的，但一定要注意维护评审的气氛和基调。避免员工在评审时不敢说出真实想法，导致潜在的问题无法体现。
评审最好找几个任务有共通性质的人进行评审。

如果团队氛围、薪资划分在正常范围内的话，大多数程序员还是希望将工作做好的，并非不愿意精益求精。不是什么时候都只有钱才能解决问题，同事、上级的认同和肯定，有时比钱的效用更持久。