早餐前我们可以发现许多开发移动应用的方法，而这是在考虑的软件与社会、本地和移动定位功能是如何交互之前。找出解决方法的问题就出现了。发现事实背后的关键问题可能会付出很高的代价，花费很多的时间，但却是必不可少的过程。

经典的解决方法就是预先获取支持的产品列表，如果你对设备提出了质疑那就更好了。允许用户自带设备（BYOD）的公司也许会发现支持的列表与用户自带的设备之间存在冲突，并引起新一轮的波动。本文主要关注如下问题：克服移动应用程序需求的“计划悖论”，关注产品的兼容性。

我们支持哪些设备？

通过与桌面浏览器具有相同功能的平板设备可以检测基于网络的移动应用程序，然后通过20字节的文本界面传送到40字节的旧手机上。任何人都可以浏览页面。问题是：“这样做会起作用吗？”以及“应该这样做吗？”

这是一个简单的问题，但是得出的答案却十分复杂。我个人最好的建议是努力找到一个产品所有者（PO）或者项目中有权利做出决策和和相关人员。产品所有者可以从很多资源中发现采用率的分布情况。例如，PO会在其他项目中查看设备，在产品市场份额中查看人口统计资料，或者宽带使用情况，通过客户人口统计来进行理想分割。

产品兼容性：重新检查产品所支持的范围

最佳的需求过程通常是创建软件的开发人员、运行软件的测试人员和为项目出资的客户之间的对话。客户必须权衡时间、特性和设备组合，对于该客户来说支持或者不支持策略使其陷入两难的局面。

还有另外的一种方法：为不同的设备和组织创建多个级别的支持策略。最简单的方法是一个三级的策略:

第一级：PO期望在软件发布之前所有基本工作流都要经过检验。

第二级：该产品组合不会被测试，但是如果有人在产品组合中有疑问，我们将帮助他们解决这个问题，并修复这个缺陷。

第三级：不经过测试。不受任何设备支持。这种级别就太糟糕了。

另外一个常见级别是通过软件支持特定用例，这样可以确保基本功能是可行的，同时可以忽略这些错误。

其他质量属性

移动设备引入其他“非功能性”需求集合。以下有一些范例：

当网络很慢时，软件应该如何运行？

当网络存在5%的包损失时，软件应该如何运行？10%或者30%包损失又该如何运行？

当用户进入电梯时，或者当设备进入睡眠状态时，又或者当应用程序被一个来电中断时，如果软件仍需要持久连接,应该做些什么？

标准的智能手机屏幕分辨率是320 x300像素，但是平板电脑要求的分辨率要更大一些，下一代移动设备可以支持高清屏幕。在额外的空白处用户应该看到什么？

我们利用Facebook、Twitter或者Google的登录系统。当服务停止运行时我们该做什么呢？我们又该如何测试服务呢？

为了把这些问题弄明白，我建议产品所有者、开发人员和测试人员应该召开一个会议，会上不仅仅是要创建需求，而是要创建驱动开发活动的案例。George Dinwiddie召开了这个三方会议，会上探讨了敏捷软件活动中一个被广泛接受的主题。

像生活中很多事物一样，早期忽略这些问题的企业最终将不得不向其所支持的用户回答这些问题。将答案放到需求过程中可以让企业选择答案，而不是让测试人员声明（“这个答案是什么”），或者允许终端客户来找到答案。

加速失败

尽管许多分析师正在预测用户将会使用什么功能，但是其他质量因素可能更具挑战性。实际上，越来越多的公司正在使用“加速失败”的方法。他们发行有限功能的产品，在修复的过程中用户产生抱怨。

如果你的公司想采用这种方法，你需要考虑一系列全新的需求：建立跟踪投诉和使用状况的工具和流程。其中包括有多少人正在使用什么设备，采用高级指标来衡量用户被阻碍时的抱怨细节，用经济指标来估算这些阻碍所造成的损失。

加速失败还算很好；我们完全可以视作是好的，但是一定要计划构建能解决问题的工具，并进行修复。

准备好改变

几年前，我的团队接到一个高管打来的惊慌失措的电话，电话中说一个潜在投资人的儿子圣诞节收到了一个iPad，上面的网站看起来很糟糕。就在那时，所有解释、逻辑以及使用率都意味着不同的含义。我们突然想要开发支持iPad的应用程序。

移动应用需求中的这些改变更像是业务范围内，而不是额外业务。每周都会出现不同形式的新因素。

换句话说，移动需求的最大挑战也许是建立对抗改变的流程。通过预先查看兼容性，考虑非功能性需求，以及建立工具来估计失败程度，虽然团队生产产品越来越迅速，但是却没有满足消费者的实际需求，这不是项目计划目的。