一些建议

 

 

一些建议

 

 

 

A， 积极驱动 胜过 惩罚与制度

“要想当英雄，就喝白兰地”

                         ――爱尔兰谚语

很多企业都有自己的制度，制订企业制度了为了方便管理，体现企业文化，维持一种雇佣公平。任何制度都脱离不了奖罚。奖励当然是好的，是积极的；惩罚则是为了维护制度的尊严，形成体系，惩罚是不可或缺的。但是惩罚太多或者不当则会打击员工的积极性，损害制度的尊严，让制度变成刻薄的手段。

在公司，经常听到某某事情不能完成或者不能按规定执行要扣钱等等的说法，比如让程序员必须自己编写单元测试代码的事情。其实在普遍的环境中（包括国内的很多软件公司），程序员都没有编写单元测试的习惯，但是程序员自己编写测试代码是一件积极，主动，且能保证开发质量，节省开发成本，减轻后期整合与测试的好事；另外早写测试代码可以早期发现代码的缺陷，减少系统耦合度。然而很多程序员都没有这样的认识，如果大家对这件事都没有清晰客观的认识之前，无论是鼓励还是惩罚都是很苍白的。

在最近3，4年里，由西方国家传入的“敏捷软件开发”（Agile SoftWare Development）技术的核心XP（极限编程）的核心组成就是“测试驱动开发”（Test Driver Development 简称 TDD），这种思想大力倡导测试的作用以及带来的好处，敏捷发起者们用了大量的事实和实践告诉开发者，如何做单元测试，如何让测试成为开发的一部分，以及如何用测试提高代码质量，早期减少Bug，早期发现缺陷。如果大家对测试驱动有个客观，科学的认识之后，相信每个人都会做的很好，因为没有一个开发人员会拒绝良好的开发方式，产出高质量的程序。

一般程序员们会认为，测试单元的编写应该是测试人员去做的事，另外很多程序员都没有接触过编写测试的方法和工具，所以他们比较抵触做测试，甚至拒绝这样做；而测试人员认为，这种事理所当然是程序员的事，所以测试人员的测试主要停留在功能测试的层面上，而不能深入影响软件的代码去测试，测试人员大多数没有编码的经验也是导致测试人员不能进行代码测试主要原因；最终的结果是这部分的工作没有人去做。给整个项目带来的后果就是测试任务加重，很多问题不能早期发现，程序员无休止的修改Bug，修复的bug带来新的问题，测试人员的耐心也遭到了极大限度的考验。在这样不断的往返中，导致项目延期，增加项目成本，甚至是项目失败（这种失败是不能如期发布或者是客户拒付项目酬金等结果）。项目团队随之陷入了失败的阴影里，大家的积极性和活力也被一点点消磨掉。

回到小节的题目，我的意思是积极驱动比起惩罚和制度更有价值，因为它可以从团队成员的内心深处激发责任和热情。但是积极驱动的背后是需要做一定的工作，这些工作就是给他们最科学和客观的认识，让他们了解到测试的好处，或者了解到努力工作的回报。

总之，制度是服务于企业的发展，是为了规范团队，为企业和团队带来可以遵循的依据；但它不是根本。企业的根本是人，无论是奖罚制度还是其他，只有让一群来自不同地方不同知识结构的人在同一个价值观的驱动下，热情，积极奋发地努力于同一个目标并最大限度地创造价值才是根本的。

 

 

B， 每个礼拜“停电”两小时

“淡泊明知，宁静致远”

                     ――诸葛亮

有一天早上上班，到公司之后发现办公室出现了局部地区“停电”的现象，大家在说一些轻松的话题或者各自看一本书。我选择了发呆和看书，我发现这段时间看书的效率是我最近看书效率最好的时候，思考问题的效果也是最好的。不过我说的主题是，那段时间我在不急不躁中安排了当日的工作计划，然后觉得心里很平静，很轻松，如果这段时间我们大家坐在一起，讨论项目的一些问题，随意的讨论，应该会有个很理想的效果，当然我不是说随意，也不是说停电是好事。 如果每个礼拜我们大家抽出1，2个小时的时间一起讨论项目的进展（不单单是具体的问题），反思各自的工作方式并进行交流，或者可以让大家畅谈一些技术话题，或者其他话题。这或许比我们偶尔因为某些技术困惑或者工作方式的古板而导致在发呆中度过的时间要划算的多。同时我想到了敏捷软件开发中提到的一个原则：“每隔一段时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。”

