IT外企那点儿事(10)：程序员不是程序

作为一个合格的程序员，往往是能够很好的管理自己的程序的，无论是源代码维护，文档，持续集成，设计模式，架构等，很多都深入程序员的思想中，甚至成为日常生活中的一种思维方式。尤其是对于长期处于纯研发中心，甚至软件园的程序员朋友们，无论是上班还是下班，甚至课外活动，碰到的都是具有相同思维的人群，进而容易觉得好像大部分人都是相同的思维方式。因而当程序员成为管理者后，往往习惯于将程序员当做程序一样进行管理。

然而程序员不是程序，是有血有肉的人，所以也呈现出很多与程序不同的特性：

首先，程序是有确定的输入和输出的，一般对于特定的输入，一定会得到特定的输出，一般规定了输入输出，也就确定了接口，对其中的具体实现不用关心，对于成熟的公共模块，也不用担心其维护，可放心的使用，达到一劳永逸的效果。

而程序员不是，不是任何对程序员的输入，都会带来特定的输出的。对于同样的输入，如任务分配，奖惩制度，绩效考核等，对于不同的程序员，甚至同一个程序员在不同的职业生涯周期，都会有不同的输出。相对来说，程序员职业生涯的早期，多倾向于诱人的前景，更多的发展计划，更多的实践机会，往往老总们激动人心的讲话，能使得他们兴奋不已，他们愿意早早的来到公司，一直到很晚才回去，公司的晚餐，健身房，小食品等，对他们来说是一种很好的吸引力，他们喜欢天天写程序，承担加班才能完成的任务，如果工作量不足，或者不让他们承担足够的项目，会使他们感到失望，没有发展，没有进步。随着工作时间的流逝，很多人有了家庭，甚至有了孩子，所以更加倾向于work live balance，也许是换了足够多家公司的原因，老总们激动人心的演讲已经很难打动他们，即便是加班费，良好的晚间福利，也无法说服他们很乐意的加班，他们大多已经无法像年轻时一样，每天晚上看大量的书籍来补充最新的知识，因而多倾向于从事一些自己熟悉的领域的架构或者管理工作，对于有多年工作经验的人，已经对整个IT行业有足够多的体验和观察，对自己的职业规划已经有相对清晰的认识，因而对他们的激励，现实的物质激励相对比较管用，对家庭的关心也是增强其归属感的方式(比如有的公司会举办家庭成员一起参加的旅游，拓展，看电影等活动)。

管理程序员不应该像使用接口，你给他输入，他给你结果，就实践来讲，一般情况下，没有对过程的良好控制，是很难得到满意的结果的。

成熟的程序是可以花很少时间维护的，而哪怕是再优秀和成熟的程序员，也都是需要不断的去维护其激情和归属感的，不然会出现让你意想不到的事情，因为一个稳定的程序，几个月不动，该是什么结果，还是什么结果，然而一个优秀的程序员，如果没有进行良好的维护，是会比普通的程序员更快的蜕变到最差的员工的。一个Bug，如果优先级比较低，可以将它放几个月不去动它，当几个月后，运行你的Test Case，它还是那个错误，也许还是无伤大雅，然而一个团队的很小的问题，如果不及时的处理，可能会传播和扩散成大的问题，甚至造成一些人再也无法回头，尽管离职的时候，谁也说不出为什么，矛盾究竟从何产生。

程序是可以需要的时候，便调用一下出结果，不调用的时候，便可以视而不见。而程序员却是一个完整的人，也即组织行为学中所谓的雇主雇佣的是一个完整的人，而非仅仅是一双可以编程的手。作为一个完整的人，程序员有兴趣，有爱好，有情感，有丰富的业余生活，所以过生日的时候一份小礼物，结婚时的一个红包，生孩子的时候的一个祝福，情人节的一封邮件，都可以是的程序员在每天枯燥的编码生活中感受到一份人文情怀。

程序逻辑常常是非此即彼的二元逻辑，然而程序员却是具有复杂的社会人。可能是从小受到的教育问题，我们常常处于二元世界，以至当我年龄蛮大的时候，还会听到同龄人在看电视或者看电影的时候，问：“这人是好人还是坏人”。尤其是对于程序员，从事了和二进制紧密工作后，越来越处于非此即彼的二元逻辑当中了。所以管理程序员就陷入了一个奇妙的关系中：程序员作为一个社会人，本身是有各种复杂的心理活动的，但是对于其管理的对象程序，则使用二元的思维方式，从而一旦程序员成长为管理者，但程序员成为其管理对象的时候，也不自觉地使用二元思维。你会下意识的区分好员工和坏员工么？你会因为几次观点不同的争吵给员工打上标签么？你是否不自觉地就会否定绩效暂且不佳的员工的建议，心想，自己的事都做不好，还这么多话？如果问卷调查反馈不错，管理是否就一定没问题么？试图去了解员工行为背后的心理和动机吧，里面可能有非此非彼的另外的世界。

