如何了解现有功能背后的需求点

谢星星

2021-10-27

1 评论 1104 浏览 1 收藏 10 分钟

B端产品建设难？缺乏系统方法论？戳此GET一套B端产品从业务逻辑到产品构建的核心方法>>

释放双眼，带上耳机，听听看~！

00:00

导读：要基于现有基础逻辑功能进行优化或改造，我们必须先要知道他原始设计的初衷，才能尽可能得避免动到其潜在的关联逻辑以及功能点优化时的合理性，在原始方案上进行推翻、优化、回退或消亡。那么，如何了解现有功能背后的需求点呢？一起来文中看看吧~

昨夜北风吹尽寒，执笔不见深思来。

又到了新的季节点，最近脑袋中总是出现一团黑黑的乱麻，就像似在白纸上用黑色铅笔不断搅动的涂鸦，理不清剪不明的感觉，这种感觉在处理需求时尤为强烈。

经常遇到一些功能，在换了一个又一个接手的人时，曾经的逻辑与需求追溯已不可见，只留下一个躯壳平静的躺在软件里，在产品长河中也会时不时有人拿出来又将其继续优化，然后变成如今的模样，多次优化下来，初始的需求已经不可见。

基于现有基础逻辑功能进行优化或改造，我们必须先要知道他原始设计的初衷，才能尽可能得避免动到其潜在的关联逻辑以及功能点优化时的合理性，在原始方案上进行推翻、优化、回退或消亡。

那么如何找到曾经的需求场景呢，历史追溯通过文档总是可以从现有零星的记录中追溯到70~80%的内容，可见文档信息保存与共享的重要性。

一、从需求工具中追溯功能点和提出对象

在需求处理工具中，我们常常使用5W1H描述我们的需求，一对一的需求里都尽可能详细的描述了需求的来源、使用者、场景及期望实现的内容，一个需求不见得特别的有说服力，所以我们会横向对比，从通用化场景中获取对应的需求并证明其有效性，故我们在进行修改时需要考虑到之前的需求存在的设计逻辑及其衍生内容，能根据类别搜索对应的模块及功能点最好。

但是并非每一个需求都会被采纳，关闭时的原因也是可以作为一个可参见的意见，判断当时未做以及推断出现在又被提出的原因。如果一个需求被多次提出且非同一客户提出的，那么他的场景在一定情况下是可信的。如果在现有方案无法满足的情况下，技术方案即使较大改动，也是应该参考入内的。

此外，非常个性化的定制如果也能从它指定行业中剥离出标准的一方面，那么其实也可以做到复用。

比如生鲜、冷饮、食品等运输的存储要求和服装、图书等类目区别较大，但是依旧可以从多家生鲜中获取共同点取名为该行业的软件特性作为通用性功能，当后续有类似项目进来之后，也能大致满足他的基本需求，这样便能大大节省了重复梳理的时间，提高效率。

然而，也是因为这样的做法，后来者接手时，就需要整理之前的需求与场景，才能尝试着是否能改动到。需求处理工具较为实在，能够清晰的描述出功能点的前置条件、后置条件、逻辑限制、业务流程等，比较适合1：N迭代的（在0到1的时候，需求点可能较为粗糙），但是这样却也有可能打破了整体的数据流转，仅限于局部内容，且不同产品经理风格不一，在描述时未必能那么详尽。

所以在产品改动时，若是能即时更新，在整体上增加描述对应的逻辑，那对后来者会更为友好。软件随着不断迭代会更为笨重，前期设定的功能和技术框架，如果扩展性跟不上的话，那么发挥的空间也会极为有限。所以处于中间阶段的需求，需要考虑到承上启下。

二、亲自跑完现有软件的功能流程和细节

既然处于迷糊阶段，看到需求无法下手，就尽量先将软件逻辑整明白，亲自将现有的软件功能亲自跑一遍，作为文档描述不够详尽的补充。不管历史如何变化，功能总是以当下的功能最为准确。想象你是你的客户，作为一位没接触过该系统的人员，你在执行作业时，是否能够顺畅理解该功能，这个功能是否能够解决了你的痛点。易用性总是客户满意度最高的一个吸引点，有些软件功能隐藏的很深，有些配置限定太死，在初次接触软件常常会把自己弄的很痛苦。

后续软件的优化点，诘取某一部分进行研究时，可以综合软件实操与反馈同步进行，明确方案的目的，分别可从总体的功能、产品架构列举，从细分的流程、使用者画像进行描述，从市场定位和功能比对中记录不同，从同个功能不同方案的枚举众比较，才能更好的了解现有软件的不足，将复杂的需求转变成简易的流程，可谓是智者见智了。

三、与人讨论，头脑风暴

不管是产品老人还是研发老人，从讨论中都是能窥探出些许设计逻辑的，后台代码是最有说服力的工具，代码注释挺重要的。另外，测试同事有不断给软件试错的用例中对不同的功能触点，测试用例也是很不错的一个参考文件。

四、分析客户本身及上下游对接

如果能从所提需求引络出其他的痛点，当获得充分信息时，大概也就能知道该需求是否能够去满足了。

经常说到要深入需求的核心，不拘于浅层，一般是指客户提出一个需求仅仅是针对当下这种情况而提出的问题，深入点就是需要理解出为什么他会出现这个问题以及这个问题的有效性，再深入点就是客户日常作业时所涉及的方方面面，问题出现的频率以及真实的、全面的、客观的场景，分析客户本身业务以及他上下游是如何进行对接和过渡的，以至于我们可以提供多种备选方案。

虽然也有很多需求就是为了满足某一个简单的想法而已，深挖倒也是大可不必了，这种一般是用户体验型的需求。

五、产品架构图

从整体的视角去看软件也可能事半功倍，模块间的数据流动体现在应用层面的具体表示。看着每家公司给出的产品架构图都十分相似，看不出“端倪”，这里的架构图不建议看别人画，而是自己画的，加深理解，可以加上一点自己的“个性”，才能将整个行为进行闭合，总-分-总的方式百试百灵。

六、上线跟踪

跟踪上线后的使用情况，能证实该需求是否存伪，用的话是否用的顺畅，不用的话原因是什么，业务调整还是未达预期，若是未达预期那么可能开始的方向就错了。

写在最后，当我们处理需求的时候，常常考虑到他的开发量、各种投入产出比、用户性格、收益率等等，但这些顾虑也有可能固化了我们的思考，从而记不得我们为用户解决问题的初衷了。衡量取舍好像已经是各大公司产品经理取之有道的共识了，不过还是想说，若可行，先行莫后折，易折为假，继续摸索吧。

本文由 @谢星星原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。

给作者打赏，鼓励TA抓紧创作！

如何了解现有功能背后的需求点