浅谈开发人员的管与理

一、口水会议
最近一期的公司内部讨论会上，“代码走查与开发规范”又成了热点讨论议题，但是这个议题已经谈论很多次，也决议了很多次。这次一些旧的问题又被的顶了上来，“应该给出统一的全公司的代码开发规范（其实早就有了）”、“新来的员工总是带着旧有的习惯”、“核心人员都在会上了，大家回去推行和执行就得了，不遵守的就扣钱”，大家踊跃发言，引发数千口水。
二、哪出了问题
我想问题争论的实质应该是开发人员的管理问题，管理离不开制度，如果管理出了问题，简单的来说要么是制度本身出了问题、要么是制度的执行出了问题。“新来的不知道规则，不遵守”、“不遵守就扣钱”等等都属于执行。软件开发人员的确是比较难于管理的，记得李开复曾经就谷歌的管理问题表示：“基本上谷歌的工程师是不能管的，只能理”。由此可以看出，以人为本非常的重要，所以我想以前之所以很多制度执行不下去，同简单粗暴的行政执行方式以及含糊不清的检查、惩罚条款有很大关系。
光管不理是行不通的。人工的检查和惩罚强行下推（例如让每个员工对制度签字画押），管是执行下去了，但是却没有理，理就是通过合理的设计防止员工触犯规章。如果不理的话，大批连续加班的员工最后被扣了钱，抱怨连天，紧接着惩罚被基层执行者人性化的包庇了，上级也给予理解。就这样制定的制度等于一纸空文，等待下一次因为规范问题引发的事故到来，然后启动下一次会议-决议-执行-取消执行的循环。
三、不能仅仅管
执行出了问题，就去加强执行的问题，甚至追究责任人。这个想法没错，也对症下药，但是我认为并不是最好的解决方式。管的劣势如下：
1. 执行成本高；
2. 行政处罚会引起抵触情绪，影响工作；
3. 容易造成官僚，影响项目进度；
4. 执行人员可能会徇私，制度失去威信；
当然如果加大投入上述问题都能够避免，但是我想换换思路，加强加强理。大家知道惩罚不是目的，目的是防止违规，让每个人都遵守制度。那么我们是否在罚款前，仔细想过是否有其他改进的余地，既做到不罚钱又保证制度的执行呢。
四、将制度融入到流程中，实现管、理并用
恶性循环的出路在哪里？在交通管理中，为了防止汽车行驶进入逆行车道，隔离带被安置在两条车道之间，这样即有效的执行了制度又降低了管理成本。同样，为了防止汽车行驶混乱，我们设计了左转、执行、右转车道，及解决了问题，又避免大批处罚的发生。那么开发人员管理也可以采用这种经验，例如在IDE启用代码开发规则检查功能，这样没有通过代码检查的项目，将无法编译成功。同时将代码规范检查嵌入到持续集成中，这样即使有人偷偷将代码迁入也依然逃不过持续集成的检验。这样制度得到了彻底的执行，同时又无需占用推行、执行人员的精力，同时避免处罚的大范围使用。以此类推我们可以将很多制度融入到开发流程中，杜绝违规行为的发生。同时这样的理是实时进行的，与开发进度紧密的结合在一起，在项目的最开始就保证规范。
在管之前先想想理，以人为本出发，理的好即能防患于未然，又能保持和谐的氛围。
欢迎大家就开发人员的管理，谈谈自己的看法。

评论

21 楼 java_will 2010-05-11  

个人觉得作为一个管理者，更多应该着眼于怎么培养手下人自我管理的能力，而不是一味的发号施令，或者一味的监督辅正。

20 楼 gurudk 2010-02-10  

非常赞同使用工具，人本来就是容易出错的，使用工具将人的注意力解放出来。

另外，确实需要言传身教，有时候讲太多，还不一对一的交流

19 楼 墓里活人 2010-02-07  

管是约束其行为。
而理则是提高工作效率，能留人才。

管：是制度、是条例、是游戏规则。
理：是谈心、交心、厚黑的施展、而管理者即在戏里也在戏外。

只管不理：虽能迅速见其效，效率增长缓慢，但最后留不住人才。
只理不管：平凡的岗位、和平的年代、缺少激情打工时代。只管不理虽能网住部分人心，但不能涉及所有，过度则有虚而不实。

只有管与理均衡施展：才能达到最佳效果。这里的奥秘只有个人用心观察，细心体会才能升华为宝贵经验，甚至是别人学不来的。 而并非简简单单分配均匀的时间去执行管和执行理。

因人不同，管与理也因人而异：比如李开复说的，谷歌的工程师只能理而不能管。那是因为有些人有“自知之明”知道自己要做什么，我付出多少我就该有多少回报少一分不少，换过来做得不好自己会内疚。对这部分人，行为自己能够约束，所以对其只施其理则有奇效。

18 楼 laojiang 2010-02-05  

