How To Ask A Question

项目开发的时候沟通成本总是很高的，现在正做着的项目的人月数经常就在这一问一答之间空耗着，先总结4点吧，下星期找个机会给公司的新人讲讲到底该怎么提问：

1. 你有必要问这个问题吗？

   经常有这种情况，你正在绘声绘色地描述一个问题，突然自己一下明白过来了：“哦哦……对不起，这问题我回去再好好看一下。”扔下一脸茫然的Leader。这到底是要干什么？因为一个人的不认真就要耽误两个人的时间，貌似这种状况还不是很少见。

2. 你能说出问题的重点吗？

   提问时最忌讳一开始就深入到技术层面去讨论细节，这个Table的这个Field是怎么怎么样的，那个控件的那个事件又要如何如何去触发等等——这样做的唯一结果只能是把人给绕晕了：“呃……对不起，你刚才到底要说什么来着?”Leader没有时间去听细节，所以提问最好的方式是三言两语就把问题的核心说出来，然后再视具体需要逐步展开。关于这点，有一个通用的衡量标准：你能不能把问题写下来？能写下来，就能问出来。

3. 你真的了解这个问题的方方面面吗？

   设想一个场景，你去报告一个问题，说这件事方案A行不通，然后Leader说，改用方案B如何？你去试，过一会儿，你又报告方案B也行不通；Leader说，改用C……STOP！这就是最糟的CASE，做项目时间再充裕也不能这么干。Leader不可能对所有问题的每一个细节都能持有正确的理解，很多地方还是需要你自己来判断。在作出提案之前，你应该事先就对各种方案做一个可行性评估，哪个方案可行，哪个不可行，各方案的成本是多少，必要的时候这些都要提供给Leader做参考，“摸着石头过河”从来都是项目实施的大忌。

4. 你做好提问的准备了吗？

   你正在给Leader描述一个问题，突然Leader问，这个操作是怎么定义的？你一下懵了，咚咚咚地跑到自己座位上查相关资料，再咚咚咚地跑回来说这个操作是这么这么定义的；或者，直接在Leader的计算机上打开VSS，在四五个不同的路径下打开七八个文档，然后说这是怎么怎么回事，那个又是怎样。Leader的时间永远比你的时间要宝贵得多，他想知道的只是这个操作在哪个文档的哪一版有着怎样的说明，他并不需要知道这些说明是在VSS哪一级目录下。你要提问，就应该事先准备好，Leader一有问起，你就要能马上拿出纸上文档来对应。

其实珠玉在前，Eric Steven Raymond在他的How To Ask Questions The Smart Way（中译：提问的智慧）已经说得十分完美，我这就算是班门弄斧了。

打不开上述链接的人可以点这里。