话说我在这个组工作的十来年，只告过一个人的状，被两个人告过，结果都是不了了之，平时大家工作还算和睦。所以我以为告状属于小概率事件。自从当上领导之后，大开了眼界，告状的人和事层出不穷。因为有人的地方就有矛盾，员工自己解决不了矛盾，就来找我倾诉。
比如我组的一个程序员和另一个组的BA兼QA做项目，那个BA基本不作为，我的程序员只好帮他做了大量的测试工作。结果我的程序员找我抱怨这个BA。因为这个BA不归我管，我只能把这个事情告诉BA的老板。结果可想而知就是不了了之。这个BA是个新人，对系统不了解，工作也不积极，就这样过了两三年，他才终于有点儿上路了。
还有一次也是我组的几个程序员和另一组的几个BA做项目，项目测试的时候好好的，上了production就出了好几个严重错误，要马上修改。负责这个项目的程序员向我抱怨这些BA测试没做仔细，好多情况没测到。因为这些BA中有工作认真的，我就开导她说，测试的时候有没有把应该测试到的所有情况跟BA沟通，回答是BA应该知道他们应该测什么。可是我们这个系统很大，要测试的情况很多，不是特别有经验的BA不会想到要测试所有情况。程序员却可以通过修改的程序顺藤摸瓜，找到所有需要测试的情况，提供给BA。双方合作好，才不会有遗漏。我后来把这个建议拿到小组会上讲，要所有程序员注意，后来类似事件很少发生了。
自从我要求组员互相review code之后，就矛盾不断。有一个组员改起code来非常aggressive，为了把程序改得完美，会做很多改动，而其他组员就没有这么aggressive，主要是想减少测试的范围。这样review的时候就会出现矛盾，一个要求多改很多code，另一个又不想改。两个人说不服对方，就来找我评理。我一开始会告诉他们我的思路，改或不改的原因，几次之后他们自己就知道怎么讨论做决定，一般不来找我了。
还有一个组员大概是个perfectionist，review别人的code仔细到鸡毛蒜皮，其他组员向我抱怨过多次。这个不太好处理，因为一个perfectionist，让他变成不是perfectionist，很难做到。我只好让他注明他的哪些comment是指出问题，哪些只是建议。后来我和他共同做code review的时候看到了他的问题，直接指出来他要改进的地方。至于他能不能改进，还有待观察。
还有一个平时其它方面表现非常好的组员，做code review的时候总是拖拉，别人向我抱怨多次。我跟他聊了几次，才发现他根本没有时间看完所有的Email，因为他也做系统管理员方面的工作，收到很多系统发出的Email，code review的Email就burry在里面了。后来我改了code review的schedule，每人每个星期是固定的一天，他就在那一天特别注意他的code review email, 就没有再拖拉了。
大家在一起工作，问题肯定会经常出现。问题报到经理这儿来，经理的任务是要搞清出问题的原因是什么。是制度上有漏洞，还是员工之间工作方法的问题，还是员工能力的问题。极少极少会是工作态度或者人品问题。根据问题原因，找到最有效的方式处理，并且促进大家共同进步，才是一个好的经理需要做的。