对程序的管理往往使用svn，cvs等工具，因而很多在项目和程序员的管理中，倾向于对项目管理工具的研究，什么scrum，什么project软件，似乎掌握了这些工具，就能够很好的管理好团队。这也是从技术路线初走到管理路线上的lead的一般问题，似乎技术和工具方面的深入研究比较重要，其实对人心的管理更加重要。我们知道，程序工作属于知识性的工作，其无论是工作量，工作进度和工作成果都是相对比较难以衡量的，而中华文化又是颇具弹性的文化之一。所以相同的制度，关键看怎么说，怎么做，则大不一样。所以我们也许会看到这样的情形，如果团队人心凝聚，则员工会将自己的工作安排的非常紧凑，模棱两可的灰色区域也会争先恐后的被解决，甚至自觉利用自己的业余时间来工作；而如何人心涣散，则员工也会变得不那么尽心尽力，使得一切流程都形同虚设。如果你强制规定上下班时间，则员工会在上班的时间增加浏览网页甚至玩网页游戏的时间；如果你要求预估项目时间，则员工会讲时间估计的极其宽松；如果你要求十分详细的拆分Task，使得预估的时间更加可靠，则员工会增长商讨文档，设计架构，设计Test Case，联调等看起来十分堂而皇之，十分必要的任务，让你说不出什么来，而其中下的真实功夫就难以衡量了；如果你把每一个步骤都定死了时间，则很可能牺牲的就是产品的质量了，东西确实作出来了，Demo出来也是那么回而事，但是架构十分易于扩展，代码是否干净，测试是否完全就不得而知，往往等有人离职了，才发现原来一直功能正常的模块是个烂摊子；如果你进行Code Review甚至结对编程，希望能够规避掉这个问题，不仅仅Code Review本身的时间如何衡量(很多Code Review成了一个人给另一个人介绍模块的过程了，大多数能Review出来的结果也就是很明显的错误，或者Code style之类的，其他的就很难说了，如果Code Review时间安排短了，几乎是什么都Review不出来，安排的长了，就觉得很不值得)，而且很大程度上，员工互相买面子的概率要大于给你面子的概率，毕竟你好我好他也好，今天我Review你的，说不定什么时候你还Reivew我的呢，相煎何太急啊；等等等等。所以凝聚人心是重中之重的，越是低level的管理人员，技术流程方面要多一些，越是高level的管理人员，人心管理要多一些，level高到一定程度，就可以通过作秀来争取人心了。

欲凝聚团队的人心，也是一个复杂的问题：

• 首先是让员工看到目标。作为知识性员工的程序员，和一般的机械工人不同，你很难只告诉他们你去做什么，然后就让他们心甘情愿的工作。尽管很多励志书籍讲《NO excuse》，但是爱好独立思考的程序员，总是爱问清楚为什么，才能塌下心来工作。我写的这个程序将来是干什么的？Demo出来是一个什么功能？在整个架构中处于什么位置，底层还是上层，有没有技术含量？整个大项目在公司产品线中处于什么地位？对这些问题的了解程度，决定了其会花多大的心思来写这一段程序。本文会用两节：你的员工为什么不努力；你总是在画饼么？来讨论这方面的问题。
• 其次是民主型的领导风格。我们知道，领导者风格大致分独裁型的和民主型的。独裁型的领导指令性较强，多进行自上而下的沟通，关注行动，而民主型的领导注重分享，双向沟通，聆听。而麦克格雷戈的组织行为学，也分X理论和Y理论，所谓X理论，认为管理者的作用就是对人的强制与控制，所谓Y理论，认为管理者的作用是为了共同目标，发挥人的潜在能力。正如上面描述的一样，由于程序设计工作是极具弹性的，因而对于程序员来讲，民主型的领导风格及Y理论的管理是相对较受欢迎。本文会在以下两节讨论这个问题：好领导和好员工，鸡生蛋还是蛋生鸡？；好员工和坏员工只有一步之遥。
• 再次是良好的沟通氛围。作为一个中层领导挺不容易的，上有高层，下有员工，内有同事，外有客户，你就是一个信息流通的桥梁，如何保持信息的畅通，自然沟通能力必不可少。你在员工眼中是上级的走狗，还是他们的利益维护者？你在高层的眼中，是自己有个独立的小团体，还是忠诚的执行者？你是否了解员工的苦乐？你是否清楚高层的喜悲？你能否完成上面给定任务？你能否顶住上面给的压力？你是喜欢板起脸来做老大哥？还是和员工亲如兄弟？这些都无不充满着矛盾。本文在以下两节讨论这个问题：上情下达易，下情上达难；左右逢源，还是左右为难？
• 再者，没有规矩不成方圆。虽然我们强调人性化的管理，但是良好的规矩，往往能够降低沟通的成本，从而促进沟通的效率和欲望。相信大家都有租房和配电脑的痛苦经历，我们都要像防贼那样防备中介是否侵吞我们的押金，防备配件商配给我们假的零件，从而使得租房和配电脑的过程精疲力尽，最后大家都乐意选择最知名的房产中介和品牌电脑，这在经济学上称为交易成本，也即在相关方之间安排合同或者契约的成本。同样沟通也有成本，你们团队是否在每天不停的开会，而效率低下？是不是员工一听开会就头大？是不是每次讨论都旷日持久而精疲力竭?是不是很多事情都在重复的讨论？是不是你的员工宁可自己单独做一份，也不愿和其他人沟通来使用别人的接口？本文会在以下两节讨论这个问题：当“we are a team”成为口头禅；又爱又恨是流程。
• 在这里值得提一下的是，在对人心的管理中，对员工的情商的管理十分重要。情商，是一个团队良好运转，互相合作的润滑剂。就像一台机器，如果每个齿轮都没有齿，可能是这个团队不够Qualify，然而如果每个齿轮都锋芒毕露，机器也不能顺利的运转，而且磨损会比较严重。齿轮的齿就是每个员工的工作能力，而情商，就是员工的沟通能力，冲突化解能力，适应变化的能力等。而这正是程序员的一大弱点。萨洛维认为，情商包含五个方面：自我认知，自我控制，自我激励，认知他人，与人交际。 在这些方面，程序员多或多或少有自己的问题，本文会在以下两节讨论这个问题：程序员的大侠情结；为什么受伤的总是我。