导言：要根据现有的基本逻辑功能进行优化或改造，要尽可能避免优化其潜在的相关逻辑和功能点时的合理性，要推翻、优化、后退或消灭原方案，要知道他的原设计的初衷那么，如何理解现有功能背后的需求点呢？ 一起看看文章吧~
昨晚北风吹走了寒冷，写作未能深入思考。
到了新的季节，最近脑子里总是出现黑色的错乱，就像白纸上用黑色铅笔不停地乱涂乱画一样，清晰切不完的感觉特别在处理需求时强烈。
根据功能的不同，接手的人不断变化的时候，看不到曾经的逻辑和需求的跟踪，只剩下一个肉体静静的躺在软件里，在产品中偶尔有人拿出来继续优化，变成现在的样子，多次优化。
要根据现有的基本逻辑功能进行优化或改造，必须尽可能避免相关逻辑和功能点优化时的合理性，要推翻、优化、后退或消灭原方案，必须知道他原设计的初衷。
那么，你是如何发现曾经的需求场景的呢？ 历史追踪通过文档总是可以从现有的理发记录追溯到70~80%的内容，由此可见保存和共享文档信息的重要性。
一、从需求工具中追溯功能点和提出对象
需求处理工具经常使用5W1H来说明我们的需求。 一对一的需求中尽可能详细地记述了需求的来源、使用者、场景、想要实现的内容。 一个需求并不一定特别有说服力，所以横向比较，从通用化的场景中获取对应的需求，证明其有效性。 因此，在进行修正时，要考虑以前的需求存在的设计逻辑及其派生内容，根据类别将对应的模块但是，并不是所有的需求都被采用，关闭时的原因也作为可以参考的意见，是当时还没有完成，又被判断为出现了的理由。 如果一个需求多次被提出，由一个顾客提出，那么他的场景在一定情况下是可靠的。 现有方案不能满足的情况下，技术方案即使有很大变更也值得参考。
另外，非常定制化的定制，如果能够从其指定行业剥离标准的侧面，实际上也可以重复使用。
例如，生鲜、冷饮、食品等运输的储存要求与服装、图书等类别有很大不同，但仍然可以从很多生鲜中获得共同点，将其行业的软件特性作为通用功能，在后续的类似项目进入后也基本满足了需求，
但是，由于这样的做法，当后来的人交接时，需要整理前面的需要和场景，尝试是否可以进行变更。 需求处理工具现实，能明确描述功能点的前置条件、后置条件、逻辑限制、业务流程等，适合1:N迭代(0到1的情况下，需求点可能会变粗糙)，但由此导致整体数据流崩溃，局限于局部内容。
所以，如果在产品变更时，能够及时更新，描述整体对应的逻辑，会对后来者更好。 软件随着世代的增长而变得越来越沉重，如果可扩展性跟不上，预设的功能和技术框架所能发挥的空间也非常有限。 因此，有必要考虑处于中间阶段的需求会从上到下继承。
二、亲自跑完现有软件的功能流程和细节
处于混乱阶段，看到需求捉襟见肘，尽量先整理软件逻辑，自行运行现有的软件功能，作为文档的描述不够补充。 不管历史如何变化，功能总是现在的功能最正确。 想象一下你是客户。 作为没有接触过这个系统的人，在执行作业时，是否能够顺利地理解这个功能，这个功能是否能够解决你的痛处。 易用性一直是顾客满意度最高的吸引点，有些软件功能隐藏得很深，有些配置有限，第一次接触软件经常会折磨自己。后续软件的优化点可以在追问某一部分进行研究时，将软件的实际技术和反馈综合起来同时进行。 明确计划的目的，分别从整体功能、产品架构进行列举，从细分的流程、使用者图像进行描述，从市场定位和功能的比较中记录不同，从相同功能的不同计划的列举中进行比较，从而更好地理解现有软件的不足。 可以说是智者的智慧。
三、与人讨论，头脑风暴
无论是产品老人还是研发老人，都能从讨论中窥见设计逻辑。 背景代码是最具说服力的工具，代码注释非常重要。 另外，测试同事在软件不断试错的用例中有不同功能的接触点，测试用例也是很好的参考文件。
四、分析客户本身及上下游对接
如果能从提示的需求中引出其他的痛点，在得到充分的信息时，也许就能知道是否能满足该需求。虽然说要经常挖掘需求的核心，但是不拘泥于浅显的东西，一般来说，客户提出一个需求只是为了应对当前的情况，深入来看，为什么他会出现这个问题，以及这个问题进一步深入，分析客户日常工作涉及的各个方面、问题发生的频率、真实、全面、客观的场景，分析客户自身的业务和他的上下游是如何对接和迁移的，提供了多种选择
虽然也有很多满足某个单纯想法的需求，但深入挖掘也是可以的。 这就是这种常见的用户体验型需求。
从整体角度来看，
五、产品架构图
软件也有可能完成更多工作，模块之间的数据 流动体现在应用层面的具体表示。看着每家公司给出的产品架构图都十分相似，看不出“端倪”，这里的架构图不建议看别人画，而是自己画的，加深理解，可以加上一点自己的“个性”，才能将整个行为进行闭合，总-分-总的方式百试百灵。六、上线跟踪
跟踪上线后的使用情况，能证实该需求是否存伪，用的话是否用的顺畅，不用的话原因是什么，业务调整还是未达预期，若是未达预期那么可能开始的方向就错了。
写在最后，当我们处理需求的时候，常常考虑到他的开发量、各种投入产出比、用户性格、收益率等等，但这些顾虑也有可能固化了我们的思考，从而记不得我们为用户解决问题的初衷了。衡量取舍好像已经是各大公司产品经理取之有道的共识了，不过还是想说，若可行，先行莫后折，易折为假，继续摸索吧。
本文由 @风中的黑猫 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议。