观察到的需求

2008年9月16日

这是我最喜欢的软件开发引言之一

需求是在开始构建产品之前应该发现的东西。在构建过程中发现需求,或者更糟糕的是,在客户开始使用你的产品时发现需求,是如此昂贵和低效,以至于我们假设任何头脑清醒的人都不会这样做,并且不会再提及它。

-- 苏珊娜和詹姆斯·罗伯逊

这是他们第一版著作《掌握需求流程》的开篇段落。正如常读者可能猜到的那样,我喜欢它与我的同意无关。我喜欢这句话,因为它概括了瀑布模型对需求的价值体系(事实上,“需求”这个词本身就带有瀑布模型的意味)。

敏捷方法违反了这一基本假设,因为它们旨在在构建过程中和交付后发现“需求”。但即使是这种对上述明智建议的轻率漠视,也比现在许多领先网站的做法逊色得多。这些网站通过观察用户在其网站上的行为来探索需求,并利用这些信息生成新的功能想法,遵循以下思路

  • 看看人们试图用网站做什么,并为他们提供更简单的方法来做到这一点。
  • 看看人们在哪里放弃做某事,并寻找解决他们沮丧的方法。
  • 构建一个新功能,看看人们是否使用它。
  • 构建一个实验性功能,并将其提供给用户群的一部分。你不仅可以看看他们是否喜欢它,还可以评估它给你的服务器带来了多少负载。

为了支持这种分析,你需要在应用程序中添加用户日志记录行为,并构建一些工具来分析这些日志。在 Web 应用程序中,许多日志记录都是免费出现的,我怀疑这是人们开始这样做的一个主要动力。但随着日志记录和分析被添加到应用程序中,它们可以走得更远。

我在网上没有找到太多关于如何做到这一点的建议,而且我在实践中也没有听到太多关于做到这一点的讨论。就像很多事情一样,它需要集中精力,花时间构建监控能力,然后利用它来探究如何改进软件。此外,它与传统软件流程(即使是敏捷项目)也相去甚远。

但这里蕴藏着巨大的潜力。每个人都知道人们说他们想要的东西和人们真正需要和使用的东西之间存在着巨大的差异。通过观察人们实际使用你的应用程序的方式,你可以发现软件的实际情况——这可以为你提供比其他来源更直接的信息。因此,我认为更多团队应该考虑将这种方法添加到他们的工具箱中。