TMD,临时需求又来了

本文作者:Kevin      公众号:Kevin改变世界的点滴

本文由PMTalk专栏作者:Kevin      原创发布于PMTalk产品社区,未经许可,禁止转载。


产品上面临上线倒计时,产品经理内心都在祈祷一切顺利,除了默默的每日等待发版本,产品经理心理的话最多或许是下面几句.......


“终于上线了!”


“改变世界的日子终于来了”


“不说了,分分钟用户上万”


“老板是不是该考虑给我加薪了


.......



就在上线前最后一周,boss找到小张:“这里有一个XX功能,你再加上吧”


上线时间不变的情况下,又多了一个功能。


产品小张心理:“what fuck x%^@!"


能不能换种解决办法?


除了上面背后唧唧歪歪说一通,产品经理可以考虑当前是否只有一种解决办法,如果是“一定要开发、一定要设计吗?“




以体验与需求满足来罗列两点。每个需求都希望能够达到体验好、并且需求也能满足。


但所需要的资源或时间是最长的


如果需求成为体验差、需求满足,则这样的时间与资源占据最小


其他两方面都是不可实行的方案,因为都是需求未满足。


以问卷为例,在产品中我们需要用户回答问卷。但针对问卷又两种方案


第一种是在app用户登录注册后填写问卷(原生)





第二种是在消息通知的情况下,给予问卷链接,用户进入链接即可回答问卷




两种方案对比,第二种方案不需要UI设计。可依靠前端直接开发即可,并且也不需要增加单独的UI入口.用http:xx....这样的链接即可。



类似上图中,在消息盒子中插入链接即可。用户收到消息即可填写问卷


开发难度的评估


产品经理,在对收集的需求应该建立简单难度评估机制。比如上面说的问卷需求,其实如果要去是做在app中,他的难度就需要牵涉客户端与服务端。


在app还没上线前,客户端本来就忙的做其他模块的搭建,再加上一个临时需求明显资源会更加却紧。


合理的评估开发团队中所面临的工作量,将需求有目的的调整为资源轻松的开发同学上,无意可以加快项目上线的进度。


针对需求中涉及的系统需求。比如新增的预约系统、XX模块管理系统。考虑是否产生与先用模块的关联。如果产生关联是否要增加对应的修改或接口添加。




比如支持原生app的页面,如果要支持web。后台接口就需要重写,支持web端展现。那么UI设计稿是同一张。



Talking

发表