• 2010-08-01

    选择题?问答题?

    版权声明:转载时请以超链接形式标明文章原始出处和作者信息及本声明
    http://www.blogbus.com/dreamhead-logs/71316268.html

    选择题比问答题更容易回答。

    团队有条不紊的进行着开发,突然,一个业务问题出现了,开发团队里没有人知道这个问题在业务场景下到底该怎么解决,还好,我们还有一个叫做“客户”的救星。

    虽然在敏捷软件开发中,我们希望有一个随叫随到的on-site customer,但是,现实往往不如人意。于是,我们决定给客户写封邮件,期望他们解救我们于水火。

    在邮件里,我们把自己面临的问题列了出来,然后问他该怎么办。点下“发送”按钮那一刻起,我们便开始等待他们的回复。

    奇怪的是,几天过去了,一向和蔼可亲的客户却一直没有给我们答复。于是,和他们一起交流时,我们善意的提醒了他们一下。大家都是明白人,客户当然知道问题确实是个问题,但他最近确实忙得没有时间仔细想想这个问题如何解决。毕竟除了和我们打交道,人家还有别的事,这种情况我们也能理解。

    就这样,问题一拖再拖,解决方案似乎遥遥无期。

    这是不是一个让人很熟悉的场景?似乎大家都没做错什么,但问题就这样耽搁着。

    时光逆转,我们再来面对一次同样的问题,又到了写邮件的环节。

    这次我们列出的不只是问题,还针对问题的根因给出了自己的分析,并结合我们已有的了解给出了几个备选方案,分析这些备选的方案的优劣,给出我们的推荐。

    客户的回复很快就回来了。一切顺利的话,他就直接同意了我们的做法,稍有一些情况的话,他会基于某个方案中给出自己的理解,几个回合下来,大路通畅了。

    这不是我的臆造,而是真真切切发生在身边的故事。其实,两种做法的差别只在于我们给客户提供了不同的选择,前一种是问答题,后一种是选择题。

    选择题比问答题更容易回答,客户不需要更多的投入就可以给出回答,而复杂的问答题需要更多的投入,如果和其它更紧急的事情比起来,它的优先级很容易就放低了。对客户而言,他不觉得是这有什么,而对团队来说,这却是一种伤害。

    换个角度来看,谁把有难度的事做了,谁的价值就大。如果我们轻易的就把不经思考的结果抛给别人,对自己来说,省事了,但也容易让人看轻我们做事的能力。而提出有质量的问题,这会更加让人欣赏。

    《程序员》杂志曾经刊载过一篇Danny Thorpe的访谈录,其中有一段是他向Chuck Jazdzewski提问的故事。Chuck对于Danny的问题如是说,“真正令我烦恼的是,当一个人打断我的工作,问的却是通过阅读文档和源代码,或是思考一会儿就能解决的问题。这些问题浪费了我的时间。然而,你的问题常常触及有趣或棘手的话题,这说明你下过功夫并思考了很多问题。我欣赏你去努力地理解问题,而不是指望别人提供所有答案。我永远欢迎你提问题。”

    关于提问,Eric Raymond在《提问的智慧》是一篇很好的参考材料。

    分享到:

    历史上的今天:

    Moco 0.8.1发布 2013-08-01
    内存之战 2006-08-01
    引用地址:

    评论

  • 其实这也是商业环境的悲哀,
    人人都被occupied满了,
    所以你要一点additional的工作,
    就很困难.

  • 现实中还有一种普遍的情况:这个客户其实是有答案的,起码是有选项的,但是出于“责任“问题,他是不会轻易做答的。当你抛给他几个选项后,他才找到”机会“做选项。 我想这种情况是我们更不愿意碰到的:)
  • 我也很欣赏 Danny thorpe & chuck 。也发现有些名人的访谈录有时候比起长篇的报道效果好很多。比如martin fowler在一次Artima Developer的访谈中谈到:重构的实质就是消除重复——简洁、直达重构的核心。