当前位置:首页 > 天道酬勤 > 正文内容

具体什么需求(客户需求背后的需求)

张世龙2021年12月20日 19:10天道酬勤370

导言:要根据现有的基本逻辑功能进行优化或改造,要尽可能避免优化其潜在的相关逻辑和功能点时的合理性,要推翻、优化、后退或消灭原方案,要知道他的原设计的初衷那么,如何理解现有功能背后的需求点呢? 一起看看文章吧~

昨晚北风吹走了寒冷,写作未能深入思考。

到了新的季节,最近脑子里总是出现黑色的错乱,就像白纸上用黑色铅笔不停地乱涂乱画一样,清晰切不完的感觉特别在处理需求时强烈。

根据功能的不同,接手的人不断变化的时候,看不到曾经的逻辑和需求的跟踪,只剩下一个肉体静静的躺在软件里,在产品中偶尔有人拿出来继续优化,变成现在的样子,多次优化。

要根据现有的基本逻辑功能进行优化或改造,必须尽可能避免相关逻辑和功能点优化时的合理性,要推翻、优化、后退或消灭原方案,必须知道他原设计的初衷。

那么,你是如何发现曾经的需求场景的呢? 历史追踪通过文档总是可以从现有的理发记录追溯到70~80%的内容,由此可见保存和共享文档信息的重要性。

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

需求处理工具经常使用5W1H来说明我们的需求。 一对一的需求中尽可能详细地记述了需求的来源、使用者、场景、想要实现的内容。 一个需求并不一定特别有说服力,所以横向比较,从通用化的场景中获取对应的需求,证明其有效性。 因此,在进行修正时,要考虑以前的需求存在的设计逻辑及其派生内容,根据类别将对应的模块

但是,并不是所有的需求都被采用,关闭时的原因也作为可以参考的意见,是当时还没有完成,又被判断为出现了的理由。 如果一个需求多次被提出,由一个顾客提出,那么他的场景在一定情况下是可靠的。 现有方案不能满足的情况下,技术方案即使有很大变更也值得参考。

另外,非常定制化的定制,如果能够从其指定行业剥离标准的侧面,实际上也可以重复使用。

例如,生鲜、冷饮、食品等运输的储存要求与服装、图书等类别有很大不同,但仍然可以从很多生鲜中获得共同点,将其行业的软件特性作为通用功能,在后续的类似项目进入后也基本满足了需求,

但是,由于这样的做法,当后来的人交接时,需要整理前面的需要和场景,尝试是否可以进行变更。 需求处理工具现实,能明确描述功能点的前置条件、后置条件、逻辑限制、业务流程等,适合1:N迭代(0到1的情况下,需求点可能会变粗糙),但由此导致整体数据流崩溃,局限于局部内容。

所以,如果在产品变更时,能够及时更新,描述整体对应的逻辑,会对后来者更好。 软件随着世代的增长而变得越来越沉重,如果可扩展性跟不上,预设的功能和技术框架所能发挥的空间也非常有限。 因此,有必要考虑处于中间阶段的需求会从上到下继承。

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

处于混乱阶段,看到需求捉襟见肘,尽量先整理软件逻辑,自行运行现有的软件功能,作为文档的描述不够补充。 不管历史如何变化,功能总是现在的功能最正确。 想象一下你是客户。 作为没有接触过这个系统的人,在执行作业时,是否能够顺利地理解这个功能,这个功能是否能够解决你的痛处。 易用性一直是顾客满意度最高的吸引点,有些软件功能隐藏得很深,有些配置有限,第一次接触软件经常会折磨自己。

后续软件的优化点可以在追问某一部分进行研究时,将软件的实际技术和反馈综合起来同时进行。 明确计划的目的,分别从整体功能、产品架构进行列举,从细分的流程、使用者图像进行描述,从市场定位和功能的比较中记录不同,从相同功能的不同计划的列举中进行比较,从而更好地理解现有软件的不足。 可以说是智者的智慧。

三、与人讨论,头脑风暴

无论是产品老人还是研发老人,都能从讨论中窥见设计逻辑。 背景代码是最具说服力的工具,代码注释非常重要。 另外,测试同事在软件不断试错的用例中有不同功能的接触点,测试用例也是很好的参考文件。

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

如果能从提示的需求中引出其他的痛点,在得到充分的信息时,也许就能知道是否能满足该需求。

虽然说要经常挖掘需求的核心,但是不拘泥于浅显的东西,一般来说,客户提出一个需求只是为了应对当前的情况,深入来看,为什么他会出现这个问题,以及这个问题进一步深入,分析客户日常工作涉及的各个方面、问题发生的频率、真实、全面、客观的场景,分析客户自身的业务和他的上下游是如何对接和迁移的,提供了多种选择

虽然也有很多满足某个单纯想法的需求,但深入挖掘也是可以的。 这就是这种常见的用户体验型需求。

从整体角度来看,

五、产品架构图

软件也有可能完成更多工作,模块之间的数据

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

六、上线跟踪

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

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

本文由 @风中的黑猫 原创发布于人人都是产品经理,未经作者许可,禁止转载。

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

扫描二维码推送至手机访问。

版权声明:本文由花开半夏のブログ发布,如需转载请注明出处。

本文链接:https://www.zhangshilong.cn/work/25820.html

标签: h1
分享给朋友:

发表评论

访客

看不清,换一张

◎欢迎参与讨论,请在这里发表您的看法和观点。