如何用故事设计的方法做需求分析？(2)

其实主线与支线并非固定不变，例如微信刚加入公众号功能时，未必就是一个主线故事，公众号并没有直接满足沟通以及社交的需求，但是却有效的拓展了微信的局限，成功将微信拓展为一个更加全面的社交工具，从而在后来发展为主线故事。

（三）做个小结

基于故事和产品的联系，以及主线故事和支线故事的关系，我便把产品的功能分成了四个等级，其中顶级的产品是我们的最终目标，而二到四级则是我们要去完成的事，便是——需求设计、需求分析与需求管理。

如何评估好故事设计中各个故事的重要程度与优先级

（一）先确定你是否需要这个故事

我每一次构思一个故事的时候，总会先想一个问题，我要把之前想到的一个情节加入进去吗？同样在设计产品功能的时候，我也会去思考一个问题，这个功能是一个需求，我要将其加入到产品中吗？

这个问题换一句话说，就是需求分析了。

关于需求分析，虽然有不少方法论可以参考，但是面对不同产品、不同团队、不同背景的情况下，强行代入方法论往往并不能得到有效的结论。其实从每一个功能确认落地到需求，大致可以分为两类。

从无到有，增加功能

这个分类是最为头痛的。在没有数据验证的情况下，谁都无法保证新增的功能一定是满足用户需求的，此时便陷入了恶性循环：无法确认功能是否可行——不敢第一时间开发——无法满足用户——继续思考功能。最可怕的就是找不到解决问题的方法。

已有功能，完善功能

这是一个容错率较高的需求分类，就算未达预期，因为前提的功能已经满足了用户，那么可以之后继续优化。

第一个分类可以总结为为用户提供了一个待确认的解决方案。这个解决方案可能帮助用户解决了新问题，或者是巩固完善了之前问题的解决方案，我称之为决定性问题。新功能一般承载着拓展产品局限，提升用户好感的重任，如果用户反馈不佳则可视为新功能未达预期，则有可能在之后的迭代中被弱化，以至于成为支线故事。

第二个分类可以总结为为用户提供了提升解决方案效率的方案。这个方案帮助用户可以更加舒适的使用已有的功能更快、更好的解决自己遇到的问题，我称之为效率性问题。效率性问题具象化程度更高，且更容易把握，例如用户界面的优化、操作流程的优化或是加入其他提升用户体验的功能。这一类需求大多在产品步入正轨以后成为产品需求的主力，即从框架建设进入细节雕琢的阶段。

那么我要如何分析提出的功能是否为需求呢？

依然以微信为例。微信的定位是社交通讯工具，那么这个产品的核心则在于社交、通讯这两点。在未加入支付功能之前，微信的定位是十分清晰的，就是一个移动社交通讯工具，而远非现在的工具平台。那么当时的微信加入包含收支的支付功能是否算是一个需求呢？

作为社交通讯工具，加入支付功能其实从表象上与社交与通讯主线故事的关联并不大。因为支付功能无法帮助直接促进社交氛围更好以及提升通讯功能效率。那么为什么依然要加入支付功能呢?

如果微信仅有即时通讯、朋友圈这些常见的通讯、社交功能，那么这个产品依然无法提升差异化程度，容易陷入同质化中。毕竟从当时的情况来看飞信以及米聊也可以加入类似的功能进行竞争。而支付功能除了拓展了工具功能以外，对于微信而言更重要的一点在于加入了收发红包功能。

源于我国特色的红包传统与社交行为相关，而红包的钱从何而来呢？此时支付功能便提供了最佳助力。因此当尚无法定义功能是否未需求之时，可以分析这个功能是否可以回归到主线，有些人会将其称之为闭环思维。

通过以上的分析可以得出结论，加入支付功能是一个可能提升微信社交品质的需求，那么接下去就可以通过灰度测试等功能进行验证了。

增加功能充满了许多的未知性，所以这一点才会让我们望而却步。这些从无到有的功能需要设计者有足够的判断力、经验以及分析能力，但是依然无法完全保证可行性，所以在及时验证通过后方可确认为是一个需求，是否可以列为未来可优化的需求。

针对这类需求的分析，建议如下：

1. 当下需要新增的功能，是否可以回归到主线。如果可以，这个功能对主线的贡献是否显著，若无法确认则可以小范围测试进行验证，切勿盲目大范围开发上线试错，为自己预留调整的空间。
2. 任何人提出的功能需要再次抽象，即问自己两个问题，他为什么需要这个功能，解决了什么问题。因为不同角色总会从当下遇到的情况出发提出一个表象的解决方案来解决当下遇到的问题。而产品设计者需要在这个基础上在提升一下自己的思考维度，发现这个方案之后遇到的问题是什么，比如说当时微信加入支付功能时最佳的辅助对象是发送红包提升社交功能竞争力，而不是建设金融平台。

对于功能完善类的需求，由于已有前提功能铺垫，所以这类需求问题分析起来都会更有把握，试错成本也更低，在此便不多赘述了。

简单的做一个总结，其实以上思路灵感来源于我自己了解了KANO模型后的一些尝试。经常有人对我说，要把问题量化。但是我觉得量化容易让自己陷入一个桎梏，盲目相信数值，忽略使用者的感受，毕竟我们打交道的是人。所以基于KANO模型，对于需求的定义，我整理为以下几个准则：

1. 加入的功能是否能让用户眼前一亮并为他们解决决定性问题。如果是，那么这样的功能需要优先系统性的思考并尽早完善为需求。
2. 加入的功能是否只是帮助用户锦上添花的解决了问题，并未提升效率。如果是，那么这可能并非是需求，只是遇到了一个问题后的感受。如果否，则这是一个较为重要的需求，有效解决效率性问题是产品设计工作中内容占比十分大且重要的内容。
3. 针对不同角色来思考，每次的需求满足范围如何，如果只是解决了极少数人的问题，有必要重新回顾自己的分析历程。

（二）确认每个情节的重要程度与优先级

记得我曾经构思了一个剑侠的故事，我为其构思了精彩的前传，但是前传对于主线而言意义并不大，算是一个补充阅读。后来我便将这个小故事放在了我主线故事之后作为一个补充章节。

不论是产品战略与功能架构设计者，还是以执行为主的执行人员，确认重要等级与优先级是必须要面对的问题。解决这个问题有一个十分有效的方法，就是根据重要程度与紧急程度分为四象限，想必这个方法大家都不陌生了。

（编辑：ASP站长网）