"代码走查"是怎么执行的，是人工的检查，还是有工具，设置好了规则直接自动完成检查，对于Java的开发人员来说有1、Eclipse 代码格式与规范2、Sonar 代码质量综合检查3、Checkstyle 代码自动检查4、PMD 代码自动检查等。至于功能上的检查估计用代码走查也看不出来，代码走查的目的是为了能够叫别的开发人员更好的理解自己写的代码，交接工作比较容易。

17 楼 anky_end 2010-02-04  

刃之舞 写道

如果你那思考和分析，最后的制度还是存在罚钱，那就是扯淡跟搞笑！

罚款是很极端的做法，一旦罚单开出，等于宣布，程序员a，你可以走了。
多开几张，老实干活的人也不想再这边干了，即使他可能还是受嘉奖的那位。

16 楼 刃之舞 2010-02-04  

如果你那思考和分析，最后的制度还是存在罚钱，那就是扯淡跟搞笑！

15 楼 spyker 2010-02-03  

主要是代码规范
做对日外包 基本大家的代码差不多

14 楼 former 2010-02-02  

首先，从代码和开发规范的角度来考虑，你所在的公司，是否能给开发人员标示出需要走的“路”。就是说，公司的开发规范、流程、代码结构、风格是否是经过实践得出的、切合公司实际和开发人员实际水平的。如果是，那恭喜你，按这个标准执行吧，新员工中，有经验一般会很快上手；刚工作的，你给他点文档，再教一下，也能很快适应。代码检查工具、行政处罚只能是辅助手段，一般的代码检查工具只能做一些死的检查（我们公司的工具可以检查提交的代码是否按照统一的风格去格式化，但是对于业务逻辑处理的优劣、有没有更优的方法，它是无能为力的）；而行政处罚只能是下下策，在我们公司，如果这个人如果因为代码而被处罚，那他离辞职也不远了。
再来看看这个代码规范的标准：定高了，开发人员适应期长，项目风险大；定低了，不如没有，而且会误导一些新人。这个度需要项目经理或开发经理自己把握。
从我们的项目实际情况来看，我们的没有很先进、很牛、很多技巧的东西，甚至有很多的“反模式”在里面，但是要控制住开发方式，告诉一线的开发人员在碰到什么样的问题时你该怎么做，同时尽量为其提供需要的基础结构，使其专心于业务，而不是整体折腾在代码、规范的口水中。我们最后的结果是，在这样的场景下，开发人员在业务中的口水比代码中的口水多的多，而项目的风险和进度都能控制住，代码的质量在一个可以接受的范围内。
从项目的角度看，跳出开发人员、代码的管与理这样的圈子，给他一条合适的“路”让他走下去，合适的就是好的，多关注项目本身的业务，控制风险是主要的。

13 楼 anky_end 2010-02-01  

chaotian 写道

一蓑烟雨任平生 写道

制度是必须要有的，也应该有考核。
问题是有谁能够做代码的评审？如果没有能力做评审，制度就是虚设，有能力，只要在项目刚开始的时候，每天开会检查代码，一个人一个人的拎，很快就会把代码整标准。
代码写的不标准，可能更多的是开发人员没人教，需要培训。

LZ可以试试我说的，你看那个做代码评审的人，自己写代码的水平怎么样，如果很高，那么先做好培训，然后每天盯代码，有问题就让他改。

能力具备了，考核就要上去，没有什么不能管的，不遵守规矩不在经济上处罚，你有什么办法？赏罚不均，对认真执行制度的人更是伤害。Google怎么样你听他吹，你自己过日子要紧。

在公司七嘴八舌反而让自己想偏了，你的思路简单、清晰，实在佩服。

1.要有制度，制度要合理。
2.要有执行
3.考核即是约束也是激励
4.结合考核赏罚分明

目前最头疼的问题是考核。

    赏罚看什么公司，我的看法是，一般情况下，奖赏易行，惩罚难做。比如做的特别好的员工，你给他物资或者精神上的奖赏，鼓舞作用还是有的。惩罚呢，如果实质性的惩罚，一次基本就能让该员工萌生走人的意思。如果是特别牛逼的企业，比如腾讯之类，该员工能力又一般，进入这种公司自己认知是烧高香的，那么还能让其认真点。否则一般情况，经济惩罚实际推行只会人心不稳。

   考核还是其次的，所谓上下都有对策，没有合适的制度，只有合适的执行者。

12 楼 chaotian 2010-02-01  

一蓑烟雨任平生 写道

实际上开发人员的管理也没有那么难的，你要求他们做什么怎么做，首先你要做到，或者你能找到人能做到，然后就是培训。
言传身教、以身作则。有能力，做的到，就管的了。
有的公司开发人员提升太快，他自己的技术能力还没有达到可以制定公司标准的水平，因为在管理的位置上，所以提出各种想法，出发点很好，就是控制不住。
在IDE里通过技术手段来解决，我觉得不是一个好办法，工具的使用是在手工处理的办法很成熟，不用工作很麻烦的条件下再考虑。也就是我们常对用户说的，业务改善先行，IT工具配合，在手工处理没有解决的情况下，不要考虑技术工具。

