由自助餐想到软件团队的管理
刚才和同事一起去吃了一顿自助餐，席间谈起一个关于自助餐厅的话题。说自助餐老板为了赚钱，往往会试图减少供应的食物量，比如对昂贵的食物用小号的盘子，又或者取肉的时候限制一次只能拿2盘，其实这样的自助餐厅反而并不赚钱。因为道理很简单，在空空如也的餐台前排队取食的顾客自然形成了竞争关系，不得不花更多的心思去“争夺”食物；另一方面，顾客们显然会对自助餐厅的做法表示不满，而发泄不满的最好办法就是“把花掉的钱吃回来”——不惜把自己吃撑也要和餐厅老板赌气！
聪明的自助餐厅会堆积大量的食物，甚至是最昂贵的食物也一样在餐台上堆积如山，还不等顾客吃完就继续上菜。这样的效果看起来很奢侈，但是食客们即没有竞争的抢食心态，又不会心怀怨恨地去和自己的肠胃赌气，所消耗的食物其实会更少。
可能是因为最近恰好做了一段时间代理Scrum master的缘故，对“管理”上的事情开始变得敏感起来了，于是不由自主的就把自助餐厅的管理手法套用到软件开发团队里来对比一番。
我在此之前的几份开发工作在团队管理上基本上都是大家熟知的国情化路线：管理就是制定规章制度然后以此去考核奖惩。我曾经就有一次一入职就让抱着厚厚的《岗位作业指导书》去啃，然后考试上岗。其实各种制度总结归纳起来无外乎就是两个字——扣钱！这应该是很多国内同仁们非常熟悉的套路了！某些时候我们甚至还能听到中层领导们一脸无奈的反问道：“（这事/这人）不扣钱还怎么管?”
当年我遇到领导这种反问句的时候，感觉是无力的。因为我象那些领导们一样没有答案！
不过，现在，我感觉我似乎可以开始寻找并且慢慢接近这个答案了！
正如前面提到的自助餐厅，当你面临竞争压力的时候，你所能做的肯定是为自己争取更多的利益——比如去抢夺食物。而你在和公司（罚款）制度赌气的时候，可能考虑的会是找到制度的漏洞并为己所用。
你会发现，你并不爱你的工作，那只是一个赚钱的手段。
你会认为工作是在为老板“卖命”，而不是自己的“事业”。（或许这也是国人热衷于创业的原因吧，纯属猜测，基本靠谱！☺）
而造成你这些想法的公司制度，其实不是正好和自助餐厅那些吝啬、苛刻的营销手法一样适得其反吗？如果~~如果没有这些规章制度，给员工们自由的空间——正如给食客们充裕的食物资源，情况就会完全不同了：
就像厨子都希望别人夸自己的菜烧得好、裁缝都喜欢别人夸自己的新款衣服做的漂亮。其实每个人都是有自己的追求的！
当外界对你的限制（比如规章制度）变小甚至没有的时候，（合格的）员工们会考虑的是什么呢？
显然是如何把自己的工作做好！
一个程序员当然会像厨子、裁缝一样，希望自己的代码优雅而高效，被用户所欣赏！
看到这里，估计有人要笑了，不要规章制度来管理，那员工们还怎么做事呢？那不是要乱套了吗！
对别的岗位，我不敢妄下断语，不过对软件开发团队而言，这套说法倒是真的可行！
我们的CTO（前后换过一次，两位都是瑞典人）从来就不在岗位职责以及如何做事上对我们指手画脚，也几乎没有给我们下发过任何成文的规章制度，但是我们公司三个开发团队运作的基本没有什么大毛病，所谓的“乱套”还真没发生过！（这里说“几乎”是因为确实有一个成文的值班制度，但仅此一个）
有时候管理就是一个这么神奇的玩意！
好了，也没什么必要卖关子了，其实神奇的地方就是前面所提到的：给开发团队以自由的空间，他们会自己好好用心做事的——中国话说就是“仓廪足而知礼节，衣食足而知荣辱”——当食客们无需抢食的时候，他们要做的是如何保持风度、体验美食；当程序员们没有行政压力的时候，写出更好的代码恐怕是最有可能的追求目标吧！
当你读到这里，我不得不承认，我其实悄悄偷换了一个概念：我们的团队在做事的时候，其实是有很多很多“制度”的。不过好在这个概念偷换得不算太大，因为这些规范我们开发过程的“制度”，没有一个是我们的领导制定出来的！这些制度的制定者、执行者和被约束者，其实正是我们团队中的每一个人。
具体我们是怎么做的呢？
这个问题不难回答，不过就是套用了Scrum敏捷开发价值观“团队定期地反思如何能提高成效，并依此调整自身的举止表现”
我们的团队在每一个开发周期结束之后（一周或者两周）需要进行反思会（retrospective ），我比较喜欢把它称之为忏悔日。在会上所有团队成员都需要进行反思，这时候除了极具自我批判精神的团队成员之外，大家一般都会把矛头指向其他人。如果你在这段时间做过一些让同伴不快的事情，那就要小心了哦！（坏笑中）
反思的结论会被总结起来，成为这个团队的“制度”贴在墙上。目前我们Team的制度挂在墙上大概已经有三张A4打印纸了，规则不可谓不多也。但是在执行这些规则的时候却不会有人有什么怨言——因为任何人都参与过这些规则的制定过程，任何人都知道为什么会有这条规则。比如下面这些是我今天刚刚主持的一场忏悔后制定的规则：
|
l Allocate time about old bugs list. 对未处理的旧bug维护一个评估表。 l Set some UI rules for all teams.（Game Team do it first） 所有团队应该使用一致的UI界面设计 l Allocate 20% time off for on-call developer now, and change the value as average in future.值班人员的正常工作量减少20%。一段时间之后将此比例更改为平均值。 l Whose bugs who fix should be faster, if you know whose it is.谁的bug谁修复（如果知道是谁写的）。 l Small defect need to be task/story if that need more than 0.5 hour to fix. Because QA would know there is something need to be test with task note.任何超过半小时的缺陷都需要写成task或者story，因为这样qa才知道有东西需要测试。 l Full Integration tests before make a task as “finish”.完成一个任务前，需要全面的测试之。 l Keep API method clear and simple.API方法需要保持简洁。 l All stories in backlog need to be estimated. All team members do that on every Thursday.每周四评估backlog里面的故事，所有故事都要被评估。 l No-planed refactor should be a task and one test task for it.计划外的重构需要被作为一个task来完成，并且为之加一个测试task。 l Pair work with new comer.和新团队成员结对工作。 l Bugs list on A4 paper is better than note paper.在scrum板上的bug用A4纸张比便签纸好。 l Discuss test cases when design meeting; discuss bugs after scrum meeting.设计会议的时候需要讨论测试用例。Bug在scrum会后讨论。 l Ever bug need Integration test, one at least. 每个bug都需要加至少一个集成测试。 |
在上面的示例里，大家不难看出，如此琐碎的细节，应该只能称之为“规则”而不能算作是“规章制度”。而且，每个团队会因为不同的工作内容、工作性质和工作方式而得到自己不同的“规则”。所以相信大家应该可以原谅我在上面偷换概念的行为了吧！
实际上，团队成员自主创造规则，并遵循之，这样的工作效率以及工作成果远远好于拿着公司成文的《XXX岗位作业指导书》来指导工作的成绩，尤其是对软件开发这样的创造性工作而言！有了宽松的工作环境，加上适当的职业道德，一个团队就可以“自维护”并且逐步完善——这是我从外国同事那里领悟的，用来回答“（不扣钱）还怎么管事/管人”问题的答案！
不过有了这个答案之后，我又不得不面对另一个尴尬的事实：很多中国人还真的是~~很没有职业道德！
曾经有一次在一个Q群里见到一群人在讨论“外企和国内私企哪个好？”这样永恒的话题。其中有人就说，外企好哇，上下班都不用打卡，多自由啊！然后是一堆附合之声，以及狂骂国内私企没良心云云。其间，我插嘴了一句，大意是说，外企也都不是一个规格的，有打卡要求很严的，也有不打卡的。别忘了打卡机还是外国人发明的呢！结果却反被一群人狂骂，还被不认识的人讽刺曰“你是大牛，怎么不把我弄去HP上班呢？”
在这些人眼里，做程序，真的只是一份工作，一个谋生赚钱的手段，不是自己的事业！
在这群人眼里，考虑的仅仅只是待遇的高低，工作是不是轻松，而不是把自己的能力提升，眼界放远！
当一个厨子都不期待顾客夸自己的菜好的时候，他还是厨子吗？
当面对这么一群没有节操，甚至没有正常逻辑的“程序员”构成的从业大军的时候，或许~~~~~~那个令人费解的问题依旧没有答案：“（这事/这人）不扣钱还怎么管?”
2012-10-12 00:11:29
