如此“赏罚分明”

　　新官上任的第一把火是什么？有时候首先想到的是如何使用自己的领导权威。

　　某公司规定：凡员工迟到十分钟，扣50元；迟到半小时，扣一天工资……（注意，项目经理及以上级别领导不限）。

　　经常在项目管理的论坛里面看到“惩罚更有效还是奖励更有效”的讨论，其中“惩罚派”占多数，毕竟被管理者都是“浮躁刁蛮的中国程序员”。参与者往往引经据典，分析人性劣根，甚至抨击独生子女的娇惯等等。有论者认为“奖励几百块钱的工资，程序员根本不会在乎”。

　　但是这个问题在很多项目中是彻头彻尾的伪命题，因为往往有一个“领导特殊”的尾巴，尽管不是所有时候都明确的写出来。自外于员工的管理不是行不通，在工业革命时代，在中国现在的血汗工厂里面都取得过成功。但是程序员一般把自己看成脑力劳动者，事实上他们的工作性质确实是这样，需要个人的创造性和热情。假如你确实觉得自己的技术人员都只需要两只手，那么这种所谓的赏罚分明也许不是一个坏主意，毕竟你可以打击程序员的自尊，让他们意识到自己只是多余的垃圾。

　　如果不是的话，那么对于你来说，采用惩罚还是采用奖励并不重要，因为如果一视同仁的要求都不能达到，那么你制定的规则完全是可以随意揉捏的人治，团队将毫无士气可言。

　　遗憾的是，现实中经常出现对下属要求严格，自己却在公司玩游戏的项目经理，10点才来上班的架构设计师。既然如此，又何必劳神去思考赏还是罚呢。无论你采用什么方法，最重要的都是一个“信”字。

　　笔者的建议是：赏罚不是包治百病的良药，赏罚的基础是团队内部的凝聚力，否则任何赏罚措施都无法收到预期的效果。管理者的职务之所以有存在的意义，是因为人类的组织架构需要把多个个体的力量集合起来，向一个方向使力，而不是因为需要管理者和被管理者的两个阶层。

　　那么如何建立这个玄乎其玄的凝聚力？如何让程序员认同团队的目标就是个人的目标？其实我们需要的并不是一只万里长征的铁军，只需要稍稍的信任，就可以解决软件开发中的很多问题。管理者可以问问自己：我会搞特殊化吗？我严于律人宽于律己吗？其实这些问题不是难解决与不难解决的问题，只是想解决与不想解决的问题。

　　当然，血汗工厂的野蛮管理也有它的价值，在那种条件下，野蛮的惩罚同样可以促使工人为企业工作，并且此简单粗暴的方法成本低廉。

发射后不管的项目计划

　　对于我们这个国家来说，计划是一种信仰，在软件行业更是如此。我们从小被灌输的是，所谓管理，就是让甲去洗菜，同时让乙去煮饭而已。

　　开始一个项目的编码工作时，我们往往是先像切蛋糕一样将其分割给几块。项目经理会给项目中的“菜鸟”、“懒虫”各分配一个模块，一个月的工作时间。

　　既然管理者的责任就是制定计划、分配工作，那么如果完成分配，项目经理就可以放心地等到一个月以后了。有些事必躬亲的项目经理会亲自搞一个模块埋头苦干，有的则轻松地看看报纸、上上网，全然不在乎菜鸟在冥思苦想，懒虫在睡大觉。

　　一个月以后，实力不济的菜鸟没有什么有价值的代码，天天偷懒的懒虫更是一张白纸。设想中的模块测试、代码集成无法开始，项目计划书成为离题万里的废纸。

　　如果管理只是指示甲做这件事情，乙做那件事情的话，恐怕这个事情谁都可以做，而且会有很多有“施虐”倾向的人愿意做。难怪人说，天下最容易的事情就是做官了。

　　在任务下达之后，仍需要不断地跟踪任务的进展情况，询问下属是否遇到了什么困难，考虑自己是否可以利用别的资源来协助他。当然其实真正最重要的是查看他是否偷懒！

　　笔者的建议是：有跟踪的计划才是真正的计划。有效的计划跟踪是一个团队可控的基本标志，不仅可以保证任务的进行，而且管理者可以利用获得的信息评估人团队成员的绩效，以及适时地调整任务。

　　可能有人要问了，那不是很麻烦啊！当然了，否则管理者的意义在哪里呢。如果你不知道怎么做的话，首先必须清楚有哪些正在进行的任务。项目工程管理软件可以帮助管理者做到这点，但是必须记住的是，跟踪始终是要靠人来完成的。有足够经验或者热情的管理者完全可以不依靠软件做到，相反有些项目工程管理软件的使用者只是把任务写在软件里面，那么这个软件起不到任何作用——除了浪费一点时间以外。

