产品经理提需求时要考虑的 15 个隐性需求

虽然世界充满未知的变化,但是有一些大的方向还是可以把握的,本文跟大家谈谈产品经理提需qiú时要考虑的 15 个隐性需qiú,enjoy~

俗话说,计划赶不上变化快,无论需qiú文档做得如何细致,考虑得如何周全,总会有些难以预料的需qiú变更在每天困扰着我们。开发人员苦恼,产品运营人员更苦恼,毕竟谁也不愿意捂着脸一遍一遍地qiú人改需qiú。

但是,虽然世界充满未知的变化,但是有一些大的方向还是可以把握的,无论是产品运营还是开发人员,都可以在需qiú确立以及需qiú评审时多多考虑一下姬小光说的这些方面,相信一定可以减少一些后期的变更成本。

下面这些内容主要是从开发人员的视角考虑的,多数基于姬小光的个人经验,难免有失偏颇,不当之处还望指正。当然,如不嫌弃,感兴趣的产品和运营人员也可以稍作参考。

1. 细节变更需qiú

在项目初期,如果产品人员没有想清楚需qiú的细节,那么细节的变更可以说是无fǎ避免的。那么作为开发人员唯一能做的就是,在设计程序结构和逻辑的时候,尽量预留出可扩展的能力。比如模块的增册刂,字段的增减,页面样式的微调等,除此之外也没什么好办fǎ了。别灰心,这都不是事儿。

2. 跨平台需qiú

跨平台需qiú有时候来的非常隐蔽,往往最初规划的时候感觉可以先在一个平台尝试一下,比如先规划了 PC 端,但是 PC 端的某些功能又会忽然很急促的想移植到移动端。

而需qiú人员往往会想当然的认为,功能差不多,只要挪一下就可以了(平移过去/拼过去)。或者是,页面长的差不多,就改成移动端的大小就可以了(缩一下)。殊不知各个平台无论在架构部署,还是cāo作体验上都有着天壤之别,如果不提前规划好,那必然是个大坑。

3. 扩展需qiú

无论是什么样的X,随着X量的增长,以及产品运营人员X的X,都会催生出各种扩展需qiú。任何固定数量的,都会增加。任何单一需要的,都会变成多个。

比如页面上设计了三个商品推荐位,就要预留出变成六个、九个,甚至分页的能力。一个接口是给某个X专用的,某天就可能变成通用的。一个简单的静态页面,某天就可能变成附带管理X的复杂系统。对于扩展性需qiú,要反复确认,不X度优化,但也要留出合理的扩展空间。

4. 异常liú需qiú

异常liú需qiú往往容易被忽略,或者多有疏漏。常见的异常liú有图片数据加载不出,图片不存在,接口挂掉,网速慢,未登录,登录态丢失,查询出错,查询无数据,内容溢出,用户输入溢出,用户输入非fǎ,视觉遮挡不可用等等等等。

那么,对应这些异常liú情况,就要有配套的前端提示给用户,引导用户进行其他cāo作。这些异常liú往往会在设计稿和文档中遗漏掉,比如各种异常提示浮层,需要登录态的cāo作,结果登录态丢失等等,都需要有对应的引导。

5. 内容运营需qiú

所有静态的内容,都可能变成运营需qiú。静态广告位可能变成轮播广告位,轮播广告位可能变成需要运营X填写数据,而不是直接写sǐ在页面里。或者某一天可能变成从另外一个自动数据源拉取数据。

关于内容运营需qiú,评审初期可以确认好运营频次,如果是个把月才改一次的,几乎不耗人力的,那也没必要都搞工具。但是如果每天改一次,或者感觉运营内容的时间已经影响到正常的工作,或者远远大于写个工具的时间,那还是老老实实开发个运营工具吧。

6. 内容校验需qiú

上面既然说到运营工具了,那么作为运营工具一定是由运营人员自己来填写。既然是非技术人员填写,cāo作就难免要X一点,或者说非技术一点,尽量cāo作简洁,并且可以校验输入。如果因为运营人员多打了个空格,或者多写了个英文逗号系统就挂了,那应该算谁不尽责呢?

还有,能分别运营的字段要分别运营,因为有的时候虽然内容看上去是合在一起的,但是经常会有部分修改的需qiú,不如分开两个字段。比如广告位链接和埋点 tag,链接可能经常换,但固定位置的 tag 值就不会换,所以分开运营会好一些。

7. 内容复用需qiú

运营同学的工作是很辛苦的,设想一下每天一边开着 excel ,一边开着你的运营系X个字段一个字段填写的时候,就知道画面有多美了。所以,运营填写的数据一定是有复用需qiú的。

比如 h5 页面上运营的数据,有可能还需要给原生 app 使用,甚至给 pc 端也用一套数据。一个广告图片和链接,可能X入到多个页面的顶部或底部,一起更新。多多沟通复用需qiú,可以随手拯救一X运营妹子。

8. 内容X需qiú

既然运营妹子这么不容易,那么工作量 KPI 如何衡量呢?这么辛苦再没人知道不是太惨了?所以,运营的数据一般是要有X的。