如果公司将其列为企业文化建设的一部分，可以称为“团队停电时间”、“团队休整（修整）时间” 或者“团队思考时间”

 

C， 狼的神话

“One World One Dream”

                     ――北京奥运会理念

很多谈管理方面的人都愿意谈“狼”的精神，因为狼是最团结，最注重团队战斗的动物。这确实可取。因为一群狼出击，少一两只不会造成影响，多一两只，它们能迅速进入战斗，不需要多少磨合。这种天生的统一是因为它们有共同的目标，如果用企业管理的话说就是有“一致的价值观”。

很多软件开发团队，因为流失了个别人员会造成项目的延期，甚至失败。这也是很多企业头疼的事。如果一个团队中，流动个别人员不会对团队造成影响，那么这肯定是一个完整，良好的团队。当然这说起来很容易，做起来就不一定这么容易了。

我借鉴敏捷软件开发中的思想，那就是“让每个人都参与到项目的每一个部分”。而不要让个别人掌握一个项目的核心或者由个别人来完成软件的架构和设计。或许很多人因为，一个项目团队完成架构和核心代码肯定是个别核心的开发人员，但是这种做法的风险是很高的。其一是如果这个别的核心人员有异常情况（请长假或者辞职甚至其他原因）会导致该项目的停滞，延期，甚至是失败。这样的例子应该有很多；其二是没有一个人的想法是完美的，如果设计出自一人，那么缺陷就是这种设计很难做到最恰当。因为团队的力量大于每个成员力量的和。

我见过最糟糕的做法就是，负责一个模块的程序员不知道其他业务模块的代码，很多可以重用的东西最后变成了，各自为战，大家各起各的炉灶。导致程序冗杂，缺乏一致性，扩展性和灵活性。

关于团队协作敏捷软件开发倡导的一条原则中这样描述：

“最好的架构、需求和设计出自于自组织的团队”。

极限编程实践的“编码标准”原则这样描述：

“系统中所有的代码看起来就好像是被单独一个――非常值得胜任的――人编写的”。

 

D，激励和勇气

“报告长官，没有任何借口”

                        ――出自西点军校

《英雄无敌》是我最喜欢的一款游戏，如果一个英雄PK时的“士气值”低，会丧失很多攻击机会，反之会赢得很多攻击机会，加大制胜的可能。熟知历史战役的人一定知道，士气是影响战争很重要的因素之一。

团队的“士气”同样会影响一个团队的成果，项目质量以及成败。

勇气是影响执行力，以及工作质量的重要潜在因素。在软件开发过程中，很多程序员有这样的坏习惯，如果一段代码几乎没有用处了，或者他想到了更好的方式，但是鉴于删除原有代码的“风险”或者繁琐（造成繁琐最大的可能是，牢固，僵化，粘滞的设计带来的）而放弃“改变”，这样的事情积累到最后可能代码里到处会充满了“垃圾”，一个最初看来有点臭味的设计，在需求不断改变的情况下，程序员舍不得修改甚至放弃这段代码，最后导致代码臃肿，僵化。最后当客户说，这里我还需要一个这样的功能，程序员会恼火的说：这会影响我的设计，会让破坏我的设计。

XP的四大原则之一就是courage（勇气）。这种勇气是面对困难，改善陈旧习惯，提高生产力的心理铺垫。

“激励和勇气”是团队乃至企业创造力的源泉。

 

E， 美味的午餐

“饭已ok，下来米西”

                     ――赵本山

如果一个员工早上来到公司之后老想着，“我的保险怎么还没有办下来？我的合同要到期了，人事怎么还没找我谈？上个月我的工资算错了，该不该找财务说呢？”等诸如此类的问题的话，我想一定会给他的工作积极性，工作热情，态度，以及效率带来负面影响。如果员工说：我不会担心“午餐”，这里很温馨，我愿意为这里效力。这是一个有吸引力的地方。那么这个企业就真正突出了人性化的管理。

 

