论迭代式开发模式吸纳用户建议的困难度

迭代式开发模型下，假设某项目，对用户体验环节的目的、方法都清晰明确，实际执行过程配合顺利，在产品验证环节，大家提出了N多条建议。

我们遇到的问题是：这么多条建议，能否实现我们用户体验环节的目的？

 

 

答案是不能实现目的，或者延迟到非常延迟，才能实现目的。

 

这和迭代式开发模型和产品开发节奏有关：

在迭代式、瀑布式的开发模型下，所有的需求都是经过一系列流程走下来的，概念落实成为设计，设计分级为架构设计和详细设计，经过多次评审评估，然后进入开发、验证阶段。

那么，在验证阶段提出了N多的用户体验修改建议，这个时候，在本次发布的产品上做修改，肯定是来不及：

A、产品计划不可能在进行较大时间的延期，箭在弦上不得不发；

B、需求的提出，要出发变更流程，又是劳民伤财的大动作，评估下来，成本太大，性价不不高。

所以，针对这个版本提出的N多用户体验建议和意见，几乎不可能在此版本就得到采纳，也就是说，针对这款产品这个版本的用户体验，实际上只是对后续产品才会起到作用。

 

那么，接下来的版本，就会采纳这N条建议和意见么？

往往也是不会，这就是和产品开发节奏有关系。

  

 

如上图所示，在产品设计阶段，通常会出现过度设计，比如一开始规划100条功能——经过产品开发周期，最后发现原始计划的100个需求/功能点，只实现了60个，剩余的40个需求/功能点需要融入到下一个迭代版本中。那么假设在此时，用户体验环节提出了10条建议，同理，也会纳入到下个迭代版本。

下个迭代版本（Build2），本身就有30个增量需求，继承上一版本（Build1）未实现的40个功能和10个用户体验建议，那么就是80个需求/功能。根据需求的优先级，几乎可以肯定未实现功能的优先级大于优化改善已有功能。所以此版本发布时，很可能就是80个实现50，还遗留23个功能和大部分（7个）第一版本的用户体验。

依次类推：Build3会规划45个功能，最后实际发布版本遗留10个功能和5个第一版本的用户体验建议。

以此类推，即使后续的build版本不再做用户体验环节，第一次的N条建议意见，也不可能在下一个版本立刻解决。实际能采纳并改进的时间，在迭代式开发的软件项目中，无法预估。

 

所以，即使能够在目前的用户体验环节，提出一些高质量的建议，在迭代式开发模型下，也不会达到最开始预期的结果：提高产品易用性，提高客户满意度，提高产品美誉度等等。因为最终建议被采纳的周期，相当漫长，甚至完全不可控。

这是迭代式开发的一个模型问题，所以在强调用户体验和感受的项目，多是采用敏捷模式。当然，对敏捷模式的理解不一致，也会导致很多似是而非的敏捷，这是另外一个话题，在此不表。