恩，结合IDE等工具进行管理只是一个辅助手段，但是它还是有一定的价值的。不能盲目信赖工具，要先有合理并且已经实行的管理解决方案。
工具本身只是为了让管理更高效、但是不能代替人去做管理。

11 楼 chaotian 2010-02-01  

一蓑烟雨任平生 写道

制度是必须要有的，也应该有考核。
问题是有谁能够做代码的评审？如果没有能力做评审，制度就是虚设，有能力，只要在项目刚开始的时候，每天开会检查代码，一个人一个人的拎，很快就会把代码整标准。
代码写的不标准，可能更多的是开发人员没人教，需要培训。

LZ可以试试我说的，你看那个做代码评审的人，自己写代码的水平怎么样，如果很高，那么先做好培训，然后每天盯代码，有问题就让他改。

能力具备了，考核就要上去，没有什么不能管的，不遵守规矩不在经济上处罚，你有什么办法？赏罚不均，对认真执行制度的人更是伤害。Google怎么样你听他吹，你自己过日子要紧。

在公司七嘴八舌反而让自己想偏了，你的思路简单、清晰，实在佩服。

1.要有制度，制度要合理。
2.要有执行
3.考核即是约束也是激励
4.结合考核赏罚分明

目前最头疼的问题是考核。

10 楼 anky_end 2010-02-01  

一蓑烟雨任平生 写道

实际上开发人员的管理也没有那么难的，你要求他们做什么怎么做，首先你要做到，或者你能找到人能做到，然后就是培训。
言传身教、以身作则。有能力，做的到，就管的了。
有的公司开发人员提升太快，他自己的技术能力还没有达到可以制定公司标准的水平，因为在管理的位置上，所以提出各种想法，出发点很好，就是控制不住。
在IDE里通过技术手段来解决，我觉得不是一个好办法，工具的使用是在手工处理的办法很成熟，不用工作很麻烦的条件下再考虑。也就是我们常对用户说的，业务改善先行，IT工具配合，在手工处理没有解决的情况下，不要考虑技术工具。

极为赞同~

我也认为，关键就在于，检查代码的人，自身水平到位，也够认真负责，拎着搞1周2周，基本就合格了。

不过很多提出制度的公司没有这类专职人员搞这种事情。

因为走查代码要求人员水平高威信高，这类人员公司觉得做走查代码又比较浪费。

9 楼 llyzq 2010-01-31  

感觉LZ前面说得都挺对。

可是最后理的措施却觉得可行性不高。

8 楼 fanfq 2010-01-30  

还是我所在的公司比较人性化，管理的很松，但是大家都很自觉。

7 楼 qamer 2010-01-28  

物治必先人治，治物必先治人

6 楼 一蓑烟雨任平生 2010-01-27  

实际上开发人员的管理也没有那么难的，你要求他们做什么怎么做，首先你要做到，或者你能找到人能做到，然后就是培训。
言传身教、以身作则。有能力，做的到，就管的了。
有的公司开发人员提升太快，他自己的技术能力还没有达到可以制定公司标准的水平，因为在管理的位置上，所以提出各种想法，出发点很好，就是控制不住。
在IDE里通过技术手段来解决，我觉得不是一个好办法，工具的使用是在手工处理的办法很成熟，不用工作很麻烦的条件下再考虑。也就是我们常对用户说的，业务改善先行，IT工具配合，在手工处理没有解决的情况下，不要考虑技术工具。

5 楼 一蓑烟雨任平生 2010-01-27  

制度是必须要有的，也应该有考核。
问题是有谁能够做代码的评审？如果没有能力做评审，制度就是虚设，有能力，只要在项目刚开始的时候，每天开会检查代码，一个人一个人的拎，很快就会把代码整标准。
代码写的不标准，可能更多的是开发人员没人教，需要培训。

LZ可以试试我说的，你看那个做代码评审的人，自己写代码的水平怎么样，如果很高，那么先做好培训，然后每天盯代码，有问题就让他改。

能力具备了，考核就要上去，没有什么不能管的，不遵守规矩不在经济上处罚，你有什么办法？赏罚不均，对认真执行制度的人更是伤害。Google怎么样你听他吹，你自己过日子要紧。

4 楼 yymt 2010-01-27  

被管理着~~

3 楼 54五味子 2010-01-26  

ziyu_1 写道

最没头脑的管理的就是"扣钱"

这个比较同意
管理要的是“人心”

2 楼 squall140 2010-01-26  

这文章写得很多

但实在的意义不大， 你这个例子说的太多了