F， 不断成长

“学无止境”

没有完美的团队，也没有绝对超强的团队，所以团队中的每个人都需要不断学习，不断成长。这样才能不断提高团队的战斗力，增强企业竞争力。国内很多企业还是不愿意花钱培训员工，只希望花最少的代价做最多的事，事实上这很难做到，这是急功近利的做法，团队的成熟和壮大是逐渐培养起来的。对于团队建设我的提议是：

每个礼拜组织1－2次的内部培训。内部培训是非常有效节省成本的，也是最多见的。这种培训最好是每个人都可以参与，每人可以根据自己的实力和兴趣为大家做1－2个小时的培训，促进互相学习，共同提高。中国有个成语叫“教学相长”，这是对谁都没有坏处的。同时内部培训也可以在技术总监或者系统架构师等的策划下，针对性的制定培训课题，由技术较擅长者担任讲师为大家培训。同时可以阶段性的将某个项目的设计拿出来做一个评审式的培训。这样做非常利于团队的共同学习和提高。

如果有条件，可以每1－2个月请专家级讲师做相关技术培训。这样的培训适合团队的共同需要，如某个开发工具，某种先进的开发技术，大家都不是很了解，但是确实对大家有帮助，对企业的技术路线，战略有帮助。那么可以花钱请专家为大家做培训。这种投资是一种可持续的双赢模式，首先团队成员从中学到了东西，满足了团队成员的学习心理（这是保证团队成员稳定的一个有力因素），同时提高了团队的开发技能。

G，拥抱变化

“变化才是永恒的”

无论是客户需求还是开发技术，无论是市场竞争还是策略方针，都是变化的。拥抱变化是一种心态，它映射一系列可操作的行为。

对于一个缺乏经验项目管理者来说，创建一张优美的pert或者Gantt图并挂起来是很有诱惑力的，他们觉得这张图赋予他们项目控制的权力，同时可以跟踪单人任务进度。但是随着项目的开发，客户增加对需求的认识，图中的某些任务会变得可有可无。图中会有新的东西加入，此时这项计划会遭受形态上的改变。越到后来越没有人去关注这些图。

较为良好的做法是：为下两周做详细的计划，为下2个月做粗略的计划，再以后的计划就可以更加粗略。这样就保持了良好的灵活性。计划不是不变的，因为计划是预测的，不是实际完全可以严格做到的。

 

H， 可以买到文化吗？

公司的书架上有数十本书，但是翻阅的人并不多，而且与工作相关的经典并不多。这里我推荐几本书，因为他们确实可以给我们带来价值。

励志类：

《把信寄到加西亚》

《没有任何借口》

以上两本被推荐为每个企业必备的励志书籍，与《伟大的推销员》齐名共妍。

软件项目管理类：

《人件》

《人月神话》

以上两本书出版20年了，却一直高居该类书籍销售榜，很多专家推荐为“从CEO到程序员必读书籍”

软件开发类：

《代码大全》

该书原名《Code Complete》，是唯一荣获两届软件开发Jolt大奖的书籍，该书第一版发行已经是10年前的事了。专家们推荐为“程序员每年必读一遍”的书籍，书的内容直接指导软件开发的每个细节，阐述如何构建高质量的代码。

《敏捷软件开发－原则、模式与实践》

13届Jolt大奖的得主，是新型软件开发阐述最具价值的书籍，这本书是对我影响最深刻，改变最大的书籍。

《UML模式与应用》

《企业应用架构模式》

《敏捷项目管理》

《重构与模式》

以上每本书都堪称经典，都是每个程序员值得多读的书籍。从中获取的知识和带来的价值将是书本身价值的N倍。

 

注：这份建议书的部分观点在我任职的上一家公司就形成了，但是遗憾的是我没有提出来。写这份建议，前前后后有3个月时间了，这是第3份，也是我最满意的一份。本来作为一个普通的开发人员直接向上级提出建议是底气不足的。但是我确实地看到了一些问题，本着积极的心态，也凭着中国的一句古语“言者无罪，闻者足戒”的“怂恿”斗胆向上级提出这份建议。没有多大奢望，如果您能读到最后这几个字就实现我基本的愿望了。

 

                                                                                   888 于2006-12-28