尝试一种新的带人方式

 

最早带人时，没有什么经验，我总是觉得他们做事太慢。慢得让我受不了时，干脆帮他们把代码和文档都写了。一般情况下，也勉强能赶上进度。但这占去了我大部分业余时间，搞我很累，他们似乎也不领情。我也知道这不是办法，他们成长很慢，我也只能干着急。

 

后来开始放手了，把任务完全分给他们，我自己只负责检查，给他们提供帮助。效果还是不好，他们根本就没有设计的能力，代码也写得很烂，只好反复的让他们改。可是在这样烂的代码基础上，根本不可能重构出良好的设计，何况他们甚至还不具备重构的技能呢。没办法，进度压力之下，也不苛求代码的质量，软件好呆能工作就行了。

 

软件中的BUG很多，这也在意料之中，这样差的代码，能期望它们有好的外在表现吗？要命的是，他们的调试能力也不行，一个BUG几天才能查出来，修改BUG的方式也是治标不治本。没办法，我只好接手他们的烂摊子，帮他们DEBUG。

 

有一段时间真的有点厌倦了，觉得还是一个人做事爽，不用操心别人的问题，这样生活得轻松自在。不过，逃避是不行的，后来终于有点顿悟了，我想既然是他们的能力不行，那就对他们进行系统的培训吧。

 

制定了一套培训计划，在副总和部门经理的建议下，在整个软件部推广。效果没有预期的好，不过还是比较可观的。问题在于培训时间比较少，大多数课程都只是泛泛而谈，真正好学的人少之又少。大家都左耳进右耳出，听完了也忘光了。

 

一直在想，如何才能让理论结合实践，在实际工作中学习呢？最近开发一个窗口管理器，一改往日的做法：

 

我自己负责设计，编写文档和框架性代码。在这期间，我让另一个组员，学习相关的相识，理解我的文档和代码，仔细阅读代码和文档，从中挑错，任何不同意见都拿出来讨论，直到达成一致意见为止。

 

最后，当他完全认可我的设计和代码了，就把这些东西移交给他，后续的代码由他编写。而我就去解决一风险性的问题，在前面扫除技术上的障碍，并给他提供一些帮助和指导，编写一些测试程序，检查他所写的代码。

 

我的意图在于，让他研究我的设计和代码，从中可以学习一些经验，由于他要接手后续的工作，就有激情去研究这些代码和文档。我鼓励他提出问题，这样一方面可以纠正他的错误观点，另外一方面他可以指出我所犯的错误。后期，角色反过来，我有机会把好质量关，由于设计和主要的代码是我写的，即使在最坏的情况下，代码质量也不会差得太离谱。