谢星星|如何了解现有功能背后的需求点( 二 )_特斯拉|ff|市值|总市值|oem|mod

后续软件的优化点，诘取某一部分进行研究时，可以综合软件实操与反馈同步进行，明确方案的目的，分别可从总体的功能、产品架构列举，从细分的流程、使用者画像进行描述，从市场定位和功能比对中记录不同，从同个功能不同方案的枚举众比较，才能更好的了解现有软件的不足，将复杂的需求转变成简易的流程，可谓是智者见智了。
三、与人讨论，头脑风暴不管是产品老人还是研发老人，从讨论中都是能窥探出些许设计逻辑的，后台代码是最有说服力的工具，代码注释挺重要的。另外，测试同事有不断给软件试错的用例中对不同的功能触点，测试用例也是很不错的一个参考文件。
四、分析客户本身及上下游对接如果能从所提需求引络出其他的痛点，当获得充分信息时，大概也就能知道该需求是否能够去满足了。
经常说到要深入需求的核心，不拘于浅层，一般是指客户提出一个需求仅仅是针对当下这种情况而提出的问题，深入点就是需要理解出为什么他会出现这个问题以及这个问题的有效性，再深入点就是客户日常作业时所涉及的方方面面，问题出现的频率以及真实的、全面的、客观的场景，分析客户本身业务以及他上下游是如何进行对接和过渡的，以至于我们可以提供多种备选方案。
虽然也有很多需求就是为了满足某一个简单的想法而已，深挖倒也是大可不必了，这种一般是用户体验型的需求。
五、产品架构图从整体的视角去看软件也可能事半功倍，模块间的数据流动体现在应用层面的具体表示。看着每家公司给出的产品架构图都十分相似，看不出“端倪”，这里的架构图不建议看别人画，而是自己画的，加深理解，可以加上一点自己的“个性”，才能将整个行为进行闭合，总-分-总的方式百试百灵。
六、上线跟踪跟踪上线后的使用情况，能证实该需求是否存伪，用的话是否用的顺畅，不用的话原因是什么，业务调整还是未达预期，若是未达预期那么可能开始的方向就错了。
写在最后，当我们处理需求的时候，常常考虑到他的开发量、各种投入产出比、用户性格、收益率等等，但这些顾虑也有可能固化了我们的思考，从而记不得我们为用户解决问题的初衷了。衡量取舍好像已经是各大公司产品经理取之有道的共识了，不过还是想说，若可行，先行莫后折，易折为假，继续摸索吧。
本文由 @谢星星原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议。