上一篇杂七杂八的说了说软件项目的问题，这一篇说说码农本身。最近事情一直比较忙，没来得及更新，直到刚看见公司代码里有同事在头文件里加了一个函数和.cc文件的一个函数实现的功能一模一样，甚至代码都完全一样，可是这哥们就这样随心所欲的增加了代码的重复，实在是无语。感慨之际，迫使我今晚把这篇文章赶出来。上次还有评论说，软件的管理不是要非人化，而是相反，应该更加人性化。我个人的理解是，项目本身的设计，实现，和测试应该尽量减少对人为主观因素的依赖，对于对开发者的管理，那必然得人性化。好了，不废话，开始。
作为管理者，如果一件事情（大到一个功能，小到一个bug）没做好，那么我们应该怎么看呢？比如上面提到的问题，一个软件工程师，无视已有的代码，直接添加了一个实现功能一模一样的甚至代码完全相同的函数，我们怎么办？把他直接叫过来骂一顿么？出了问题，直接劈头车脸的责怪，绝对不会解决问题。
我以为，我们首先要想两个问题，是他不能做好么？还是他不想做好？有的人会说，我去，这么简单的事，怎可能是不能做好，必然是不想做好，还用想什么。其实不然，当我们把这件事拿到一个大的项目中来看的时候，就存在各种可能性，这也就是我们要做到人性化的地方。当一个人不能把事情做好，可以有两种可能性，第一是没时间做好。当项目非常急，客户等着要，老板一直催，甚至订单就在那等这个项目的时候，软件工程师承受的压力其实非常大，生怕由于自己影响公司的销售，因此在迅速完成项目并紧锣密鼓的测试的时候，很多人没有心情静下心来去看看已有的代码，这么简单的东西，随手就写一个，赶紧把任务完成绝对占据他的最高优先级。如果遇到怕脑袋的经理，随便的就答应销售甚至客户，根本没有仔细考虑工作量（原谅他吧，因为如果说开发者眼里重要的是项目，那么他眼里就是如何尽快把项目变成利润），那么这种情况应该经常出现，尤其是在小公司，这种情况更常见。如果出现这种情况，就该管理者本身进行反思一下，是不是有点不切实际了。
一个人不能把事情做好的另一种可能性就是技能不够。有一句话说的非常好，五年的工作经验不能与一个技能用五年。在工作中，很多人觉得自己在开始的时候，进步非常快，但是越到后来随着对工作环境的熟悉对代码的了解越没什么进步，甚至停滞不前。把手头的工作做顺手了，按部就班的就能完成工作任务。但是很少有人去仔细看看自己以前的代码哪里写得不好，那些问题考虑不周，有那些方法太笨，自己后来有没有为这些不好的地方学习，现在有没有更好的方法实现，更很少有公司会对员工不断进行培训，增加员工的技能，是员工更加高效的完成任务。作为管理者，如果员工本身没有学习，就更要经常地组织一些学习交流培训，让高级工程师讲讲他们的项目的设计，讲讲他们代码中用到的算法，设计模式，通信机制，以及遇到的问题等等，这些对初级工程师的成长非常有帮助。因此，当一个人不能把事情做好的时候，管理者应该首先反思自己是不是对任务量估计不足，定目标定得太草率了。其次应该反省一下，团队的水平是不是长久以来都停留在某个水平上，这就提醒你需要对你手下的兄弟培训了。当然，作为码农，也要有一颗成长的心，愿意不断的学习一些新东西，看看书，温习温习算法，这样才能干五年就有五年的工作经验，而不是一个经验用五年。仔细想想，一个经验用五年，是多么悲哀的一件事啊。
如果不是那哥们不能做好，而是他就不想做好，那该怎么办呢？有人说开除他，都TM不想干了，留着也没用。其实这一点也可以分两个角度来看。第一就是外因使得他不想干好，比如公司对项目的要求本身就不高，而且团队中大家都这样，随便干干就得，干得太认真也没啥用，领导也看不到，谁干的多干得快谁涨工资多，对自己要求太严没啥好处。作为码农，对于写代码是一件良心活，我深有体会，把qa混过其实不难，但是要把每一点都做得很好，难度很高。这种情况下，管理者应该及时察觉那些平时平时做事认真写代码却蒙混的人及时找他们谈谈，看看是不是自己忽略了很多人倾注在代码的心思，同时看看是不是项目中的标准太低了。
简单的说一个例子，对于同一个任务，你去问两个不同的人，你多长时间能做完？两个人很可能给出的时间差距很大，不要因此就断定一个人在跟你磨时间，而要多问一句，你说的做完的标准是什么？很可能你就听到一个人说，完成所有的功能，并对每一个功能点构造测例通过这些测试，并考虑可能出现的异常情况边界情况以及对它们进行处理，而另一个人说的是写完代码。这就是在公司没有统一规定时每个人对做完的标准定义不一样。通过这些，其实我们也可以更好的了解一个人，请珍惜那些给出第一个答案的码农。
不想干好的另外一个外因是，和领导有矛盾，比如领导喜欢头脑风暴，员工喜欢深思熟虑，那就就会出现领导觉得员工不好使，而员工觉得领导一点脑子都没有的情况。如果领导深思熟虑，而员工头脑风暴型，那么领导会觉得员工浮躁一点不靠谱，而员工觉得领导畏首畏尾难成大事。此时，作为管理者，首先应该尽显去发现跟自己风格不一致的那些员工，并注意跟他们的相处，因为毕竟你是领导，你是需要琢磨怎么管人的，而他更多的是在考虑项目。如果矛盾逐渐加深，很容易员工离职。还有很多细微的问题，都需要管理者注意，一定要尽量做到知人善用。相信我们都见过有些员工因为不能从事自己喜欢的领域或者自己擅长的领域离职的情况。其实这些都是管理者本身的问题。
对于不想干好的另一个可能性是员工本身的内因，这其实也是两个因素。第一就是对自己要求不高，同时公司又没有一个很高的标准，那么员工自己的惰性就会使得他把目标定在完成任务上，而不是做好任务上。我就见过有的人把自己写完代码的功能直接扔给qa测试，测出问题就修修，没问题就这样。我也见过，有的人在一开始写代码就开始想自己的功能怎么测，在哪里测，用什么方法测，那些地方可能有功能问题，那些地方有异常情况没处理，那些地方可能有性能问题，他把这些一一都记录下来，会在交给qa之前，自己用测例确保所有的功能正确，所有自己考虑到的地方基本没问题，然后再交给qa，让他们帮自己测那些可能自己没想到的问题。对于这样的员工，一个严格的流程和要求，就可以解决问题。第二个内因就是员工的态度不好。这个世界上有人把工作当做一切，就有人把工作当做吃饭生活的手段，有的人真的只想干点活拿点工资，平时过点自己的小日子，有严重的在公司都干自己的事，看看小说，上上网，事情来了凑合做一做，然后继续自己的生活。这部分人我们真的伤不起，如果你很在意团队的一起拼搏的感觉，并且你有非常大的气场，不妨跟他谈谈，改变了他的心就改变了他的态度。要么你就不在意团队一起拼搏，大家就井水不犯河水挺好。否则的话，早点散了吧，为了大家都好。
一转眼又啰嗦了这么多。关于软件的项目管理先就写这么多吧。本来打算把培训，svn，branch，release，测试，bug管理，等等，都写写，但是又觉得太细节了。目前就先这样了，有需要的话，以后再写。