文山会海

　　当一个团队急于摆脱草台班子状态时，第一次规范化的尝试往往是这样的：

　　早上要开会，布置一天的工作
　　每天要写工作日志，填表格描述工作内容
　　任何工作要项目经理发出书面通知
　　任何代码的改动要提出书面申请
　　……

　　总之都是“要”字诀。

　　这些手段往往可以在项目管理的书籍或规范中找到依据，但是在现实中往往流于形式。我们往往可以发现所有工作日志都是每天一句话：“全天工作”；“没有收到通知书”成为某些人不开始工作的借口；早上的会议，除了项目经理以外，其他人一言不发。

　　如此一来，这些原本试图有效控制团队成员的“管理工具”不仅无法达到效果，而且成为浪费时间的黑洞。可以想象一下，如果一个程序员因为心怀不满而在无人过问的时候偷懒，那么他完全有可能在自己的工作日志上写上千篇一律的“全天工作”。

　　工作日志是沟通和协调的手段，如果没有工作日志（或类似的手段），即使一个有经验的管理者也不太可能知道五名以上的下属员工在做什么。但是管理者如果没有看这些工作日志，或者没有对它们做出反应的话，那么工作日志的意义只是浪费资源和输入时间而已。

　　笔者的建议是：如果管理者本身就不注意沟通和协调，就如我们前面所说的发射后不管的项目经理，那么不管员工的工作日志是写在纸上还是写在电脑里面，都没有区别，管理者需要的是看在心里，并用人脑做出反应。

“我们不需要重量级的管理”

　　“我们不需要重量级的管理”，这是继形式主义之后的另一个思潮，也许可以解释为对文山会海的逆反。对于所谓重量级的管理，国外进行了反思，并有人提出新的项目管理理念。

　　在实践应用中，有时候是这样的：

　　不必开会了，大家知道自己做什么就可以了
　　工作日志不必写了，每星期说一下就可以了
　　任务不用书面通知了，我们面对面沟通好
　　 ……

　　我们把否定一切的条条框框，做为了解决沟通协调的灵丹妙药。现实中，它可能是这样的结果：项目计划回到了发射后不管的状态。

　　项目经理和程序员的争执内容往往是项目经理指责程序员没有做自己要求的事情，而去做了别的，程序员则坚持自己按照了指示，两个人无休止地争论自己没有记错。人的记忆力不是可靠的，假如当初的任务指派是有记录的（纸张或者电子的），那么即使这种事情发生了，我们也可以减少争吵的时间，更关键的是避免了关系的恶化。

　　在此绝非否定所谓的轻量级管理。在一个有序的软件开发团队中，过多的规则很有可能消耗了大量的时间，降低了团队对需求变化的响应速度。轻量级管理的出发点在于减少这些浪费，加快对变化的反应。但是多数的软件开发团队并不是处在条条框框太多的状态，而是处在混沌不可控的状态。

　　继续刚才的比喻。如果一个程序员在工作日志上写上千篇一律的“全天工作”，他是不是也完全有可能在无人过问的情况下偷懒呢。我们不能把问题归结到工作日志上，而要思考真正的问题：为什么他的工作没有人过问？为什么他心怀不满？这个问题的答案往往只能是或者是此人的职业道德存在问题，或者是管理者缺乏沟通能力。然而，不管是哪个，这显然都是很让人难以面对的答案。人总是倾向于选择容易接受的答案：工作日志没有意义。

　　任何管理问题都绕不开人的问题。组织内的沟通协调可以用形式化的依赖制度的方法处理，也可以用自由的依赖人员当面协调的方式处理。两者的极端分别是严格的管理制度（按本子办事，事事申请、批准）和合作伙伴之间的高度信任。这两个极端之间的任何一点都是可取的，关键是在于选择合适自己团队规模和能力的沟通方式。

　　棋手或者习武者从一招一式入门，而最终到无招胜有招的境界。没有“招”的管理者，要么是高手，要么是一无所知。

　　笔者的建议是：不依靠表格、会议等来分配和跟踪任务。这实际上对管理者的人际沟通能力提出了更高的要求，可以取得很好的效果，但不是新手容易做到的。如果自认为还不是高手，那么就应该从简单的管理规范（如晨会、每日工作日志）入手，只要管理者不要忘记这些规章和制度是做为管理的辅助，那么也许有一天可以到不依赖他们的境界。

　　小结

　　软件项目开发中，不只有上面的几个问题，同理，一个项目经理在工作中不只是面临上面的几个小“错误”。希望在以后的系列文章中，同读者共同探讨软件项目管理中的一些问题。