如果就一个坑位,每次都改掉内容来更新,上一次的就没了,那么鬼知道我一天改了多少次?一周做了多少次更新?当然,这里更偏向工具类的需qiú了,不过我重点要说的是,有运营需qiú,就可能有运营的X记录需qiú。

9. 排序&打标需qiú

排序需qiú其实也是内容运营需qiú的一种,无论是运营填写的还是自动拉取的内容,永远都会有调整顺序的需qiú。不同的坑位对应不同的关注度,不同的视觉焦点,浏览路径。运营往往需要X调整位置或者加些标记来突出某些内容。

比如商品列表,可能近期有几个商品比较好mài,就挪到前面,打上 hot 或者 new 的标记,从而促成更多的销量。对于排序和打标需qiú,往往从X开始就要预留可扩展字段,到前端也要可以方便的调整位置和加 icon 标记才行。

10. 筛选需qiú

对应于排序和打标,筛选也是经常用到的。比如我搜集了一坨数据,又只想挑一部分来展示,这时候往往需要一个可以方便cāo作的地方,类似帖子加精,评论置顶等等。商品类的数据筛选需qiú就更多啦,不过一般可以集成在搜索功能中,作为通用接口X。但是,运营同学手动填写的数据再进行筛选,那功能就只能X侧自己设计了,可以根据需要增加不同的筛选字段供运营同学填写。

11. 数据统计需qiú

数据统计需qiú是很容易失控的一种需qiú,产品运营最初往往觉得我要个 PV UV 啥的就够用了,过几天可能说能不能统计下这个按钮的X量,再过几天可能恨不得把所有的cāo作都埋点,再加X问路径、X路径、转化率、蹦失率、页面停留时间、X热图、鼠标轨迹……再给我出个月度季度报表,趋势图等等。

这里,对于数据统计需qiú一定要评审时梳理好,甚至我觉得可以X于正常的需qiú,作为单独的数据统计需qiú整体梳理后提出。

12. 翻旧账需qiú

我实在找不到更贴切的词汇了。翻旧帐的意思就是,凡事进到我系统里的数据,都希望有个方便的形式可以看到。比如用户创建的 UGC,一定要有个唯一的地址可以看到这个资源。用户录入的信息,要有个方便的地方可以导出,或者下载 excel。即使当前的需qiú不需要你展示X记录或者以前的任何内容,也要预留出方便的查询接口备用。

13. 报销需qiú

这个有点诡异,报销关我鸟事?

当然关。许多大X的报销liú程都很严格,毕竟是涉及到钱的问题。那么对于涉及到钱的活动来说,唯一的凭据可能就是你数据库里的数据了。所以有关钱的需qiú,最好开始就确认好报销需要哪些内容,比如用户的XX等等(确认是真人参与活动,没有X),以此来作为最终报销的凭据,否则就只能运营同学自己X了。

14. 扩容需qiú

当X量稳步上升时就会伴随着扩容的需qiú,尤其当访问量骤增的时候,快速扩容就迫在眉睫了。扩容包hán很多方面,一些性能方面的问题会在高并发史迅速凸显,比如:查询低效,PHP慢速,无静态化 web,并发压力大等等。

此时关于性能优化的一切知识都可以派上用场了,静态化、缓存、查询优化、锁表等等。而机器扩容也没那么简单,除了机器内容的复制还有相应X的批量启动,定时任务的执行,曰志的归集等等。

所以,如果评估时预计X会有bào发性增长(如微信活动),在资金允许的情况下不妨多准备些机器,总比一发布就挂了强。

15. 安全需qiú

这一点放到了最后,同样也是最重要的。安全问题包hán的范围非常广泛,虽然有X的同事负责安全以及运维相关的工作,但是在需qiú初期如果能稍微做些防范就会避免很多问题。一般的X都会有个基础的安全规范,比如如何防止 XSS, CSRF 攻击,如何防止 SQL X,如何X脚本攻击等。

还有一些外部接口需要鉴泉的,有时可能做了基本的鉴泉,确没有更高级的防护。比如一个人虽然登录了,可以看到自己的某些资料,但是如果这个登录的用户还可以X相同的接口查看其他人的某些信息,那就是安全问题了。有可能这个信息是存储在相对X的表中,并没有严格挂在这个用户id下,那么查询的时候就一定要再X一下数据和用户的对应关系。

对于安全需qiú,普通前X开发人员能做的其实并不多,能按部就班做好这些基础防护就不容易了。加上X公共的安全扫描平台,基本上可以杜绝绝大部分安全问题了。之所以写到这里单独列一条,还是希望大家要对安全足够重视。

综上所述,绝大部分的隐性需qiú都是有迹可寻的。然并卵,即便沟通再明确,邮件再确认,改来改去啪啪啪打脸,该做的需qiú还是要做,所以,节哀吧。

收藏 (0) 打赏

以上内容不错,打赏支持一下!

打开微信/支付宝扫一扫,即可进行扫码打赏哦,分享从这里开始,精彩与您同在
点赞 (0)

声明:本站所有教程资源,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。

雄发创业网 自媒体是如何赚钱的 产品经理提需求时要考虑的 15 个隐性需求 https://www.xiongfawang.com/3835.html

常见问题

相关文章

产品经理提需求时要考虑的 15 个隐性需求-海报

分享本文封面