[转]由自助餐想到软件团队的管理

 [转载]

刚才和同事一块儿去吃了一顿自助餐，席间谈起一个关于自助餐厅的话题。说自助餐老板为了赚钱，每每会试图减小供应的食物量，好比对昂贵的食物用小号的盘子，又或者取肉的时候限制一次只能拿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上班呢？”

在这些人眼里，作程序，真的只是一份工做，一个谋生赚钱的手段，不是本身的事业！

在这群人眼里，考虑的仅仅只是待遇的高低，工做是否是轻松，而不是把本身的能力提高，眼界放远！

当一个厨子都不期待顾客夸本身的菜好的时候，他仍是厨子吗？

当面对这么一群没有节操，甚至没有正常逻辑的“程序员”构成的从业大军的时候，或许~~~~~~那个使人费解的问题依旧没有答案：“（这事/这人）不扣钱还怎么管?”