工作了这么长时间，对一些项目管理方面的看法和经验抽出时间总结下，今天就开一个系列，谈谈如何一点一滴的改善我们认为难以驾驭或处理的问题。
诚如我们做技术，做面向对象编程一样。其实做任何事情或任何行业都有一个基本原则或准则，这就相当于一个最基本的底限，如果这个最基本的原则都遵守不了，就不用谈去做任何事情或者做了多久的事情，只能说你的工作还处于一片混沌中，就算目前还没出问题，但是迟早会出问题。跟我们做面向对象程序的设计一样，遵守最基本的原则“开闭原则”，如果你用面向对象的语言，而不遵守这样的原则，就是我的程序对扩展关闭，意料之中的事情或变化任意修改原有的架构(或者不能称之为架构和设计)，久而久之原有的东西恐怕会变得无法维护和运行，最后不得不废弃掉原有的东西，而重新来一遍，但是新的东西可能还会陷入原有的循环。
引用他山之石，我今天就来谈谈项目管理中的对错原则。
何为对？何为错？如果一个团队连对“对错”的理解都没有达到一致的共识，或者大家自顾自的工作处于松散状态。那么请注意了，无论现在你们多么忙，手头上的事多么多，请先放下这些事情，先一起坐下来各自谈谈自己对工作中对错的理解，他人或者团队的管理者一起对所有人提出的发生的对错的事情达成一致的结果，一定要把大家达成一致的东西记录一个地方，大家一起去遵守，不管是团队的普通成员还是管理者。
具体的“对错原则”是什么？其实就是---对的保留，每个人都要按对的做，按对的方式去思考和处理问题；错的摒弃，以后坚决不要再发生，或者不能按错误的方式处理问题和思考问题。
我们可以想一想，假如一个团队里或者个人明明知道自己或别人做事的方式是错的，不去纠正，错误之风泛滥，后果是什么？只能是好的东西越来越少，错误的东西越来越多！
例子：
公司实行弹性工作制，正常上下班时间早晨9点-下午18点，由于团队实行弹性工作制，最晚可以10点上班，19点下班。公司制定此规定的初衷肯定是好的。
团队里6个人，A、B、C、D、E、F。
早晨A(家住的比较近，喜欢早到公司早把事情解决)、C君9点到公司了打开电脑，一看昨天开会时订的需求有个细节必须和B君(家住的稍微远点，路上可能会堵车)讨论，否则今天的工作就被blocking住了。但是由于弹性工作制嘛，B君家住得又比较远，B一般又快10点的时候才能到公司。A只能先放下手头的工作，找点其他的于现在工作或其他的事情去做了，只能等到B来了之后才能一起讨论，然后继续今天的工作。
B君呢，由于一来公司之后就和A君讨论需求，需求和流程弄清之后，A就去开发自己负责的模块。B也去忙自己的事情了，B忙了个昏天黑地，突然间有个技术问题自己不是特别清楚理解的比较浅，但是自己的模块中需要更加深入的使用，但是貌似C对着块非常熟悉，一抬头发现办公室里就剩下自己和E了，一问C和其他人呢？E答道：现在都18点15了，其他人早下班走了。
B叹了口气，看来得自己解决了。B从网上搜了好多例子，看得云里雾里的，搞到了8点左右，一看表得赶紧回家了，只能明天让C看看自己到底弄得对不对。
D君是团队的经理，经过一段时间的观察，每周大家的集体讨论，发现了诸如此类和那类的问题。D提出我们大家工作日的9：45到公司，18：45下班，这样大家的工作都处于一个同步状态，有问题也好找到人及时沟通。大家对此达成了共识。
这个例子说明了一个简单的问题：好的东西不规范利用，也会变成坏的东西。表面开来整个团队由于没有一个整体的上下班时间点的共识，可能会造成团队时间上的浪费，从而可能导致项目延期。
上面的例子看起来小事一桩，但是从小事看出大家由于没有一个共识造成了团队资源的浪费，最后大家达成了共识，在最大程度上既没破坏公司的制度也满足了每个人的利益，并且好好的利用了团队的资源没有造成任何浪费。