| 有朋友刚刚从程序员提升到经理，面对这次角色变换他有些困扰，毕竟要自我发展出新的技巧去处理新的问题。我仔细回忆
8 年前我的菜鸟经理起步过程，然后在 MSN 上给他建议：每天一会(daily meeting)
99 年 12 月，我刚刚满 22 岁，没有任何管理经验(准确的说我在 21 岁之前几乎是可以用宅男来形容)，拿现在的眼光看甚至还不能算得上一个好程序员。但受某种野心的驱使，我受命领导
4 名更加没有经验的程序员(大三的学生)去进行一个软件项目——该项目最初的代码是在地球的另外一端进行的，没有面对面的代码交接，只是有那么一点儿文档；雇佣方担心我们经验不够，于是还另外从清华大学找了个靠谱的人每周来一次天津指导我们工作；我、指导者、原始开发者也就是架构设计者仅仅是通过
smth bbs 上的站内信件和消息进行日常沟通。
还要加一个限定条件：除了那四个大三学生，我当时也是 part time 做这份经理工作。怎么看怎么会是一个注定失败的软件项目，但该项目在
2000 年 4 月份上线，这就是 eyou.com；而我们最后成功的形成了一个胶冻团队，"邱哥"的称呼就是从那时候开始的。
那么想想能够值得别人借鉴的经验吧：
* 热情。经验不是问题，能力不是问题，兼职工作也不是问题，是那种迫切希望在某个领域取得成功的欲望支持我克服了许多困难，并给团队其他人增加信心。一开始我没有意识到这点，直到
2001 年初，老板让每个员工用一个英文单词来表达自己，我才从自己身上找到 passion，而不是什么
smart、friendly...之类。无独有偶，伟大的
Joel，还有其他人也是这么认为的。
* daily meeting。由于这个项目的特殊性，使得我必须每天和这四个小伙子开会讨论最新的进度和碰到的问题，而他们也很乐意跟我吃一顿免费的晚饭。团队就是在会议讨论和聚餐中形成的；我也慢慢形成了和下属打交道的风格，并巩固了这种工作上人际交往的自信。
不过也是直到这次有人问起，我才感到 daily meeting 的重要性。尤其是对只专注在一个项目(或者说虽然多个项目但是同一个业务领域)上的团队来说，daily
meeting 就更切合实际了——团队所有人都清楚的知道别人在进行什么工作，碰到什么难题以及可能解决的方向。
* daily code review。回忆中最让人惊奇的是，我们居然一直在做
code review，虽然这也是因为项目的特殊性导致的——大家都不在一起工作，而且代码迟迟不能组装到一起，所以我必须一个模块一个模块的检查，当场编译和修改。在这个过程中，不仅仅是我一个人在看那个倒霉家伙的代码，Toshiba
笔记本屏幕旁边还有另外三个脑袋也在研究。
由于 code review，我们的 daily meeting 大大超过了半小时（Scrum 的建议上限），但如果团队规模比较小，每天花一个小时做这项工作是完全没有问题的（假设一个程序员的生产力是
300 行/日，花 10-15 分钟做 review）。
这种每日的团体代码评审可能真的是个好主意：每个程序员每天都要训练如何向大家发表自己的意见；虽然没有
pair programming，但我们很快彼此熟悉代码风格，学习最酷的 shell 和编辑器命令技巧；大家对彼此的工作更加了如指掌；的确可能有人会打哈欠，但注意观察那些对别人的代码也满怀好奇的程序员，他们将会是日后你的好帮手。
写到这里，我决定给我所有的一线经理都申请笔记本，不过好像要等到下半年预算了——搜狐在很多方面都可担得上十佳雇主的称号，但在提高员工生产率方面稍微僵化了一点点。
* 每日集体午餐。如果做不到每日集体代码评审，那这个就是最低要求了。
==========这是华丽的分隔线========
* daily blog。上面的这些为什么我没能早些总结出来？每日三省吾身很重要啊..hehe
Update:
* 更新了一张来自 http://martinfowler.com/articles/itsNotJustStandingUp.html
的照片
* 另外有人说我们的座位都靠在一起，每日例会还需要到会议室去开吗？我的直觉是：需要，一定要有一个正式的会议形式，Same
Place, Same Time——而且每天早上 9:00-10:00 有大把空闲的会议室可用。
| 
