毛选第一卷里写道：

你对于某个问题没有调查，就停止你对于某个问题的发言权。这不太野蛮了吗？一点也不野蛮。你对那个问题的现实情况和历史情况既然没有调查，不知底里，对于那个问题的发言便一定是瞎说一顿。

你以为只是那个时代的毛病吗？在公司工作，我也常常看到这样的问题。

每半年的组内计划都会在一月或者六月定好，但计划细分之后的每项工作的时间预估有的时候却是没有根据的。比如“一个客户端这半年我们需要部署到 99.5% 的用户上”，为什么是 99.5% 呢？为什么不是 99.4%？

再比如说我最近经历的迁移数据，要把数据从一个数据存储服务 A 迁移到存储服务 B 上。这个迁移的过程可能旷日持久，并且对于用户本身来说牵一发而动全身–不仅是数据，连同访问数据的代码一样需要改动。这个时候大多数人都没有办法拿出方案来，觉得没有方向，毫无头绪。

如果凡事都以调查为切入点，一条一条的路就会慢慢铺开。首先当然是先去了解目前的存储需求，总数据是 50 PB，每秒的数据读写是 40GB/s，元数据（metadata) 是 100K QPS，然后就可以拿着已经有的数据去和 B 的产品经理开始沟通。和 B 沟通完之后还需要调查什么呢？当然是用户，要亲自查阅用户的代码，然后再制定下一步的计划。但很多时候，大家常常都仅仅知道，我们应该和 B 一起完成这个迁移，而忘记自己先做调查这个事情，预先拟定很多会议，但常常只是浪费时间。

工作之外呢？对于自己的事情，这样的态度会带来什么帮助呢？就以加入开源项目来说，大家都会认为自己是新手，没有办法从一开始就接触到项目的核心开发，于是刚开始加入项目的时候常常问，可以从什么地方入手，或者直接问，你觉得我适不适合。这就是没有调查就开始发言。一旦开始了调查，你就会开始以下几个步骤：

1. 这个 open issue 是在解决什么事情？
2. 看完了相关代码之后，对于围绕问题的代码我到底能看懂多少？
3. 如果看不懂，说明基础不够扎实，我有需要补足欠缺的地方
4. 如果看懂了，现在能理解要解决的问题吗？
5. 如果能理解的话，有哪些方法可以解决这个问题

到了这一步，就可以开始发表看法，跟开发者沟通了，接下来的沟通就会非常有效。对比其他的人，而开发者也会更愿意跟你合作。

另外一个例子是时间规划。到底分配一个小时还是两个小时看书呢？那没有调查过，你怎么能就贸然定下目标每天要看书两个小时呢？对于一本30万字的小说，你一般要花多少时间你自己了解吗？对于一个有效的调查，你需要了解自己每天平均都看多长时间的书，都习惯什么时候看书，然后再定下目标。这个问题我在大学里经历过很长一段时候，应该是最有发言权的了。

这几个例子都是我平时所见所闻，发现自己和其他人做事都还处于非常幼稚的阶段。就拿我自己说，在时间分配上，我的方法是高效的，但远远达不到一个高屋建瓴打通所有做事方法的程度，更没有归纳什么行事准则。毛选一句话就让我大彻大悟。