【IT168 技术文章】

 　对于大多数产品经理来说，他们的产品真正发布进入市场的那一天才是他们职业生涯中最紧张的一天。毕竟，只有到了这一天用户才最终会对他们数月的努力，花在设计、编码和测试上的精力，以及为了将不成熟的想法变成实际可用的软件程序而殚精竭虑作出的决定进行评价。对于大多数经理而言，这也是兑现他们（有时候是他们的职业生涯）的奖励的时候。难怪他们会在这一天心跳加速、呼吸加快。

　　但是令人坐立不安的是，产品的发布并不是一个终结；它通常只是漫长的维护、升级过程的开始。一旦产品进入市场，产品经理就需要开始考虑如何将他们接收到的用户反馈融入下一个版本的产品里，以提高可用性、用户友好程度、特性和整体的价值。公平对待他们接收到的所有用户反馈意见是不可能的；决定把重心放在哪些内容（以及忽略哪些内容）上因而成为了一个重要的管理问题。与最开始的产品开发周期（在这个周期里产品经理可以在很大程度上不考虑用户的意见）不同，已经形成的用户群在这场博弈中对产品经理能够做什么以及不能做什么有着重要影响，这进而导致复杂得多的决策和妥协。

　　本文将为这一过程提供一个路线图，提供一些可以采用的简单做法，以保证您接收到的反馈意见能够被正确地按重要程度排序和在下一次产品发布里实现。

　　1．理解反馈意见

　　一个好的产品是一个能够理解用户心声的产品，在产品开发的一开始就对用户进行分析是确保最终产品的满意度保持在较高水平的一种好方法。但是，如果您最初的用户抽样并不具备代表性，或者问卷调查过程不够严谨，那么用户很有可能会碰到问题和表达不满意的声音。这种不满意必须被读懂、分类和加到下一个产品开发的循环中。常见的反馈意见包括对图形用户界面的不满意（缺少工具提示、菜单不够友好）；功能不全；特性无法按照设计要求工作；未能预计的错误；以及安装或者配置失败等。

　　2．剔除违反常理和现实做法的反馈意见

　　一旦理解和分析了这些反馈意见，您就要根据产品的业务要求对其进行过滤，剔除那些不合理或者不可行的意见，这一点十分重要。例如，在财务软件里，在会计科目表里为每个帐户都设立一个唯一的名字是习惯做法。允许设立匿名帐户就是不符合实际的；不论从用户还是从数据库的角度来看，这样的要求都应该有正当的理由被剔除。没有通过过滤的反馈意见应该被归到不同的分类里，例如错误、请求的更改、特性的增强，以及要求获得新功能等。

　　3．为行动内容排定优先顺序

　　在决定哪些内容值得去动手实现之后，下一步就是为它们排定优先顺序了。一般来说，修复错误应该优先处理，以保证能够满足用户的最低期望——产品能够正常运行。特性增强应该具有中等的优先权，进行可行性研究是确定什么是可能实现的和什么是不可能实现的良好的第一步。是否在产品的下一次发布里对某个功能进行增强在很大程度上取决于对可用性的作用、重要性和范围的研究的结果。最后，只是用来提高产品美观的新特性应该具有最低的优先权。

　　4．制定工作计划

　　在这一阶段进行时间效益和成本效益分析对于理解加到产品里的每项变化所具有的价值十分重要。时间效益分析有助于回答是否值得为不同的内容花费不同的时间这样的问题，例如增加一个需要数月时间来开发的复杂特性，或者一个只需要数小时就完成的小特性的增强，或者是某个更改对交付日期的影响。

　　成本效益分析对于以时间和材料为基础的项目十分有用；需要消耗很多资源的小的增强常常要比需要较少资源或者专业技能的大的增强更加昂贵。这些类型的分析都必须在本阶段结尾生成的工作计划里反映出来。

　　5．记录决定

　　这看起来似乎是老生常谈，但是有太多的经理们都忽略了这个问题，所以值得旧事重提。记录所有针对用户反馈而作出的决定是最重要的事情。实现这一目的的最好方法是使用一个电子表格或者公布一个计划工具，以记录将要加入下一次产品发布里的反馈／请求以及它们的优先顺序和预定日期；将要推迟到下一次产品发布里的反馈／请求以及这样做的理由；以及被拒绝的反馈／请求以及原因。

　　您要随着项目的进展定期更新这个表格。如果在未来的某个时候——比如在下一个反馈周期里——您疑惑自己为什么在众多选择中挑选这条道路，那么这个记录将是帮助您清理记忆和避免开发过程中毁灭性死循环的强有力的工具。

　　在这整个过程中，很重要的一点是要记住您的产品是设计用来被人使用的——如果用户不满意，那么您投入的所有精力、时间、金钱和资源都是白费的。在决定哪些反馈意见需要反映在产品里的时候，一定要一直把用户的看法放在心里，运用自己的判断、推理和分析来支持您的决定。这样做的结果将会赢得用户的满意、更好的产品和更高的奖励！