技术团队坚持的总则-对错原则(上)

工做了这么长时间，对一些项目管理方面的见解和经验抽出时间总结下，今天就开一个系列，谈谈如何一点一滴的改善咱们认为难以驾驭或处理的问题。

诚如咱们作技术，作面向对象编程同样。其实作任何事情或任何行业都有一个基本原则或准则，这就至关于一个最基本的底限，若是这个最基本的原则都遵照不了，就不用谈去作任何事情或者作了多久的事情，只能说你的工做还处于一片混沌中，就算目前还没出问题，可是早晚会出问题。跟咱们作面向对象程序的设计同样，遵照最基本的原则“开闭原则”，若是你用面向对象的语言，而不遵照这样的原则，就是个人程序对扩展关闭，意料之中的事情或变化任意修改原有的架构(或者不能称之为架构和设计)，长此以往原有的东西恐怕会变得没法维护和运行，最后不得不废弃掉原有的东西，而从新来一遍，可是新的东西可能还会陷入原有的循环。

引用他山之石，我今天就来谈谈项目管理中的对错原则。

何为对？何为错？若是一个团队连对“对错”的理解都没有达到一致的共识，或者你们自顾自的工做处于松散状态。那么请注意了，不管如今大家多么忙，手头上的事多么多，请先放下这些事情，先一块儿坐下来各自谈谈本身对工做中对错的理解，他人或者团队的管理者一块儿对全部人提出的发生的对错的事情达成一致的结果，必定要把你们达成一致的东西记录一个地方，你们一块儿去遵照，不论是团队的普通成员仍是管理者。

具体的“对错原则”是什么？其实就是---对的保留，每一个人都要按对的作，按对的方式去思考和处理问题；错的摒弃，之后坚定不要再发生，或者不能按错误的方式处理问题和思考问题。

咱们能够想想，假如一个团队里或者我的明明知道本身或别人作事的方式是错的，不去纠正，错误之风泛滥，后果是什么？只能是好的东西愈来愈少，错误的东西愈来愈多！

例子：

 

公司实行弹性工做制，正常上下班时间早晨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下班，这样你们的工做都处于一个同步状态，有问题也好找到人及时沟通。你们对此达成了共识。

这个例子说明了一个简单的问题：好的东西不规范利用，也会变成坏的东西。表面开来整个团队因为没有一个总体的上下班时间点的共识，可能会形成团队时间上的浪费，从而可能致使项目延期。

 

上面的例子看起来小事一桩，可是从小事看出你们因为没有一个共识形成了团队资源的浪费，最后你们达成了共识，在最大程度上既没破坏公司的制度也知足了每一个人的利益，而且好好的利用了团队的资源没有形成任何浪费。