只有用户能够决定sha手级功能

　　这绝对是一件非常有挑战性的任务。因为，当产品推出之后，只有应用的实际使用者才能判断出哪种功能让人感觉模棱两可。这种不确定性的感觉是非常可怕的。启动一个互联网项目需要很多投入，包括时间、资金、人脉，还有精力。而我们希望用户会喜欢的那些功能，就是sha手级功能。

　　但是，我们也无法确定哪种指定的功能会成为sha手级，初创公司往往会增加多种功能，即使其中一个无法成为sha手级，他们也希望另一个有可能成为。他们这么做，是一种降低风险的战略，但是实际上，往往无法达到预期的目标。

　　为客户量体裁衣：用户喜欢简化。他们喜欢App应用和网站能够被轻松理解，如果他们可以明白自己可以从网站上得到哪些益处，他们会觉得非常自信。

　　如果网站或应用设计的非常复杂，用户会觉得可用性非常差，而且很容易让他们感到不舒服，更让用户产生挫败感，太多无法使用的功能其实是非常不利的。

　　一些使用技巧不能为用户提供一切，这些技巧应该为用户提供他们真正需要的东西。

　　项目负载过多功能是非常致命的：你的用户会让你知道他们还需要些什么，然后你就会知道哪些是必要的功能了。

　　那么，如何知道哪些功能是必须的，哪些又可能成为sha手级的功能呢?

　　FUV(Feature Usage/Value)：功能用途/价值评级

　　首先，你要列出所有你不确定的功能。

　　如果你的项目是关于问题追踪，你就会知道“打开一个新问题”是一个必要功能。这个项目如果没有这项功能是不行的。

　　事实上，要专注在一些不断产生怀疑的功能上。如果你无法确认某一功能是否关键，那么就把这个功能写在那个名单上。

　　其次，根据以下两个标准给每一个功能进行评估并评级：

　　有多少百分比例的客户可能使用它?

　　它给用户会产生多少价值(评分范围从1到10分).

　　对以下因素要特别注意，因为可能会影响你的评级：

　　用户群细分。不同人的目的，需要，以及动机都是不一样的。这导致了同一系统会有不同的用途。

　　项目经理使用问题追踪系统一定和他的客户，或程序员，或设计师完全不同。项目经理或客户可能会把大量时间花在创建新问题上，而程序员的时间则大部分花在了了解问题并更新问题状态上。

　　考虑系统的潜在用户是非常重要的(通常是以用户“角色”的形式)，而每个用户可能使用系统的不同方式也同样重要。最好的办法，是把每一个角色的系统使用流程都能走一遍。

　　一项功能的价值贡献。这往往是最大的障碍。我们倾向于和投资人坠入爱河，特别是当我们认为自己的发明会成为一个sha手级功能的时候。

　　但是，如果这个功能真的有价值，我们该如何表述呢?

　　问问自己和团队：如果没有这个功能，会发生什么呢?如果系统没有这个功能，用户会知道吗?他们会注意没有了这个功能吗?这个功能很容易学会，并很容易使用吗?这个功能会被定期使用吗?

　　一旦你在怀疑清单对所有的功能都评级以后，下一步，就是建立一个图表，把这些功能使用比例和价值评级画在图上。

　　现在，是时候决定你的功能价值政策应该是什么样子了。一个经验法则是，一个功能应该让至少50%以上的用户感到有用，而且其价值评级分数至少在5分以上(总分10分)。

　　这条法则实际上范围是非常宽泛的……如果你认为一项功能对用户越重要，那么使用百分比的门槛就要越高。

　　你越认为每一个功能都需要变得出色，那么你的价值评级的最低分就要设定的越高。

　　在图表上标注上你的最低评级，如图所示：

　　这个图表非常清晰的显示出那些功能应该被包括。如果某一功能位于黄色区域------就选它们吧，而其他区域里的-----下次如果运气好，就再选吧。(当然，如果事情发生变化，把你最初的评级适时的重新评估一下也是个明智的选择)

　　确定sha手级功能

　　读到这里，你已经得到了一些如何识别sha手级功能的形象化指导。

　　注意上图中右上角的绿点，那代表了一项功能有近100%的客户使用了，而且他们给这项功能的价值评级达到了满分10分。可以肯定的说，这就是那个最配得上叫做“sha手级功能”的功能了。

　　当然，这个功能不可能经常让你发现。在那些案例中，那些接近完美评级的功能实际上都有可能成为sha手级功能。

　　最后，注意在左下角底部的那个红点，这个级别的功能，就像是初创公司sha手，所以要确认永远不要让这个功能出现在你的项目之中。