第二章 项目启动与需求分析：需求收集方法、干系人访谈技巧、现有界面审计清单
界面移植这件事，说白了就是「把旧房子里的家具搬到新房子，还得保证每件东西都能用」。我见过太多团队上来就开干，结果搬到一半发现沙发进不了门，或者插座位置全不对。嗯，这就是需求分析没做透的后果。
这一章，我们聊聊怎么把「搬家具」这件事规划清楚。核心就三块：怎么收集需求、怎么跟人聊透、怎么给现有界面做体检。
需求收集方法：别只盯着「用户说」
我个人习惯把需求收集分成三个层次。你想想看，用户告诉你的，往往只是冰山一角。
| 层次 | 方法 | 典型产出 |
|---|---|---|
| 显性需求 | 问卷、访谈、用户反馈 | 功能清单、优先级列表 |
| 隐性需求 | 行为观察、日志分析、A/B测试 | 用户路径图、痛点清单 |
| 潜在需求 | 竞品分析、趋势预判、技术推演 | 扩展性规划、技术债清单 |
我在项目中遇到过一件事：用户说「我要一个搜索框」，结果我们做了个功能完备的搜索组件，上线后使用率不到 5%。后来一查日志，发现用户真正需要的是「按最近使用排序」——他们根本不用搜，靠翻的。这就是显性需求骗人的典型案例。
干系人访谈技巧：聊出真东西
访谈这件事，很多人把它搞成了「审问」。你问一句，对方答一句，最后拿到一堆废话。我自己的访谈套路是这样的：
- 先破冰，再破题。 前 5 分钟聊点跟项目无关的，比如「最近业务忙不忙？」。让对方放松下来。
- 用场景代替功能。 别问「你需要什么功能？」，改问「你每天上班第一件事做什么？遇到什么问题？」。场景能带出真实需求。
- 追问细节。 对方说「这个页面太慢了」，你得追问「慢到什么程度？加载要几秒？你当时在做什么？」。模糊的描述背后往往藏着关键信息。
- 确认理解。 每聊完一个点，用自己的话复述一遍：「我理解你的意思是……对吗？」。这一步能避免大量返工。
访谈结束后，我习惯当天就把录音转成文字，然后画一张「干系人-需求-痛点」映射表。这样谁说了什么、谁在意什么，一目了然。
现有界面审计清单：给旧系统做个体检
审计现有界面，不是「打开页面看一眼就完事」。我有一套固定的检查清单，每次移植前都会跑一遍。
| 审计维度 | 检查项 | 常见问题 |
|---|---|---|
| 功能完整性 | 所有页面、弹窗、状态、异常流 | 遗漏边缘状态、隐藏功能 |
| 交互一致性 | 按钮位置、操作反馈、手势逻辑 | 同一操作在不同页面行为不同 |
| 视觉资产 | 图标、字体、颜色、间距、组件库 | 设计稿与线上不一致 |
| 技术债 | 依赖库版本、废弃 API、性能瓶颈 | 旧代码无法直接迁移 |
| 数据依赖 | 接口字段、数据结构、缓存策略 | 接口返回格式与新系统不兼容 |
审计的时候，我建议你打开浏览器的开发者工具，把 Network 面板和 Console 面板开着。很多问题在界面上看不出来，但网络请求和报错信息会告诉你真相。
下面这张图，是我每次做界面审计时用的流程框架。它帮我把「从打开页面到输出报告」这件事结构化。
审计报告写完后，我建议你做一个「风险热力图」。把每个模块的移植难度标出来：绿色是低风险，黄色是中风险，红色是高风险。这样项目排期的时候，大家一眼就能看出哪里需要多留时间。
需求分析阶段，最怕的就是「我以为」。你以为理解了需求，你以为界面很简单，你以为技术债不多。嗯，这些「以为」最后都会变成加班和返工。所以，多问、多看、多记，把每一件小事都落在文档上。这才是系统化移植的第一步。