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

（图片来源网络，侵删）