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

    支持哪些设备

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

    这是一个简单的问题，但是得出的答案却十分复杂。笔者建议努力找到一个产品所有者（PO）项目中有权利做出决策和和相关人员。产品所有者可以从很多资源中发现采用率的分布情况。最佳的需求过程通常是创建软件的开发人员、运行软件的测试人员和为项目出资的客户之间的对话。客户必须权衡时间、特性和设备，对于该客户来说支持或者不支持策略使其陷入两难的局面。

    其他质量属性

    移动设备引入其他“非功能性”需求集合。以下有一些范例：当网络很慢时，软件应该如何运行？当网络存在5%的包损失时，软件应该如何运行？当服务停止运行时我们该做什么呢？我们又该如何测试服务呢？

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

    将答案放到需求过程中可以让企业选择答案，而不是让测试人员声明，或者允许终端客户来找到答案。

    加速失败

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

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

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

    准备好改变

    几年前，笔者的团队接到一个高管打来的惊慌失措的电话，电话中说一个潜在投资人的儿子圣诞节收到了一个iPad，上面的网站看起来很糟糕。于是，公司开始开发支持iPad的应用程序。移动应用需求中的这些改变更像是业务范围内，而不是额外业务，每周都会出现不同形式的新因素。

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

（CIO）