如果让你接手一个老旧的软件系统,你会如何做好需求?作者结合相关案例,谈谈自己的做法,一起来看看吧。
作为互联网产品设计人员,在工作中碰到最多的问题之一:如果让你接手一个老旧的软件系统,你会怎么去把需求做好?今天来详细谈谈我的案例。
先复盘一下我之前的经历,我曾经接手过多个旧系统,其中2个旧的软件系统有印象,比如14年贵金属交易系统,22年智慧工地老系统。
在14年左右,我刚入行产品岗位,从运营转到产品部门,我的第一个任务就是优化移动端和PC端贵金属的注册流程。刚开始我以为挺简单,但入手后就碰到一堆问题,这个有点让我措手不及,后面输出第一版需求就被领导否决了,领导当时说你只了解表面,没有了解里面的业务关系。然后给我一点思路,后面根据领导指示和自己的理解花了2天完成任务。其实我做了三步:
1)第1天熟悉贵金属里面的大概逻辑,核心业务流程,这是打基础。
2)第2天正式开始,首先换位思考一下,如果你是客户,当要开户时你的需求是什么,肯定是注册越简单越好,容易操作。所以围绕这个思路可以展开工作,比如注册流程的字段能不显示就不显示,能放后端就不要放前端,这是一点。第二点页面要让客户看的懂自己要做什么,比如第一视觉要让用户明白自己要怎么做,有几步,要填什么信息,另外提交后反馈,有些需要审核,有些是秒通过,这个取决于客户的用户注册时的L等级。
3)最后就是细节问题,如提示密码问题,入口问题、体验还有显示位置的问题。然后输出到文档即可。这个回想起来其实是产品入门时最简单的需求。
第二个优化项目是22年智慧工地(老)系统优化,这个是我应该见过最复杂的系统。当时接手时难度较大,功能点多达几百个
1)了解底层的业务需求,因为任何一个软件系统其目的主要是实用,如果解决不了用户的需求,再高大上的系统也是鸡肋,所以明白这一点,就要从业务需求着手。建议采访提需求的业务人员,了解需求的动机,多思考一下系统给谁用的,解决了什么问题。
2)在了解业务需求的基础上,建议画一个思维导图,折分不同的业务流程,然后全都跑一下流程。当你熟悉该业务以后,再进行标记。当然这个过程有点麻烦,而且有的不一定有这个条件。比如我之前就是在测试环境时发现全是BUG,而且帐号也不一定有相关的测试数据,串联不起来,针对这个问题我分3步走,1是让开发修复,2是要帐号,3如果都不行,只能在生产上跑,不过要注意制造的数据不能影响到系统稳定。
熟悉功能模块也有顺序,建议是优先熟悉底层的架构功能,然后是流程,最后是内容。比如
3)第2步中,非必要的流程建议工作闲暇时间完成,而必要的需求建议采用紧急的方法,比如可以问一下熟悉业务客户,或者内部测试或研发人员,这样更能把握需求的痛点,对设计的需求业务合理化,逻辑正确化提供帮助。
作者:平心而论,公众号:书海顿悟
本文由 @平心而论 原创发布于人人都是产品经理,未经许可,禁止转载
题图来自 Unsplash,基于 CC0 协议
该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。