【转】梦断代码 读后感（II） 交流和时间

时间和交流：时间对每一个人都是公平的，对每一个软件项目也是这样。

nearly all software projects require only 1/6 of their time for the writing of code and fully 1/2 of their schedule for testing and fixing bugs.  But it was rare project manager who actually planned to allocate developers' time according to such a breakdown. [p17]

书中援引理论家的话说，最高效的软件团队规模应该是一个人，因为这样就不用交流了。 随着人数的增加，依赖关系的复杂，新手，老手员工之间的不同步，交流的成本会随着几何级数增加。在这里插播一个有奖竟猜：

当Windows 研发团队在开发Windows 2000的时候，团队内部每天有多少封e-mail 交流？ a) 90 b) 900 c) 9,000 d) 90,000

对每一个团队成员来说，他/她不仅要完成手头工作，还有报告自己的进展（通过email 或其他形式），回答别人的问题，了解其他人的进展。每个人的时间都是有限的，那怎么能保证我们在应付所有的交流/沟通之后，能有时间完成“手头工作”？

一个微软的同事前两天跟我说，他们最近没写什么代码，集中精力做“planning” 去了，大家写了很多PowerPoint，改了很多PowerPoint。然后给VP, General Manger 做了两轮汇报，然后根据VP们的意见再修改，再汇报。。。 PowerPoint 的风格变得非常专业和花哨，但是他们仍然没有完成Planning，进入实质开发阶段。华丽的 PowerPoint 中的每一个条目，也需要花PM 很多时间才能写明白，让VP 了解，同时也要花一线dev/test 很多时间才能实现，但是VP，PM 和 Dev/Test 面对同一个条目，他们心里想的是同一回事么？

外部交流

在Chandler 项目中，幸运的是，他们没有这么多VP 要汇报 （真正的VP  -  Al Gore 只露了一个小脸），但是我注意到他们用于交流的时间也非常多。例如

Every day the developers shared a chat room via Internet Relay Chat (IRC) [p139]

1 internal and  4 external email list set up. 

blogs, wiki's...

这些都是花时间的！我看到团队成员还要回复素未谋面的爱好者的各种问题（例如质问他们为何不用某某框架，等等），当然这种透明度也满足了很多人的好奇心，开源，社区的优点么。。。 另一方面，项目管理人员发现他们面对着大量的任务没有时间完成。就像第一章 Doomed 的开篇就说到：

John is doomed,  he has 500 hours of work scheduled between now and the next release... [p11]

团队中其他人也好不到哪里去。那在这种情况下，是花时间继续参加各种讨论，blog，提供Transparency，满足大众的好奇心，还是集中精力把自己“手头的事” 搞定？我从书中没有看到经验丰富的管理人员这时候采取了什么措施。事实上，在产品发布之后，没有证据表明，那些在IRC，Email，BBS 上发了很多议论的爱好者未必真正下载并使用你根据他们的意见开发出来的软件。那这么忙于交流是为嘛?!

事实上，这么多交流和信息并不能帮助人们回答一个最重要的问题 -

What had each programmer accomplished in the past week, and what task was next? [p141]

我的故事 - 在MS Outlook97 发布之后，网上对这个V1 版本有很多意见，也有很多期待。 其中很多用户在 NewsGroup (新闻组) BBS 上发表了强烈的建议，要求Outlook 支持直接阅读 NewsGroup/BBS 的内容，当时只有Outlook Express 有这个功能。Outlook 的开发成员一度认为用户的要求太强烈了，如果我们没有这个功能，可能V2就会很不受欢迎 （几个dev 已经做了一个初始版本）。 但是大家仔细分析后发现，在BBS上强烈发言的，就是那么几个人，因为他们老用BBS，因此他们的需求特别强烈，并且好像声势浩大，但是别的大部分用户根本就不上BBS，因此也没机会表达意见。所以Outlook 决定不做 NewsGroup 的功能，一直到现在。

内部的交流

除了外部的交流，还有内部的交流，随着一个人经验的增多，会有很多其他人来找你，为大大小小的事咨询你的意见。然而你自己也有无数的任务要完成，怎么办？微软的员工对这种情况也不陌生，微软团队允许一些人 “Go Dark”，他们可以关起门自己干活，敲门不答应，不回答一般的email，不参加会议等等。

据说很早以前，BillG 把开发OS/2 API 的任务交给了一个牛人，这位前辈接受任务之后，并没有开新闻发布会，建立email distribution list, 或者QQ 群，而是挂了一个和下面类似的牌子在办公室门外，把门一关，一个人闷头开发去了。

我们知道交流很重要，但是软件不是在QQ 群中交流出来的（当然，有人在QQ 群中交流别人写好的软件），而是一些人一行行写出来的。 这个过程需要集中注意力，避免打扰。在一个 “集市” 风格， “共享” 的开发氛围中，如何能保证关起门来开发呢？